From: Konstantin Kletschke <konstantin.kletschke@inside-m2m.de>
To: barebox@lists.infradead.org
Cc: Trent Piepho <trent.piepho@igorinstitute.com>
Subject: Re: Howto implement bootchooser <-> rauc interaction
Date: Tue, 14 Dec 2021 22:28:46 +0100 [thread overview]
Message-ID: <c4ae26b8698992ad37f201101795b1bb@inside-m2m.de> (raw)
In-Reply-To: <CAMHeXxOoXjqtSGXdE73oROUk9ybFmFv7gi8PtzLsKn=iH+FXLA@mail.gmail.com>
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@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2021-12-14 21:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-03 12:40 Konstantin Kletschke
2021-12-03 17:52 ` Trent Piepho
2021-12-05 22:55 ` Roland Hieber
2021-12-06 8:52 ` Konstantin Kletschke
2021-12-14 21:40 ` Konstantin Kletschke
2021-12-15 10:56 ` Ahmad Fatoum
2021-12-16 19:35 ` Konstantin Kletschke
2021-12-17 10:00 ` Ahmad Fatoum
2021-12-17 12:50 ` Konstantin Kletschke
2022-01-03 15:24 ` Roland Hieber
2021-12-06 8:30 ` Konstantin Kletschke
2021-12-14 21:28 ` Konstantin Kletschke [this message]
2021-12-15 10:50 ` Ahmad Fatoum
[not found] ` <297b3425baa118783dccb6446900fbfa@inside-m2m.de>
2021-12-16 19:42 ` Fwd: " Konstantin Kletschke
2021-12-17 9:46 ` Ahmad Fatoum
2021-12-17 12:43 ` Konstantin Kletschke
2021-12-17 13:08 ` Ahmad Fatoum
2021-12-17 14:21 ` Konstantin Kletschke
2021-12-22 14:05 ` Konstantin Kletschke
2022-01-05 17:50 ` Ahmad Fatoum
2022-01-06 9:59 ` Konstantin Kletschke
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c4ae26b8698992ad37f201101795b1bb@inside-m2m.de \
--to=konstantin.kletschke@inside-m2m.de \
--cc=barebox@lists.infradead.org \
--cc=trent.piepho@igorinstitute.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox