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

[Caleb James DeLisle]

On 04/06/2025 22:11, Daniel Golle wrote:
> 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.
Yes indeed, SPI is the easy part. The challenge is the mtk_bmt
framework.
> MediaTek BMTv1/v2 as well as NMBM are legacy bad-block management
> systems, nowadays everybody should just be using UBI instead.
I see.
> 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.
The bootloader is based on old Trendchip code, not U-boot or
otherwise Linux based, so they don't accept that it's GPL. There
is source code online, but it compiles for a lot of different chips
and of course it has a bunch of ASM with esoteric bit-bashing for
clock setup, memory configuration and such.

Also, I would like to (as far as it's reasonably possible) use the
dual image support to implement effectively dual-boot between
OpenWRT and the factory OS. This currently works, but it won't work
if we don't support the annoying BMT/BBT thing.
>
>> 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.

I take it you're referring to the patch which adds the mtk_bmt_attach
and mtk_bmt_detach calls. This is copied from /airoha, and the same
patch is present in /mediatek. In /ramips it's not necessary because
the mtk_bmt_attach call is present in mt7621_nand.c

> 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.
Please correct me if I'm wrong, but as best as I understand I did
exactly that, i.e 
https://github.com/openwrt/openwrt/pull/19021/files#diff-3111d1b107a4c9659c2ab6a45f7a11f94122553012203c0fd792da78c3fd3e6cR1433

The hook into the SPI NAND subsystem is mtk_bmt_attach which is
what mtk_bmt requires in order to work. It would be nice if we had
a mtd->mtd mapper driver so that we don't need that hook, then in
principle the whole mtk_bmt framework could be upstreamed with just
minor changes. I can't imagine that hook will be accepted.

To be honest I'm not such a fan of mtk_bmt because it doesn't tell
you whether you're being asked to remap because of a read / write, or
an erase, so you don't know if a failure to copy the bad block is a
data loss event (in which case the user should get an error), or if
it's nothing because they wanted it erased in the first place (so
give them a fresh block). Maybe we should consider adding
bbt_why_remap() which can be called from within remap_block(), but
that's another story for another day.


Please let me know if I'm missing something, and thanks for the
review.

Caleb


>
>
> Cheers
>
>
> Daniel