U-Boot overlays (HERE BE EVIL DRAGONS, AND THEY BE HUNGRY) ;)

Okay, i have a version of u-boot with overlays enabled, ready for some
basic testing..

*************Background***************************************

in u-boot we are doing:

dtb= is loaded at ${fdtaddr}

We read /boot/uEnv.txt for (dtb_overlay=<path/file.dtbo>)

then load it, into ${rdaddr} #(no reason that specific address)

Then we must run thru this routine:

fdt addr ${fdtaddr}
fdt resize;
fdt apply ${rdaddr}
fdt resize;

Without the "fdt resize, the jump to kernel bomb's in bootz."

Robert,

So, I have a custom overlay for a physical custom cape . . . as of this moment, I have a few gpio’s( I think around 22 ish ), 6 PWM’s, and eventually I can put an ADC into that same overlay. Right, now for the ADC I’m just loading the “stock” ADC overlay for ADC functionality. Additionally, in the future I may also need to add uart4 back into the mix. For now, our current cape no longer needs uart.

The question I have is . . . Would this improve anything for us ? Right now, I just load the custom overlay through initramfs, which also seems fine. For this project we do not really have a need for an LCD, but that might change in the future. At least for some hardware configurations.

For those interfaces, there's not a lot of overlay loading issues on
the kernel side. The biggest change, you should see your pin's taken
earlier and more consistently at bootup. You can also optimize your
boot time more, as one of the big reasons everything we have is built
as a module, is just too make the kernel overlays work more reliable.

Regards,

I wonder if this will help mitigate, at least *some* of the big boot "lag"
waiting on network interfaces to come up. That alone, if so, would be a
huge plus.

Anyway, the steps you've listed above will work on emmc as well as sdcard ?

Additionally, although perhaps not related to this per se. I'd really like
to see some sort of boot options where "we" did not have to write an
environment file for the sdcard *if* we just wanted to boot from the emmc,
but would like an sdcard inserted for extra storage. That is, without
having to hack the second stage bootloader. Or is that a big deal for you
guys ? You know, I'm not even sure how that would work . . .honestly this
just popped into my head right now.

For those interfaces, there's not a lot of overlay loading issues on
the kernel side. The biggest change, you should see your pin's taken
earlier and more consistently at bootup. You can also optimize your
boot time more, as one of the big reasons everything we have is built
as a module, is just too make the kernel overlays work more reliable.

I wonder if this will help mitigate, at least *some* of the big boot "lag"
waiting on network interfaces to come up. That alone, if so, would be a huge
plus.

the cpsw/eth0 is just broken. :wink: i saw on github (irc zmatt) was looking at it:

https://github.com/dutchanddutch/bb-kernel/commit/0c720957b43a8cea423b80e9fa8772ddb41c186c

Anyway, the steps you've listed above will work on emmc as well as sdcard ?

it should, it's looking in the /boot/uEnv.txt file..

Additionally, although perhaps not related to this per se. I'd really like
to see some sort of boot options where "we" did not have to write an
environment file for the sdcard *if* we just wanted to boot from the emmc,
but would like an sdcard inserted for extra storage. That is, without having
to hack the second stage bootloader. Or is that a big deal for you guys ?
You know, I'm not even sure how that would work . . .honestly this just
popped into my head right now.

ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in the 1st
partition, or /boot/uEnv.txt in any of the first 7 partitions and
it'll ignore the microSD..

Regards,

the cpsw/eth0 is just broken. :wink: i saw on github (irc zmatt) was looking
at it:

https://github.com/dutchanddutch/bb-kernel/commit/
0c720957b43a8cea423b80e9fa8772ddb41c186c

hmmm, I wonder if that works ? Matthijs hehe I should have known.

ah, just don't have /uEnv.txt, /boot.scr, /boot/boot.scr in the 1st
partition, or /boot/uEnv.txt in any of the first 7 partitions and
it'll ignore the microSD..

Ah, ok, sounds like it's been around a while and I just haven't realized.
Thanks for the answers, and have a great Christmas !

Are these changes in the most recent distros, Robert?

These changes are only 6 hours old, you must have missed the first post with all the details.

Regards,

So . . .

By the way, I could test with 3 different boards. and A5A, an Element14 RevC, and an BBG.

So . . .

Okay, i have a version of u-boot with overlays enabled, ready for some
basic testing..

*************Background***************************************

in u-boot we are doing:

dtb= is loaded at ${fdtaddr}

We read /boot/uEnv.txt for (dtb_overlay=<path/file.dtbo>)

then load it, into ${rdaddr} #(no reason that specific address)

Then we must run thru this routine:

fdt addr ${fdtaddr}
fdt resize;
fdt apply ${rdaddr}
fdt resize;

Without the "fdt resize, the jump to kernel bomb's in bootz."

*****************************************************************

*************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-00002-g52b3c56009 (Dec 23 2016 - 16:22:21)
Trying to boot from MMC1

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

If not, eMMC probably messing with you..

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

What ?!?

Step 4: /boot/uEnv.txt

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

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

before:
kernel:
root@beaglebone:~# dmesg | grep serial
[ 2.082007] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.096583] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 159,
base_baud = 3000000) is a 8250
[ 20.106023] systemd[1]: Created slice system-serial\x2dgetty.slice.

after:
U-Boot:
loading /boot/dtbs/4.4.39-ti-r75/am335x-boneblack-wireless.dtb ...
64988 bytes read in 163 ms (388.7 KiB/s)
debug: [dtb_overlay=/lib/firmware/BB-UART2-00A0.dtbo] ...
loading /lib/firmware/BB-UART2-00A0.dtbo ...
883 bytes read in 276 ms (2.9 KiB/s)

kernel:
root@beaglebone:~# dmesg | grep serial
[ 2.081559] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 158,
base_baud = 3000000) is a 8250
[ 2.095942] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 159,
base_baud = 3000000) is a 8250
[ 2.096807] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 160,
base_baud = 3000000) is a 8250
[ 20.316939] systemd[1]: Created slice system-serial\x2dgetty.slice.

Step 5: Profit!!! :wink:

*****************************************************************

I know it's a little limited, but something for testing over Christmas. :wink:

FAQ:

What does this solve? Lots of random kernel races... (looking at
video/emmc/etc)... As U-Boot updates the final *.dtb and not the
kernel...

What about 2+ overlays? Maybe next week, for Christmas you get one.. :wink:

Does this replace the current method? No it just improves things..

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

Will it read the eeprom and auto load the correct overlay? Sure,
sometime between next week and the start of the new year... :wink:

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
dtb_overlay=/lib/firmware/xyz.dtbo

Ok, so I have zero problems testing. But what I do have problems with is
understanding how to get from point A to point B

Exact steps, with no "mumbo jumbo" in between.

Like those posted?

So first, will this work with the latest "stable" image ?

Yes.

If so, why would I
want to destroy the partition table of the only boot-able partition ?

Explained by the "if not" in step 3...

I
would actually want the partition table intact so I can make these changes
while reflecting those same changes.on the boot able "image" / file system.

Regards,

This patch/test is not about the base board's..

This is about capes.. Especially the LCD capes...

Regards,

So what you’re telling me that testing for different boards is irrelevant ?

My point was that . . .

on reboot, it should show:

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

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

If not, eMMC probably messing with you…

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

Is a bit heavy handed, and perhaps a bit too overboard.

That is correct. This feature has been enabled in our version of
u-boot since last October or so... So we know those boards work.

Just finally figured out the missing piece to actually load an overlay
on top of the main dtb..

Regards,

sweet. Do tell :wink:

"fdt resize"

Regards,

Well, I’m not sure why I should be testing then. I do not have an LCD cape, and probably never will. But I figured I could test my custom cape at boot AFTER I get something like 1-wire to load at boot. e.g. the is infinitely easier to test, and something I could also test in hardware right away.

Ok so from a fresh emmc flashing( slightly modified rootfs on the flasher image)

debian@beaglebone:~$ rm /uEnv.txt
rm: cannot remove ‘/uEnv.txt’: No such file or directory

debian@beaglebone:~$ sudo apt-get update
debian@beaglebone:~$ sudo apt-get install git

debian@beaglebone:~$ cd /opt/scripts/tools/developers/
debian@beaglebone:/opt/scripts/tools/developers$ git pull
debian@beaglebone:/opt/scripts/tools/developers$ sudo ./update_bootloader.sh --use-beta-bootloader
debian@beaglebone:/opt/scripts/tools/developers$ sudo reboot

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

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

cmdline=coherent_pool=1M quiet

debian@beaglebone:~$ sudo reboot
debian@beaglebone:~$ cat /sys/bus/w1/devices/28-00000647ddf6/w1_slave
0b 01 4b 46 7f ff 05 10 a8 : crc=a8 YES
0b 01 4b 46 7f ff 05 10 a8 t=16687

One minor thing of concern - “evm” :

Are you 100% sure, on selecting [am335x_evm] (y/n)? y
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/MLO-am335x_evm-v2017.01-rc2-r4 of=/dev/mmcblk0 seek=1 bs=128k
0+1 records in
0+1 records out
68504 bytes (69 kB) copied, 0.00287351 s, 23.8 MB/s
log: dd if=/tmp/tmp.HPy1G6iV9J/dl/u-boot-am335x_evm-v2017.01-rc2-r4.img of=/dev/mmcblk0 seek=1 bs=384k

Robert,

Have you created a script that removes all the unnecessary kernel modules loaded superfluously at boot ? I mean there are a lot of them, and I’d say that 99% of them in most cases will just be wasting a lot of memory . . .