linux-mtd.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Patrick DELAUNAY <patrick.delaunay@foss.st.com>
To: Tom Rini <trini@konsulko.com>,
	Miquel Raynal <miquel.raynal@bootlin.com>,
	Patrice Chotard <patrice.chotard@foss.st.com>
Cc: 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 11:23:41 +0100	[thread overview]
Message-ID: <5a01a9d1-9068-576a-7028-53415cc03ed8@foss.st.com> (raw)
In-Reply-To: <20230123200131.GD631605@bill-the-cat>

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.


Regards


Patrick







______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

  reply	other threads:[~2023-02-23 10:24 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 [this message]
2023-02-23 22:35         ` Tom Rini

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=5a01a9d1-9068-576a-7028-53415cc03ed8@foss.st.com \
    --to=patrick.delaunay@foss.st.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=sjg@chromium.org \
    --cc=trini@konsulko.com \
    --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).