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