On Thu, Dec 18, 2025 at 11:04:59PM +0100, Yuri Honegger wrote: > Hello, > Recently I've been playing around with the imx23-olinuxino > (mx23_olinuxino_defconfig) and booting NetBSD using u-boot. During that, I've > noticed that NetBSD panics because u-boot places the device tree in the BSS > section of NetBSD. NetBSD clears the BSS section and then complains > that the device tree is corrupt. > > Reading the logs, it appears that FDT and kernel get loaded at non-overlapping > ranges, but then u-boot relocates the device tree right after the kernel into > the BSS section. > > ## Booting kernel from Legacy Image at 42000000 ... > Image Name: NetBSD/earmv5 11.99.4 > Image Type: ARM Linux Kernel Image (no loading done) (uncompressed) > Data Size: 11950164 Bytes = 11.4 MiB > Load Address: 00000000 > Entry Point: 00000000 > Verifying Checksum ... OK > ## Flattened Device Tree blob at 41000000 > Booting using the fdt blob at 0x41000000 > Working FDT set to 41000000 > XIP Kernel Image (no loading done) to 42000040 > Loading Device Tree to 42b93000, end 42b99a0a ... OK > Working FDT set to 42b93000 > Starting kernel ... > > The bootm command seems to insist on having to relocate the device tree. > > Is this something the OS is expected to deal with? > > In the meantime, I've managed to work around this by running > env set fdt_high 0x41000000; > before bootm. Is there a better solution than this to force the placement > of the device tree?
So, interesting setup. It's not a FIT image, it's a legacy image, so there's a few details missing that might be helpful here. But, why are you loading the image so high in memory? And we're calling it a Linux kernel, not a NetBSD image, so we should likely be updating our docs for booting modern NetBSD releases. The big problem is that for a legacy image, we don't (and can't in many/most cases) know where the OS ends it's BSS and so have to hope that we're relocating to the correct spot (in other cases we can see this overlap and avoid it). At https://docs.u-boot.org/en/latest/usage/environment.html#list-of-environment-variables we document all of the environment variables and bootm_low / bootm_size / bootm_mapsize are relevant to this case, along with perhaps just loading the kernel image lower in memory to start with? -- Tom
signature.asc
Description: PGP signature
