Jonas Gorski <[email protected]> writes: > On Sun, 6 Nov 2022 at 12:50, Bjørn Mork <[email protected]> wrote: >> Jonas Gorski <[email protected]> writes: >> >> > An option is also to set a load address for the dtb in the FIT image, >> > then U-Boot will relocate it before passing it to the kernel. >> >> Yes, that is worth trying. I thought this would be part of the fdt >> relocation step, but I see that the "load" property is used before the >> final relocation. >> >> I'll test this when I have console again. Or earlier if someone can >> tell me how to calculate a semi-safe load address. Will the kernel >> $loadaddr + aligned(8, 32, 512. 4096?) kernelsize be ok? > > You'll probably then have the chance to land in the .bss section, > which gets zeroed on boot. > > Safest might be a static address like RAMSTART + 16MiB. This is what > e.g. DentOS does. > > Not sure if 16 MiB is enough for ramdisk kernels.
Thanks. Will try that, but considering the big question marks I think it will have to wait until the next time I can use the console. It also doesn't relly sound like a much more robust solution in the end, than simply forcing the fdt's to be aligned. Still working on that. Injecting some FDT_NOPs in mkimage looks promising. >> And how do I figure out where in memory the fdt ended up, without seeing >> the console output from u-boot? Can't see anything obvious in dmesg or >> in sysfs. Do I need to enable a memory debug device, or is this address >> directly available somewhere? > > I don't think so, at least I don't see anything obvious. > > So I guess you'll need to sprinkle some debug printks there (e.g. > fw_arg0 or argument passed to __dt_setup_arch()). Ok, I guess I can do that. Bjørn _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
