On Tue, Dec 06, 2022 at 08:02:45PM +0100, Marek Vasut wrote:
> On 12/6/22 11:16, Miquel Raynal wrote:
> > Hi Francesco,
>
> Hello everyone,
>
> > francesco@xxxxxxxxxx wrote on Mon, 5 Dec 2022 20:07:18 +0100:
> >
> > > On Mon, Dec 05, 2022 at 07:52:08PM +0100, Marek Vasut wrote:
> > > > On 12/5/22 19:18, Miquel Raynal wrote:
> > > > > marex@xxxxxxx wrote on Mon, 5 Dec 2022 19:07:14 +0100:
> > > > > > On 12/5/22 18:58, Miquel Raynal wrote:
> > > > > > > , it's not
> > > > > > > complex to do, there are plenty of examples. This would be IMHO a
> > > > > > > better step ahead rather than just a cell change. Anyway, I don't mind
> > > > > > > reverting this once we've sorted this mess out and fixed U-Boot.
> > > > > >
> > > > > > Won't we still have issues with older bootloader versions which
> > > > > > paste partitions directly into this &gpmi {} node, and which needs
> > > > > > to be fixed up in the parser in the end ?
> > > > >
> > > > > I believe fdt_fixup_mtdparts() should be killed, so we should no longer
> > > > > have this problem.
> > > >
> > > > The fdt_fixup_mtdparts is U-Boot code. If contemporary Linux kernel is
> > > > booted with ancient U-Boot, then you would still get defective DT passed to
> > > > Linux, and that should be fixed up by Linux. Removing fdt_fixup_mtdparts()
> > > > from current mainline U-Boot won't solve this problem.
> > > >
> > > > I think this is also what Francesco is trying to convey (please correct me
> > > > if I'm wrong).
> >
> > If we can get rid of fdt_fixup_mtdparts(), it means someone has to
> > create the partitions. I guess the easy way would be to just provide
> > mtdparts to Linux like all the other boards and let Linux deal with it.
>
> This is based on an assumption that the platform kernel command line can be
> updated to insert such a workaround. If Francesco cannot update the
> bootloader, the kernel command line may be immutable all the same.
Exactly.
What I can do is update the latest stuff and enable people to upgrade, eventually.
But here we are talking about a board that is just generally available
in high volume to a multitude of people since years ... in practice the
vast majority of the users will not upgrade it.
> > Then we can just assume in Linux that perhaps if the partitions are
> > invalid (#size-cell is wrong?) then we should just stop their creation
> > and fallback to another mechanism instead of failing entirely. This way
> > no need for hackish changes in the parsers and compatibility is still
> > valid with old U-Boot (if mtdparts was provided on the cmdline, to be
> > checked). Otherwise we'll have to deal with it in Linux, that's a pity.
>
> I am very much banking toward -- fix it up in the parser, just like any
> other firmware issue.
I agree again.
> Esp. since the fix up is printing a warning, and it is like a 2-liner
> patch.
Here we might assess if we need more to handle the other weird situation
in which a `partitions{}` node is present, U-Boot ignores it and the
kernel fails to detect the partitions. As of today colibri-imx7 is not
affected by this.
Francesco
