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.2 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham 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 E3B6BC4338F for ; Mon, 2 Aug 2021 21:28:12 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3DFDF60F9C for ; Mon, 2 Aug 2021 21:28:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3DFDF60F9C Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 568608342C; Mon, 2 Aug 2021 23:28:10 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="hfTEaQ1l"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0766D8342F; Mon, 2 Aug 2021 23:28:08 +0200 (CEST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 18FDD833FC for ; Mon, 2 Aug 2021 23:28:04 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qk1-x733.google.com with SMTP id e14so514940qkg.3 for ; Mon, 02 Aug 2021 14:28:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hNY2FVSPtJ8lETlQn806KiaJ8ltTR1nW3+iByfWCQMk=; b=hfTEaQ1lVH93va4qY9JPr7Uzrood8EnUQ+FJo6N5+QEjBtmQuqQ7DI1DMZbvmUdXCN 35rT0Vk0Nt4AOGvN0fiJpuWlFw6ENFu7Q9VrdUS/B/LjxBt6Z9+xPlzcfjgsR9NjdDml nsxSqFtgVSAJcIfrYfSaRdPZsDacGdqtU++QA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=hNY2FVSPtJ8lETlQn806KiaJ8ltTR1nW3+iByfWCQMk=; b=r84tAgw5RKCFP7BnJ5w6iD/weuBT+P8ZQK86Rb7q7CF/pGizxQh3e1Hrg9ytwyjsDF 9fL9vwOYwbLv0eL/5w7w2i0aiEZgKDypTbxZiiSvbf0Zc8SHirJXR4dVooQcJh5QxTso j1iVVDz5k5pY/LMOTld/2VznnXZVwhmKEo72itzGDx/YlrwAh7wtXBAm6Lv5Ns4tn/FH JkmQXn8uYztncWSvZzJ9dkIrqr7XTMmrsRO/NUYQ6QgiMyihvA6G20P/csdb4GGOI7F+ sqc91w3L4kUu5KwazLF+pZDWuDi48FY/PCbFTWWZOArI3wrzZWH/xa+6fPKATor1mwzn vPQw== X-Gm-Message-State: AOAM532eQCB2sFVjfnNeRWZvfCOEfgXlApMgJo5Ei5BrL4ozB7Z5Ob8w /QHk6AvObATG5xzJ7KwTr55Diw== X-Google-Smtp-Source: ABdhPJzXLhHomnsYtDhtdb+oXK0WMkP3Eb9nNsIr9UnDglaufXQdeALUR61n+4ZYe7yz+oxccQc3hw== X-Received: by 2002:a37:ef13:: with SMTP id j19mr17713948qkk.364.1627939682818; Mon, 02 Aug 2021 14:28:02 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-a0a3-ef76-0712-405d.res6.spectrum.com. [2603:6081:7b01:cbda:a0a3:ef76:712:405d]) by smtp.gmail.com with ESMTPSA id i123sm6778035qkf.60.2021.08.02.14.28.01 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 02 Aug 2021 14:28:01 -0700 (PDT) Date: Mon, 2 Aug 2021 17:27:59 -0400 From: Tom Rini To: Jan Kiszka , Wolfgang Denk , Marek Vasut Cc: U-Boot Mailing List , Hai Pham , Simon Goldschmidt , Stephen Warren , Lokesh Vutla Subject: Re: [PATCH] Revert "arm: bootm: Disable LMB reservation for command line and board info on arm64" Message-ID: <20210802212759.GD9379@bill-the-cat> References: <1971775f-28de-83d0-9459-a4e68c744a18@siemens.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7Iz6e4189NaFV4m" Content-Disposition: inline In-Reply-To: <1971775f-28de-83d0-9459-a4e68c744a18@siemens.com> X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean --i7Iz6e4189NaFV4m Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 29, 2021 at 09:22:02AM +0200, Jan Kiszka wrote: > From: Jan Kiszka >=20 > This reverts commit 2359fa7a87848626bcbd3399e92c657595880cd7. >=20 > While the goal is valid and there is surely unused memory in that area, > we also have a lot of crucial things still located at the top-of-memory > while running lmb_alloc_base. Such things are the page table (tlb_addr), > relocated U-Boot and the active stack. Possibly more. So this patch was > premature, we will need relocations of those things first if we want to > use the range. >=20 > Fixes booting on the IOT2050, but likely also on other boards. It got=20 > stuck on relocating the FDT - over the relocated U-Boot code. >=20 > Signed-off-by: Jan Kiszka > --- >=20 > Practically, >=20 > void arch_lmb_reserve(struct lmb *lmb) > { > lmb_reserve(lmb, gd->relocaddr, gd->ram_top - gd->relocaddr); > } >=20 > worked as well for me - but it left the stack in danger. I want to cycle back up to this practically part. Marek, would changing the arch_lmb_reserve (or possibly even making this a more global thing / option) still let the area you want exposed on rcar3 (I assume) be exposed ? Or would it be covered again? Part of the problem, practically speaking, is that we need to ensure that as part of (attempting and likely succeeding in) booting the OS we don't overwrite ourself and hang. An alternative that I'm not 100% sure I like would be adjusting env_get_bootm_size() so that the case of bootm_size and bootm_low are unset, so we figure out a value based on gd->ram_top we also take in to account where U-Boot itself is atm and exclude that. It's possible that if we had something like that at the start of the DT world, we wouldn't have the code to disable fdt relocation, which really feels like it's largely been "things crash when we relocate stuff, disable relocation" and not so much "save a little boot time, we optimized things VERY CAREFULLY". --=20 Tom --i7Iz6e4189NaFV4m Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmEIY1wACgkQFHw5/5Y0 tyzSTQwAr1NZBenaVWBJKfSLa+ZBfg7QR8JWJKHDo/k6UoIyDpPBITGerFXSaZS+ Rtw0Xrn3RFBOgVW4TS/97zCt7RybWOsGA2aEvwHkkXA/PgQ0IVF5ESO3nWlZVzfD /9dIx/97zm0ftATmnR3qSl+pNoYR4i8eBiA+8pV07xTEO/kqfbHB1NM8/fVWhLCd 4MKVMsUITnDSGeOdzoEgWIBdt587dU2tsKi7lJuOlEoxsIvOmQeLgW93Idllg68Y aZ+OpYNpojuxdJJLs8BHt+mU47iggp7mVd1hPylTvcPqHBzlRnojvCOEeqS+50ek KxolPTdovD4RX5sbdbGXbnkj2YKNeAXtjfPgFO4SQwDvw8YMHnpyZIxUVHtPldAb Hc9dpOQddvfRrD1BSBaxKCk1XDpSi5wLn26OanBXqsu/N20BX5i1D8q0Q8HbaSKp kowHenRIAf/cNIWCnzUZfs/dOePHL8Mqd5VXAnhqVehODitACpb+FBbldAxVZKLV ybE7udUe =bpg0 -----END PGP SIGNATURE----- --i7Iz6e4189NaFV4m--