On 9/23/26 5:53 PM, Aleksei Sviridkin wrote: > On 9/23/26 9:50 AM, David Lechner wrote: >> It would help to know more what your overall plan/goal is. What do you hope >> to accomplish by using U-Boot rather than the stock bootloader? >> >> If this board simply isn't going to work without a NMBM layer, then we >> should probably wait and see what kind of response we get to a patch series >> that proposes adding it. I found something similar [1] where it was >> suggested that such things should be linux-first. >> >> [1]: >> https://lore.kernel.org/u-boot/[email protected]/ > > The goal is the shared port on the Keenetic KN-1012 (MT7981B). Port 5 > of its MT7531 switch has one SerDes, and a mux on GPIO 27 routes it > either to an SFP cage or to an Airoha EN8811H copper PHY. Which one to > use is only known at boot, from the SFP presence pin on GPIO 23. Linux > cannot switch this port's media at runtime today, and the stock loader > always boots the default configuration of the FIT image. My U-Boot reads > GPIO 23 on each boot, sets the mux, picks the copper or the SFP device > tree, and falls back to TFTP if booting from flash fails. > > NMBM comes with the stock loader, and I keep that loader on purpose. Its > TFTP recovery works whatever happens to the rest of the flash. Most > OpenWrt users could not unbrick the router if a replaced loader went > wrong, since that takes a serial console and the BootROM. The stock > loader writes the firmware through NMBM, so anything reading it back has > to use NMBM too. > > So I am dropping v2, and the board stays in OpenWrt for now. I will not > propose NMBM myself: a layer that remaps bad blocks behind MTD's back is > what the thread you linked turns away, and it is not my code to push. > > Weijie, the NMBM patches OpenWrt carries are yours. Is taking NMBM > upstream something MediaTek plans? If it lands, I will come back with > the board.
On the Linux side, rather than trying to get this in the kernel (I would expect push-back on a vendor-specific thing like this since there is already UBI) if we could implement NMBM using ublk (user-space block device). We would need an initrd to load the rootfs using this. And U-Boot would still need at least a read-only NMBM implementation. Just some ideas if you want to keep pushing this forward.
