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
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
