On Sat, 5 Nov 2022 at 09:46, Bjørn Mork <bj...@mork.no> wrote: > > David Bauer <m...@david-bauer.net> writes: > > On 11/4/22 09:29, Bjørn Mork wrote: > >> You are right that the bootloader must be fixed. But the vendor isn't > >> likely to do that as long as they run older kernels. I believe the > >> OpenWrt policy in such cases is to try to work around the issue. > >> Replacing the vendor bootloader is a last resort. Please correct me if > >> I'm wrong. > > > > I haven't tried this yet, but I think we should be able to boot a FIT > > image configuration which only contains a kernel image. We could then simply > > use the legacy append-DT like we do for legacy uImage ramips. > > > > Not the nicest way, but considering we need it for the target anyways, i > > consider > > this the simpler solution. > > Yes, that sounds acceptable if it is supported. Which I guess it should > be. > > I can test it the next time I get a chance. But that might take a while > before I'm close enough to these APs to use the console. Should have > had a console I could access remotely there, but I don't.
An option is also to set a load address for the dtb in the FIT image, then U-Boot will relocate it before passing it to the kernel. This way U-Boot also retains access to the dtb, in case it wants to update/modify it (e.g. updating the /memory/ node with the actual memory present, setting the cmdline, setting mac addresses etc). Jonas _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel