> 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@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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
