Fwd: Re: Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

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 <konstantin.kletschke at inside-m2m.de>

  		TO:
  		Ahmad Fatoum <a.fatoum at pengutronix.de>

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