[0/4] of: bootargs handling improvement

Message

Christian Marangi May 12, 2024, 1:25 p.m. UTC

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.

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.

This feature is different than hardcoding the CMDLINE since that is
usable only with some specific case and is really problematic if the
same kernel is used for multiple devices that share a common kernel and
.dtsi

Christian Marangi (3):
  docs: dt: Document new bootargs chosen property
  of: add support for bootargs-override chosen property
  of: add support for bootargs-append chosen property

David Bauer (1):
  MIPS: add bootargs-override property

 Documentation/devicetree/usage-model.rst |  9 +++++++++
 arch/mips/kernel/setup.c                 | 14 +++++++++++++-
 drivers/of/fdt.c                         | 15 +++++++++++++--
 3 files changed, 35 insertions(+), 3 deletions(-)

Comments

Rob Herring (Arm) May 20, 2024, 3:12 p.m. UTC | #1

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