your mail

[Daniel Golle]

On Wed, Aug 05, 2020 at 04:51:00PM -0300, SAn via openwrt-devel wrote:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
> 
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.

> Date: Wed, 5 Aug 2020 16:51:00 -0300
> From: SAn <spiccinini at altermundi.net>
> To: Daniel Golle <daniel at makrotopia.org>
> Cc: s.l-h at gmx.de, openwrt-devel at lists.openwrt.org
> Subject: Re: your mail
> 
> Hi Daniel
> 
> On 8/5/20 6:04 AM, Daniel Golle wrote:
> > On Tue, Aug 04, 2020 at 08:35:26PM -0300, SAn via openwrt-devel wrote:
> >> The sender domain has a DMARC Reject/Quarantine policy which disallows
> >> sending mailing list messages using the original "From" header.
> >>
> >> To mitigate this problem, the original message has been wrapped
> >> automatically by the mailing list software.
> > 
> >> Date: Tue, 4 Aug 2020 20:35:26 -0300
> >> From: SAn <spiccinini at altermundi.net>
> >> To: Daniel Golle <daniel at makrotopia.org>, s.l-h at gmx.de
> >> Cc: openwrt-devel at lists.openwrt.org
> >> Subject: Re: your mail
> >>
> >> 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? :)
> > 
> > You can hack a MTD partition parser(/-splitter) which evaluates the
> > U-Boot environment and according to what it finds there sets partition
> > names accordingly (ie. swap firmware with firmware2, then 'firmware'
> > will be split into 'kernel' and 'rootfs' during boot).
> > For sysupgrade you can then always use firmware2 (ie. the currently
> > unused image) and toggle which image to load on boot by default (eg.
> > by using fw_setenv)
> > How does librerouter's vendor U-Boot decide which image to boot?
> 
> If I understand you, that is how it is done at the moment, here [0] is documented. Or are you saying to read this u-boot env from the kernel itself to find out the mtd particions?

Yes exactly. If updating U-Boot to something which can do FIT and DT is
not an option that's kinda the only thing you got left. It's not
terribly hard to do and has been done before :)

> 
> 
> >>
> >>> 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.
> > 
> > How have you been managing this on ar71xx until now?
> 
> From the fork [1] we just don't have the patch-cmdline in the kernel for the device, so the kernel load the mtd from the cmdline. So until now only images provided by our fork can be installed properly using dual-boot. Official OpenWrt images can be installed only in the first partition (and if usins sysupgrade only from the first firmware partition also).
> 
> [0] https://github.com/libremesh/lime-packages/blob/master/packages/safe-upgrade/Readme.md#how-safe-upgrade-works
> [1] https://gitlab.com/librerouter/librerouteros
> 
> Thanks
> SAn
> 
> 

> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel