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=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,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 46927C43461 for ; Wed, 9 Sep 2020 21:45:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 0820A21D7E for ; Wed, 9 Sep 2020 21:45:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=atishpatra.org header.i=@atishpatra.org header.b="OZ/llB7d" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726642AbgIIVpQ (ORCPT ); Wed, 9 Sep 2020 17:45:16 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726426AbgIIVpN (ORCPT ); Wed, 9 Sep 2020 17:45:13 -0400 Received: from mail-wr1-x443.google.com (mail-wr1-x443.google.com [IPv6:2a00:1450:4864:20::443]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C99BC061573 for ; Wed, 9 Sep 2020 14:45:12 -0700 (PDT) Received: by mail-wr1-x443.google.com with SMTP id g4so4509333wrs.5 for ; Wed, 09 Sep 2020 14:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zjXB6RSVR31iO/o/+lQkByeEIJlLeUpgP6mQyDn/b/c=; b=OZ/llB7dYS9Mz7UxAsP/ozoZXGJhVoR1/qxsJAsztQ7MQBvEAXC5AEVxS7a+nIfwCJ lRs5bGHeQfPTd+s1BO4OpXW+UMBUXT7EzXFve/7cnQGOWLWdiAuxZXHjX2b/nx1snSZs /dqG78RZbyK9aDL+IPxIkLGGvzvW2FdTVR4io= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zjXB6RSVR31iO/o/+lQkByeEIJlLeUpgP6mQyDn/b/c=; b=k3+8CCY6cxSdBuSxlN0TPigDAW470LID21bzeDJieVmFX0FImdSRG/0wcicZKWy7if h8vsmbw7hBS61P4WkPEOnyN+ikAa+xij6iod+2ooXRqAJkHkKEKOcQ/bajPEMBgpecJK C5Hiuy42bMEW+5dXrKSpPkfE2zJ7/1QJBEvflyvbTlDuiGoc/ExwRZL/Hg4exYku59XC Koj8AI0SilOldWqYNEqtUxjfxKr/IFYqdcJ6WIm+1Z2dKPlQA9Nxn/T9c0TYo5msEiw2 hLc7vF7Up1x2NNjFT7cGeTkzwlUcgQQHk2qdajjNOIsJdte/pMt6EY7AQYGIXrihrd+z mgzA== X-Gm-Message-State: AOAM531rHCq7kUh3sxrrzFtdW6pZKhRmgdSHAdKZEz/wfqXrY0j5BpEp qK6v/g7iBuq0aVuac93bHopYZhGSQrmmWNCsObbB X-Google-Smtp-Source: ABdhPJz3pDCBDEHwsMyOAEopSTwmqesSI9PYXVRCP1kF57g5AXOXavKqcFCIQzXGDfwoWb2L9B1eqp7kssP/dlIcSYc= X-Received: by 2002:a5d:4bcf:: with SMTP id l15mr5685168wrt.384.1599687910745; Wed, 09 Sep 2020 14:45:10 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> In-Reply-To: From: Atish Patra Date: Wed, 9 Sep 2020 14:44:59 -0700 Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base To: Palmer Dabbelt Cc: Ard Biesheuvel , 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@st.com, AKASHI Takahiro , patrice.chotard@st.com, sumit.garg@linaro.org, Grant Likely , Ilias Apalodimas , christophe.priouzeau@linaro.org, r.czerwinski@pengutronix.de, 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 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(-) -- Regards, Atish 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=-3.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 4EEB0C433E2 for ; Wed, 9 Sep 2020 21:46:44 +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 DC27A205CB for ; Wed, 9 Sep 2020 21:46:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="1U7igC/V"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=atishpatra.org header.i=@atishpatra.org header.b="OZ/llB7d" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DC27A205CB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=atishpatra.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=IL2pn+l1JZVsba7L6i7rk+/knCMhy7vif54D+KYiN1w=; b=1U7igC/VGmGfYktXBUnygzp3g lsi/YMLB5p5xnJn2E5wDTkKmQIg0LcpxJ64InnsTszlCYJizQ3C6YklPaGlDKgCng4o1mU1MifNln FEa1mtCaj1eG1G6Um3jBX1PmGXNNfQl6D3aUli8RyaUlmF9l3TWfPIxYKMMVq9H2XCu2DBOrciOXZ v4BbPlFAm70wteA1yNxtVIcUyOFJFREkNMyZVuDmMKkJV80/Pf8gUro3K+HhbIoiKJZVczp83H1Uh hFvh593rvYYVl8LwLHWf/CjoT4y6O7UtRo6ZItoZLrgYoa6mTel9rc92VY4QQILiUYGLKnB+0rpl8 auiQpqfHA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kG7u0-0007w8-6H; Wed, 09 Sep 2020 21:45:16 +0000 Received: from mail-wr1-x444.google.com ([2a00:1450:4864:20::444]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kG7tx-0007vh-KD for linux-arm-kernel@lists.infradead.org; Wed, 09 Sep 2020 21:45:14 +0000 Received: by mail-wr1-x444.google.com with SMTP id k15so4478079wrn.10 for ; Wed, 09 Sep 2020 14:45:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zjXB6RSVR31iO/o/+lQkByeEIJlLeUpgP6mQyDn/b/c=; b=OZ/llB7dYS9Mz7UxAsP/ozoZXGJhVoR1/qxsJAsztQ7MQBvEAXC5AEVxS7a+nIfwCJ lRs5bGHeQfPTd+s1BO4OpXW+UMBUXT7EzXFve/7cnQGOWLWdiAuxZXHjX2b/nx1snSZs /dqG78RZbyK9aDL+IPxIkLGGvzvW2FdTVR4io= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zjXB6RSVR31iO/o/+lQkByeEIJlLeUpgP6mQyDn/b/c=; b=QP+IV+r9WvsHBZK2rNMX3FCi5OxDE4ePmG4WDxkAzEtcfq85mkuNnqVIDH20g/ocu+ 1LLdweIGsJ0L9Afq6YHtNTHV5xOgrW2uBwgVKWzYGEoWMIezIlN/OMYGkfDhQQB32Sij YsMt+nXsJved4sCp7aZA8vi2a7scF/P7Nu1VEMYzG24dExcOv7G8bxFpLloNPRZX5MFq IOIKm1wfWFfe0DaiEDhcIVGvOpqPIYZI5X5L0rQcUm4O4iSjtF5LXnEELSrIzlfOZah5 tw5NHQLnVqvJK0uQzhIGB81lJoLgGQrx2sYiDVwzst+zWDetNtDjg661HW/s3KXGaPra HEgg== X-Gm-Message-State: AOAM532Wxu3yhXiEVgtANLEnvIzH/tuobarg56rpU0aLiiATU0IO3G1I kYZPlhaaWakZxp2x8To69/7TGUnC1wFdk7qu+20d X-Google-Smtp-Source: ABdhPJz3pDCBDEHwsMyOAEopSTwmqesSI9PYXVRCP1kF57g5AXOXavKqcFCIQzXGDfwoWb2L9B1eqp7kssP/dlIcSYc= X-Received: by 2002:a5d:4bcf:: with SMTP id l15mr5685168wrt.384.1599687910745; Wed, 09 Sep 2020 14:45:10 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> In-Reply-To: From: Atish Patra Date: Wed, 9 Sep 2020 14:44:59 -0700 Message-ID: Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base To: Palmer Dabbelt X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200909_174513_764954_16267772 X-CRM114-Status: GOOD ( 27.55 ) 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@st.com, =?UTF-8?Q?Fran=C3=A7ois_Ozog?= , Maxim Uvarov , Grant Likely , AKASHI Takahiro , r.czerwinski@pengutronix.de, Heinrich Schuchardt , Ilias Apalodimas , patrice.chotard@st.com, Patrick Delaunay , Jens Wiklander , Atish Patra , linux-efi , christophe.priouzeau@linaro.org, Ard Biesheuvel , "linux-arm-kernel@lists.infradead.org" , sumit.garg@linaro.org 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 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(-) -- Regards, Atish _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel