good, *current* online tutorial for capemgr for BBB?

[Robert P. J. Day]

i'm sure there are a number of these, but can someone recommend an
online tutorial on slots and capemgr for the BBB that's up-to-date for
the 3.12-whatever kernel? thanks.

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================

[Robert Nelson]

On Thu, Nov 7, 2013 at 1:54 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>
> i'm sure there are a number of these, but can someone recommend an
> online tutorial on slots and capemgr for the BBB that's up-to-date for
> the 3.12-whatever kernel? thanks.

The current guides for 3.8 should work, once "we fix" 3.12.. ;)

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

[Robert P. J. Day]

On Thu, 7 Nov 2013, Robert Nelson wrote:

> On Thu, Nov 7, 2013 at 1:54 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> >
> > i'm sure there are a number of these, but can someone recommend
> > an online tutorial on slots and capemgr for the BBB that's
> > up-to-date for the 3.12-whatever kernel? thanks.
>
> The current guides for 3.8 should work, once "we fix" 3.12.. ;)

ah ... for some reason, i thought something was changing between 3.8
and 3.12 in terms of device trees and the cape manager, but it's only
a matter of getting things to work as they did in 3.8? excellent.

[Robert Nelson]

On Thu, Nov 7, 2013 at 2:22 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
> On Thu, 7 Nov 2013, Robert Nelson wrote:
>
>> On Thu, Nov 7, 2013 at 1:54 PM, Robert P. J. Day <rpj...@crashcourse.ca> wrote:
>> >
>> > i'm sure there are a number of these, but can someone recommend
>> > an online tutorial on slots and capemgr for the BBB that's
>> > up-to-date for the 3.12-whatever kernel? thanks.
>>
>> The current guides for 3.8 should work, once "we fix" 3.12.. ;)
>
> ah ... for some reason, i thought something was changing between 3.8
> and 3.12 in terms of device trees and the cape manager, but it's only
> a matter of getting things to work as they did in 3.8? excellent.
> thanks.

I've had a few email reports of 'manually' loading the simple capes,
aka like the uart dtbo is working fine..

[Mike Bremford]

Not for me they're not! The UART DTBOs are not working correctly under 3.12: BB-UART1 creates /dev/ttyO2, not /dev/ttyO1 as it should. BB-UART2 and 4 are also incorrectly out by one, and UART5 doesn't load at all.

The UART DTBOs are definitely NOT working correctly under 3.12.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Robert Nelson]

On Thu, Nov 7, 2013 at 5:09 PM, Mike Bremford <mi...@bfo.com> wrote:
> Not for me they're not! The UART DTBOs are not working correctly under 3.12:
> BB-UART1 creates /dev/ttyO2, not /dev/ttyO1 as it should. BB-UART2 and 4 are
> also incorrectly out by one, and UART5 doesn't load at all.
>
> The UART DTBOs are definitely NOT working correctly under 3.12.

Eh, I kinda call that a win in my book, as they do enable a serial
port... Especially since I haven't had a chance to look into and fix
the cape stuff in 3.12.x yet...

[Mike Bremford]

Working for certain values of working ;-) Sadly I'm relying on all including UART5 on my home-designed cape, so I guess I'm back to 3.8 for a bit...

[sels...@gmail.com]

On Thursday, November 7, 2013 11:09:09 PM UTC, Mike Bremford wrote:

Not for me they're not! The UART DTBOs are not working correctly under 3.12: BB-UART1 creates /dev/ttyO2, not /dev/ttyO1 as it should. BB-UART2 and 4 are also incorrectly out by one, and UART5 doesn't load at all.

The UART DTBOs are definitely NOT working correctly under 3.12.

Actually, I suspect they're working just fine. See  https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am33xx.dtsi?id=dde3b0d64c3df7272082128133f0af592d7ac50f then compare to what's in your uart dts files.

On a related note, does anyone know where to find a reliable source, git tree preferably, for the various cape overlays ?  Pulling out of date versions from angstrom clearly isn't useful anymore. I've spent a couple of days hunting for useable with 3.12 uart,hdmi & emmc dts files and this thread is probably the closest thing I've found so far.

