[LEDE-DEV] kernel 4.9 migration for next release
jonas.gorski at gmail.com
Wed Oct 4 14:40:28 PDT 2017
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 ).
>> 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 .
>> My WRT54GLs are now booting kernel 4.9 :-)
>> (Being happy to (still) have 'current trunk' on the good old WRTs)
>> P. Wassi
> 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), then add the relocate stub to move back again to the
kernel expected load address .
AFAICT you can tell the CFE arbitrary extraction/load addresses as
well, so this solution might work there as well.
 Originally I tried 8 MiB / 0x80080000, but this caused issues with
newer CFEs loaded at 6 MiB offset).
 d8ba40cfcdd509e7e1ed68878cb93d9a81e245b6 is the commit where I
More information about the Lede-dev