From: Ahmad Fatoum <a.fatoum@pengutronix.de>
To: Stefano Manni <stefano.manni@gmail.com>,
barebox <barebox@lists.infradead.org>
Subject: Re: fixed partitions issue
Date: Wed, 30 Jul 2025 14:40:20 +0200 [thread overview]
Message-ID: <bbc6d12d-4c8a-463a-ae7e-8b2f36afebb9@pengutronix.de> (raw)
In-Reply-To: <8JK70T.9NOP3AIQTVWR@gmail.com>
Hi Stefano,
On 7/30/25 12:45, Stefano Manni wrote:
> Dear all,
>
> I'm encountering an issue with fixed-partitions on spinor with
> v2025.07.0 that
> was not there in v2025.01.0.
>
> The partitions are configured as follows:
>
> partitions {
> compatible = "fixed-partitions";
> #size-cells = <1>;
> #address-cells = <1>;
>
> barebox: partition@0 {
> label = "barebox";
> reg = <0x0 0x0100000>;
> };
>
> barebox_env: partition@100000 {
> label = "barebox-env";
> reg = <0x0100000 0x100000>;
> };
>
> barebox_state: partition@200000 {
> label = "barebox-state";
> reg = <0x0100000 0x100000>;
The first cell is the start address, so this should be 0x200000, not
0x0100000.
> };
> };
>
> It seems to me the partition offsets (0, 0x100000, 0x200000) are not
> taken into account
The unit address in the node name is never parsed as address, neither in
barebox or in Linux. What's in reg is what matters.
> so the results is that all the partitions point to the same piece of
> memory. That's how I tested it:
The devinfo command without arguments will show you the start/end
address of all partitions.
> Do you have any hint? After the changes on drivers/of/partition.c
> between v2025.01.0 and v2025.07.0
I don't know how it worked before, but that DT description is buggy.
What changed is that barebox doesn't refuse identical partitions, it
just makes the dupes a link to the first registered.
Do you maybe have board code that calls devfs_add_partition()?
The output of devinfo in both versions would be useful as well to
understand this.
> shall I need to change something in my dts?
It should work after fixing the reg properties. There has been changes
around the partition handling stuff, but they affected only fixed
partitions in eMMC/EEPROM. The MTD binding is an upstream binding and no
intentional changes happened here.
Cheers,
Ahmad
>
> Best,
> Stefano
>
>
>
>
>
>
>
>
>
>
>
>
--
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 |
next prev parent reply other threads:[~2025-07-30 12:42 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 10:45 Stefano Manni
2025-07-30 12:40 ` Ahmad Fatoum [this message]
2025-07-31 17:43 ` Stefano Manni
2025-08-05 5:24 ` 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=bbc6d12d-4c8a-463a-ae7e-8b2f36afebb9@pengutronix.de \
--to=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=stefano.manni@gmail.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