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.
--- Begin Message ---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
--- End Message ---
_______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
