From: Alexander Egorenkov <egorenar@posteo.net>
To: Simon Horman <horms@verge.net.au>,
Alexander Egorenkov <egorenar-dev@posteo.net>
Cc: rmk@armlinux.org.uk, kexec@lists.infradead.org
Subject: Re: [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage
Date: Mon, 12 Apr 2021 13:27:27 +0200 [thread overview]
Message-ID: <874kgb3fq8.fsf@posteo.net> (raw)
In-Reply-To: <20210412103853.GA28946@vergenet.net>
Simon Horman <horms@verge.net.au> writes:
> On Thu, Apr 08, 2021 at 10:06:44PM +0200, Alexander Egorenkov wrote:
>> If the passed zImage happens to have a DTB appended, then the magic 4 bytes
>> of the DTB are copied together with the kernel image. This leads to
>> failed kexec boots because the decompressor finds the aforementioned
>> DTB magic and falsely tries to replace the DTB passed in the register r2
>> with the non-existent appended one.
>>
>> Signed-off-by: Alexander Egorenkov <egorenar-dev@posteo.net>
>
> Hi,
>
> I also see that, on line 558 len is further expanded as follows:
>
> /*
> * The zImage length does not include its stack (4k) or its
> * malloc space (64k). Include this.
> */
> len += 0x11000;
>
> Is it intentional that this patch also excludes this extra length
> from the DTB? Or am I missing something?
>
Hi,
if i understood it right, then len expresses not the length of the
kernel image in the zImage but the length of the kernel memory segment
into which the kernel image is being loaded. And on this line of code
it is adjusted to account for stack and heap, i think.
Regards
Alex
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2021-04-12 11:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-08 20:06 [PATCH 1/1] arm: do not copy magic 4 bytes of appended DTB in zImage Alexander Egorenkov
2021-04-12 10:38 ` Simon Horman
2021-04-12 11:27 ` Alexander Egorenkov [this message]
2021-04-17 7:19 ` Simon Horman
2021-04-12 10:52 ` Russell King - ARM Linux admin
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=874kgb3fq8.fsf@posteo.net \
--to=egorenar@posteo.net \
--cc=egorenar-dev@posteo.net \
--cc=horms@verge.net.au \
--cc=kexec@lists.infradead.org \
--cc=rmk@armlinux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox