From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Kefeng Wang <wangkefeng.wang@huawei.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Russell King <linux@armlinux.org.uk>,
Libin <huawei.libin@huawei.com>, Ard Biesheuvel <ardb@kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel
Date: Tue, 29 Sep 2020 10:53:53 +0800 [thread overview]
Message-ID: <2038e40f-cc08-83ac-2660-b5459f580488@huawei.com> (raw)
In-Reply-To: <CAMuHMdWHa-o=-a8VM+NCpxGoTEeTcm4v1FSrA17xVKzyuZDj9g@mail.gmail.com>
On 2020/9/28 20:57, Geert Uytterhoeven wrote:
> Hi Zhen,
>
> On Mon, Sep 28, 2020 at 2:15 PM Ard Biesheuvel <ardb@kernel.org> wrote:
>> On Mon, 28 Sep 2020 at 13:57, Leizhen (ThunderTown)
>> <thunder.leizhen@huawei.com> wrote:
>>> On 2020/9/28 18:14, Ard Biesheuvel wrote:
>>>> 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.
>>>
>>> But it works well on my board.
>>>
>>
>> That is because you load zImage at the base of DRAM.
>>
>>>>
>>>> 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).
>>>
>>> Maybe this is further guaranteed by the following code:
>>> /*
>>> * Set up a page table only if it won't overwrite ourself.
>>> * That means r4 < pc || r4 - 16k page directory > &_end.
>>> * Given that r4 > &_end is most unfrequent, we add a rough
>>> * additional 1MB of room for a possible appended DTB.
>>> */
>>>
>>> In addition, the Image has already been loaded when this position is reached.
>>>
>>> ----------- <--128MiB boundary
>>> | |
>>> ----------- <--TEXT_OFFSET <--
>>> | (1)Image | |
>>> ------------ |
>>> | | |
>>> ----------- (2)--copyto-----
>>> | (2)Image |
>>> -----------
>>>
>>> I don't think it's the case of (2), but (1). Because no code modification is
>>> required for the case (2).
>>>
>>> By the way, I'm not familiar with the arm32 code, so I'm just speculating.
>>>
>>
>> The zImage code that runs has not received *any* information from the
>> platform on where DRAM starts, so the only info it has is the current
>> placement of zImage.
>>
>> So when zImage is loaded at the intended base of DRAM, things work fine.
>>
>> If the zImage is loaded close to the end of a 128 MB region, the
>> rounding would pick the start of that 128 MB region. However, the
>> _start symbol you are using will point to an address that is close to
>> the end of the 128 MB [given that it is inside zImage] so your logic
>> will pick an address that is much higher in memory.
>
> https://people.kernel.org/linusw/how-the-arm32-linux-kernel-decompresses
> https://people.kernel.org/linusw/how-the-arm32-kernel-starts
> are good reads.
Thanks for your information.
>
> Gr{oetje,eeting}s,
>
> Geert
>
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
> -- Linus Torvalds
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2020-09-29 2:56 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
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) [this message]
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=2038e40f-cc08-83ac-2660-b5459f580488@huawei.com \
--to=thunder.leizhen@huawei.com \
--cc=ardb@kernel.org \
--cc=geert@linux-m68k.org \
--cc=huawei.libin@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--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).