mail archive of the barebox mailing list
 help / color / mirror / Atom feed
* Compiled in boot environment and dtbo files
@ 2021-06-16  8:10 Konstantin Kletschke
  2021-06-16 12:34 ` Sascha Hauer
  2021-06-18  6:48 ` Ahmad Fatoum
  0 siblings, 2 replies; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-16  8:10 UTC (permalink / raw)
  To: barebox


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

Dear community,

actually I wonder how to prepare a reset/boot up default boot environment compiled in.

Is it correct, that my 1st task to achieve this is to add a new file in defaultenv/defaultenv-2-base/boot
like “insidem2m” for example? I managed to modify the existing “sd” entry to be able to boot
and persist this, thats how my new entry should look:

#!/bin/sh

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”

right?


I can edit and modify those file and persist them, where is this saved? In my case it looks modified stuff shows
up in barebox.env in my /boot.

Especially my question is, when I add a boot entry compiled in, the boot.default variable should get this entry
and this must be reset/default compiled-in, how is this done?

My second issue is, currently I need to apply two dtbo files to the kernel booting, how do I do this in barebox?

In u-boot this looks like

uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo

in uEnv.txt, I did not find a pendant in the barebox world yet. The capemgr/slot kernel commandline stuff is
deprecated, right? 




INSIDE M2M GmbH
Konstantin Kletschke
Berenbosteler Straße 76 B
30823 Garbsen

Telefon: +49 (0) 5137 90950136
Mobil: +49 (0) 151 15256238
Fax: +49 (0) 5137 9095010

konstantin.kletschke@inside-m2m.de
http://www.inside-m2m.de 

Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
HRB: 111204, AG Hannover


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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16  8:10 Compiled in boot environment and dtbo files Konstantin Kletschke
@ 2021-06-16 12:34 ` Sascha Hauer
  2021-06-16 15:57   ` Konstantin Kletschke
  2021-06-18  6:48 ` Ahmad Fatoum
  1 sibling, 1 reply; 12+ messages in thread
From: Sascha Hauer @ 2021-06-16 12:34 UTC (permalink / raw)
  To: Konstantin Kletschke; +Cc: barebox

Hey Konsti,

On Wed, Jun 16, 2021 at 10:10:55AM +0200, Konstantin Kletschke wrote:
> Dear community,
> 
> actually I wonder how to prepare a reset/boot up default boot environment compiled in.
> 
> Is it correct, that my 1st task to achieve this is to add a new file in defaultenv/defaultenv-2-base/boot
> like “insidem2m” for example? I managed to modify the existing “sd” entry to be able to boot

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.

> and persist this, thats how my new entry should look:
> 
> #!/bin/sh
> 
> 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”
> 

You could do it that way. I suggest using
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".

> 
> 
> I can edit and modify those file and persist them, where is this saved? In my case it looks modified stuff shows
> up in barebox.env in my /boot.

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.

> 
> Especially my question is, when I add a boot entry compiled in, the boot.default variable should get this entry
> and this must be reset/default compiled-in, how is this done?

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"

> 
> My second issue is, currently I need to apply two dtbo files to the kernel booting, how do I do this in barebox?

The command for this would be

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

This assumes you have your rootfs on the second eMMC partition. Replace
mmc1.1 with something else when your rootfs is elsewhere.

We are currently working on more convenience around loading overlays,
something to automatically load desired overlays from a known place in
the rootfs when booting with bootloaderspec, but we are not there yet.

> 
> in uEnv.txt, I did not find a pendant in the barebox world yet. The capemgr/slot kernel commandline stuff is
> deprecated, right?

I don't know, I haven't followed what happened to the capemgr stuff.

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16 12:34 ` Sascha Hauer
@ 2021-06-16 15:57   ` Konstantin Kletschke
  2021-06-16 19:55     ` Trent Piepho
  2021-06-17  6:41     ` Sascha Hauer
  0 siblings, 2 replies; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-16 15:57 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox


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

> 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 #1.2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 4124 bytes --]

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16 15:57   ` Konstantin Kletschke
@ 2021-06-16 19:55     ` Trent Piepho
  2021-06-18 12:43       ` Konstantin Kletschke
  2021-06-17  6:41     ` Sascha Hauer
  1 sibling, 1 reply; 12+ messages in thread
From: Trent Piepho @ 2021-06-16 19:55 UTC (permalink / raw)
  To: Konstantin Kletschke; +Cc: Sascha Hauer, Barebox List

On Wed, Jun 16, 2021 at 8:59 AM Konstantin Kletschke
<konstantin.kletschke@inside-m2m.de> wrote:
> global.bootm.image=/boot/uImage
> global.bootm.oftree=/boot/am335x-boneblack.dtb
>
> 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?

While I have not yet used overlays in barebox, and don't know what is
wrong here, the order of loading is not what you think.

Setting global.bootm.* only sets a env variable.  It does not load
anything.  The file doesn't even need to exist, i.e. it can be on a
device that is not mounted yet.  These variables set the defaults for
when the "bootm" command is run.  One can put dtb and kernel image on
the command line of bootm too, so override the default from the env
variables.

So the dtb will always be loaded after calling of_overlay, since the
dtb is not loaded until the last command barebox will run to actually
boot the kernel.

of_overlay will call of_register_overlay(), and that registers the
overlay to be loaded when bootm runs, after it has loaded the main dtb
and is applying fixups.  But it registers to binary dtb data, not just
the file name, so the file is loaded when of_overlay is run.  Looks
like that fixup process run by bootm didn't work for some reason and
this is the source of the errors.

To be more consistent with the rest of bootm, there should probably be
variables "global.bootm.ofoverlay.*" and bootm will load the files in
those variables as overlays.  Those improvements Sascha alluded to are
probably something like this.

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16 15:57   ` Konstantin Kletschke
  2021-06-16 19:55     ` Trent Piepho
@ 2021-06-17  6:41     ` Sascha Hauer
  2021-06-18 13:15       ` Konstantin Kletschke
  1 sibling, 1 reply; 12+ messages in thread
From: Sascha Hauer @ 2021-06-17  6:41 UTC (permalink / raw)
  To: Konstantin Kletschke; +Cc: barebox

On Wed, Jun 16, 2021 at 05:57:09PM +0200, Konstantin Kletschke wrote:
> 
> > 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…

In the end it goes down to putting an entry like this into
loader/entries/foo.conf into your rootfs:

title      brand new stuff
version    5.13-rc6
machine-id 6a9857a393724b7a981ebb5b8495b9ea
linux      /boot/sha-linux-phyFLEX-i.MX6
devicetree /boot/sha-oftree-phyFLEX-i.MX6
linux-appendroot true

Linux and device tree paths are relative to the top of the rootfs.
The good thing about it is that now you can exchange Kernel and device
tree as part of your rootfs or even with your distros package
management. The linux-appendroot property is barebox specific. When this
is found then barebox will add a suitable root= option to the Kernel
commandline, so you don't have to care about that anymore.

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

You have to compile the device tree with -@ passed to dtc. If you are
building the device tree in the Kernel this does the trick:

make dtbs DTC_FLAGS=-@

Sascha

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16  8:10 Compiled in boot environment and dtbo files Konstantin Kletschke
  2021-06-16 12:34 ` Sascha Hauer
@ 2021-06-18  6:48 ` Ahmad Fatoum
  2021-06-18 13:16   ` Konstantin Kletschke
  1 sibling, 1 reply; 12+ messages in thread
From: Ahmad Fatoum @ 2021-06-18  6:48 UTC (permalink / raw)
  To: Konstantin Kletschke, barebox

Hello Konstantin,

On 16.06.21 10:10, Konstantin Kletschke wrote:
> Dear community,
> 
> actually I wonder how to prepare a reset/boot up default boot environment compiled in.
> 
> Is it correct, that my 1st task to achieve this is to add a new file in defaultenv/defaultenv-2-base/boot
> like “insidem2m” for example? I managed to modify the existing “sd” entry to be able to boot
> and persist this, thats how my new entry should look:
> 
> #!/bin/sh
> 
> 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”
> 
> right?
> 
> 
> I can edit and modify those file and persist them, where is this saved? In my case it looks modified stuff shows
> up in barebox.env in my /boot.
> 
> Especially my question is, when I add a boot entry compiled in, the boot.default variable should get this entry
> and this must be reset/default compiled-in, how is this done?
> 
> My second issue is, currently I need to apply two dtbo files to the kernel booting, how do I do this in barebox?
> 
> In u-boot this looks like
> 
> uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo
> uboot_overlay_addr1=/lib/firmware/BB-UART4-00A0.dtbo
> 
> in uEnv.txt, I did not find a pendant in the barebox world yet.

You could add a bootspec file with

devicetree-overlay BB-UART1-00A0.dtbo BB-UART4-00A0.dtbo

