[PATCH] ramips: fix Unifi 6 Lite boot failure with v5.15 kernels
David Bauer
mail at david-bauer.net
Mon Nov 7 05:51:44 PST 2022
Hi Bjorn,
On 11/7/22 13:57, Bjørn Mork wrote:
> 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.
I have a patch for that prepared in my staging tree, I will re-test it on
my unit. My proposed "append DTB to kernel" worked, so we have a fallback
in case the DTB load-addr does not solve the issue.
David
>
> 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
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list