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.