If you want the overlay application to happen in the bootloader, but
decide the overlay selection policy in userspace.

> The capemgr/slot kernel commandline stuff is
> deprecated, right? 
> 
> 
> 
> 
> INSIDE M2M GmbH
> Konstantin Kletschke
> Berenbosteler Straße 76 B
> 30823 Garbsen
> 
> Telefon: +49 (0) 5137 90950136
> Mobil: +49 (0) 151 15256238
> Fax: +49 (0) 5137 9095010
> 
> konstantin.kletschke@inside-m2m.de
> http://www.inside-m2m.de 
> 
> Geschäftsführung: Michael Emmert, Ingo Haase, Dr. Fred Könemann, Derek Uhlig
> HRB: 111204, AG Hannover
> 
> 
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-16 19:55     ` Trent Piepho
@ 2021-06-18 12:43       ` Konstantin Kletschke
  0 siblings, 0 replies; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-18 12:43 UTC (permalink / raw)
  To: Trent Piepho; +Cc: Sascha Hauer, Barebox List


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

> While I have not yet used overlays in barebox, and don't know what is
> wrong here, the order of loading is not what you think.

I think I got your point.
Setting those parameters are not really loading stuff. 
So the setting order has nothing to do with load order, the booting itself
loads the stuff and the kernel gets a prepared list of addresses where each
part was located from the bootloader.

> the file name, so the file is loaded when of_overlay is run.  Looks
> like that fixup process run by bootm didn't work for some reason and
> this is the source of the errors.

I will prepare another mail to this list replying to Sascha what I found out
about that error meanwhile. It is not much but probably the problem is not
barebox related I suppose.

> To be more consistent with the rest of bootm, there should probably be
> variables "global.bootm.ofoverlay.*" and bootm will load the files in
> those variables as overlays.  Those improvements Sascha alluded to are
> probably something like this.

Thanks for the information.

Kind Regards
Konsti


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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-17  6:41     ` Sascha Hauer
@ 2021-06-18 13:15       ` Konstantin Kletschke
  2021-06-21  4:01         ` Sascha Hauer
  0 siblings, 1 reply; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-18 13:15 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox


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



> In the end it goes down to putting an entry like this into
> loader/entries/foo.conf into your rootfs:

I will investigate this definitely carefully since this has nice advantages
controlling the boot from userspace, especially in order to gain a proper
failover environment.

Meanwhile I realized I most probably have no problem with barebox and
dtb/dtbo handling. At least it _is_ preparing “my” dtbo files and trying to 
handle them.

In my initial mail regarding this thread I mentioned how this works on my 
Beaglebones when I kept the delivered debian environment with u-boot.
The goal is to have the serial lines enabled as serial after bootup on the
pinheaders and there
this works with those dtbo files. Also I realized I can omit them and bitbang
in the GPIO multiplex mechanism below /sys/platform/... to gain the same
effect. Because the debian kernel setup (including the dtb file?) is enabling all
four serial lines at boot, regardless what I do:

[    0.952482] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 3000000) is a 8250
[    1.713812] console [ttyS0] enabled
[    1.718482] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 31, base_baud = 3000000) is a 8250
[    1.728498] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 32, base_baud = 3000000) is a 8250
[    1.738387] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 33, base_baud = 3000000) is a 8250
[    1.748351] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 34, base_baud = 3000000) is a 8250
[    1.758188] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 35, base_baud = 3000000) is a 8250

The dtbo files only do some GPIO multiplexing (I realized yesterday).

In my kernel setup only the first serial interface gets enabled:

[    0.734644] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 29, base_baud = 3000000) is a OMAP UART0
[    1.303154] printk: console [ttyO0] enabled

Maybe the overlays are not working since there are referring to not enabled serial interfaces, 
like "target = <&uart1>;” for example? I am still investigating where differences between my 
rather vanilla setup and the debian changes are...


>> 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
> 
> You have to compile the device tree with -@ passed to dtc. If you are
> building the device tree in the Kernel this does the trick:
> 
> make dtbs DTC_FLAGS=-@

I prepared a kernel (usually I use yocto, I did not found where to apply flags for “make dtbs” so I
prepared a test setup) and dtbo files this way. The compile process spits many warnings and the 
resulting binary size increases, but the error “[…] Invalid argument" is identical.

As said, I have to figure this out further, I suppose the barebox is doing just fine!

Kind Regards
Konstantin



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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-18  6:48 ` Ahmad Fatoum
@ 2021-06-18 13:16   ` Konstantin Kletschke
  0 siblings, 0 replies; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-18 13:16 UTC (permalink / raw)
  To: Ahmad Fatoum; +Cc: barebox


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


> You could add a bootspec file with
> 
> devicetree-overlay BB-UART1-00A0.dtbo BB-UART4-00A0.dtbo
> 
> If you want the overlay application to happen in the bootloader, but
> decide the overlay selection policy in userspace.

Thanks for the information, I will definitely check this out!

Kind Regards
Konsti


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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-18 13:15       ` Konstantin Kletschke
@ 2021-06-21  4:01         ` Sascha Hauer
  2021-06-21 14:21           ` Konstantin Kletschke
  0 siblings, 1 reply; 12+ messages in thread