[Robert Nelson]

For "3.12" no one has taken the time. (i've been personally swamped
with other personal things these last few weeks, so haven't really
touched any kernel code..)

The master 3.8/capmger is here:
https://github.com/beagleboard/kernel/tree/3.8

just need to port the dts settings to:
https://github.com/beagleboard/kernel/tree/3.12

[Mike Bremford]

The .dtbo's distributed with Robert's 3.12 kernel binary exhibit the symptoms I described, but no I haven't compiled from DTS source (because I haven't been able to find them). That said: yep, that patch looks like the numbering system has changed for some reason - nice catch. Hopefully it's an easy fix.

--

[Mike Bremford]

Finally found the required changes to get UART1, 2, 4 and 5 loaded and numbered correctly under 3.12.

The source for the "capes" I was looking for (BB-UARTn) were created by this patch: https://github.com/beagleboard/kernel/blob/3.8/patches/not-capebus/0176-capes-Add-virtual-capes-serving-as-examples.patch, and it looks like the RS232 cape would need the same change. The file isn't in the 3.12 branch and I don't speak git so I've attached a patch for this patch (sorry) which fixes the UART and RS232 overlays.

If anyone just needs working DTS and DTBO files for BB-UART1, BB-UART2, BB-UART4 and BB-UART5 for kernel 3.12, I'm attaching them here as well in bb-uart-dts-312.tar.gz

[Bert Lindner]

On Wednesday, November 20, 2013 1:56:55 PM UTC+1, Mike Bremford wrote:

Finally found the required changes to get UART1, 2, 4 and 5 loaded and numbered correctly under 3.12.

The source for the "capes" I was looking for (BB-UARTn) were created by this patch: https://github.com/beagleboard/kernel/blob/3.8/patches/not-capebus/0176-capes-Add-virtual-capes-serving-as-examples.patch, and it looks like the RS232 cape would need the same change. The file isn't in the 3.12 branch and I don't speak git so I've attached a patch for this patch (sorry) which fixes the UART and RS232 overlays.

If anyone just needs working DTS and DTBO files for BB-UART1, BB-UART2, BB-UART4 and BB-UART5 for kernel 3.12, I'm attaching them here as well in bb-uart-dts-312.tar.gz

Thanks Mike!

-Bert

[sels...@gmail.com]

On 19/11/13 18:34, Mike Bremford wrote:
> The .dtbo's distributed with Robert's 3.12 kernel binary exhibit the symptoms I described, but no I haven't compiled from DTS source (because I haven't been able to find them). That said: yep, that patch looks like the numbering system has changed for some reason - nice catch. Hopefully it's an easy fix.

You can find the capes dts files in a recent angstrom image under /lib/firmware but there doesn't seem to be a proper source for them anywhere I can find, not knowing where angstrom gets them from leaves us in the difficult position of not really knowing where to send patches to.

[Dan Clapp]

[Bert Lindner]

On Wednesday, November 20, 2013 1:56:55 PM UTC+1, Mike Bremford wrote:

Finally found the required changes to get UART1, 2, 4 and 5 loaded and numbered correctly under 3.12.

The source for the "capes" I was looking for (BB-UARTn) were created by this patch: https://github.com/beagleboard/kernel/blob/3.8/patches/not-capebus/0176-capes-Add-virtual-capes-serving-as-examples.patch, and it looks like the RS232 cape would need the same change. The file isn't in the 3.12 branch and I don't speak git so I've attached a patch for this patch (sorry) which fixes the UART and RS232 overlays.

If anyone just needs working DTS and DTBO files for BB-UART1, BB-UART2, BB-UART4 and BB-UART5 for kernel 3.12, I'm attaching them here as well in bb-uart-dts-312.tar.gz

Just to confirm that all UARTs appear as expected on my BBB Rev. A5C running Robert's  Ubuntu 13.04 image with kernel 3.12.0-bone8.

