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=-6.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 EA54CC43461 for ; Fri, 11 Sep 2020 02:16:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A6BA22076D for ; Fri, 11 Sep 2020 02:16:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=dabbelt-com.20150623.gappssmtp.com header.i=@dabbelt-com.20150623.gappssmtp.com header.b="WleHAgg9" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725385AbgIKCQn (ORCPT ); Thu, 10 Sep 2020 22:16:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53248 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725306AbgIKCQm (ORCPT ); Thu, 10 Sep 2020 22:16:42 -0400 Received: from mail-pj1-x1041.google.com (mail-pj1-x1041.google.com [IPv6:2607:f8b0:4864:20::1041]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1A395C061573 for ; Thu, 10 Sep 2020 19:16:40 -0700 (PDT) Received: by mail-pj1-x1041.google.com with SMTP id q4so955084pjh.5 for ; Thu, 10 Sep 2020 19:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=n4v/8rr4VkLsCE+CfY9rCVTARECuJFIXohdPd2zyXTQ=; b=WleHAgg9vWTEvgdLvDghO2BkCqWqrk1JEDuvlC1o4sEkaBomsTKalfNPsUZxQ2ruZr gqLjYegWIW+CkUeqJj4EblGKIFPjluIkv2ODcrrFZzatS/cbvOCNEvmOzqRzB3lsPD5M I/87nVkWdeWCpi9vPuouMuMwniw1oYt6QOpTMnbEHP+3+StzYHYtuPzdjDkuQZ6WxGxV t6DSa94u4zoYuOmforKM8oKFkw8+xlM2hHwUBjhdLs0Rc2qBIqVA/5uqFot5zcKwDAaV 49MkQXdHSZHNs18LH8TYqEcoFHMStN8awZq/zCegLgE2FZ3KcFxkNp53aBeEIAO8o0NN FDMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=n4v/8rr4VkLsCE+CfY9rCVTARECuJFIXohdPd2zyXTQ=; b=ujcft75qhFXFRdse9YIWCNQsYCtrjH6SHJUtA4qaMS5xxKj9mg9WPwp+sZIV+++PIa KPx1xek3ej41sc7mpxGkcnfT3AXdK4enP8JELrbzKGabGW3ImPqEI2z4G9lH1Gz04rYn ixvlZv40YZLOL6WcOcw8ohcA88Lf7CVYebbkAFe5Av07xUehs4pzb+aHNwUoRZy2lCkI sfmcOTrxnywG8RaVT45D0OOyyehdUwQx0ZNsCRNieNmNpUpflxkCWOBChfWN7PuNjU2F teGXeofj488v0C3z6dA17zocidrTvVIqbbdao03tns/93C1S6a9hBsQMWO4gsarqOaDo DLzA== X-Gm-Message-State: AOAM530WrD0KaAgidpFu6xkCTiNl/RbpQCs5LKpJYzHYXPYm85Pd0CmW tZZ2St+yhPzJnDPC6o5u/dNxcyXnscBnWQ== X-Google-Smtp-Source: ABdhPJwGtM8lnuFyTNYcmWKTWl78+u1+1Wp/vKfr2wpUYejVt8g10MPZsXyb4QavLxLQnh/UiGyV7w== X-Received: by 2002:a17:90a:f117:: with SMTP id cc23mr97942pjb.155.1599790599306; Thu, 10 Sep 2020 19:16:39 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id v26sm266958pgo.83.2020.09.10.19.16.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2020 19:16:38 -0700 (PDT) Date: Thu, 10 Sep 2020 19:16:38 -0700 (PDT) X-Google-Original-Date: Thu, 10 Sep 2020 19:16:37 PDT (-0700) Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base In-Reply-To: CC: atishp@atishpatra.org, linux-efi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, maxim.uvarov@linaro.org, xypron.glpk@gmx.de, Atish Patra , jens.wiklander@linaro.org, francois.ozog@linaro.org, etienne.carriere@st.com, takahiro.akashi@linaro.org, patrice.chotard@st.com, sumit.garg@linaro.org, Grant.Likely@arm.com, ilias.apalodimas@linaro.org, christophe.priouzeau@linaro.org, r.czerwinski@pengutronix.de, patrick.delaunay@st.com From: Palmer Dabbelt To: ardb@kernel.org Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Thu, 10 Sep 2020 07:08:07 PDT (-0700), ardb@kernel.org wrote: > On Thu, 10 Sep 2020 at 13:04, Ard Biesheuvel wrote: >> >> 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. > > OK, > > So, just to annoy Palmer and you more than I already have up to this > point: any chance we could do a final respin of the RISC-V code on top > of these changes? They are important for ARM, and I would prefer these > to be merged in a way that makes it easy to backport them to -stable > if needed. > > So what I would suggest is: > - I will create a new 'shared-efi' tag/stable branch containing the > existing two patches, as well as these changes (in a slightly updated > form) > - Palmer creates a new topic branch in the riscv repo based on this > shared tag, and applies the [updated] RISC-V patches on top > - Palmer drops the current version of the riscv patches from > riscv/for-next, and merges the topic branch into it instead. > > Again, sorry to be a pain, but I think this is the cleanest way to get > these changes queued up for v5.10 without painting ourselves into a > corner too much when it comes to future follow-up changes. That's fine for me. 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=-6.8 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,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 A65CBC433E2 for ; Fri, 11 Sep 2020 02:18:20 +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 2AAEC2076D for ; Fri, 11 Sep 2020 02:18:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="iByllS+D"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=dabbelt-com.20150623.gappssmtp.com header.i=@dabbelt-com.20150623.gappssmtp.com header.b="WleHAgg9" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2AAEC2076D Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=dabbelt.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-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Mime-Version:Message-ID:To:From:In-Reply-To:Subject: Date:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:References:List-Owner; bh=vh5zJt/XIln56pU9Jg8ZfOAI+XO1Kwb27fslvETA7Dg=; b=iByllS+DWfmE0mWhHF6YCpXgh KVXIIzorC/Op7B8fcgzBwJp50DBtGf9FTjb1L+p0UaPu6QOXa8qZfJQGZIM6qKbHiV1lug9c9Wfok v++CsMdBLi4WcC1mRUB7TSp9W9HNC4MsG6kky0udDqOhPeUk5yOAygQUAQWIyunoxARqf2aMkmI8v y55zs/Z0xS/eScj9rOmly2HejHB2UBOO0A+V8o/NOdFFbDpQs61WqhX0qbSFUBSTu10V2HhDbD9gV xtRs1JJXLgA/4YxzcpAd2rFXhKGBDyWCoFV+LccoNo+/eCRS82VRr+gQOZMhh7yGUxYmyv0TI4TyG oeohNdRIg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGYcH-0004Xy-Ov; Fri, 11 Sep 2020 02:16:45 +0000 Received: from mail-pj1-x1044.google.com ([2607:f8b0:4864:20::1044]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kGYcF-0004XY-I6 for linux-arm-kernel@lists.infradead.org; Fri, 11 Sep 2020 02:16:44 +0000 Received: by mail-pj1-x1044.google.com with SMTP id fa1so967533pjb.0 for ; Thu, 10 Sep 2020 19:16:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dabbelt-com.20150623.gappssmtp.com; s=20150623; h=date:subject:in-reply-to:cc:from:to:message-id:mime-version :content-transfer-encoding; bh=n4v/8rr4VkLsCE+CfY9rCVTARECuJFIXohdPd2zyXTQ=; b=WleHAgg9vWTEvgdLvDghO2BkCqWqrk1JEDuvlC1o4sEkaBomsTKalfNPsUZxQ2ruZr gqLjYegWIW+CkUeqJj4EblGKIFPjluIkv2ODcrrFZzatS/cbvOCNEvmOzqRzB3lsPD5M I/87nVkWdeWCpi9vPuouMuMwniw1oYt6QOpTMnbEHP+3+StzYHYtuPzdjDkuQZ6WxGxV t6DSa94u4zoYuOmforKM8oKFkw8+xlM2hHwUBjhdLs0Rc2qBIqVA/5uqFot5zcKwDAaV 49MkQXdHSZHNs18LH8TYqEcoFHMStN8awZq/zCegLgE2FZ3KcFxkNp53aBeEIAO8o0NN FDMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:subject:in-reply-to:cc:from:to:message-id :mime-version:content-transfer-encoding; bh=n4v/8rr4VkLsCE+CfY9rCVTARECuJFIXohdPd2zyXTQ=; b=RLDbeBf+l0sx9JXhfbF+PG4UJ2cXixb7WYqgsQPXvtHM11d+1G4RCzfXKWh2NgTHL1 bSduG3PtK98TJjbM2d/b3Fttfrr/A4xafRMsy/IwkS4lMOS/Rdt/llUN4pywm/k89f8o OqVzA9Ns01hArh7Wl/URUdCDgtKc3p0oEuIAmLbXEekjXP4iMQHbD2BydaRkGPhYAbgb bd5uFLmeBezD/+YYSyrFS+h2PU1RVz4SiVNh95heS/zzH9Q03cXR0Vs0/CoEhWoYChiX fc6HKsU78/o7lqumH5Ts6sX4zquHCsGYN3DAd55D89nlwAFsQ80fLC8pMtg9UfRD9n0H mmqQ== X-Gm-Message-State: AOAM530wX12QPx53QnbSYznovlYN5O/9hC2Kh9i3u+iizKLyDpKDuzU0 ds9C0XRzr9qWoXZRqBKjO+Js1A== X-Google-Smtp-Source: ABdhPJwGtM8lnuFyTNYcmWKTWl78+u1+1Wp/vKfr2wpUYejVt8g10MPZsXyb4QavLxLQnh/UiGyV7w== X-Received: by 2002:a17:90a:f117:: with SMTP id cc23mr97942pjb.155.1599790599306; Thu, 10 Sep 2020 19:16:39 -0700 (PDT) Received: from localhost (76-210-143-223.lightspeed.sntcca.sbcglobal.net. [76.210.143.223]) by smtp.gmail.com with ESMTPSA id v26sm266958pgo.83.2020.09.10.19.16.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 10 Sep 2020 19:16:38 -0700 (PDT) Date: Thu, 10 Sep 2020 19:16:38 -0700 (PDT) X-Google-Original-Date: Thu, 10 Sep 2020 19:16:37 PDT (-0700) Subject: Re: [PATCH RFC/RFT 0/3] efi/libstub: arm32: Remove dependency on dram_base In-Reply-To: From: Palmer Dabbelt To: ardb@kernel.org Message-ID: Mime-Version: 1.0 (MHng) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200910_221643_729485_C53ACD76 X-CRM114-Status: GOOD ( 48.94 ) 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, francois.ozog@linaro.org, maxim.uvarov@linaro.org, Grant.Likely@arm.com, takahiro.akashi@linaro.org, r.czerwinski@pengutronix.de, xypron.glpk@gmx.de, ilias.apalodimas@linaro.org, patrice.chotard@st.com, patrick.delaunay@st.com, Atish Patra , linux-efi@vger.kernel.org, atishp@atishpatra.org, christophe.priouzeau@linaro.org, jens.wiklander@linaro.org, linux-arm-kernel@lists.infradead.org, sumit.garg@linaro.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, 10 Sep 2020 07:08:07 PDT (-0700), ardb@kernel.org wrote: > On Thu, 10 Sep 2020 at 13:04, Ard Biesheuvel wrote: >> >> 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. > > OK, > > So, just to annoy Palmer and you more than I already have up to this > point: any chance we could do a final respin of the RISC-V code on top > of these changes? They are important for ARM, and I would prefer these > to be merged in a way that makes it easy to backport them to -stable > if needed. > > So what I would suggest is: > - I will create a new 'shared-efi' tag/stable branch containing the > existing two patches, as well as these changes (in a slightly updated > form) > - Palmer creates a new topic branch in the riscv repo based on this > shared tag, and applies the [updated] RISC-V patches on top > - Palmer drops the current version of the riscv patches from > riscv/for-next, and merges the topic branch into it instead. > > Again, sorry to be a pain, but I think this is the cleanest way to get > these changes queued up for v5.10 without painting ourselves into a > corner too much when it comes to future follow-up changes. That's fine for me. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel