From: Tom Rini <trini@konsulko.com>
To: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
Cc: Miquel Raynal <miquel.raynal@bootlin.com>,
Patrice Chotard <patrice.chotard@foss.st.com>,
Francesco Dolcini <francesco@dolcini.it>,
Simon Glass <sjg@chromium.org>,
u-boot@lists.denx.de,
Marcel Ziswiler <marcel.ziswiler@toradex.com>,
Francesco Dolcini <francesco.dolcini@toradex.com>,
Marek Vasut <marex@denx.de>,
linux-mtd@lists.infradead.org
Subject: Re: [PATCH v1 0/3] fdt: Fix mtparts fixup
Date: Thu, 23 Feb 2023 17:35:10 -0500 [thread overview]
Message-ID: <Y/fqHjw4e8LSaz1e@bill-the-cat> (raw)
In-Reply-To: <5a01a9d1-9068-576a-7028-53415cc03ed8@foss.st.com>
[-- Attachment #1.1: Type: text/plain, Size: 4502 bytes --]
On Thu, Feb 23, 2023 at 11:23:41AM +0100, Patrick DELAUNAY wrote:
> Hi,
>
> On 1/23/23 21:01, Tom Rini wrote:
> > On Mon, Jan 23, 2023 at 11:06:06AM +0100, Miquel Raynal wrote:
> > > Hi Tom,
> > >
> > > trini@konsulko.com wrote on Fri, 13 Jan 2023 14:34:11 -0500:
> > >
> > > > On Fri, Jan 13, 2023 at 07:45:44PM +0100, Francesco Dolcini wrote:
> > > >
> > > > > From: Francesco Dolcini <francesco.dolcini@toradex.com>
> > > > >
> > > > > Recently we had a boot regression on colibri-imx7 because of a cleanup change
> > > > > on Linux imx7.dtsi setting nand controller node #size-cells from 1 to 0.
> > > > >
> > > > > Because of that Linux partition parser was no longer able to properly
> > > > > parse the OF partitions leading to a boot failure, the above change was
> > > > > reverted in the meantime as an immediate workaround, but some improvement
> > > > > is required on both Linux and U-Boot.
> > > > >
> > > > > This change improve the U-Boot part of it, #size-cell is set to 1 when
> > > > > it has an invalid value. This has the limitation to work only with devices
> > > > > smaller than 4GiB. In general the suggestion from the Linux MTD maintainer would
> > > > > be to just deprecate using this U-Boot function and pass the MTD partitions
> > > > > from the command line, unless they are statically defined in the DTS file
> > > > > in the first place.
> > > > >
> > > > > This series therefore convert colibri-imx6ull and colibri-imx7 to pass the
> > > > > partition list from the command line instead of fixing up the DT.
> > > > >
> > > > > Link: https://lore.kernel.org/all/20221202071900.1143950-1-francesco@dolcini.it/
> > > > > Link: https://lore.kernel.org/all/Y4dgBTGNWpM6SQXI@francesco-nb.int.toradex.com/
> > > > My higher level question / concern here is, is using one of the dts
> > > > partition schemes still valid / preferred, or should everyone now have
> > > > reverted to passing via the kernel command line? If device tree still,
> > > > is mtd/partitions/fixed-partitions.yaml the one to follow or something
> > > > else?
> > > I don't think we can "prefer" one mode over the other between cmdline
> > > and DTS. Both should work pretty well. Of course on the cmdline you can
> > > only define fixed partitions and many devices require more advanced
> > > parsers, which are only available through DTS, but for simple
> > > partitions, it works totally okay.
> > When both are present, which one is used?
> >
> > > The only thing that I would like to avoid is the need to write code in
> > > the bootloaders to tweak the FDT in order to add partitions. That is
> > > clearly not needed, error prone, and do not follow evolution of the
> > > "standard", as we just discovered.
> > I'm not sure about this. Looking around in U-Boot today, I see two types
> > of cases. One of which, the colibri case, can clearly be not done and
> > either passed on the command line, or put in to the device tree as
> > there's nothing run-time related being tweaked here. That's a fine path
> > to take on those platforms and Francesco's patches should be updated to
> > remove the unused C code too from the board code.
> >
> > But the other cases are doing something dynamic and run-time related.
> > There's the omap3 igep00x0 family (which yes, legacy) that is doing NAND
> > or oneNAND and adjusting things at run time. I don't know how much
> > anyone has interest in those platforms at this point, nor exactly who to
> > contact (for Linux or U-Boot). There's also the stm32mp1 family doing
> > something that's very not obvious at first glance, so I've cc'd the
> > maintainers there.
> >
>
> For information, today for stm32mp1 family we are using the build
>
> of MTDPARTS and fdt fixup, only for backward compatibility issue
>
> (the MTD partitions change for boot with or without OP-TEE,
>
> with or wihtout FIP, with SPL).
>
>
> Today we are already plan to remove this dynamic management
>
> and to switch to static MTD partition defined in device tree,
>
> as already proposed by Tom in the serie
>
> "mtd: spi: nor: force mtd name to "nor%d""
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210916155040.v3.2.Ia461e670c7438478aa8f8939209d45c818ccd284@changeid/
>
>
> This patchset is already ready, we are currently testing it internally
>
> and it should be pushed when it will be validated in our donwstream.
Great, thanks.
--
Tom
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2023-02-23 22:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-13 18:45 [PATCH v1 0/3] fdt: Fix mtparts fixup Francesco Dolcini
2023-01-13 18:45 ` [PATCH v1 1/3] fdt: validate/fix cells count on mtdpart fixup Francesco Dolcini
2023-01-15 14:35 ` Marek Vasut
2023-01-16 14:20 ` Francesco Dolcini
2023-01-16 17:54 ` Marek Vasut
2023-01-16 18:00 ` Francesco Dolcini
2023-01-17 0:59 ` Marek Vasut
2023-01-23 9:56 ` Miquel Raynal
2023-01-24 8:41 ` Francesco Dolcini
2023-01-24 8:58 ` Miquel Raynal
2023-01-24 10:24 ` Francesco Dolcini
2023-01-13 19:34 ` [PATCH v1 0/3] fdt: Fix mtparts fixup Tom Rini
2023-01-23 10:06 ` Miquel Raynal
2023-01-23 20:01 ` Tom Rini
2023-02-23 10:23 ` Patrick DELAUNAY
2023-02-23 22:35 ` Tom Rini [this message]
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=Y/fqHjw4e8LSaz1e@bill-the-cat \
--to=trini@konsulko.com \
--cc=francesco.dolcini@toradex.com \
--cc=francesco@dolcini.it \
--cc=linux-mtd@lists.infradead.org \
--cc=marcel.ziswiler@toradex.com \
--cc=marex@denx.de \
--cc=miquel.raynal@bootlin.com \
--cc=patrice.chotard@foss.st.com \
--cc=patrick.delaunay@foss.st.com \
--cc=sjg@chromium.org \
--cc=u-boot@lists.denx.de \
/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;
as well as URLs for NNTP newsgroup(s).