[PATCH] ramips: fix Unifi 6 Lite boot failure with v5.15 kernels

[Bjørn Mork]

Jonas Gorski <jonas.gorski at gmail.com> writes:
> On Sun, 6 Nov 2022 at 12:50, Bjørn Mork <bjorn at mork.no> wrote:
>> Jonas Gorski <jonas.gorski at gmail.com> 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