From: Sascha Hauer @ 2021-06-21  4:01 UTC (permalink / raw)
  To: Konstantin Kletschke; +Cc: barebox

On Fri, Jun 18, 2021 at 03:15:32PM +0200, Konstantin Kletschke wrote:
> 
> 
> > In the end it goes down to putting an entry like this into
> > loader/entries/foo.conf into your rootfs:
> 
> I will investigate this definitely carefully since this has nice advantages
> controlling the boot from userspace, especially in order to gain a proper
> failover environment.
> 
> Meanwhile I realized I most probably have no problem with barebox and
> dtb/dtbo handling. At least it _is_ preparing “my” dtbo files and trying to 
> handle them.
> 
> In my initial mail regarding this thread I mentioned how this works on my 
> Beaglebones when I kept the delivered debian environment with u-boot.
> The goal is to have the serial lines enabled as serial after bootup on the
> pinheaders and there
> this works with those dtbo files. Also I realized I can omit them and bitbang
> in the GPIO multiplex mechanism below /sys/platform/... to gain the same
> effect. Because the debian kernel setup (including the dtb file?) is enabling all
> four serial lines at boot, regardless what I do:
> 
> [    0.952482] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 30, base_baud = 3000000) is a 8250
> [    1.713812] console [ttyS0] enabled
> [    1.718482] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 31, base_baud = 3000000) is a 8250
> [    1.728498] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 32, base_baud = 3000000) is a 8250
> [    1.738387] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 33, base_baud = 3000000) is a 8250
> [    1.748351] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 34, base_baud = 3000000) is a 8250
> [    1.758188] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 35, base_baud = 3000000) is a 8250
> 
> The dtbo files only do some GPIO multiplexing (I realized yesterday).
> 
> In my kernel setup only the first serial interface gets enabled:
> 
> [    0.734644] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 29, base_baud = 3000000) is a OMAP UART0
> [    1.303154] printk: console [ttyO0] enabled
> 
> Maybe the overlays are not working since there are referring to not enabled serial interfaces, 
> like "target = <&uart1>;” for example? I am still investigating where differences between my 
> rather vanilla setup and the debian changes are...
> 
> 
> >> 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
> > 
> > You have to compile the device tree with -@ passed to dtc. If you are
> > building the device tree in the Kernel this does the trick:
> > 
> > make dtbs DTC_FLAGS=-@
> 
> I prepared a kernel (usually I use yocto, I did not found where to apply flags for “make dtbs” so I
> prepared a test setup) and dtbo files this way. The compile process spits many warnings and the 
> resulting binary size increases, but the error “[…] Invalid argument" is identical.

Have a look at the generated dtb file with 'dtc -I dtb -O dts <file>'.
It should contain a __symbols__ node.

BTW do you have a good reason to use overlays? Overlays only have a
value when you have different hardware variants in which different
overlays are loaded. If that's not the case I'd just go with a static
devicetree and be done with it.

Sascha


