[PR] Add new platform: EcoNet EN751221 (DSL / XPON modems)

[Felix Baumann]

Am 4. Juni 2025 22:11:35 MESZ schrieb Daniel Golle <daniel at 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 at 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