I've tried the RX signals (with a GPS board), they all work apart from, for some reason, UART5/RX (P9/38). Not sure what the issue is there.

Thanks again, best,

-Bert

[William Hermans]

Bert, I have not looked but is there a pin conflict ? Perhaps with a emmc pin , or possibly hdmi ? If so and in the case of emmc I have been told that once booted, you *can* reclaim a few pins back from the eMMC. Then in the case of hdmi, if not used you can just disable it via uEnv.txt.

--

[Mike Bremford]

Yep, that's exactly what's happening. tl;dr summary is that HDMI isn't being disabled, although the capemgr (I presume) seems to think it is.

So: I have the HDMI overlays disabled in uEnv.txt: here's the relevant line:

   optargs=capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN

And this setup was working working fine under 3.8. Here's my state after boot

# cat /sys/devices/bone_capemgr.6/slots 

 0: 54:PF--- 

 1: 55:PF--- 

 2: 56:PF--- 

 3: 57:PF--- 

 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 6: ff:P-O-- Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV1

 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-I2C1

As you can see the HDMI virtual capes are not loaded. Now I load UART5:

# echo BB-UART5 > /sys/devices/bone_capemgr.6/slots 

No error: the overlay loads and I get a /dev/ttyO5, but it's quiet, and I see this in the logs:

[   74.569278] bone-capemgr bone_capemgr.6: part_number 'BB-UART5', version 'N/A'

[   74.569372] bone-capemgr bone_capemgr.6: slot #9: generic override

[   74.569402] bone-capemgr bone_capemgr.6: bone: Using override eeprom data at slot 9

[   74.569432] bone-capemgr bone_capemgr.6: slot #9: 'Override Board Name,00A0,Override Manuf,BB-UART5'

[   74.569589] bone-capemgr bone_capemgr.6: slot #9: Requesting part number/version based 'BB-UART5-00A0.dtbo

[   74.569621] bone-capemgr bone_capemgr.6: slot #9: Requesting firmware 'BB-UART5-00A0.dtbo' for board-name 'Override Board Name', version '00A0'

[   74.572522] bone-capemgr bone_capemgr.6: slot #9: dtbo 'BB-UART5-00A0.dtbo' loaded; converting to live tree

[   74.572840] bone-capemgr bone_capemgr.6: slot #9: #2 overlays

[   74.584829] pinctrl-single 44e10800.pinmux: pin 44e108c4.0 already requested by hdmi.7; cannot claim for 481aa000.serial

[   74.596454] pinctrl-single 44e10800.pinmux: pin-49 (481aa000.serial) status -22

[   74.604185] pinctrl-single 44e10800.pinmux: could not request pin 49 (44e108c4.0) from group pinmux_bb_uart5_pins  on device pinctrl-single

[   74.617410] omap_uart 481aa000.serial: Error applying setting, reverse things back

[   74.636557] of_get_named_gpio_flags: can't parse gpios property of node '/ocp/serial@481aa000[0]'

[   74.643806] 481aa000.serial: ttyO5 at MMIO 0x481aa000 (irq = 62, base_baud = 3000000) is a OMAP UART5

[   74.644534] bone-capemgr bone_capemgr.6: slot #9: Applied #2 overlays.

On a hunch I plugged in my HDMI monitor and I can see my console. HDMI is enabled. Although I've got a large wobbly green smudge, a result of my GPS which is hardwired to the same pins! I suppose if I could just interpret that I could figure out the position that way...

I'm not sure where to go from here. HDMI doesn't seem to be properly disabled: the OS thinks it is, and the capemanager lets me load the cape, but my screen still works (including fairly early during the boot process) and clearly the pinmux won't free the pins for the UART. I've booted with and without the cape, same result.

* If anyone else has disabled HDMI on kernel 3.12, try plugging in a monitor anyway. See anything?

* If anyone has any suggestions, please let me know, I'm happy to test them.

[sels...@gmail.com]

Robert, with all respect to some of the great work you do, those tree-of-patches things you've linked to are probably the biggest single roadblock to others, like me, helping out with some of this stuff.

For example, I was looking for UART related dts files, but I really wasn't looking under patches/dma for patches/dma/0034-ARM-dts-Add-UART4-support-to-BeagleBone.patch since it has nothing to do with dma. I've not found uart 1-3 or 5 yet!

Converting this stuff to a normal kernel git tree where the history and sequence is obvious and relevant would be a wonderful first step that I think would get more people interested in contributing. Or at least in sending fixes for the things they're interested in.

I have been trying to do it on and off, but the loss of the development history makes it difficult to untangle what pieces are needed. I sort of feel like the effort is wasted as long as the tree-of-patches approach continues, the 3.13 branch just rebases all the patches at a different point, minus the history, and I end up back at square one redoing the untangle.

[Robert Nelson]

On Mon, Nov 25, 2013 at 9:40 AM, <sels...@gmail.com> wrote:
> On 19/11/13 16:35, Robert Nelson wrote:
>> On Tue, Nov 19, 2013 at 10:06 AM, <sels...@gmail.com> wrote:
>>> On a related note, does anyone know where to find a reliable source, git
>>> tree preferably, for the various cape overlays ? Pulling out of date
>>> versions from angstrom clearly isn't useful anymore. I've spent a couple of
>>> days hunting for useable with 3.12 uart,hdmi & emmc dts files and this
>>> thread is probably the closest thing I've found so far.
>> For "3.12" no one has taken the time. (i've been personally swamped
>> with other personal things these last few weeks, so haven't really
>> touched any kernel code..)
>>
>> The master 3.8/capmger is here:
>> https://github.com/beagleboard/kernel/tree/3.8
>>
>> just need to port the dts settings to:
>> https://github.com/beagleboard/kernel/tree/3.12
> Robert, with all respect to some of the great work you do, those tree-of-patches things you've linked to are probably the biggest single roadblock to others, like me, helping out with some of this stuff.
>
> For example, I was looking for UART related dts files, but I really wasn't looking under patches/dma for patches/dma/0034-ARM-dts-Add-UART4-support-to-BeagleBone.patch since it has nothing to do with dma. I've not found uart 1-3 or 5 yet!

Sorry, i was just the backup for the 3.8 tree, i'd tell you to submit
a patch to fix it, but honestly 3.8 is in maintenance mode..

>
> Converting this stuff to a normal kernel git tree where the history and sequence is obvious and relevant would be a wonderful first step that I think would get more people interested in contributing. Or at least in sending fixes for the things they're interested in.

Well push the "git am'ed" KERNEL directory after running "./patch.sh"
to where ever you want..

>
> I have been trying to do it on and off, but the loss of the development history makes it difficult to untangle what pieces are needed. I sort of feel like the effort is wasted as long as the tree-of-patches approach continues, the 3.13 branch just rebases all the patches at a different point, minus the history, and I end up back at square one redoing the untangle.

"history" your forgetting a couple things, go look back at the 3.2 and
3.6/3.7 branches there are two former implementations of what we call
the capemanager that were rejected by mainline. (the current
implementation in 3.8 isn't in mainline either..)

idk, a few of use have been supporting the beagleboard.org project
with this 'rebase' technique since 2.6.27-ish, as we've always been
pulling in beta-not-for-mainline patchset's from random ti tree's just
to keep things working..

[rinze...@gmail.com]

 Could someone explain to me how to play the uartpatchpatch.gz to a 3.12 kernel. I am kinda new to Linux and need UART1 (ttyO1) working on a non 3.8 kernel for the beaglebone Black.

[Robert Nelson]

Start with the debian image here:

http://beagleboard.org/latest-images

cd /opt/scripts/
git pull
./tools/update_kernel.sh --beta-kernel

<reboot>

edit: /boot/uboot/uEnv.txt

changes "CAPE=" to "CAPE=ttyO1"

(not eMMC is disabled when you do that^ i need to fix that, so only
use the microSD image)