> Am 09.01.2026 um 12:34 schrieb Simon Glass <[email protected]>:
>
> Hi Yuri,
>
> On Thu, 18 Dec 2025 at 16:30, Yuri Honegger <[email protected]> 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
