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?
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
?
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
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
