mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@arri.de>
To: barebox@lists.infradead.org
Subject: state framework, fixed-partitions, eeprom and linux
Date: Mon, 3 Feb 2020 13:12:29 +0100	[thread overview]
Message-ID: <12186927.ML1T7lbObL@n95hx1g2> (raw)

I've tried to use the state framework with an SPI eeprom as described here:
https://www.barebox.org/doc/latest/user/state.html#eeprom

The eeprom uses a "partition" for the state data:
------------------------8<---------------------------
eeprom@50 {
        partitions {
                compatible = "fixed-partitions";
                #size-cells = <1>;
                #address-cells = <1>;
                backend_state_eeprom: eeprom_state_memory@400 {
                        reg = <0x400 0x100>;
                        label = "state-eeprom";
                };
        };
};
------------------------>8---------------------------


It looks like there a 2 different concepts of having partitions in flashes:
1. As direct subnodes to the eeprom/flash
2. As subnodes within a "fixed-partition" subnode (as in the example above)

From linux/Documentation/devicetree/bindings/mtd/partition.txt:
"For backwards compatibility partitions as direct subnodes of the flash device 
are supported. This use is discouraged."

So using the 2nd approach is right, isn't it?

Trying to use this with the at25 nvmem driver in Linux, I get the following 
error:

nvmem spi0.00: nvmem: invalid reg on /soc/aips-bus@2000000/spba-bus@2000000/
spi@2008000/fram@0/partitions

Looking into nvmem_add_cells_from_of() in the linux sources, the NVMEM code 
seems to differ from the MTD core. It only expects the partitions as direct 
subnodes (without "fixed-partitions").

In Barebox, of_partition_fixup() can be configured using the 
global.of_partition_bindingof_partition_binding variable. But I couldn't find 
any user of this and this would probably affect both, NVMEM and MTD.

From the barebox point of view it seems best to add "fixed-partitions" support 
to Linux NVMEM. Any other suggests?

regards
Christian




_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

             reply	other threads:[~2020-02-03 12:12 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-03 12:12 Christian Eggers [this message]
2020-02-03 17:17 ` Ahmad Fatoum
2020-02-03 17:47   ` Ahmad Fatoum
2020-02-04 13:06     ` Christian Eggers
2020-02-04 13:45       ` Ahmad Fatoum
2021-03-05 20:35       ` Ahmad Fatoum

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=12186927.ML1T7lbObL@n95hx1g2 \
    --to=ceggers@arri.de \
    --cc=barebox@lists.infradead.org \
    /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