> 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?
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.
>
> 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.
> 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.
>
> --
> Tom
Thank you,
Yuri
