Howto implement bootchooser <-> rauc interaction

[Konstantin Kletschke]

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 at 50  {
		partitions {
			compatible = "fixed-partitions";
			#size-cells = <1>;
			#address-cells = <1>;
			backend_state_eeprom: state at 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 at 50 {
                 compatible = "atmel,24c256";
                 reg = <0x50>;
                 #address-cells = <0x1>;
                 #size-cells = <0x1>;
                 baseboard_data at 0 {
                         reg = <0x0 0x100>;
                 };
                 partitions {
                         compatible = "fixed-partitions";
                         #size-cells = <0x1>;
                         #address-cells = <0x1>;
                         state at 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 at 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 at 44c00000/segment at 200000/target-module at b000/i2c at 0/baseboard_eeprom at 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 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.

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 see, I read much about partitions in MMC being OF partitions, how do 
they live among with
mmcblk0p1 .. mmcblk0p3?

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

Kind Regards
Konsti