Hi, On 16.12.21 20:42, Konstantin Kletschke wrote: > I forgot to address the ML. > 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? It was backported to stable in v5.10.20. Backport commit is 663a18271. >> 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? Yes. Device Tree compiler helps here a bit by warning if two nodes on the same bus have the same base address. >>> 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? Open Firmware. It's the original standard that described device trees. > 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. Latter is what I usually do. > 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? arch/arm/dts/imx6qdl-prti6q-emmc.dtsi places it on eMMC. Check it out. > 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. You can of course use a MBR partition, but raw, without a file system. >> 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@xxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
