All of lore.kernel.org
 help / color / mirror / Atom feed
From: f.fainelli@gmail.com (Florian Fainelli)
To: linux-arm-kernel@lists.infradead.org
Subject: ARM64 kernel Image size limitations?
Date: Tue, 29 Aug 2017 09:51:14 -0700	[thread overview]
Message-ID: <aced65d9-13f4-5851-0398-0329bd64dca3@gmail.com> (raw)
In-Reply-To: <CAKv+Gu8iBDYpP4Zzq+2Q7cm=kgZpMcGnXNUwyti__TUv+MR=zg@mail.gmail.com>

On 08/29/2017 01:15 AM, Ard Biesheuvel wrote:
> On 28 August 2017 at 22:24, Florian Fainelli <f.fainelli@gmail.com> wrote:
>> (fixed Will's address, apologies)
>>
>> On 08/28/2017 01:01 PM, Ard Biesheuvel wrote:
>>> Hi,
>>>
>>> On 28 August 2017 at 20:55, Florian Fainelli <f.fainelli@gmail.com> wrote:
>>>> 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?

Silly me, this is a bootloader limitation, unlike what I thought the
load address is not at PA 0, it is at PA 0x06FFC000 and there is only
~34MB worth of space available, mayhem ensues.

Thanks!
-- 
Florian

  reply	other threads:[~2017-08-29 16:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-28 19:55 ARM64 kernel Image size limitations? Florian Fainelli
2017-08-28 20:01 ` Ard Biesheuvel
2017-08-28 21:24   ` Florian Fainelli
2017-08-29  8:15     ` Ard Biesheuvel
2017-08-29 16:51       ` Florian Fainelli [this message]
2017-08-29 16:58         ` Florian Fainelli
2017-08-29 10:31 ` Mark Rutland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aced65d9-13f4-5851-0398-0329bd64dca3@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.