From: Ard Biesheuvel <ardb@kernel.org>
To: Zhen Lei <thunder.leizhen@huawei.com>,
Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
Libin <huawei.libin@huawei.com>,
Russell King <linux@armlinux.org.uk>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel
Date: Mon, 28 Sep 2020 12:14:27 +0200 [thread overview]
Message-ID: <CAMj1kXGK8x4eBL55mLMWVQWpFZKa+FSCaQj9_gieWCQSgG=xAQ@mail.gmail.com> (raw)
In-Reply-To: <20200928092641.2070-3-thunder.leizhen@huawei.com>
On Mon, 28 Sep 2020 at 11:27, Zhen Lei <thunder.leizhen@huawei.com> wrote:
>
> mov r4, pc
> and r4, r4, #0xf8000000 //truncated to 128MiB boundary
> add r4, r4, #TEXT_OFFSET //PA(_start)
>
> Currently, the decompressed kernel must be placed at the position: 128MiB
> boundary + TEXT_OFFSET. This limitation is just because we masked PC with
> 0xf80000000. Actually, we can directly obtain PA(_start) by using formula
> : VA(_start) + (PHYS_OFFSET - PAGE_OFFSET).
>
> So the "PA(_start) - TEXT_OFFSET" can be 2MiB boundary, 1MiB boundary,
> and so on.
>
> Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
No, this won't work.
The whole reason for rounding to a multiple of 128 MB is that we
cannot infer the start of DRAM from the placement of the zImage (which
provides _start).
There are patches on the list by Geert [0] to obtain the start of DRAM
from the device tree directly, to work around this masking. And when
booting via EFI (which is supported by u-boot too these days), the
zImage could be anywhere in [32-bit addressable] memory, and the start
of DRAM is obtained from the EFI memory map.
Note to Geert: this is a followup to an effort by Zhen Lei and myself
[1] to lower the minimum alignment of PHYS_OFFSET from 16 MiB to 2
MiB, and this affects your patch as well.
[0] https://lore.kernel.org/linux-arm-kernel/20200902153606.13652-1-geert+renesas@glider.be/
[1] https://lore.kernel.org/linux-arm-kernel/20200921154117.757-1-ardb@kernel.org/
> ---
> arch/arm/boot/compressed/head.S | 33 ++++++++++++++-------------------
> 1 file changed, 14 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index 434a16982e344fe..e5ba2ad2ea4700f 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -255,26 +255,16 @@ not_angel:
>
> #ifdef CONFIG_AUTO_ZRELADDR
> /*
> - * Find the start of physical memory. As we are executing
> - * without the MMU on, we are in the physical address space.
> - * We just need to get rid of any offset by aligning the
> - * address.
> - *
> - * This alignment is a balance between the requirements of
> - * different platforms - we have chosen 128MB to allow
> - * platforms which align the start of their physical memory
> - * to 128MB to use this feature, while allowing the zImage
> - * to be placed within the first 128MB of memory on other
> - * platforms. Increasing the alignment means we place
> - * stricter alignment requirements on the start of physical
> - * memory, but relaxing it means that we break people who
> - * are already placing their zImage in (eg) the top 64MB
> - * of this range.
> + * Find ZRELADDR (Address where the decompressed kernel was
> + * placed, usually == PHYS_OFFSET + TEXT_OFFSET). That's the
> + * start physical address of the text section, PA(_start).
> + * As we are executing without the MMU on, we are in the
> + * physical address space.
> */
> - mov r4, pc
> - and r4, r4, #0xf8000000
> - /* Determine final kernel image address. */
> - add r4, r4, #TEXT_OFFSET
> + adr r0, LC2
> + ldmia r0, {r3-r4}
> + sub r3, r0, r3 @ PHYS_OFFSET - PAGE_OFFSET
> + add r4, r4, r3 @ PA(_start)
> #else
> ldr r4, =zreladdr
> #endif
> @@ -660,6 +650,11 @@ LC1: .word .L_user_stack_end - LC1 @ sp
> .word _edata - LC1 @ r6
> .size LC1, . - LC1
>
> + .align 2
> + .type LC2, #object
> +LC2: .word LC2
> + .word _start @ start VA of text section
> +
> .Lheadroom:
> .word _end - restart + 16384 + 1024*1024
>
> --
> 1.8.3
>
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-09-28 10:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-28 9:26 [PATCH 0/2] ARM: decompressor: relax the loading restriction of the decompressed kernel Zhen Lei
2020-09-28 9:26 ` [PATCH 1/2] ARM: p2v: fix trivial comments Zhen Lei
2020-09-28 9:26 ` [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel Zhen Lei
2020-09-28 10:14 ` Ard Biesheuvel [this message]
2020-09-28 11:57 ` Leizhen (ThunderTown)
2020-09-28 12:15 ` Ard Biesheuvel
2020-09-28 12:57 ` Geert Uytterhoeven
2020-09-29 2:53 ` Leizhen (ThunderTown)
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='CAMj1kXGK8x4eBL55mLMWVQWpFZKa+FSCaQj9_gieWCQSgG=xAQ@mail.gmail.com' \
--to=ardb@kernel.org \
--cc=geert+renesas@glider.be \
--cc=huawei.libin@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=thunder.leizhen@huawei.com \
--cc=wangkefeng.wang@huawei.com \
/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;
as well as URLs for NNTP newsgroup(s).