Placement of FDT in memory

Placement of FDT in memory

[Yuri Honegger]

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?

Thank you,
Yuri

Re: Placement of FDT in memory

[Simon Glass]

Hi Yuri,

On Thu, 18 Dec 2025 at 16:30, Yuri Honegger <yuri.honegger@icloud.com> 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?

Do you have a value for fdt_high before you set it to that?

See boot_relocate_fdt() for the logic.

Regards,
Simon

Re: Placement of FDT in memory

[Yuri Honegger]

> Am 09.01.2026 um 12:34 schrieb Simon Glass <sjg@chromium.org>:
> 
> Hi Yuri,
> 
> On Thu, 18 Dec 2025 at 16:30, Yuri Honegger <yuri.honegger@icloud.com> 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?
> 
> Do you have a value for fdt_high before you set it to that?
> 
> See boot_relocate_fdt() for the logic.

No, fdt_high doesn’t have a default. I found fdt_high by backtracking the code in question to find a way to get it off the path where it automatically chooses a memory location just behind the kernel image.

I’m mainly wondering about why we have the relocation logic active in this scenario. We already have the fdt in memory from when it is loaded from disk. We have to provide a manual address for this, so we can choose it so that it doesn’t overlap. As soon as we bootm, u-boot relocates it to an address that conflicts, while the original address would have been fine, so I’m wondering about the reasons for the relocation.

> 
> Regards,
> Simon

Thank you,
Yuri

Re: Placement of FDT in memory

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2362 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Placement of FDT in memory

[Yuri Honegger]

> Am 09.01.2026 um 18:09 schrieb Tom Rini <trini@konsulko.com>:
> 
> 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

Re: Placement of FDT in memory

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 5051 bytes --]

On Fri, Jan 09, 2026 at 10:13:25PM +0100, Yuri Honegger wrote:
> 
> 
> > Am 09.01.2026 um 18:09 schrieb Tom Rini <trini@konsulko.com>:
> > 
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Placement of FDT in memory

[Martin Husemann]

On Fri, Jan 09, 2026 at 10:13:25PM +0100, Yuri Honegger wrote:
> 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 NetBSD variant did not pass the FDT blob IIRC, so it is mostly
useless nowadays. We switched to marking the images as linux kernel
as there really is no difference for the boot loader.

Martin

Re: Placement of FDT in memory

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 711 bytes --]

On Sat, Jan 10, 2026 at 08:56:33AM +0100, Martin Husemann wrote:
> On Fri, Jan 09, 2026 at 10:13:25PM +0100, Yuri Honegger wrote:
> > 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 NetBSD variant did not pass the FDT blob IIRC, so it is mostly
> useless nowadays. We switched to marking the images as linux kernel
> as there really is no difference for the boot loader.

I thought it might be something like that. Are there any non-EOL NetBSD
releases that don't use device tree? If not, we can go and mark the
legacy option as non-default. Thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: Placement of FDT in memory

[Martin Husemann]

On Sat, Jan 10, 2026 at 10:43:49AM -0600, Tom Rini wrote:
> I thought it might be something like that. Are there any non-EOL NetBSD
> releases that don't use device tree? If not, we can go and mark the
> legacy option as non-default. Thanks!

I think there are still some ancient arm and mips platforms that have not
been converted to use FDT, though there was a project to fix them recently
(but it is not done).

Martin