Re: [PATCH 0/4] of: bootargs handling improvement

[Rob Herring <robh@kernel.org>]

On Sun, May 12, 2024 at 03:25:07PM +0200, Christian Marangi wrote:
> This is a very simple series that try to solve a very simple problem.
> 
> Many emebedded devices have very hacked (by OEMS) bootloader that do all
> kind of modification and makes the kernel unbootable with the very first
> small modification. And also many times these broken bootloader have
> hardcoded values that can't be modified and would require risky
> procedure that can brick the device.
> 
> One of the common modification done is hardcoding bootargs in the
> appended kernel DT trashing the bootargs set in the /chosen.
> 
> The main usage of this is to have dynamic stuff to support dual
> partition scheme and make the kernel load a dedicated rootfs. But the
> other usage of this is to effectively lockup the device and cause kernel
> panic on modification like using squashfs instead of legacy jffs2.
> 
> The simple solution to this is to let the bootloader override the
> bootargs in /chosen and make the kernel parse a different property.

What happens when bootloaders start using these new "standard" bootarg 
properties and you need to override them? Perhaps name it something the 
OEM wouldn't use (maybe): 
"use-this-bootargs-instead-for-the-broken-bootloader"

> >From long time on OpenWRT we use bootargs-override as the alternative
> property for this task fixing the problem of overridden bootargs.
> 
> The second feature is bootargs-append. This is self-explanatory,
> sometimes bootargs from bootloader might be good but lack of some
> crucial things that needs to be appended, like rootfstype or rootfs
> path.

It is unfortunate that the kernel's handling of appending or prepending 
to bootargs is ambiguous. And MIPS is a further mess with handling 
cmdline from multiple sources.

I'm not really interested in adding any more complexity to the cmdline 
handling until it is made common. There's been at least 2 approaches to 
doing that.

Rob