linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).