On 9/23/26 2:22 AM, Aleksei Sviridkin wrote: > On 9/22/26 3:48 PM, David Lechner wrote: >> We don't want to add an option that is only used by downstream (code >> janitors tend to like to remove things that aren't being used). But I think >> what Tom meant is that you should add a defconfig for this board so that it >> isn't downstream anymore. :-) >> >> Then we could do something more like board/armltd/vexpress64/Kconfig where >> we just select LINUX_KERNEL_IMAGE_HEADER on a symbol that only applies to >> that board (so no MTK_KERNEL_IMAGE_HEADER and no config prompts needed). > > Adding the board works for me. One thing to check before I do it. > > Upstream would get the board itself: the device tree, the defconfig, and > a board symbol that selects the header and carries the offset base, the > way vexpress64 does it. The OS on this board sits behind NMBM, > MediaTek's bad-block layer for SPI-NAND, and U-Boot has no NMBM. OpenWrt > carries it for all its filogic boards, together with this board's boot > flow: reading the kernel through NMBM and picking the copper or SFP > device tree for the shared port on each boot. So upstream U-Boot on this > board would not load the OS from flash by itself. > > Reading flash on my unit also needs support for its FM25G02B SPI-NAND, > which is still waiting: > https://lore.kernel.org/u-boot/[email protected]/ > > Is a board in that shape fine, or do you want a board to boot its OS > from upstream alone before it goes in?
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]/
