On Fri, Jan 09, 2026 at 10:13:25PM +0100, Yuri Honegger wrote: > > > > Am 09.01.2026 um 18:09 schrieb Tom Rini <[email protected]>: > > > > 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. > > Yes, NetBSD only generates legacy images when compiling the kernel. I suspect > there could be licensing issues with FIT stuffing everything in a single file > depending on how it is distributed. Most device trees are GPL. I haven’t > looked into it all that much to be honest. > > The memory location for the kernel are the defaults from u-boot for the > imx23-olinuxino (see mx23_olinuxino.h and mx23_olinuxino_defconfig) and > memory ranges from 0x40000000 to 0x44000000. Is there an issue with how they > have been chosen?
It's not so much an issue but rather than OS kernels were smaller 13 years ago. The platform has 128MiB of memory at most? But is yours only showing 48? It's odd that it's not relocating the device tree towards the end of 128MiB, or 64MiB but instead 48MiB (base is 0x40000000 so 0x42b93000 looks like 48MiB minus U-Boot itself and malloc pools and so on). We were also a lot less careful aobut picking device tree and OS kernel and ramdisk addresses back then. > As for u-boot calling the netbsd kernel a linux kernel: That is NetBSDs > fault, for some reason it produces images with —os linux, although I don’t > know the backstory. We have some specific NetBSD support but I don't know when the last time someone tried it was. > > 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). > > I agree, we can’t expect u-boot to know where the BSS is. Perhaps I should > have explained my question better. Why does u-boot relocate the device tree > before jumping to the kernel? If we have to provide manual addresses anyways > during the loading step, we already have to take care of ensuring they don’t > overlap and so on. From NetBSD’s point of view, they already were in a > perfectly acceptable place before the the relocation. We relocate the device tree because we don't know that it was put in a valid position or properly aligned. We also normally relocate the OS kernel to where it was set to be loaded in memory, but in your case it's instead set as "noload" and so run in place. > > 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? > > Thank you for pointing them out, I’ll play around some more and see if I can > find a setup that doesn’t require too much fiddling. A full console log from power on through initial kernel boot might help too, for making suggestions. Generally, the OS gets loaded towards the bottom of memory and the device tree moved towards the top of memory and there's not an overlap. -- Tom
signature.asc
Description: PGP signature
