[LEDE-DEV] kernel 4.9 migration for next release

[Jonas Gorski]

On 4 October 2017 at 21:34, Hauke Mehrtens <hauke at hauke-m.de> wrote:
> On 10/04/2017 03:58 PM, p.wassi at gmx.at wrote:
>> Hi Hauke, Hi Rafal,
>>
>>> The following targets are on kernel 4.4 and need a upgrade to kernel 4.9
>>> to be included:
>>> * brcm47xx
>>>      4.9 patches available
>>>      Some devices have problems with "big" kernel images
>>>      @Rafał: did you explain this in some mail in detail were you saw
>>>      these problems, I would like to investigate this.
>>
>> The WL500gPv2 is working fine (see [1]).
>> The WRT54GL is one of the devices, which always had problems with 4.9
>> (and also 4.4 in trunk with KALLSYMS enabled)
>>
>> @Hauke: I just did some kind of 'investigation' and probably found a solution
>> or at least a workaround for me. But as I'm not an expert in CFE and booting,
>> I have no idea whether (and why) my findings really are the issue's origins.
>> And if this can be fixed in the loader or must be fixed in the CFE.
>> Please check out (and maybe also try yourself) what I've documented at [2].
>>
>> My WRT54GLs are now booting kernel 4.9 :-)
>> (Being happy to (still) have 'current trunk' on the good old WRTs)
>>
>> Regards,
>> P. Wassi
>>
>> [1]:
>> https://pwassi.privatedns.org/lede/brcm47xx/wl500gpv2/
>>
>> [2]:
>> https://pwassi.privatedns.org/lede/brcm47xx/wrt54gl/
>>
>
> Thank you for your analysis.
>
> Do you have JTAG connected to your devices?
>
> Do you know how the boot process works in detail, so when memory gets
> moved to which position? Your findings support my assumption that some
> memory region is overflowing. We still have the loader in between on
> some devices it could be possible to change the way we unpack the
> kernel, but I am not so familiar with the boot process.

On brcm63xx I had the same issue (with CFE located at 4 MiB), my
solution was to load the kernel on top the CFE (at 10 MiB /
0x800a0000[0]), then add the relocate stub to move back again to the
kernel expected load address [1].

AFAICT you can tell the CFE arbitrary extraction/load addresses as
well, so this solution might work there as well.

Regards
Jonas

[0] Originally I tried 8 MiB / 0x80080000, but this caused issues with
newer CFEs loaded at 6 MiB offset).

[1] d8ba40cfcdd509e7e1ed68878cb93d9a81e245b6 is the commit where I
added relocation