Re: Howto implement bootchooser <-> rauc interaction

[Ahmad Fatoum <a.fatoum@pengutronix.de>]

Hello Konstantin,

On 14.12.21 22:28, Konstantin Kletschke wrote:
> 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?

Ye, DT here looks just like arch/arm/dts/imx6qdl-phytec-state.dtsi
and that's ok. You could increase backend-stridesize a bit to
be able to easily add non-bootchooser variables
in future if you like, but you don't have to.

> barebox, booting, puts out:
> 
> state: New state registered 'state'
> state: Using bucket 0@0x00000000
> 
> 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@44c00000/segment@200000/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
> 
> ?

Ye. How device trees should be interpreted is called a binding. The Linux nvmem driver
didn't adhere to the nvmem binding, which caused eeprom probe to fail, as you see.

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
kernels as well. You'll need that patch if you have CONFIG_NVMEM enabled in the kernel.

You can work around it in barebox, but the aforementioned kernel patch is the
proper fix.

> What are those reg = < X Y > entries, are those in this use case offset + length?

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.

> 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).

> Alternatively, in the MBR I have on my MMC ther should be plenty of bytes be available for this,
> can I address areas raw while a partition is over it?

You can place state in EEPROM. It looks very similar to your snippet above,
but your backend partition will be a MMC OF partition.

> You see, I read much about partitions in MMC being OF partitions, how do they live among with
> mmcblk0p1 .. mmcblk0p3?

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.

> The problem is, my EEPROM aproach is nice to learn but in production it is hard write proteccted.
> I just realized.

For devices with an EEPROM, I'd use EEPROM for state over everything else.
If your only issue is the kernel error above, just import the patch
(or update to a newer more shiny Linux release :-)

HTH.

Cheers,
Ahmad

> 
> Kind Regards
> Konsti
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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