From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-12.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,NICE_REPLY_A,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04F62C2D0A8 for ; Mon, 28 Sep 2020 11:59:24 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9FDB32073A for ; Mon, 28 Sep 2020 11:59:23 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="BZc/inDV" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9FDB32073A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=upY0UrMbRfPMaccX8zjP9yYI15tfXZFSOCZCwTytY2w=; b=BZc/inDVa2DuzoMlTqbpyPsfk c/vmRO1zLysTzLV/wCLklZfPVAZ2/LSa3nx26sMLD7UbKSUlHXuy+MtDJIjQ7HiFG2+PNiB63BswZ jWWPd1K0RXmE7Z23oVbUNwOdRnkiW6Q50rGK7CYtxwO/H1VdvV03zDeRD0TAG+hnWrZ9Wwn9ucxRP dQcqXlB+bPDEVfzCYmY48G7C9l1lTIyBWQeQ17PzuCvsN+iCU78RQS16CNL9DDOA0k6EH5VaOylpk 554ZvPs58nWz8fqyLeMCWnQ1AT0ZFHMWiXBfyft/o6wK5c8DF1dApIxbeNn7GuU1QT8JfPYCYkHyK blKr/BNlQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMrnA-0006mm-7l; Mon, 28 Sep 2020 11:58:04 +0000 Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kMrn5-0006kZ-Oo for linux-arm-kernel@lists.infradead.org; Mon, 28 Sep 2020 11:58:01 +0000 Received: from DGGEMS401-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 9FACA390B4AB410C5106; Mon, 28 Sep 2020 19:57:53 +0800 (CST) Received: from [127.0.0.1] (10.174.177.253) by DGGEMS401-HUB.china.huawei.com (10.3.19.201) with Microsoft SMTP Server id 14.3.487.0; Mon, 28 Sep 2020 19:57:44 +0800 Subject: Re: [PATCH 2/2] ARM: decompressor: relax the loading restriction of the decompressed kernel To: Ard Biesheuvel , Geert Uytterhoeven References: <20200928092641.2070-1-thunder.leizhen@huawei.com> <20200928092641.2070-3-thunder.leizhen@huawei.com> From: "Leizhen (ThunderTown)" Message-ID: Date: Mon, 28 Sep 2020 19:57:43 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Originating-IP: [10.174.177.253] X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200928_075800_139385_7CAF2748 X-CRM114-Status: GOOD ( 28.40 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Kefeng Wang , Libin , Russell King , linux-arm-kernel , linux-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 2020/9/28 18:14, Ard Biesheuvel wrote: > On Mon, 28 Sep 2020 at 11:27, Zhen Lei 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 > > No, this won't work. But it works well on my board. > > 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. > > 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