Compiled in boot environment and dtbo files

[Konstantin Kletschke]

> defaultenv/defaultenv-2-base/boot is the generic place used for all
> boards. As you are using the beaglebone you should rather manipulate
> arch/arm/boards/beaglebone/defaultenv-beaglebone/. This directory is
> added with defaultenv_append_directory(defaultenv_beaglebone) to the
> environment once we actually know we are running on the beaglebone.

I moved my customisations to the board specific part of the tree, works
like a charm. Thanks for the clarification about its role.

> https://systemd.io/BOOT_LOADER_SPECIFICATION/. With that you can put
> Kernel and device tree into the rootfs and start the whole thing with
> "boot emmc".

Well, I am rather open minded to do that, even if I can configure the kernel and
device tree from rootfs. But I need to investigate on how this is done properly…

> Yes. Where this is stored depends on the board. In case of the
> beaglebone there's a FAT on the eMMC anyway, so we use that to store the
> environment. The environment is a binary file, it's like that because
> normally you don't have a FS available.

I found the file but I was not sure if my setup was working properly, I tried to
change boot.default via “global boot.default=…”, found it in the env and after
reboot in the file in the env tree, but not applied in the environment. Sourcing it
worked. 

> During runtime that would be "nv boot.default=insidem2m; saveenv".
> When you want to make that the default create a file
> arch/arm/boards/beaglebone/defaultenv-beaglebone/nv/boot.default with
> the content "insidem2m"

The “nv boot.default=…” approach worked fine, was persisted and reread on reset
and creating the file got me a fine compiled in default for that. Thanks for the helpful
advise!

> mount mmc1.1
> of_overlay /mnt/mmc1.1/lib/firmware/BB-UART1-00A0.dtbo
> of_overlay /mnt/mmc1.1/lib/firmware/BB-UART4-00A0.dtbo

Are those commands supposed to be integrated into a boot entry? Your assumptions
about mmc1.1are understood. Mounting works and with of_overlay (I did not have the
command available, wasn’t aware of CONFIG_CMD_OF_OVERLAY=y)
I can load the dtbo files manually and automated with my modified boot entry:


barebox at TI AM335x BeagleBone black:/ cat /env/boot/insidem2m 
#!/bin/sh


mount mmc1.1
of_overlay /mnt/mmc1.1/boot/BB-UART1-00A0.dtbo
of_overlay /mnt/mmc1.1/boot/BB-UART4-00A0.dtbo


global.bootm.image=/boot/uImage
global.bootm.oftree=/boot/am335x-boneblack.dtb
global.linux.bootargs.dyn.root="cape_enable=capemgr.enable_partno=BB-UART1,BB-UART4 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait”


In both cases I get an error+warning:

Booting entry 'insidem2m'
mounted /dev/mmc1.1 on /mnt/mmc1.1

Loading ARM Linux zImage '/boot/uImage'
Loading devicetree from '/boot/am335x-boneblack.dtb'
ERROR: of_resolver: __symbols__ missing from base devicetree
WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument
ERROR: of_resolver: __symbols__ missing from base devicetree
WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument
commandline: console=ttyO0,115200n8  cape_enable=capemgr.enable_partno=BB-UART1,BB-UART4 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p2 rootfstype=ext4 rootwait
Booting Linux on physical CPU 0x0
[…]

As expected, no additional serial UARTs available.

Is the order of loading (of_overlay before loading devicetree) messing things up? If not, what does?
Is it reasonable for me to learn the bootloader spec stuff?


Kin regards
Konsti

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4124 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/barebox/attachments/20210616/6c27ccc0/attachment-0001.p7s>