Re: Rockchip rk3328 support?
Hi Sascha, On Fri, Nov 10, 2023 at 01:42:06PM +0100, Sascha Hauer wrote: > The rk3328 is not yet supported. We have support for rk3568 and rk3288 > though, so the ground work for generally supporting Rockchip SoCs has Ok > been done. I don't know how similar the rk3328 is to the supported SoCs, > you could have a look at the Kernel or U-Boot to see how close they are. Actually I am fighting with u-boot. There are Dusun SDKs with all sources available but what they are using are ancient 2017.09 u-boot version which are forked in mirrors rooting to a rockchip github tree. Now I am fighting with a Dusun SDK using a rather vanilla 2022 u-boot which is not the same, I just managed to get a working SDRAM setup. Now reading MMC gives mmc block read error probably yielding to DT setup issues. Then we will investigate what has to be done among the common stuff to put this into barebox. Kind Regards Konstantin
Rockchip rk3328 support?
Dear barebox community, is something like the rk3328 supported actually? I have a Dusun DSGW-210 device here which _seems_ to be mainly 99% like a rk3328 EVB board (Olimex rk3328 eval bord). >From the CONFIG options or cpu support files I would say no, but there is dts/src/arm64/rockchip/rk3328-evb.dts which sounds rather good so I wonder if this is hidden as a subset under other board/cpu. Kind Regards Konstantin -- INSIDE M2M GmbH Konstantin Kletschke Berenbosteler Strasse 76 B 30823 Garbsen Telefon: +49 (0) 5137 90950136 Mobil: +49 (0) 151 15256238 Fax: +49 (0) 5137 9095010 konstantin.kletsc...@inside-m2m.de http://www.inside-m2m.de Gesch"aftsf"uhrung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover
Re: Autoboot when idling at prompt possible?
Dear Ahmad, thanks for your kind support. On Thu, Mar 16, 2023 at 01:51:39PM +0100, Ahmad Fatoum wrote: > If you keep ctrl+c pressed during boot, you may abort before init runs, > even if global.autboot_timeout=0. Interesting, I double checked "my" barebox for this feature, nice to know. > You can enable watchdog before init runs, e.g. in your board code, let's > say with a timeout of 2 minutes. If you have reason to use the shell, you > run wd -x manually or set global.autoboot=abort and reset. This sounds neat and not over complicated. Nice Idea, to have a watchdog enabled at barebox level, why not. The manual required "wd -x" is fine. I have a beaglebone board, added CONFIG_WATCHDOG and manual enabling watchdog via "wd 120" and disabling vie "wd -x" works fine. Now I wonder how to enable at boot up. Something like --- a/arch/arm/boards/beaglebone/board.c +++ b/arch/arm/boards/beaglebone/board.c @@ -25,6 +25,8 @@ #include #include +#include + #include "beaglebone.h" static int beaglebone_coredevice_init(void) @@ -84,6 +86,9 @@ static int beaglebone_devices_init(void) if (IS_ENABLED(CONFIG_SHELL_NONE)) return am33xx_of_register_bootdevice(); + struct watchdog *wd = watchdog_get_default(); + watchdog_set_timeout(wd, 120); + return 0; } coredevice_initcall(beaglebone_devices_init); ? I can't test at the moment because I am remote and cant handle a abused crashing barebox at the moment. It compiles, though! The passwort entry approach is kinda neat to, I will investigate this feature too. Kind Regards Konstantin -- 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.kletsc...@inside-m2m.de http://www.inside-m2m.de Geschäftsführung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover
Autoboot when idling at prompt possible?
Hi there, in order to get the booting more robust I already changed autoboot_abort_key from "any" to "ctrl-c". We wan't to keep the autoboot_timeout to be able to access the bootloader prompt manually or with install tools more reliably to a non zero positive value. I.e. enter prompt with timeout greater than zero still should be possible. Is there a mechanism already implemented or thinkable to be added as a command, which boots when the prompt is idling for a couple of minutes? Lets say the bootloader caught ctrl-c by accident (free serial pins in headless encasing in rough EMV environment) and idles there for years... Kind Regards Konstantin -- 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.kletsc...@inside-m2m.de http://www.inside-m2m.de Geschäftsführung: Michael Emmert, Derek Uhlig HRB: 111204, AG Hannover
Re: Boot from SD if SD-Card is present - Beaglebone Black
On Fri, May 06, 2022 at 02:20:04PM +0200, Ahmad Fatoum wrote: > Great that you got it working. I'd still suggest that > CONFIG_MMCBLKDEV_ROOTARG=y > be used for new projects with new kernels an with the same aliases hardcoded > in Looks great, works: barebox@TI AM335x BeagleBone black:/ boot mmc1.1 ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 Booting entry 'BeagleBone Black - Inside M2M (/mnt/mmc1.1/loader/entries/boneblack.conf)' blspec: booting BeagleBone Black - Inside M2M from mmc1 Adding "root=/dev/mmcblk1p2" to Kernel commandline Thank you! Regards Konsti -- 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.kletsc...@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
Re: Boot from SD if SD-Card is present - Beaglebone Black
On Thu, May 05, 2022 at 10:25:07AM +0200, Sascha Hauer wrote: > Several partitioning tools set this automatically, but not all it seems. I got it. The partitions are created via sfdisk. No PARTUUID. If I change the disk identifier with fdisk afterwards, the partitions magically also get PARTUUIDs. This can be scripted (by me): Something like fdisk /dev/mmcblk1 x i 0xaffedead r w Problem solved, with this the bootloader spec is working and I will implement that! Regards Konsti -- 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.kletsc...@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
Re: Boot from SD if SD-Card is present - Beaglebone Black
On Thu, May 05, 2022 at 10:25:07AM +0200, Sascha Hauer wrote: > Is this a DOS partition table or GPT on this card? > I assume it's a DOS partition table in which case you should have a > variable mmc1.nt_signature. Set this to some arbitrary 32bit value. > Several partitioning tools set this automatically, but not all it seems. I investigated from running system: /dev/mmcblk1p3: LABEL="rootfs.1" UUID="6bd1a1f7-f1cb-4121-b1e1-4abe41aa05e6" BLOCK_SIZE="4096" TYPE="ext4" /dev/mmcblk1p1: SEC_TYPE="msdos" UUID="ACC9-583C" BLOCK_SIZE="512" TYPE="vfat" /dev/mmcblk1p4: UUID="348c5617-7055-44f9-a658-562d8bb299a1" BLOCK_SIZE="512" TYPE="xfs" /dev/mmcblk1p2: UUID="e15c856f-aa7f-46b2-9f2e-58672eaaeca5" BLOCK_SIZE="4096" TYPE="ext4" /dev/mmcblk0p2: UUID="f4c88afd-2420-4d50-8672-9ed4cd2d3ff9" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="eaabcc21-02" /dev/mmcblk0p1: SEC_TYPE="msdos" UUID="CBEC-9FB6" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="eaabcc21-01" You mean this PARTUUID stuff, right? Interestingly the external SD-Card has something like this. So I tested bootloaderspec booting from there: barebox@TI AM335x BeagleBone black:/ mount mmc0.1 ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 mounted /dev/mmc0.1 on /mnt/mmc0.1 barebox@TI AM335x BeagleBone black:/ devinfo ext40 Driver: ext4 Bus: fs Parent: mmc0 Parameters: linux.bootargs: root=PARTUUID=eaabcc21-02 (type: string) barebox@TI AM335x BeagleBone black:/ boot mmc0.1 Booting entry 'BeagleBone Black - Inside M2M (/mnt/mmc0.1/loader/entries/boneblack.conf)' blspec: booting BeagleBone Black - Inside M2M from mmc0 Adding "root=PARTUUID=eaabcc21-02" to Kernel commandline Loading ARM Linux zImage '/mnt/mmc0.1//boot/zImage' Loading devicetree from '/mnt/mmc0.1//boot/am335x-boneblack.dtb' commandline: root=PARTUUID=eaabcc21-02 console=ttyS0,115200n8 rootwait Booting Linux on physical CPU 0x0 [...] blablabla [...] mmcblk0: mmc0: SC16G 14.8 GiB mmcblk0: p1 p2 EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) VFS: Mounted root (ext4 filesystem) readonly on device 179:26. Thanks for pointing out to the root cause! Either I change my sfdisk scripting to create partitions including PARTUUIDs or... is utilizing this "variable mmc1.nt_signature" a sufficient workaround in barebox? I can not handle this information, yet. Kind Regards Konsti -- 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.kletsc...@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
Re: Boot from SD if SD-Card is present - Beaglebone Black
Hey Sascha, On Thu, May 05, 2022 at 09:06:02AM +0200, Sascha Hauer wrote: > It's only "bootsource" and "bootsource_instance", without the global. > prefix for historic reasons. Ah okay. Those varables are existing. If I boot from internal MMC bootsource is mmc and instance is 1. If I boot from external SD-Card bootsource is mmc and instance is 0. I hope I did not confuse, my use case is to boot from internal MMC always, booting from external SD-Card (i.e. use SD-Cards bootloader) requires pressing a button which is not accessible. Boot from internal always, if SD-Card is there use its rernel/rootfs. So it is 100% sufficient (succesfully tested already) doing something like: * boot.default=insidem2m_sd bootchooser ** /env/boot/insidem2m_sd mounts and boots mmc0.1 ** bootchooser targets (system0, system1) mount and boot mmc1.1/mmc1.2 Haken dran! > Try mounting manually with "mount mmc1.2". What does "devinfo ext40" say > then? It should contain a linux.bootargs option. barebox@TI AM335x BeagleBone black:/ mount mmc1.2 ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 mounted /dev/mmc1.2 on /mnt/mmc1.2 barebox@TI AM335x BeagleBone black:/ cat /mnt/mmc1.2/loader/entries/boneblack.conf title BeagleBone Black - Inside M2M version 5.14 options rootwait linux /boot/zImage devicetree /boot/am335x-boneblack.dtb linux-appendroot truebarebox@TI AM335x BeagleBone black:/ devinfo ext40 Driver: ext4 Bus: fs Parent: mmc1 barebox@TI AM335x BeagleBone black:/ So, no bootargs option :-| > > Where is this scripting stuff going into? It is not boot.default (gives > It would go to /env/boot/somename Thanks for pointing this out! Kind Regards, Konsti -- 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.kletsc...@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
Re: Boot from SD if SD-Card is present - Beaglebone Black
On Mon, May 02, 2022 at 08:35:55AM +0200, Ahmad Fatoum wrote: > There is, but I'd check first if it's possible to boot from eMMC only > as a fallback if SD boot failed. On some bootroms, this is possible > and can easily be scripted in barebox with $global.bootsource > and $global.bootsource_instance variables. When I type "magicvars" I have no global.boosource. Is that a "no bootsource in your bootrom" or has this a fetaure to be enabled as a CONFIG_ at compile time? However, booting from internal MMC is normal use case, SD-Cards are only inserted for updates and if some invalid SD-Card is inserted and system does not boot because of that I can live with that. > title BeagleBone Black - M2M > version 5.17 > options rootwait > linux /boot/zImage > devicetree/boot/am335x-boneblack.dtb > linux-appendroot true > > This way, you can just type boot mmc1.1 to boot. linux-appendroot > will have barebox add a root= option pointing at the device it read > the bootloader spec file from. You'll want to set CONFIG_MMCBLKDEV_ROOTARG=y > to get root=/dev/mmcblk* fixups instead of partuuid (which might be the > same if you have the exact same image on SD and eMMC). I already investigated bootloader spec but have it much more complicated in memory. This is darn simple and allows me to boot from different partitions with this same identical setup, right? I will go for it. I have no CONFIG_MMCBLKDEV_ROOTARG=y, UUID is fine since all roots are individually formatted, no same image. But alas, the rootfs is not appended. I created an entry just like you proposed and this happens: barebox@TI AM335x BeagleBone black:/ boot mmc1.2 ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 Booting entry 'BeagleBone Black - M2M (/mnt/mmc1.2/loader/entries/boneblack.conf)' blspec: booting BeagleBone Black - M2M from mmc1 Loading ARM Linux zImage '/mnt/mmc1.2//boot/zImage' Loading devicetree from '/mnt/mmc1.2//boot/am335x-boneblack.dtb' commandline: console=ttyS0,115200n8 rootwait [...] Waiting for root device ... What could I do about this? > boot already accepts multiple boot targets to try in order, Okay, I was just not aware somehow. To use it for that. So /env/nv/boot.default will take "mmc0.1 bootchooser" with bootchooser deciding between internal mmc1.1 and mmc1.2. If i get bootloader spec booting to fly. > if detect mmc0; then > boot mmc0.1 > fi > > boot mmc1.1 Where is this scripting stuff going into? It is not boot.default (gives me errors like "no entry if ... found"), is this going into entry boot.default points to? Since I have bootloader spec not running yet, I have "insidem2m_sd bootchooser" in /env/nv/boot.default. This works well, if no SD-Card is inserted and I get a nasty red error with both variants. Without the detect mechanism in insidem2m_sd I get Booting entry 'insidem2m_sd' mount: No such file or directory could not open /mnt/mmc0.1/boot/zImage: No such file or directory ERROR: Booting entry 'insidem2m_sd' failed Booting entry 'bootchooser' with this detect mechanism I get Booting entry 'insidem2m_sd' detect: Connection timed out ERROR: Running script '/env/boot/insidem2m_sd' failed: error -127 ERROR: Booting entry 'insidem2m_sd' failed Booting entry 'bootchooser' Each time it goes to bootchooser which successfully boots internal MMC... When SD-Card is inserted it chooses it successfully in both ways, so both variants work well. > On less recent kernels, the order might change, but at least now it's > fixed (with aliases). I spent the whole day to update Kernel, bootloader, rescue SD-Cards, Install scripts so now internal mmc is mmcblk1, external SD-Card is mmcblk0 (5.10.12 -> 5.10.63). Like barebox was alaways. Kind Regards Konstantin Kletschke -- 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.kletsc...@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
Boot from SD if SD-Card is present - Beaglebone Black
Hi All, I have a Beaglebone Black whith internal MMC and external SD-Card interface. I boot from internal MMC always. The system itself aways boots from internal MMC. Is there a way - may be scriptable in boot entry - to start system from external SD-Card, if it is present? Normally I boot this way, bootchooser select system0 or system1: #!/bin/sh mount mmc1.1 global.bootm.image=/mnt/mmc1.1/boot/zImage global.bootm.oftree=/mnt/mmc1.1/boot/am335x-boneblack.dtb global.linux.bootargs.dyn.root="root=/dev/mmcblk0p2 rootfstype=ext4 rootwait" If I stop autoboot and want to use external SD-Card I manually select insidem2m_sd as a boot entry: #!/bin/sh mount mmc0.1 global.bootm.image=/mnt/mmc0.1/boot/zImage global.bootm.oftree=/mnt/mmc0.1/boot/am335x-boneblack.dtb global.linux.bootargs.dyn.root="root=/dev/mmcblk1p2 rootfstype=ext4 rootwait" Can this be something like: IF external SD-CARD IS PRESENT bootentry is insidem2m_sd ELSE bootchooser ? Please obey if you are inspecting the CMDLINE, in more recent Kernels the mmcblk0 and mmcblk1 numbering is exchanged. Kind Regards Konstantin -- 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.kletsc...@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
Re: Howto implement bootchooser <-> rauc interaction
On Wed, Jan 05, 2022 at 06:50:17PM +0100, Ahmad Fatoum wrote: > RAUC hardcodes bootstate, so that's what you need to use, unless you patch > RAUC. Dear Ahmad, thanks again for your technical advise. My wall of text indeed was intended to ask for this detail, I realized. If this "bootstate" id hardcoded (Yes, it is) I understand, what's going on. Nice! Kind Regards Happy new year Konstantin -- 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.kletsc...@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
Re: Howto implement bootchooser <-> rauc interaction
chooser: Cannot read remaining attempts for target system1, using default 3 Cannot set parameter state.system0.remaining_attempts: No such device ERROR: bootchooser: Failed to save bootchooser state: No such device Booting entry 'bootchooser' WARNING: bootchooser: Cannot read priority for target system0, using default 1 WARNING: bootchooser: Cannot read remaining attempts for target system0, using default 3 WARNING: bootchooser: Cannot read priority for target system1, using default 1 WARNING: bootchooser: Cannot read remaining attempts for target system1, using default 3 Cannot set parameter state.last_chosen: No such device Cannot set parameter state.system0.remaining_attempts: No such device Booting entry 'system0' ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 mounted /dev/mmc1.1 on /mnt/mmc1.1 [...] But userspace is fine: rauc-Message: 18:58:50.111: rauc status: marked slot rootfs.0 as good rauc status: === System Info === Compatible: insidem2m Variant: Booted from: rootfs.0 (system0) === Bootloader === Activated: rootfs.0 (system0) === Slot States === [bootloader.0] (/dev/mmcblk0p1, vfat, inactive) o [rootfs.1] (/dev/mmcblk0p3, ext4, inactive) bootname: system1 boot status: good x [rootfs.0] (/dev/mmcblk0p2, ext4, booted) bootname: system0 mounted: / boot status: good barebox-state -d: bootstate.last_chosen=2 bootstate.system0.remaining_attempts=3 bootstate.system0.priority=21 bootstate.system0.ok=0 bootstate.system1.remaining_attempts=2 bootstate.system1.priority=20 bootstate.system1.ok=0 I assume this has to do with bootchooser.state_prefix. If I change from state to bootstate (yes, brute force) I get: global excerpt: * bootchooser.state_prefix: bootstate devinfo state looks the same as previous. boot: barebox@TI AM335x BeagleBone black:/ boot ERROR: bootchooser: Cannot get state 'bootstate' Nothing bootable found on 'bootchooser' Booting entry 'insidem2m_1' ext4 ext40: EXT2 rev 1, inode_size 256, descriptor size 64 mounted /dev/mmc1.1 on /mnt/mmc1.1 [...] When I set: * bootchooser.state_prefix: state.bootstate I get best of both worlds! "devinfo state" still the same as previous two cases (logical, since DT setup is the same, only bootchooser.state_prefix changed), "bootchooser -i" looks sane, booting happens w/o any error, and userspace (barebox-state -d, rauc status, barebox-state -g bootstate.system0.ok) too! Wall of text, two questions: Is this resulting setup (DT with bootstate parent, state_prefix: state.bootstate) sane? Can the variant without the boostate variant work too? If it was the other way around, userspace working w/o the bootstate variant but bnot _with_ I would say additional configuration required or something, but this way... I would like to understand this fully. Kind Regards Konstantin -- 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.kletsc...@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
Re: Howto implement bootchooser <-> rauc interaction
On Fri, Dec 17, 2021 at 02:08:01PM +0100, Ahmad Fatoum wrote: > git remote add stable > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git > git fetch stable --tags > git cherry-pick 663a18271 > > Or just update to a more recent kernel release. I need to figure out how the cherry picking works and for updating the kernel I need to cope with "my" yocto framework I already deployed here. The 5.10 branch seems to be the hottest shit, I will figure out how to implement my own linux based upon the existing build framework... > reg = <0x300 0xffd00>; I forgot to substract 0x300 from the length, of course! Thanks for clarification. > Could be. You'd have to know how the on-disk partition table looks like, > but I'd guess that partitions are aligned to 1M boundaries and this is > as you describe directly beneath it. Of course, I do not know their layout neither, just to understand the addressing/length theme. Thank You Ahmad! -- 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.kletsc...@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
Re: Howto implement bootchooser <-> rauc interaction
On Fri, Dec 17, 2021 at 11:00:28AM +0100, Ahmad Fatoum wrote:
> You need to tell bootchooser which state to take via bootchooser.state_prefix,
> but that's it. No need to mess direclty with the state variables.
Okay, this sounds reasonable.
> See https://elinux.org/images/9/9d/Barebox-bells-n-whistles.pdf Slide 26 for
> an example
> /env/nv for a redundant boot setup.
Thank you, I will investigate.
> It's a two step thing. First you define your targets, e.g. system0 and system1
> Then bootchooser knows the name of the state variables to consult and then
> basically does boot ${global.bootchooser.system0.boot}.
Okay, I need to figure this out.
Thanks again for your patience, I will test out all your hints and
examples and instructios, thank you!
Kind Regards
Konstantin
--
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.kletsc...@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
Re: Howto implement bootchooser <-> rauc interaction
Hi :-) On Fri, Dec 17, 2021 at 10:46:42AM +0100, Ahmad Fatoum wrote: > It was backported to stable in v5.10.20. Backport commit is 663a18271. Sorry my git/google-foo is unsufficient, how do I get my hands on this commit? > > So one has to take care of the parent note size being big enough to contain > > the sum of > > all length and thse itself must not overlap, right? > > Yes. Device Tree compiler helps here a bit by warning if two nodes on the > same bus > have the same base address. Okay. > Open Firmware. It's the original standard that described device trees. Oh, I wasn't aware, thanks for the information. > > On the other hand, I could access plenty of space unallocated after the MBR > > if 1st partition > > starts at a late sector like 1024 or so. > > Latter is what I usually do. Okay. > arch/arm/dts/imx6qdl-prti6q-emmc.dtsi places it on eMMC. Check it out. Yes, I will do, thank you! > > And is doing this state thing in a file (for example on the 1st FAT where > > barebox.env is) > > for barebox and raux/barebox-state possible or not? > > FAT isn't power-fail safe. It's ok for reading or writing stuff during > development (e.g. environment), but you really don't want to use it > for barebox-state that's meant to be power-fail safe. Okay again, I am convinced about the no-file-in-FAT state. So, just to be shure for the state OF partition placed after the MBR before 1st MBR partition: If I have 1st partition's start sector being 2048 I hafe plenty of room before this after the MBR. The barebox state OF partition should be in there and I could place it at reg = <0x300 0xf> because the MBR ends at 0x1ff and the 1st partition starts at sector 2048 ( 2048*512byte=1MB=0x1), is that correct, is the reg addressing done this way? Of course a length of 0xf is far too much, just to get a picture. Also to transfer this to an OF partition in a MBR partition. The container partition reg = <0xc 0x4> in imx6qdl-prti6q-emmc.dtsi seems to be directly going to below a MBR partiton starting at 2048th sector with size 256kB, correct? Thanks for your patience! Regards Konstantin 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.kletsc...@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
Fwd: Re: Howto implement bootchooser <-> rauc interaction
I forgot to address the ML.
May be somebody else is interested!
:-/
Original Message
SUBJECT:
Re: Howto implement bootchooser <-> rauc interaction
DATE:
2021-12-16 19:24
FROM:
Konstantin Kletschke
TO:
Ahmad Fatoum
On 2021-12-15 11:50, Ahmad Fatoum wrote:
Ye, DT here looks just like arch/arm/dts/imx6qdl-phytec-state.dtsi
I think you are 100% right. It is borrowed from
https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/
and I thing this exact file is displayed as an example there.
This is fixed in Linux upstream since 0445efacec75 ("nvmem: core: skip
child nodes not
matching binding"), first included with v5.12-rc1. This has been
backported to older
Okay, this information is extremely useful. I have seen your intital
patch series but was
not able yet to gather information what commit in what time relates to
roughly what
kernel version. So I am involved because I have 5.10.1n here. I will
check to update
to a newer one but do you have a backport for this available by chance
for 5.10.1x?
The parent node has #address-cells and #size-cells, which describe how
much 32-bit
cells are offset and length. For #address-cells = 1 and #size-cells =
1, X is offset
and Y is length.
So one has to take care of the parent note size being big enough to
contain the sum of
all length and thse itself must not overlap, right?
What me bugs more is, how should a devicetree setup look like (is
there a reasonable example?)
to make the same in a file in the first FAT partition, is this
possible? In the state specification
I read it should be able to be done by a file but ... I don't get it.
I can't follow. What do you want to place in the FAT partition? The
state itself?
The DT describing it? What bothers you about the current setup? (DT
description
and state in EEPROM).
I am sorry I did create confusion.
I did a mistake somehow. When I have the EEPROM setup up and running
(may be tomorrow? Always other
work looks more important) this was only for me to understand
barebox-state fully to
work with this for production use later upon.
Because the mistake is, I _totally_ forgot when in production the
Beaglebone Black I2C EEPROM
is write protected. The EEPROM's WP pin is hard pulled up on those
boards with no chance
other than solder a wire to the pin to ground (against the pullup
resistor). I forgot,
my daily work golden example has a wire but we sell so much that I must
avoid using
the EEPROM because I cant solder wires onto every BBB.
I need to put the state somewhere else, into the MBR, before partition
table (1st partition?)
or I need to find some NVRAM elsewhere on the board (PHY, CPU...).
You can place state in EEPROM. It looks very similar to your snippet
above,
but your backend partition will be a MMC OF partition.
That's indeed a bit rough around the edges. You can keep unpartitioned
space at the start
of the MMC device and partition it with OF and have regular MBR/GPT
partition start at
a later offset. barebox will warn you if they overlap.
So state in MMC will be an OF partition which must or be covered or
overlap with MBR
partitioning, right? What does the "OF" mean?
On the other hand I am shure in MBR the 1st 446 bytes are available
because the TI am335x
CPU is ignoring it while searching for a bootable flagged FAT and loads
BL from there...
On the other hand, I could access plenty of space unallocated after the
MBR if 1st partition
starts at a late sector like 1024 or so.
And what I understood from the examples, documentation is how to access
exactly what byte
in an EEPROM, but how do I setup and access the bytes at 0x100 to 0x300
in the MMC at
mmc1 interface or the bytes 0x1000 to 0x2000?
And is doing this state thing in a file (for example on the 1st FAT
where barebox.env is)
for barebox and raux/barebox-state possible or not?
For devices with an EEPROM, I'd use EEPROM for state over everything
else.
You are right, I will search for some place rather than the file or MMC
thingy because
i chose it because it looks most convenient, but as said, Write Only in
produktion.
If your only issue is the kernel error above, just import the patch
(or update to a newer more shiny Linux release :-)
No, no problem with either updating the kernel or patching it, the
latter is at the project's
state actually more convenient I - admit.
HTH.
Very much, thanks for your friendly elaboration :-)
Regards
Konstantin
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Howto implement bootchooser <-> rauc interaction
On 2021-12-15 11:56, Ahmad Fatoum wrote: I think Roland meant that you shouldn't rely on the _mutable_ environment for production. It's nice to test out stuff, but once you have figured out what you need, add it to the built-in environment (e.g. arch/arm/ Okay, then I got it - the intention of Roland. Compiled default environment is no problem. But regarding required bootchooser variables: what of those are required? I said I utilised https://bootlin.com/blog/another-system-update-adventure-with-rauc-barebox-yocto-project/ there is the barebox-state DT tree setup explained (a bit) and then it points out [...]Now we have to add bootchooser variables associated to both targets in arch/arm//env/nv[...] Which is rather abstract on how to do this, especially, if I have bootstate.system0.remaining_attempts in the DT, why should I replicate this in arch/arm//env/nv? Or is there a connection needed to be created? Which variables need to be specified? Isn't it already there? > barebox@TI AM335x BeagleBone black:/ devinfo state > Parameters: > bootstate.last_chosen: 0 (type: uint32) > bootstate.system0.ok: 0 (type: uint32) > bootstate.system0.priority: 21 (type: uint32) > bootstate.system0.remaining_attempts: 3 (type: uint32) > bootstate.system1.ok: 0 (type: uint32) > bootstate.system1.priority: 20 (type: uint32) > bootstate.system1.remaining_attempts: 3 (type: uint32) > dirty: 0 (type: bool) > init_from_defaults: 0 (type: bool) > save_on_shutdown: 1 (type: bool) > Is bootchooser smart enough to gather system0 and system1 as bootable entries/possibilities? > barebox@TI AM335x BeagleBone black:/ bootchooser > ERROR: bootchooser: Target list $global.bootchooser.targets is empty > No bootchooser found May be this is my problem: hand is manageable, because you restrict what variables are available and how they interact with the rest of the system. ? What I mixed into my not so elaborated mail is a SIDE QUEST: I can boot a bootloader spec equipped partitio like this: barebox@TI AM335x BeagleBone black:/ boot mmc1.2 How do I make a boot entry "system0" a boot.default variable can point to and also a member of bootchooser.targets? I tried mmc1.2 or "boot mmc1.2" as system0 content but that did not work... Kind Regards Konsti ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Howto implement bootchooser <-> rauc interaction
On 2021-12-05 23:55, Roland Hieber wrote: You probably also want to delete your bootchooser variables from the env Are you shure about that? I read some example/documentation at bootlin.com doing/presenting a nice phytec device tree for EEPROM state but later on it points out to "[...]add bootchooser variables associated to both targets in arch/arm//env/nv[...]" When I utilize "devinfo state" (with all global/nv bootchoser variables removed) I get barebox@TI AM335x BeagleBone black:/ devinfo state Parameters: bootstate.last_chosen: 0 (type: uint32) bootstate.system0.ok: 0 (type: uint32) bootstate.system0.priority: 21 (type: uint32) bootstate.system0.remaining_attempts: 3 (type: uint32) bootstate.system1.ok: 0 (type: uint32) bootstate.system1.priority: 20 (type: uint32) bootstate.system1.remaining_attempts: 3 (type: uint32) dirty: 0 (type: bool) init_from_defaults: 0 (type: bool) save_on_shutdown: 1 (type: bool) Is bootchooser smart enough to gather system0 and system1 as bootable entries/possibilities? For bootchooser.targets... My system is not proven to work (I just sent a different mail with my other issues to this thread) yet, may be there are other issues hidden, but I do not get this part. I created two boot entries system0 and system1 in /env/boot/ with content mmc1.1 (for system0) and mmc1.2 (for system1.2). Both are bootloader-spec-enabled partitions. What me bothers is, "boot mmc1.1" works, "boot system0" not. How do I properly make a bootchoser entry for mmc1.1? If no variables are required, where could be the cuplrit for this: barebox@TI AM335x BeagleBone black:/ bootchooser ERROR: bootchooser: Target list $global.bootchooser.targets is empty No bootchooser found Kind Regards, Konsti ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Howto implement bootchooser <-> rauc interaction
Dear Trent, dear mailing list people,
I managed to - somehow - utilize an onboard EEPROM for this.
On 2021-12-03 18:52, Trent Piepho wrote:
Yes you can use your EEPROM to store state and use rauc. One could
This is barebox devicetree I come up with:
/ {
aliases {
state = &state_eeprom;
};
state_eeprom: state_eeprom {
#address-cells = <1>;
#size-cells = <1>;
compatible = "barebox,state";
magic = <0xcafebabe>;
backend-type = "raw";
backend = <&backend_state_eeprom>;
backend-storage-type = "direct";
backend-stridesize = <54>;
/* keep-previous-content; */
bootstate {
#address-cells = <1>;
#size-cells = <1>;
last_chosen {
reg = <0x0 0x4>;
type = "uint32";
};
system0 {
#address-cells = <1>;
#size-cells = <1>;
remaining_attempts {
reg = <0x4 0x4>;
type = "uint32";
default = <3>;
};
priority {
reg = <0x8 0x4>;
type = "uint32";
default = <21>;
};
ok {
reg = <0xc 0x4>;
type = "uint32";
default = <0>;
};
};
system1 {
#address-cells = <1>;
#size-cells = <1>;
remaining_attempts {
reg = <0x10 0x4>;
type = "uint32";
default = <3>;
};
priority {
reg = <0x14 0x4>;
type = "uint32";
default = <20>;
};
ok {
reg = <0x18 0x4>;
type = "uint32";
default = <0>;
};
};
};
};
};
&i2c0 {
baseboard_eeprom@50 {
partitions {
compatible = "fixed-partitions";
#size-cells = <1>;
#address-cells = <1>;
backend_state_eeprom: state@0 {
reg = <0x0 0x100>;
label = "state-eeprom";
};
};
};
};
And this kinda works. And reveals more questions, I am not familiar with
barebox-state and - I admit - devicetree, yet. The problem was for me to
address
the onboard I2C EEPROM but I managed it by digging with devinfo, this is
a snippet
from "devinfo i2c0":
baseboard_eeprom@50 {
compatible = "atmel,24c256";
reg = <0x50>;
#address-cells = <0x1>;
#size-cells = <0x1>;
baseboard_data@0 {
reg = <0x0 0x100>;
};
partitions {
compatible = "fixed-partitions";
#size-cells = <0x1>;
#address-cells = <0x1>;
state@0 {
reg = <0x0 0x100>;
label = "state-eeprom";
phandle = <0x5d>;
};
};
};
Does this and wit device tree look reasonable?
barebox, booting, puts out:
state: New state registered 'state'
state: Using bucket 0@0x
What I wonder is, when this works, is in linux for the userspace the
EEPROM still
write- and readable or blocked? I cant't judge because I suffer from
this:
When linux boots, this happens:
nvmem 0-00501: nvmem: invalid reg on
/ocp/interconnect@44c0/segment@20/target-module@b000/i2c@0/baseboard_eeprom@50/partitions
at24: probe of 0-0050 failed with error -22
Is this still something like this:
https://lkml.org/lkml/2020/4/28/411
?
What are those reg = < X Y > entries, are those in this use case offset
+ length?
What me bugs
Re: Howto implement bootchooser <-> rauc interaction
On 2021-12-05 23:55, Roland Hieber wrote: In short: barebox state is meant to be read (and written) from the Linux world too, in contrast to the barebox env, which is only meant to be used by barebox itself. Thanks for the clear statement, I wont mess with environment for that anymore :) You probably also want to delete your bootchooser variables from the env so they don't cause confusion :-) You can inspect the state variables with 'devinfo state', and set them via 'state.variablename=value'. They should also show up in 'global'. I will clear this up, I will check to move this into the state.* namespace. Regards Konsti ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Howto implement bootchooser <-> rauc interaction
Dear Trent, thank you so much for this comprehensive clarification. On 2021-12-03 18:52, Trent Piepho wrote: You should add a node of "barebox,state" to the *Barebox* device tree. I will try to prepare a proper device tree. It was this special tiny detail: must have state node ALSO in the Linux device tree. But you do not need to add it manually! Barebox will automatically inject the state What I was not aware of, yet! I think I got the point now. For this to work, you need to have Barebox give the kernel the Linux device tree when booting. This is the normal way to boot now. All current docs tell you to do this. There was a much older style where the dtb was appended to the kernel image and the kernel found it itself without involving the bootloader. I assume this will not work, but I think Barebox state did not exist when I last booted a system this way, so I haven't tried. Yes, no problem, I stumpled upon the combined image+dtb thingy once in our but the new stuff I am working upon is barebox passing the dtb to the kernel. Thanks also for explaining the possibilities and requirements, I will figure a nice way to do this on my Beaglebone Black now. Kind Regards Konstantin ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Howto implement bootchooser <-> rauc interaction
Hi All, finally I managed to integrate rauc and barebox-state into my yocto build. I am not sure completely yet if this is done properly, though. I want to make this bootchoser-alternate-rootfs-switchover-thingy working properly with bootchooser detecting reset cause and additionally rauc/barebox-state marking successful boots. The documentation looks very good and comprehensive overall but may be its me not getting the part how and where the shared data is properly stored. Please let me briefly explain what I already have (targets mmc1.1 and mmc1.2 are bootloader spec entries): bootchoser variables defined in barebox (preliminary in nv namespace, does it need to go elsewhere?): barebox@TI AM335x BeagleBone black:/ nv allow_color: true autoboot_timeout: 3 boot.default: bootchooser insidem2m bootchooser.last_chosen: 2 bootchooser.retry: 1 bootchooser.system1.boot: mmc1.1 bootchooser.system1.default_attempts: 3 bootchooser.system1.default_priority: 21 bootchooser.system1.priority: 21 bootchooser.system1.remaining_attempts: 0 bootchooser.system2.boot: mmc1.2 bootchooser.system2.default_attempts: 3 bootchooser.system2.default_priority: 20 bootchooser.system2.priority: 20 bootchooser.system2.remaining_attempts: 1 bootchooser.targets: system1 system2 user: none barebox@TI AM335x BeagleBone black:/ bootchooser -i Good targets (first will be booted next): system2 id: 2 priority: 20 default_priority: 20 remaining attempts: 1 default attempts: 3 boot: 'mmc1.2' Disabled targets: system1 id: 1 priority: 21 default_priority: 21 remaining attempts: 0 default attempts: 3 boot: 'mmc1.1' disabled due to remaining attempts = 0 last booted target: system2 When linux is booted rauc complains: (rauc:396): rauc-WARNING **: 08:32:31.311: Failed getting primary slot: Failed getting primary slot: No content to read EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null) rauc-Message: 08:32:31.729: rauc status: GDBus.Error:org.gtk.GDBus.UnmappedGError.Quark._g_2dio_2derror_2dquark.Code30: Failed marking 'rootfs.1' as good: Failed to run barebox-state: Child process exited with code 1 # rauc status (rauc:583): rauc-WARNING **: 08:33:46.622: Failed getting primary slot: Failed getting primary slot: No content to read === System Info === Compatible: insidem2m-s Variant: Booted from: rootfs.1 (system2) === Bootloader === Activated: (null) ((null)) === Slot States === o [rootfs.1] (/dev/mmcblk0p3, ext4, booted) bootname: system2 mounted: / boot status: bad o [rootfs.0] (/dev/mmcblk0p2, ext4, inactive) bootname: system1 boot status: bad # barebox-state -d Neither /aliases/state nor /state found # cat /proc/cmdline bootchooser.active=system2 console=ttyO0,115200n8 root=/dev/mmcblk0p3 rootfstype=ext4 rootwait This is /etc/rauc/system.conf: # cat /etc/rauc/system.conf [system] compatible=insidem2m-s bootloader=barebox [keyring] path=ca.cert.pem [slot.rootfs.0] device=/dev/mmcblk0p2 type=ext4 bootname=system1 [slot.rootfs.1] device=/dev/mmcblk0p3 type=ext4 bootname=system2 Actually I fully understand that rauc/barebox-state has no info where to store its marking to be read later for barebox. Even /boot/ is not mounted with the barebox environment in it (/dev/mmcblk0p1 vfat carries bootloader images and barebox.env). Is it possible to utilize that for interaction? Is it a must to utilize the barebox-state framework for this? I read very much about this but everytime it is referenced as a device tree extension which is provided as an example in arch/arm/dts/state-example.dtsi. Every doc or walk through refers to a device tree. But - sorry - does this go into the barebox device tree? Or into the kernel device tree? Or both? Both parts needs to be informed but how does userspace rauc/barebox-state access stuff provided by device tree? I could easily utilize the I2C EEPROM on my Beaglebone Black for this but how should this look like for barebox and kernel? Kind Regards Konstantin ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
yocto integration - best practice
Hi All, I wonder how to properly integrate bare box into my yocto. I read many other examples in the internet how other people do this and I am a little stupid now. I have a yocto poky image up and running based on their beaglebone-yocto subset which can be utlilized in my case with a rather minimal setup with a local.conf only. This since I by accident actually use a Beaglebone Black board. I added my own meta-insidem2m layer also and in this layer I modify kernel config, integrate out of kernel modules and other stuff. Also barebox patches (for default boot configs) are added from there. The local.conf shrunk to a rather minimal content, because I have an own distro in it with three different images. Additionally I integrated meta-barebox successfully into this and use barebox in my daily development work to boot from internal MMC and external SD-Card. What I wonder, what is need to be done to integrate MLO and barebox.bin into the SD-Card image? It is not really importand, since copying the files by hand into the boot partition works fine and the final install goes into the internal MMC flash anyway. But it would be fine to get barebox initially into the image to generate immediately bootable images for SD-Card. It would be possible to raw write such an image to the internal MMC 1:1 also... But where is the hook to exchange u-boot by barebox in the yocto framework? Can it be done in an own distro? I find bootloader stuff dealt with in /conf/machine/*, is it necessary to be done there? This would be challenging a bit since then a kernel and other system stuff has to be recreated too (tried that) and relying/utilizing the beaglebone stuff is not possible anymore. Additionally I see many companies heavily providing software support for their boards with yocto and barebox without /conf/machine/* stuff (if I read right). Other way round: I plan to fully integrate RAUC into our software, what is best preparation for this regarding barebox integration? Kind Regards Konstantin Kletschke ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
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
smime.p7s
Description: S/MIME cryptographic signature
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
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 '.
> 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
smime.p7s
Description: S/MIME cryptographic signature
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
> 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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
> 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 = 300) is a 8250 [1.713812] console [ttyS0] enabled [1.718482] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 31, base_baud = 300) is a 8250 [1.728498] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 32, base_baud = 300) is a 8250 [1.738387] 481a6000.serial: ttyS3 at MMIO 0x481a6000 (irq = 33, base_baud = 300) is a 8250 [1.748351] 481a8000.serial: ttyS4 at MMIO 0x481a8000 (irq = 34, base_baud = 300) is a 8250 [1.758188] 481aa000.serial: ttyS5 at MMIO 0x481aa000 (irq = 35, base_baud = 300) 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 = 300) 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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
> 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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Compiled in boot environment and dtbo files
> 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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Compiled in boot environment and dtbo files
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.kletsc...@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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Beaglebone Black defconfigs
>> And a coloured command prompt! Are you guys serious? Nice! > > We're not in the 90ies anymore, are we? ;) Yes, there have many things happen when I left bootloader/kernel programming, many. And yesterday I realised my u-boot was not reading my uEnv.txt, never did, neither where I put it. So I bet faster is getting barebox to work than finding out how to make u-boot eating my uEnv.txt. > Indeed that address looked suspicous to me, but I grepped the sourcecode > for 0x4020f010 and 0x4020f0 afterwards. Okay, I am “glad" you needed to verify with grep :-D Konsti smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Beaglebone Black defconfigs
> On 11. Jun 2021, at 13:08, Sascha Hauer wrote: > > Hi Konsti, nice to see you here :) Hi Sascha :-D Nice to see you, too. > That's the config for the beaglebo*ard*, for the beaglebo*ne* you'll > have to use the omap_defconfig. This is the config for all omap/am33xx > boards. The resulting image is images/barebox-am33xx-beaglebone.img. Thank. You. Very. Much. E voila, second stage is fine: […] barebox 2021.05.0-00093-g7689055a8 #5 Fri Jun 11 13:24:00 CEST 2021 Board: TI AM335x BeagleBone black detected 'BeagleBone Black’ […] And a coloured command prompt! Are you guys serious? Nice! > Looks consistent. 0x4020f010 is OMAP3_SRAM_SCRATCH_SPACE + 0x10 used in > beagle_board_init_sdram(). It seems you start a binary for the > beagleboard on your beaglebone. All your assumptions are correct, I have a nice boot loader-coloured-prompt now and will figure out now to give it my kernel to boot. Expect more stupid questions soon :-) But you don’t tell me you know this address from brain muscle memory? Regards Konsti smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: Beaglebone Black defconfigs
Dear Ahmad, thanks for your kind explanations, I really appreciate it. As Sascha already pointed out, my 1st stage was beaglebone and the second was beagleboard. Which explains my confusion because it was reasonable. May be I discovered this, if I had investigated more properly. Regards Konstantin smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Beaglebone Black defconfigs
Hello, I am currently trying to bring up barebox for my Beaglebone Black devices. I did an "ARCH=arm CROSS_COMPILE=arm-buildroot-linux-gnueabihf- make am335x_mlo_defconfig”, make and copied resulting barebox-am33xx-beaglebone-mlo.img to MLO into my FAT boot partition. Then I did "ARCH=arm CROSS_COMPILE=arm-buildroot-linux-gnueabihf- make omap3530_beagle_defconfig”, make and copied resulting barebox-beagleboard.img to barebox.bin into my boot FAT. Is the the different prefix in the defconfigs (am33… vs. omap35…) reasonable? Is this approach generally reasonable? Many references in internet to matching defconfigs I found refer to non existing ones, there seems to happen great overhaul meanwhile. I am also asking because, well, it does not work: barebox 2021.05.0-00093-g7689055a8 #2 Fri Jun 11 09:01:36 CEST 2021 Board: TI AM335x BeagleBone detected 'BeagleBone Black' omap-hsmmc 4806@0.of: registered as mmc0 omap-hsmmc 481d8000@0.of: registered as mmc1 booting from MMC mmc1: detected MMC card version 5.1 mmc1: registered mmc1 unable to handle paging request at address 0x4020f010 pc : [<8ffbbd5a>]lr : [<8ffbbd89>] sp : 9ffeffb0 ip : fp : 00014e2c r10: 00125920 r9 : 8ffbbce5 r8 : 9ffe4000 r7 : 8000 r6 : 9fe1a46e r5 : 402f0400 r4 : 8ffbbcdc r3 : 060a r2 : 4020f010 r1 : abe742c3 r0 : 8000 Flags: nzCv IRQs off FIQs on Mode SVC_32 no stack data available This repeats endlessly. I investigated the data sheet and if I am correct 0x4020f010 seems to be a reserved area in L3 memory map. Kind Regards Konsti 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.kletsc...@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 smime.p7s Description: S/MIME cryptographic signature ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
