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=-7.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no 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 34494C433E2 for ; Thu, 10 Sep 2020 10:04:40 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D94C321D6C for ; Thu, 10 Sep 2020 10:04:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599732279; bh=89wkvXMicfQ3Tzmgp/iPdj5kO7A8JFHzCkSSUnKwDaA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=CV0QWu/DF7hsNyfXgUcYE5Yev/His1VK/8Rh1Y/RtYTBsEq1m4H4cqQfU4ybc/6f1 ttQu6LzWhCfEAwBxrgIBr7Q0WoGjW/IZ/3KHSVDF5Dl38RxGGY6i5AJrt4U0TnQnqT 2YmcktIiILvPX43nzpm0RlW7bxGyXlR64eiNlg74= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730150AbgIJKEj (ORCPT ); Thu, 10 Sep 2020 06:04:39 -0400 Received: from mail.kernel.org ([198.145.29.99]:53318 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729971AbgIJKEi (ORCPT ); Thu, 10 Sep 2020 06:04:38 -0400 Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5419F21D6C for ; Thu, 10 Sep 2020 10:04:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599732277; bh=89wkvXMicfQ3Tzmgp/iPdj5kO7A8JFHzCkSSUnKwDaA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fmi0Hp7Phopb3mVcAzB84+2qHKfBkywkKV866gcInXman2RCsHcAOG0IxYZLXC1ap tUq+GYsYWNFx7vhJ/EtRacE1oFv/7vqYzBZtL0/c3gB19Gej2QPC5Ch6cspxtNOs47 ZMDWOkodHNze8JPVIg6FOKahhCY2pdHBqsIjOPjc= Received: by mail-oi1-f180.google.com with SMTP id u126so5339119oif.13 for ; Thu, 10 Sep 2020 03:04:37 -0700 (PDT) X-Gm-Message-State: AOAM531GrgzfVngmSAkYZAIshhce+8FDCGdQtv8iG4ASmzyvBdxImu5N 38OJ4W1IP+CM/17TI8zPrx+rbIwfwUOspclURFY= X-Google-Smtp-Source: ABdhPJz5zCKoas/n3Hvs6zfOnsaRHF3WPUy7aJ5Z7Dj1bImf3qdptbzYBc1D5asBm1rwcQ3h+td8vbpXc+NVT4cSGfQ= X-Received: by 2002:a54:4517:: with SMTP id l23mr3374226oil.174.1599732276545; Thu, 10 Sep 2020 03:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Thu, 10 Sep 2020 13:04:25 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base To: Atish Patra Cc: Palmer Dabbelt , linux-efi , "linux-arm-kernel@lists.infradead.org" , Maxim Uvarov , Heinrich Schuchardt , Atish Patra , Jens Wiklander , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Etienne CARRIERE , AKASHI Takahiro , Patrice CHOTARD , Sumit Garg , Grant Likely , Ilias Apalodimas , Christophe Priouzeau , Rouven Czerwinski , Patrick Delaunay Content-Type: text/plain; charset="UTF-8" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, 10 Sep 2020 at 04:34, Atish Patra wrote: > > On Wed, Sep 9, 2020 at 2:44 PM Atish Patra wrote: > > > > On Wed, Sep 9, 2020 at 1:52 PM Palmer Dabbelt wrote: > > > > > > On Wed, 09 Sep 2020 08:16:20 PDT (-0700), ardb@kernel.org wrote: > > > > Maxim reports boot failures on platforms that describe reserved memory > > > > regions in DT that are disjoint from system DRAM, and which are converted > > > > to EfiReservedMemory regions by the EFI subsystem in u-boot. > > > > > > > > As it turns out, the whole notion of discovering the base of DRAM is > > > > problematic, and it would be better to simply rely on the EFI memory > > > > allocation routines instead, and derive the FDT and initrd allocation > > > > limits from the actual placement of the kernel (which is what defines > > > > the start of the linear region anyway) > > > > > > > > Finally, we should be able to get rid of get_dram_base() entirely. > > > > However, as RISC-V only just started using it, we will need to address > > > > that at a later time. > > > > > > Looks like we're using dram_base to derive two argumets to > > > efi_relocate_kernel(): the preferred load address and the minimum load address. > > > I don't see any reason why we can't use the same PAGE_OFFSET-like logic that > > > x86 uses for the minimum load address, but I don't think we have any mechanism > > > like "struct boot_params" so we'd need to come up with something. > > > > > > > As discussed in the other thread > > (https://www.spinics.net/lists/linux-efi/msg20262.html), > > we don't need to do anything special. efi_relocate_kernel can just > > take preferred address as 0 > > so that efi_bs_alloc will fail and efi_low_alloc_above will be used to > > allocate 2MB/4MB aligned address as per requirement. > > > > I don't think the other changes in this series will cause any issue > > for RISC-V. I will test it and update anyways. > > > > > > Cc: Maxim Uvarov > > > > Cc: Heinrich Schuchardt > > > > Cc: Atish Patra > > > > Cc: Palmer Dabbelt > > > > Cc: Jens Wiklander > > > > Cc: Francois Ozog > > > > Cc: Etienne CARRIERE > > > > Cc: Takahiro Akashi > > > > Cc: Patrice CHOTARD > > > > Cc: Sumit Garg > > > > Cc: Grant Likely > > > > Cc: Ilias Apalodimas > > > > Cc: Christophe Priouzeau > > > > Cc: Rouven Czerwinski > > > > Cc: Patrick DELAUNAY > > > > > > > > Ard Biesheuvel (3): > > > > efi/libstub: Export efi_low_alloc_above() to other units > > > > efi/libstub: Use low allocation for the uncompressed kernel > > > > efi/libstub: base FDT and initrd placement on image address not DRAM > > > > base > > > > > > > > arch/arm/include/asm/efi.h | 6 +- > > > > arch/arm64/include/asm/efi.h | 2 +- > > > > drivers/firmware/efi/libstub/arm32-stub.c | 177 ++++---------------- > > > > drivers/firmware/efi/libstub/efi-stub.c | 2 +- > > > > drivers/firmware/efi/libstub/efistub.h | 3 + > > > > drivers/firmware/efi/libstub/relocate.c | 4 +- > > > > 6 files changed, 47 insertions(+), 147 deletions(-) > > > > I verified the above patches along with the following RISC-V specific changes. > > diff --git a/arch/riscv/include/asm/efi.h b/arch/riscv/include/asm/efi.h > index 93c305a638f4..dd6ceea9d548 100644 > --- a/arch/riscv/include/asm/efi.h > +++ b/arch/riscv/include/asm/efi.h > @@ -37,7 +37,7 @@ static inline unsigned long > efi_get_max_fdt_addr(unsigned long dram_base) > static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base, > unsigned long image_addr) > { > - return dram_base + SZ_256M; > + return image_addr + SZ_256M; > } > Ah yes, we need this change as well - this is a bit unfortunate since that creates a conflict with the RISC-V tree. > --- a/drivers/firmware/efi/libstub/riscv-stub.c > +++ b/drivers/firmware/efi/libstub/riscv-stub.c > @@ -100,7 +100,7 @@ efi_status_t handle_kernel_image(unsigned long *image_addr, > */ > preferred_addr = round_up(dram_base, MIN_KIMG_ALIGN) + MIN_KIMG_ALIGN; > status = efi_relocate_kernel(image_addr, kernel_size, *image_size, > - preferred_addr, MIN_KIMG_ALIGN, dram_base); > + 0, MIN_KIMG_ALIGN, 0); > > FWIW: Tested-by: Atish Patra Thanks for confirming. 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=-7.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no 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 D729CC43461 for ; Thu, 10 Sep 2020 10:06:04 +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 5A68B20BED for ; Thu, 10 Sep 2020 10:06:04 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ZgdayHkF"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="fmi0Hp7P" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5A68B20BED Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=2ImT1H3rSd34BMa5gD5xDNbeqRvDhNdYHWUxDiUypUw=; b=ZgdayHkFIY3xxZruAvIZVCLIK qgvRtN8FxHJ76hki7Y1y4RkKE4rpgpgiF8/DnxDnLF93NfjRPXVmjZANVFnoGkd2Qz1qZdTBdVi8h 7hK7k62FuL8vW61IYhnShNmm9aICOLMgrbPtU5yGRSAUYwIX6pGCKS9vMNbi42PRjG+Bj5wASbDm/ ftgegSR96DJ0mYjt/6XF8Hp5UwJXd6V8evQOSNKo4Mfg6N1+prTn5UDEfCSE0+0DQfIz7oSp/DyDL 9XQc9TuRtb3m1meFGCpdfv/Ve/6czH8F5PMTgxsduWRGnpxoPjoSNBsTQN062QiT0p8J9A0cLq2BV FKmdKHr6g==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGJRb-0006rC-4l; Thu, 10 Sep 2020 10:04:43 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGJRX-0006q8-Lp for linux-arm-kernel@lists.infradead.org; Thu, 10 Sep 2020 10:04:40 +0000 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 546D721D7E for ; Thu, 10 Sep 2020 10:04:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599732277; bh=89wkvXMicfQ3Tzmgp/iPdj5kO7A8JFHzCkSSUnKwDaA=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=fmi0Hp7Phopb3mVcAzB84+2qHKfBkywkKV866gcInXman2RCsHcAOG0IxYZLXC1ap tUq+GYsYWNFx7vhJ/EtRacE1oFv/7vqYzBZtL0/c3gB19Gej2QPC5Ch6cspxtNOs47 ZMDWOkodHNze8JPVIg6FOKahhCY2pdHBqsIjOPjc= Received: by mail-oi1-f176.google.com with SMTP id t76so5370405oif.7 for ; Thu, 10 Sep 2020 03:04:37 -0700 (PDT) X-Gm-Message-State: AOAM531bPFh0vqvco6OdlvPShZDO6GBaSY2cnMw8ke6zMOsXFbcnzlpf CTkYr5ifnkYD8Uh6TT+DVocS0Qv11azas0u6DTA= X-Google-Smtp-Source: ABdhPJz5zCKoas/n3Hvs6zfOnsaRHF3WPUy7aJ5Z7Dj1bImf3qdptbzYBc1D5asBm1rwcQ3h+td8vbpXc+NVT4cSGfQ= X-Received: by 2002:a54:4517:: with SMTP id l23mr3374226oil.174.1599732276545; Thu, 10 Sep 2020 03:04:36 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> In-Reply-To: From: Ard Biesheuvel Date: Thu, 10 Sep 2020 13:04:25 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base To: Atish Patra X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200910_060439_851768_17B3480F X-CRM114-Status: GOOD ( 40.11 ) 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: Etienne CARRIERE , =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Maxim Uvarov , Grant Likely , AKASHI Takahiro , Rouven Czerwinski , Heinrich Schuchardt , Ilias Apalodimas , Patrice CHOTARD , Patrick Delaunay , Atish Patra , linux-efi , Palmer Dabbelt , Christophe Priouzeau , Jens Wiklander , "linux-arm-kernel@lists.infradead.org" , Sumit Garg 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 Thu, 10 Sep 2020 at 04:34, Atish Patra wrote: > > On Wed, Sep 9, 2020 at 2:44 PM Atish Patra wrote: > > > > On Wed, Sep 9, 2020 at 1:52 PM Palmer Dabbelt wrote: > > > > > > On Wed, 09 Sep 2020 08:16:20 PDT (-0700), ardb@kernel.org wrote: > > > > Maxim reports boot failures on platforms that describe reserved memory > > > > regions in DT that are disjoint from system DRAM, and which are converted > > > > to EfiReservedMemory regions by the EFI subsystem in u-boot. > > > > > > > > As it turns out, the whole notion of discovering the base of DRAM is > > > > problematic, and it would be better to simply rely on the EFI memory > > > > allocation routines instead, and derive the FDT and initrd allocation > > > > limits from the actual placement of the kernel (which is what defines > > > > the start of the linear region anyway) > > > > > > > > Finally, we should be able to get rid of get_dram_base() entirely. > > > > However, as RISC-V only just started using it, we will need to address > > > > that at a later time. > > > > > > Looks like we're using dram_base to derive two argumets to > > > efi_relocate_kernel(): the preferred load address and the minimum load address. > > > I don't see any reason why we can't use the same PAGE_OFFSET-like logic that > > > x86 uses for the minimum load address, but I don't think we have any mechanism > > > like "struct boot_params" so we'd need to come up with something. > > > > > > > As discussed in the other thread > > (https://www.spinics.net/lists/linux-efi/msg20262.html), > > we don't need to do anything special. efi_relocate_kernel can just > > take preferred address as 0 > > so that efi_bs_alloc will fail and efi_low_alloc_above will be used to > > allocate 2MB/4MB aligned address as per requirement. > > > > I don't think the other changes in this series will cause any issue > > for RISC-V. I will test it and update anyways. > > > > > > Cc: Maxim Uvarov > > > > Cc: Heinrich Schuchardt > > > > Cc: Atish Patra > > > > Cc: Palmer Dabbelt > > > > Cc: Jens Wiklander > > > > Cc: Francois Ozog > > > > Cc: Etienne CARRIERE > > > > Cc: Takahiro Akashi > > > > Cc: Patrice CHOTARD > > > > Cc: Sumit Garg > > > > Cc: Grant Likely > > > > Cc: Ilias Apalodimas > > > > Cc: Christophe Priouzeau > > > > Cc: Rouven Czerwinski > > > > Cc: Patrick DELAUNAY > > > > > > > > Ard Biesheuvel (3): > > > > efi/libstub: Export efi_low_alloc_above() to other units > > > > efi/libstub: Use low allocation for the uncompressed kernel > > > > efi/libstub: base FDT and initrd placement on image address not DRAM > > > > base > > > > > > > > arch/arm/include/asm/efi.h | 6 +- > > > > arch/arm64/include/asm/efi.h | 2 +- > > > > drivers/firmware/efi/libstub/arm32-stub.c | 177 ++++---------------- > > > > drivers/firmware/efi/libstub/efi-stub.c | 2 +- > > > > drivers/firmware/efi/libstub/efistub.h | 3 + > > > > drivers/firmware/efi/libstub/relocate.c | 4 +- > > > > 6 files changed, 47 insertions(+), 147 deletions(-) > > > > I verified the above patches along with the following RISC-V specific changes. > > diff --git a/arch/riscv/include/asm/efi.h b/arch/riscv/include/asm/efi.h > index 93c305a638f4..dd6ceea9d548 100644 > --- a/arch/riscv/include/asm/efi.h > +++ b/arch/riscv/include/asm/efi.h > @@ -37,7 +37,7 @@ static inline unsigned long > efi_get_max_fdt_addr(unsigned long dram_base) > static inline unsigned long efi_get_max_initrd_addr(unsigned long dram_base, > unsigned long image_addr) > { > - return dram_base + SZ_256M; > + return image_addr + SZ_256M; > } > Ah yes, we need this change as well - this is a bit unfortunate since that creates a conflict with the RISC-V tree. > --- a/drivers/firmware/efi/libstub/riscv-stub.c > +++ b/drivers/firmware/efi/libstub/riscv-stub.c > @@ -100,7 +100,7 @@ efi_status_t handle_kernel_image(unsigned long *image_addr, > */ > preferred_addr = round_up(dram_base, MIN_KIMG_ALIGN) + MIN_KIMG_ALIGN; > status = efi_relocate_kernel(image_addr, kernel_size, *image_size, > - preferred_addr, MIN_KIMG_ALIGN, dram_base); > + 0, MIN_KIMG_ALIGN, 0); > > FWIW: Tested-by: Atish Patra Thanks for confirming. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel