Thread (7 messages) read the whole thread 7 messages, 3 authors, 2017-08-29

ARM64 kernel Image size limitations?

From: Ard Biesheuvel <hidden>
Date: 2017-08-29 08:15:30

On 28 August 2017 at 22:24, Florian Fainelli [off-list ref] wrote:
(fixed Will's address, apologies)

On 08/28/2017 01:01 PM, Ard Biesheuvel wrote:
quoted
Hi,

On 28 August 2017 at 20:55, Florian Fainelli [off-list ref] wrote:
quoted
Hi,

I have been fighting with a reasonably large kernel Image: 46MB and
found unable to boot it. This is on v4.13-rc6, but I could go back as
far as v4.9~ish. It is so big, because it's got some debugging enabled,
and the initramfs compression is disabled, but still that ought to be
possible.

After some experimentation I found that the breaking size is somewhere
around 33MB total for arch/arm64/boot/Image and when that happens, I get
the following backtrace which suggests that there is some memory
corruption of some kind (or so it seems to me), other experiments
indicated that the backtrace may point back to where the bootloader had
set up its exception vector. I am fairly confident that the bootloader
is not responsible for corrupting the Image that is loaded.

Is there such a size limitation or am I possibly tripping over something
else?
What boot environment are you using? Is it possible the DTB is copied
on top of the kernel by the boot loader?
Bootloader is BOLT (Broadcom's own implementation, has PSCI and is
capable of doing FDT live patching), and yes the DTB is provided by the
bootloader at an address higher than the kernel.

Physical offset of the RAM on this platform is 0, so the load is going
to be at PA 0x80000, 0x80000 + size (35MB) = 0x2280000, DTB is placed at
0x771f000 and is 0x90ef bytes.
Could you try to dump __log_buf from gdb?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help