your mail

[SAn]

Hi Stefan and Daniel,

On 8/2/20 8:19 PM, Daniel Golle wrote:
> On Sun, Aug 02, 2020 at 07:49:40PM -0300, SAn via openwrt-devel wrote:
>> Subject: ath79 subtarget with cmdline from bootloader
>>
>> Hi! 
>>
>> The LibreRouter uses a dual-boot scheme that relies on the bootloader configuring the kernel cmdline. At ar71xx 18.06 it was possible to select per device if the cmdline from the bootloader has to be honored (using patch-cmdline).
>> AFAIK there is no such possibility on ath79.
>>
>> Would you consider accepting a patch that adds a new ath79 subtarget with CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (or CONFIG_MIPS_CMDLINE_BUILTIN_EXTEND)?
>>
>> It would be valuable for the people using LibreRouter devices to be able to use official OpenWrt 20.xx images with the dual-boot support. Currently there are multiple mips targets that use CONFIG_MIPS_CMDLINE_FROM_BOOTLOADER (bcm47xx, octeon, malta, and a few more).
> 
> I don't think this justifies an extra subtarget just for the sake of
> having the kernel process cmdline arguments passed by an outdated
> (ie. non-DT, non-FIT) bootloader.
> If it really has to be that way (and eg. parsing uboot-env cannot be
> used instead and bootloader cannot be updated to properly pass this
.

Another bootloader can be used, but I am not aware of a newer one with QCA955x support, do you? The last time I checked u-boot there was upstream support to qca956x and qca953x. Adding support to 955x seemed to me a lot of work (there are thousands of undocumented constants everywhere in the code), but maybe I am mistaken?

I did not understand the "parsing uboot-env". Can you expand on this please? :)

> in dtb), I guess something along the lines of
> CONFIG_ARM_ATAG_DTB_COMPAT_CMDLINE_MANGLE
> could work (would have to be implemented for MIPS first, obviously)

If there is no other viable way I would go this way..
Thanks Stefan for the pointers to the patches!

> Alternatively, as a quick-and-dirty workaround, just move the whole
> librerouter.dts into a .dtsi and then have two .dts files referecing
> them, each setting different cmdline. Then generate two images.
> That'd be the same effect as what patch-cmdline used to do on non-DT
> targets.
> 

I think this is too complicated for end users. Maybe a friendlier way could be to pack both images into a tarfile and then use the correct one from a userspace tool to perform the upgrade.

Thanks for the help!
SAn