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
