[LEDE-DEV] kernel 4.9 migration for next release

[p.wassi at gmx.at]

Hi Jonas, Hi Hauke,

> Do you have JTAG connected to your devices?
Yes, I had JTAG connected :-)

> Do you know how the boot process works in detail, so when memory gets
> moved to which position?
I've just dug into this (yesterday).

> Your findings support my assumption that some memory region is overflowing.
>From what I understand by now, I do not see an overflow issue. (At decompressing,
we're still 118 kB away from running code)
Please check out [1] for more information. There's one little detail with
the addresses which makes me think it's the memory setup or something similar.
(Checkout the "Conclusion" for that)

> AFAICT you can tell the CFE arbitrary extraction/load addresses as
> well, so this solution might work there as well.
Yes, you can set that address with the nvram variable "os_ram_addr" (which
defaults to 80001000). This is the location, to where the loader is gunzipped to.
In the loader, we can first set the address to where the decompressor is moved to
(currently 0x80400000) and then of course also configure the base address for kernel
unpacking/execution.

> my solution was to load the kernel on top the CFE, then add the relocate stub to
> move back again to the kernel expected load address
I'd actually expect this to work for brcm47xx too, but first, I'd like to understand
why this is not working. I mean, if we do the relocation thing, we need to have a solution
which fits to all devices that currently operate with the CFE->loader->decompressor->kernel
chain. And since working/not-working is somehow related to the memory area which is used by
the CFE... (Or could/should we just touch those target devices, which do have a problem in
booting larger kernels?)

Best regards,
P. Wassi

[1]:
https://pwassi.privatedns.org/lede/brcm47xx/wrt54gl/boot/