mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Konstantin Kletschke <>
To: Sascha Hauer <>
Subject: Re: Compiled in boot environment and dtbo files
Date: Wed, 16 Jun 2021 17:57:09 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

[-- Attachment #1.1: Type: text/plain, Size: 3601 bytes --]

> 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.

> 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

> 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

> 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 

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

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

[-- Attachment #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4124 bytes --]

[-- Attachment #2: Type: text/plain, Size: 149 bytes --]

barebox mailing list

  reply	other threads:[~2021-06-16 16:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-16  8:10 Konstantin Kletschke
2021-06-16 12:34 ` Sascha Hauer
2021-06-16 15:57   ` Konstantin Kletschke [this message]
2021-06-16 19:55     ` Trent Piepho
2021-06-18 12:43       ` Konstantin Kletschke
2021-06-17  6:41     ` Sascha Hauer
2021-06-18 13:15       ` Konstantin Kletschke
2021-06-21  4:01         ` Sascha Hauer
2021-06-21 14:21           ` Konstantin Kletschke
2021-06-22 10:40             ` Konstantin Kletschke
2021-06-18  6:48 ` Ahmad Fatoum
2021-06-18 13:16   ` Konstantin Kletschke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox