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@xxxxxxxxxxxxx>
TO:
Ahmad Fatoum <a.fatoum@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
