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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 E7F60C433E2 for ; Wed, 9 Sep 2020 15:33:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id A8329218AC for ; Wed, 9 Sep 2020 15:33:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599665592; bh=A58R2FwpUk+Bv6cIGIrRQlDvLoWAI4dMEu48+3I7uSI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=FhzAXaK3MjGLaD+YRirmBG3bovX0ZW8dzXeBMnsNdzAzvmyvlGbp/Kx3uSfYyizrc mlWjyOwn63GQ3Zz5k8mbAJV2ogvTMP/f+0jPJUFsfoWaxSKGePQBc4MEOSDnie0Jot LrM6blvnfhcya/odqy8MMWcTNYeVyKj/iVP9yJnE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728264AbgIIPcl (ORCPT ); Wed, 9 Sep 2020 11:32:41 -0400 Received: from mail.kernel.org ([198.145.29.99]:59002 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729449AbgIIPbc (ORCPT ); Wed, 9 Sep 2020 11:31:32 -0400 Received: from mail-oo1-f49.google.com (mail-oo1-f49.google.com [209.85.161.49]) (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 E66B922283 for ; Wed, 9 Sep 2020 15:30:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599665438; bh=A58R2FwpUk+Bv6cIGIrRQlDvLoWAI4dMEu48+3I7uSI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hV9ES6+EQyRJTCs8sTquOUtviNCTiNtTXcoGJIj0+i18niZEno34dQMlBVXjWs5nF 6aFeAhACrfDq0ZTn+S3cpe/qPcstup1lpj8oUwNGOTMX2zHkMUDEUOoCXojIqtDy5u sE997awefMQAUNxDQ5iI7QGbdkaRa1mxBpGwvveo= Received: by mail-oo1-f49.google.com with SMTP id s17so669801ooe.6 for ; Wed, 09 Sep 2020 08:30:37 -0700 (PDT) X-Gm-Message-State: AOAM533w++ZUYZQ5AU6YZsoIYIMOEUHrlGZvQzKZc6ZvIoZyIuuppwkN ojtFq7J3b4JOXR0dvqmMkRq/n0uJn/JGb3zAP0g= X-Google-Smtp-Source: ABdhPJz3B4t15hMJe1o9XqYUkGhgjNuE9BYBuLbPapwiG5EN+HYguvsehK0+esAd6EzUpksmXTdhrErc2NpvXfTmNaw= X-Received: by 2002:a4a:c541:: with SMTP id j1mr1177486ooq.13.1599665437106; Wed, 09 Sep 2020 08:30:37 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> <5b4c9d0f-d0c1-4627-d000-3bdf093b252a@arm.com> In-Reply-To: <5b4c9d0f-d0c1-4627-d000-3bdf093b252a@arm.com> From: Ard Biesheuvel Date: Wed, 9 Sep 2020 18:30: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: Grant Likely Cc: linux-efi , Linux ARM , Maxim Uvarov , Heinrich Schuchardt , Atish Patra , Palmer Dabbelt , Jens Wiklander , Francois Ozog , Etienne CARRIERE , Takahiro Akashi , Patrice CHOTARD , Sumit Garg , Ilias Apalodimas , Christophe Priouzeau , Rouven Czerwinski , Patrick DELAUNAY , nd 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, 9 Sep 2020 at 18:26, Grant Likely wrote: > > > > On 09/09/2020 16:16, Ard Biesheuvel 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 reasonable to me. Presumably all special cases (platform specific > spin tables, etc) are covered as reserved in the UEFI memory map, correct? > Yes. The only reason the code is as it is today is for a proprietary HP Inc. platform that had a bootservicesdata allocation at the base of DRAM of 8 KiB, but this should now be covered in the same way as any other reserved region living in the window below TEXT_OFFSET. (Note that the current logic is flawed in any case: even though boot services regions are released to the OS at ExitBootServices(), there are types of EFI configuration tables that keep their contents in BsData regions as well, and those may get clobbered by the decompressed image) In summary, I am not expecting these changes to regress any platforms we care about (famous last words), and if it works, we can start removing the dram base handling code altogether (which currently gets called on arm64 as well, even though we never use the result) 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=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,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 0ACBEC433E2 for ; Wed, 9 Sep 2020 15:32:32 +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 AA303218AC for ; Wed, 9 Sep 2020 15:32:31 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="3IQKcfUR"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="hV9ES6+E" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org AA303218AC 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=GPjMbIEZcs7FVRdr1DZmkXQFaO1PnN0yqH3/dPamoco=; b=3IQKcfURi98usFNKQBIrOwbXs qXlGuI7rmplyNyNZ0oEhA6tB6C7XaIXnCCtKKxHl6/gzbpiLQYBRQhTiat/++QwHeSeiozY9ppf7b 1eBaOeKV/09LJzFBeDWalhakqjiDPGeM/NfH9KtTTZ4AIAWBIrnhEbBcnut8KLWCNjZmTKsMxRAqu l6czFgaR0MXamOuCfLXb1PCEExJft9gnpNXYKXGecua0nX6lrbOvPQ31WWPlyCEDeJhJh8OA+MZsV 6TFriQ+JvRDLAns8Lh9yz1LlUTIaRAve41xnbswS/05vbOch7NvJOTyCPllPFAT+/a6lsWeXpyP5M 6Mw2r353w==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kG23W-0005ZD-D3; Wed, 09 Sep 2020 15:30:42 +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 1kG23S-0005Xk-Ne for linux-arm-kernel@lists.infradead.org; Wed, 09 Sep 2020 15:30:39 +0000 Received: from mail-oo1-f42.google.com (mail-oo1-f42.google.com [209.85.161.42]) (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 E1DAF22274 for ; Wed, 9 Sep 2020 15:30:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1599665438; bh=A58R2FwpUk+Bv6cIGIrRQlDvLoWAI4dMEu48+3I7uSI=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=hV9ES6+EQyRJTCs8sTquOUtviNCTiNtTXcoGJIj0+i18niZEno34dQMlBVXjWs5nF 6aFeAhACrfDq0ZTn+S3cpe/qPcstup1lpj8oUwNGOTMX2zHkMUDEUOoCXojIqtDy5u sE997awefMQAUNxDQ5iI7QGbdkaRa1mxBpGwvveo= Received: by mail-oo1-f42.google.com with SMTP id t3so666056ook.8 for ; Wed, 09 Sep 2020 08:30:37 -0700 (PDT) X-Gm-Message-State: AOAM530YKAFyOFKLbIKO59udJXaF/nDcIK2fsnQcTUfnvm/c+a3vo8B5 5u6zt+qX6Dk+u/ur0GhupHAbaQgKgdwdfrpcMrw= X-Google-Smtp-Source: ABdhPJz3B4t15hMJe1o9XqYUkGhgjNuE9BYBuLbPapwiG5EN+HYguvsehK0+esAd6EzUpksmXTdhrErc2NpvXfTmNaw= X-Received: by 2002:a4a:c541:: with SMTP id j1mr1177486ooq.13.1599665437106; Wed, 09 Sep 2020 08:30:37 -0700 (PDT) MIME-Version: 1.0 References: <20200909151623.16153-1-ardb@kernel.org> <5b4c9d0f-d0c1-4627-d000-3bdf093b252a@arm.com> In-Reply-To: <5b4c9d0f-d0c1-4627-d000-3bdf093b252a@arm.com> From: Ard Biesheuvel Date: Wed, 9 Sep 2020 18:30: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: Grant Likely X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200909_113038_994556_D5C25499 X-CRM114-Status: GOOD ( 23.27 ) 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 , Francois Ozog , Maxim Uvarov , Rouven Czerwinski , Takahiro Akashi , Heinrich Schuchardt , Ilias Apalodimas , Patrice CHOTARD , Patrick DELAUNAY , Atish Patra , linux-efi , Palmer Dabbelt , Christophe Priouzeau , nd , Jens Wiklander , Linux ARM , 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 Wed, 9 Sep 2020 at 18:26, Grant Likely wrote: > > > > On 09/09/2020 16:16, Ard Biesheuvel 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 reasonable to me. Presumably all special cases (platform specific > spin tables, etc) are covered as reserved in the UEFI memory map, correct? > Yes. The only reason the code is as it is today is for a proprietary HP Inc. platform that had a bootservicesdata allocation at the base of DRAM of 8 KiB, but this should now be covered in the same way as any other reserved region living in the window below TEXT_OFFSET. (Note that the current logic is flawed in any case: even though boot services regions are released to the OS at ExitBootServices(), there are types of EFI configuration tables that keep their contents in BsData regions as well, and those may get clobbered by the decompressed image) In summary, I am not expecting these changes to regress any platforms we care about (famous last words), and if it works, we can start removing the dram base handling code altogether (which currently gets called on arm64 as well, even though we never use the result) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel