Cape Manager for U-Boot

GoogleGroups
1

Okay, second pass more things work, more corner cases to fix...

Here is the base u-boot patch, plus the cape manager:

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.01-rc2/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2017.01-rc2/0002-U-Boot-BeagleBone-Cape-Manager.patch

Probally lots of string handling bugs, found my self trying to write
everything in bash, yet it's C.. :wink:

So, the fun details of U-Boot:

U-Boot found the BeagleBone Serial Cape:

Board: BeagleBone Black
<ethaddr> not set. Validating first E-fuse MAC
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
/lib/firmware/BB-BONE-SERL-03-00A1.dtbo
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net: eth0: MII MODE

U-Boot loaded the BeagleBone Serial Cape overlay on top of the main dtb:

loading /boot/dtbs/4.4.39-ti-r77/am335x-boneblack.dtb ...
62069 bytes read in 135 ms (448.2 KiB/s)
debug: [uboot_overlay_addr1=/lib/firmware/BB-BONE-SERL-03-00A1.dtbo] ...
loading /lib/firmware/BB-BONE-SERL-03-00A1.dtbo ...
887 bytes read in 189 ms (3.9 KiB/s)
loading /boot/initrd.img-4.4.39-ti-r77 ...
5237762 bytes read in 466 ms (10.7 MiB/s)
debug: [console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONE-SERL-03 root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait coherent_pool=1M quiet net.ifnames=0] ...
debug: [bootz 0x82000000 0x88080000:4fec02 88000000] ...

Kernel: second ttyS2 comes up nice and early...

root@beaglebone:~# dmesg | grep serial
[ 2.073749] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.088159] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
base_baud = 3000000) is a 8250
[ 7.807662] systemd[1]: Created slice system-serial\x2dgetty.slice.

Hurrah!!!

First issue... Now the Kernel Cape Manager get's in the way, i need to
pass a global kill switch (or find the global disable), right now you
have to "disable" capes loaded by U-Boot.. (you don't have too, it
just looks weird when they both load fine..)

root@beaglebone:~# dmesg | grep bone
[ 0.000000] Kernel command line: console=ttyO0,115200n8
bone_capemgr.disable_partno=BB-BONE-SERL-03 root=/dev/mmcblk0p1 ro
rootfstype=ext4 rootwait coherent_pool=1M quiet net.ifnames=0
[ 2.345976] bone_capemgr bone_capemgr: Baseboard:
'A335BNLT,00C0,2516BBBK2626'
[ 2.346020] bone_capemgr bone_capemgr:
compatible-baseboard=ti,beaglebone-black - #slots=4
[ 2.382381] bone_capemgr bone_capemgr: slot #0: No cape found
[ 2.412268] bone_capemgr bone_capemgr: slot #1: 'BeagleBone RS232
CAPE,00A1,Beagleboardtoys,BB-BONE-SERL-03'
[ 2.450326] bone_capemgr bone_capemgr: slot #2: No cape found
[ 2.494321] bone_capemgr bone_capemgr: slot #3: No cape found
[ 2.500199] bone_capemgr bone_capemgr: Skipping loading of disabled
cape with part# BB-BONE-SERL-03
[ 2.500214] bone_capemgr bone_capemgr: initialized OK.
[ 6.813904] systemd[1]: Set hostname to <beaglebone>.
[ 15.389423] LUN: removable read only file:
/var/cache/doc-beaglebone-getting-started/beaglebone-getting-started-2016-11-07.img

So to actually test follow:

*************Actual testing...***************************************

Step 1: Do you have a usb serial adapter to monitor the boot process?

no = stop reading now... till you have one in hand...
yes = please continue

Step 2: Remove /uEnv.txt (i forgot to code that path in this test)

rm /uEnv.txt

Step 3: Update u-boot to v2017.01-rc2

cd /opt/scripts/tools/developers/
git pull
./update_bootloader.sh --use-beta-bootloader

On reboot, it should show:

U-Boot SPL 2017.01-rc2-00003-g835d6bbf46 (Dec 29 2016 - 15:28:49)
Trying to boot from MMC1

U-Boot 2017.01-rc2-00003-g835d6bbf46 (Dec 29 2016 - 15:28:49 -0600),
Build: jenkins-github_Bootloader-Builder-496

If not, eMMC probably messing with you..

dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

Step 4: /boot/uEnv.txt

remove "cape_universal=enable" we dont want any false posititves...

and remember to disable your Kernel overlay:

cape_disable=bone_capemgr.disable_partno=BB-BONE-SERL-03

Step 5: Profit!!! :wink:

2

First issue... Now the Kernel Cape Manager get's in the way, i need to
pass a global kill switch (or find the global disable), right now you
have to "disable" capes loaded by U-Boot.. (you don't have too, it
just looks weird when they both load fine..)

adding "of_overlay_disable" to the boot arg's kills it..

Regards,

3

Okay, second pass more things work, more corner cases to fix...

Does this replace the current method? Yes, I'm thinking for v4.10.x+ :wink:

<snip>

What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote
this email up and got ready to go home...

BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"
BB-W1-P9.12-00A0.dtbo overlay works too.

Will this fix the issue with the painful out of box experience with
LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. :wink:

How do i actually test things?

Easiest, /boot/uEnv.txt

dtb=am335x-boneblack-overlay.dtb

Regards,

Ok so let me get one thing clear here. I can remove "dtb=<whatever proper
board file> and it should load automatically via uboot's board file loader
? One caveat here, for me anyhow. I have a modified
am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality
removed. So, how could I load that instead of the default for the board
eeprom ?

4

Additionally to the previous post I've made. So assuming I leave my
dtb=<board file I want loaded> in to bypass the default behavior. Does this
work in this manner ? e.g. I need a specific, and custom board file to load
at boot.

5

err, I kind of messed that post up. but the question is still valid, just hanging off the wrong post. But I was curious what you mentioned in your last post.

adding “of_overlay_disable” to the boot arg’s kills it.

So I find this a little confusing. This means we’re able to disable the kernel / userspace cap manager, or the uboot cape manager? The later doesn’t make sense to me. what who says that it needs to ?

6

Okay, second pass more things work, more corner cases to fix...

Does this replace the current method? Yes, I'm thinking for v4.10.x+ :wink:

<snip>

yeah, probably not. :wink:

What have you tested it on? Just BB-UART2-00A0.dtbo and then i wrote
this email up and got ready to go home...

BB-W1-P8.26-00A0.dtbo which is an adaption of the "stock"
BB-W1-P9.12-00A0.dtbo overlay works too.

Sweet!

Will this fix the issue with the painful out of box experience with
LCD3/LCD4/LCD7? Correct, as long as they have an eeprom. :wink:

How do i actually test things?

Easiest, /boot/uEnv.txt

dtb=am335x-boneblack-overlay.dtb

Regards,

Ok so let me get one thing clear here. I can remove "dtb=<whatever proper
board file> and it should load automatically via uboot's board file loader ?
One caveat here, for me anyhow. I have a modified
am335x-boneblack-emmc-overlay.dtb with ethernet sleep functionality removed.
So, how could I load that instead of the default for the board eeprom ?

As long as you specify "dtb=<something>" i won't start with a
different default dtb.. Your still in full control.

I also want to add a variable to /boot/uEnv.txt enable this, so end
users can easily disable it..

Regards,

7

it turns out of_overlay_disable kill's everything in the kernel land.
So while it kill's the auto slot loading, it also kills manually
loading..

So what i really need to do, is patch v4.1.x/v4.4.x/v4.9.x and set a
flag so the kernel knows u-boot already loaded the 4 eeprom slots, and
doesn't try to auto load an overlay that's already loaded....

* I also need to add the eMMC, hdmi-video, hdmi-audio,
ethernet/wireless overlays. So we can do things like the old
3.8.13-bone.... (except thru u-boot)

Regards,

8

Ok, cool, thanks Robert.

However I feel compelled to add a bit more information just in case it ever becomes important.

First up. While the one wire overlay does seem to work fine( I can talk to a 1-wire temp sensor just fine ). dmesg only gives this:

[ 11.712253] Driver for 1-wire Dallas network protocol.

Where as the serial boot log I get:

. . .
Running uname_boot …
loading /boot/vmlinuz-4.4.12-ti-r31 …
7777640 bytes read in 513 ms (14.5 MiB/s)
loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb …
60139 bytes read in 39 ms (1.5 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] …
loading /lib/firmware/BB-W1-P8.26-00A0.dtbo …
974 bytes read in 72 ms (12.7 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 …
4556959 bytes read in 308 ms (14.1 MiB/s)
debug: [console=ttyO0,115200n8 root=UUID=b83ca291-b04b-4c94-819a-b33f39e574c8 ro rootfstype=ext4 rootwait coherent_pool=1M quiet] …
. . .

No biggie to me, it works. So if that information is not in the dmesg syslogs, personally I’m fine with that. But maybe that is not your desired result ?

The rest I think you may have just answered in a new post so will read that first.

9

You just stumbled on the biggest issue...

Debugging's going to be fun.. Specially if the end user doesn't have
a usb-serial cable..

After u-boot patches the device-tree, the kernel will never know..
(that's also why things, video/mmc/wl18xx will also just work better)

Regards,

10

Honestly, and obviously just my opinion. But if anyone is truly serious
about using a beaglebone black / green*. They really need a serial debug
cable. Otherwise, they should just "stay home". As far as spending a little
extra time reading a couple logs, versus just one . . .yeah whatever. If
you're serious, you're serious. A small price to pay for such a useful bit
of hardware that can be used in many different ways.

11

Robert, oh right the other bit of information I needed to let you know about . . .

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
Already up-to-date.

Where the boot log still says . . .

[116467.340818] reboot: Restarting system

U-Boot SPL 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC2

U-Boot 2017.01-rc2-00002-g52b3c56009 (Dec 23 2016 - 16:22:21 -0600), Build: jenk ins-github_Bootloader-Builder-493

CPU : AM335X-GP rev 2.1

So apparently, for now. I’m unable to “play”. I’d so an apt-get update. But somehow, I don’t think that’d work :wink:

12

What I mean, is that in this post you seem to be on build 496, where I am
still in "sync" with the last post using build 493. Not sure that is
important or not after the information you just posted about disabling cape
manager disables everything . . . but Perhaps not.

13

Okay, time to push it out as default...

First stable build is:

U-Boot SPL 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57)
Trying to boot from MMC1

U-Boot 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600),
Build: jenkins-github_Bootloader-Builder-497

This includes a U-Boot overlays disabled by default, end user has to
enable in /boot/uEnv.txt overide..

Doc's:

to enable this new feature, set enable_boot_overlays in /boot/uEnv.txt

enable_uboot_overlays=1

First 4 slots are then auto-loaded
5th slot, can be set by user

dtb_overlay=/lib/firmware/*.dtbo

Works best with a r78 based v4.4.x kernel..

Regards,

14

Hey Robert,

So, a question some of us who already have existing, and working images may
have. Is how do we update our uboot ? When updating to a new kernel, I
suspect this will happen automatically via dpkg. But what if "we" do not
wish to update our kernel? Things may be working perfectly etc, and maybe
we're a bit skittish about updating to a newer kernel. Or maybe we have
kernel reliant software ( custom kernel modules, etc ).

I just did a git pull update of the scripts repo's but the only two files
updated seem like they're unrelated. Or maybe it just seems that way to me
. . .

15

So I thought about it for a few minutes when not otherwise busy, and figured it out on my own.

$ cd /opt/scripts/tools/developers/
$ git pull
$ sudo ./update_bootloader.sh
$ sudo reboot

serial debug:
…
[84389.038894] reboot: Restarting system

U-Boot SPL 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57)
Trying to boot from MMC2

U-Boot 2017.01-rc2-00003-ga4c7d45040 (Dec 30 2016 - 11:30:57 -0600), Build: jenkins-github_Bootloader-Builder-497
…

But I forgot to change /boot/uEnv.txt to allow uboot cape manager . . .

$ sudo nano /boot/uEnv.txt
. . .
##BeagleBone Black: HDMI (Audio/Video) disabled:
enable_uboot_overlays=1
dtb=am335x-boneblack-emmc-overlay.dtb
dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo

. . .

Serial debug now:
loading /boot/vmlinuz-4.4.12-ti-r31 …
7777640 bytes read in 514 ms (14.4 MiB/s)
loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb …
60139 bytes read in 39 ms (1.5 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-W1-P8.26-00A0.dtbo] …
loading /lib/firmware/BB-W1-P8.26-00A0.dtbo …
974 bytes read in 72 ms (12.7 KiB/s)

Testing 1-wire temp sensor:
debian@beaglebone:~$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
1c 01 4b 46 7f ff 04 10 e8 : crc=e8 YES
1c 01 4b 46 7f ff 04 10 e8 t=17750

Everything working fine.

16

dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo

Seems to work fine as well. I’ve no reason to think it doesn’t work, but I have not tested the SPI transmission with spidev_test, or a logic analyzer YET. The overlay does seem to load the drivers fine

loading /boot/dtbs/4.4.12-ti-r31/am335x-boneblack-emmc-overlay.dtb …
60139 bytes read in 40 ms (1.4 MiB/s)
debug: [dtb_overlay=/lib/firmware/BB-SPIDEV0-00A0.dtbo] …
loading /lib/firmware/BB-SPIDEV0-00A0.dtbo …
1235 bytes read in 60 ms (19.5 KiB/s)
loading /boot/initrd.img-4.4.12-ti-r31 …

And the interfaces show up in /dev/

debian@beaglebone:~$ ls /dev |grep spidev
spidev1.0
spidev1.1

17

So, I’ve tested this a few times over the last . . .<whatever it’s been since announcement >, and I have found that loading a single overlay seems to work really good. Attempting multiple overlays however, seems to be an exercise in frustration. e.g. It’s not ready. It’s possible that I got something wrong, but I do not usually do that more than once. I’ve tried multiple times.

So my recommendation is, if you’re an embedded Linux noob, or a beginner to this platforms boot process. Steer clear. If you’re reasonably experienced in both of these areas, and don’t mind testing - Have fun. But I would definitely strongly advise to not attempt this on a production system.

Basically what happens is uboot complains that the cmdline kernel parameter does not contain a valid flattened device tree overlay path. Why exactly, I’m not sure. I did see uboot “mention” that it can not find a valid partition for partitions 1-6 . . . which I think may be standard uboot debug output. First, it checked the path for the UUID, then attempted the blk device. Failing ( or flailing ). However, this works perfectly fine when using:

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=controller,BB-ADC,BB-W1-P8.26

After making sure the overlays exist in /lib/firmware/, and then running:

root@beaglebone:~# cd /opt/scripts/tools/developers/
root@beaglebone:/opt/scripts/tools/developers# ./update_initrd.sh
root@beaglebone:/opt/scripts/tools/developers# reboot

One should also keep in mind that if you update to a newer kernel before this process. Make sure you reboot into your new kernel first. Otherwise your board WILL boot, but the boot process will stop inside the initramfs. I fell into this trap myself, and basically what happens. You will end up updating the initramfs you just replaced, while leaving the replacement initramfs without a clue as to where to go next. Once the initramfs loads that is.

Anyway, this is a potentially really cool, and good feature. I look forward to this working flawlessly in the future. However, at this point in time, I have to give testing a pass. As I have other priorities that must come first - currently.

18

By the way, the kernel I failed with was: linux-image-4.4.43-bone-rt-r16

19

So adding a couple more fdt commits from u-boot mainline: (to actually
report what failed)

loading /boot/vmlinuz-4.9.4-bone4 ...
8225160 bytes read in 543 ms (14.4 MiB/s)
loading /boot/dtbs/4.9.4-bone4/am335x-boneblack-overlay.dtb ...
52712 bytes read in 63 ms (816.4 KiB/s)
debug: [uboot_overlay_addr0=/lib/firmware/BB-BONE-LCD7-01-00A3.dtbo] ...
loading /lib/firmware/BB-BONE-LCD7-01-00A3.dtbo ...
5778 bytes read in 136 ms (41 KiB/s)
fdt_overlay_apply(): FDT_ERR_NOSPACE

that's why it's not applying it..

Regards,

20

Not enough memory allocated ?