Re: u-boot places device-tree in bss

[Yuri Honegger <yuri.honegger%icloud.com@localhost>]

> Am 15.12.2025 um 08:12 schrieb Nick Hudson <nick.hudson%gmx.co.uk@localhost>:
> 
> 
> On 14/12/2025 21:57, Yuri Honegger wrote:
>> 
>>> Am 14.12.2025 um 21:39 schrieb Nick Hudson <nick.hudson%gmx.co.uk@localhost>:
>>> 
>>> On 14/12/2025 18:56, Yuri Honegger wrote:
>>>> Hello,
>>>> When the memory address for the device tree isn't provided to u-boot, u-boot
>>>> decides where to place the device tree by itself. For me, it chooses to place it
>>>> right after the code, overlapping the bss section. This means the device tree
>>>> gets overwritten when clearing the bss and a bit later, NetBSD rightfully panics
>>>> because of a corrupt device tree.
>>>> Since u-boot leaves some space between the code and the device tree, it works
>>>> with a small kernel, but as soon as I enable more features and bss grows, I run
>>>> into this issue.
>>> I'm a little surprised that NetBSD's GENERIC_V5 is bloated compared to your u-boot's idea of how big the kernel is, but not completely.
>> I think u-boot might only considers text + other initialized segments and ignores bss when allocating the memory, then round up or something like that. I’ll have to investigate it more thoroughly.
> Not sure how this works. From a quick glance at usr.bin/mkubootimage I don't think the bss is even registered in the netbsd.ub image.

So I studied the u-boot logs and code in more detail. In a first step, we load it in a non-overlapping place. But then in a second step, u-boot moves it around before jumping to the kernel. It determines the address for the relocation from what seems to be a general-purpose allocator.

https://github.com/u-boot/u-boot/blob/e37de002fac3895e8d0b60ae2015e17bb33e2b5b/boot/image-fdt.c#L257

Anyways, I can boot just fine using a boot.scr with an env variable to use a custom fdt address:

env set fdt_high 0x41000000;
fatload mmc 0:2 0x41000000 imx23-olinuxino.dtb;
fatload mmc 0:2 0x42000000 uImage;
bootm 0x42000000 - 0x41000000;

I’ll probably take this upstream to u-boot in a few days.  

>>>> I can work around this by giving u-boot a boot.scr that manually places the
>>>> device tree, but I'm wondering if this could be fixed in NetBSD.
>>>> We could add a panic if we encounter this situation. That would be a bit more
>>>> helpful than the current error:
>>>> [ 1.0000000] panic: fdt_check_header failed: FDT_ERR_BADMAGIC
>>> Sure... something like the attached. Oh, looking at arm32_bootmem_init it's a bit more complicated, but you get the idea.
>> It almost works. One issue is that the fdt address is physical memory while the bss start/end addresses are virtual memory.
>> 
>> In my case:
>> FDT VA: 0x42b93000 PA: 0x42b93000
>> BSS VA: 0xc05de580 PA: 0x425de580
>> 
>> Once you account for that it it catches the issue for me. I’ve also changed to lower bound comparison to <=.
>> 
>> 
> yeah, I realised I was probably mixing VA and PA. thanks for dealing with that.
>> I don’t quite get your point about arm32_bootmem_init. When we reach it, we’ve already copied the fdt using fdt_open_into so we don’t need the original fdt anymore.
> 
> I mean something like the attached.
> 
> 
> <diffv3.txt>

This version works for me, you can commit it if you want.