-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-21  4:01         ` Sascha Hauer
@ 2021-06-21 14:21           ` Konstantin Kletschke
  2021-06-22 10:40             ` Konstantin Kletschke
  0 siblings, 1 reply; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-21 14:21 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox


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

Dear community, dear Sascha,

an accident happened on my side. I totally overlooked that after my initial mail with the 
initial quoted error message the message changed.

Probably either the change of compiling the dtb file (make dtbs DTC_FLAGS=-@) got
me a __symbols__ node or another thing was sorted out by me on accident meanwhile
since still I am trying to get used to device tree handling.

In detail, this messages are not valid any more:

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

but I get a different set of errors. Probably since including Friday and I overlooked this.
How embarassing, sorry!

Now I get:

ERROR: of_resolver: cannot find node ocp in base devicetree
WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument
ERROR: of_resolver: cannot find node ocp in base devicetree
WARNING: Failed to fixup node in of_overlay_fixup+0x1/0x4: Invalid argument

which is very reasonable: 

> Have a look at the generated dtb file with 'dtc -I dtb -O dts <file>'.
> It should contain a __symbols__ node.

The decompiled result of “my” dtb has a __symbols__ note at the bottom of the file, yes!
I suppose each “fragment@n {target = XYZ …”) in a overlay has to have a matching 
counterpart XYZ in the __symbols__ node in the base file, right? Because in my overlay
there is an "target = <&ocp>!" without a matching counterpart in the base dtb.
Two other entries (uart1, am33xx_pinmux) have a matching entry. 

> BTW do you have a good reason to use overlays? Overlays only have a

No indeed I don’t necessarily - I realized meanwhile by myself.

Additionally I relaized the overlays I have here in question only do some GPIO
multiplexing I can do by hand/script in the /sys gpio section anyway. Only interesting
for serial line availability at boot. May be later it’s interesting for us for different
variante, I hope I am used to this stuff then. 

> value when you have different hardware variants in which different
> overlays are loaded. If that's not the case I'd just go with a static
> devicetree and be done with it.

For now I agree and I try to understand how to enable the UART1 and UART4
in a static dtb way and I currently search the vanille device tree on how to do 
this and how this currently this is done at least with the working UART0 :-)

Sadly not barebox related :-)

Kind Regards
Konsti


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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Compiled in boot environment and dtbo files
  2021-06-21 14:21           ` Konstantin Kletschke
@ 2021-06-22 10:40             ` Konstantin Kletschke
  0 siblings, 0 replies; 12+ messages in thread
From: Konstantin Kletschke @ 2021-06-22 10:40 UTC (permalink / raw)
  To: Sascha Hauer; +Cc: barebox


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

I got the uart1 and uart4 available on boot after I changed the appropiate dtsi in this way:

--- arch/arm/boot/dts/am335x-bone-common.dtsi_ORIG	2021-01-29 15:08:15.085080693 +0100
+++ arch/arm/boot/dts/am335x-bone-common.dtsi	2021-06-22 11:26:48.197115876 +0200
@@ -96,6 +96,20 @@
 		>;
 	};
 
+	uart1_pins: pinmux_uart1_pins {
+		pinctrl-single,pins = <
+			AM33XX_PADCONF(AM335X_PIN_UART1_RXD, PIN_INPUT_PULLUP, MUX_MODE0)
+			AM33XX_PADCONF(AM335X_PIN_UART1_TXD, PIN_OUTPUT_PULLDOWN, MUX_MODE0)
+		>;
+	};
+
+	uart4_pins: pinmux_uart4_pins {
+		pinctrl-single,pins = <
+            AM33XX_PADCONF(AM335X_PIN_GPMC_WAIT0, PIN_INPUT_PULLUP, MUX_MODE6)	/* (T17) gpmc_wait0.uart4_rxd */
+            AM33XX_PADCONF(AM335X_PIN_GPMC_WPN, PIN_OUTPUT_PULLDOWN, MUX_MODE6)	/* (U17) gpmc_wpn.uart4_txd */
+		>;
+	};
+
 	clkout2_pin: pinmux_clkout2_pin {
 		pinctrl-single,pins = <
 			AM33XX_PADCONF(AM335X_PIN_XDMA_EVENT_INTR1, PIN_OUTPUT_PULLDOWN, MUX_MODE3)	/* xdma_event_intr1.clkout2 */
@@ -190,6 +204,20 @@
 
 	status = "okay";
 };
+
+&uart1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart1_pins>;
+
+	status = "okay";
+};
+
+&uart4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&uart4_pins>;
+
+	status = "okay";
+};
 
 &usb {
 	status = "okay”;


This change is activating and enabling those uarts at boot and does pin muxing properly.
It’s not muxing only as I previously assumed wrongly investigating the initial overlays.

I will go with that and if in future it is required programming proper overlays for
this that will be a side quest unrelated to barebox.

I just put a result into this mail thread if someone stumbles upon this.

Kind Regards
Konsti



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

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

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-06-22 10:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-16  8:10 Compiled in boot environment and dtbo files Konstantin Kletschke
2021-06-16 12:34 ` Sascha Hauer
2021-06-16 15:57   ` Konstantin Kletschke
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox