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?
