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 ---Am 4. Juni 2025 22:11:35 MESZ schrieb Daniel Golle <dan...@makrotopia.org>: >Hi Caleb, > >first of all thank you for taking care of the EcoNet legacy MIPS >platforms -- they are pretty popular and running up-to-date Linux on >them would be very nice. Supporting xPON or xDSL WAN is still a lot >more work, obviously, but it's good to start from somewhere. > >On Wed, Jun 04, 2025 at 02:36:31PM +0200, Caleb James DeLisle wrote: >> Hello all, >> >> >> This is my second submission of a PR to add support for EcoNet. Per >> community feedback, >> >> I submitted the bulk of the platform code upstream where it has been >> reviewed and accepted. >> >> https://patchwork.kernel.org/project/linux-mips/list/?series=960479&state=* >> >> >> What is submitted here that is not upstream is support for SPI NAND flash. >> This depends on >> >> a MediaTek BMT framework which is not upstream. > >Nothing should prevent you from submitting support for the SPI host >controller or the SPI-NAND chip to upstream Linux. > >MediaTek BMTv1/v2 as well as NMBM are legacy bad-block management >systems, nowadays everybody should just be using UBI instead. > >If the (binary) bootloader expects a BMT-variant, as the source >should be GPLv2 you can build it from source without expecting BMT >and use UBI instead. > >> >> Any comments and reviews would be most appreciated. >> >> >> https://github.com/openwrt/openwrt/pull/19021 > >Looking at the series I noticed that you are patching SPI subsystem in >order to support BMT, and you also add another vendor-specific driver >as well as DT attribute for that. >If you want to use BMT at all in order to not have to replace the >bootloader it would be better to extend the existing support for the >various MediaTek BMT and NMBM variants, see >target/linux/generic/files/drivers/mtd/nand/ > >Ie. if what ECONET is doing is really different from any of the existing >MediaTek BMT variants, please just implement OPs for struct mtk_bmt_ops >instead of adding a new standalone driver which needs to hook into >SPI NAND subsystem. > > >Cheers > > >Daniel > >_______________________________________________ >openwrt-devel mailing list >openwrt-devel@lists.openwrt.org >https://lists.openwrt.org/mailman/listinfo/openwrt-devel Hi Daniel, the following is not meant as critique. Rather I would like to hear your point of view on the topic of replacing bootloaders: It's not exactly common practice to replace the bootloader nowadays is it? I see the advantages but it's not the easiest to do it without screwing yourself over and having to reflash the flash chip with a backup using a test clip adapter or so Atleast it was never common practice on ramips-mt7621. Who guarantees that the GPL source builds a compatible uboot will all the bells and whistles necessary? The way this has been done so far afaik: use ubi for the rootfs and only exclude that ubi partition from bmt-v2, bbt or nmbm. <https://github.com/search?q=repo%3Aopenwrt%2Fopenwrt%20bmt-remap-range&type=code> Maybe that is possible for this style of bmt, too? Or do you suggest moving the whole flash chip or atleast kernel + rootfs into a ubifs? because without bmt on the squashfs it would become corrupt eventually unless the kernel is inside a ubi partition and a modern uboot boots it. Maybe all of these questions have obvious answers. They just aren't obvious to me. I hope voicing my concern was okay here 😅 Caleb, I'm grateful for all the work you've already done. Thank you :) Regards Felix Baumann
--- End Message ---
_______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
