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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 82D2CC5479D for ; Wed, 11 Jan 2023 13:59:25 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 1CCBE854F4; Wed, 11 Jan 2023 14:59:23 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (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="nGG1gfpx"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 79ACF854F4; Wed, 11 Jan 2023 14:59:21 +0100 (CET) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 60B948549A for ; Wed, 11 Jan 2023 14:59:18 +0100 (CET) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf32.google.com with SMTP id i12so10726982qvs.2 for ; Wed, 11 Jan 2023 05:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=GxuDQMhkHq1SF3p2U2tPYZ86LAbwuj802T2r3CvqOKY=; b=nGG1gfpxLaP7yprn6cznLTUf/s4BATFyQtKx0t3a0+WiOYMs4GVwEm5VRvvHoQB1b2 dPWtfhBZzWQQ9lyOX+gcnyXoQ008nWmDvNvmbOMeC+1l3IOWDet27DqYqFoexqsirv95 VBZxw9lAN6t16q2t9f0l7Amgqn1/fhAHFMvlk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=GxuDQMhkHq1SF3p2U2tPYZ86LAbwuj802T2r3CvqOKY=; b=7eT2PjR95FDQvRchuBWJ5hM8z+/4PZg5knN7OPl+slk6KNoVK2R3NwhISOb03SGCav curgA2oEagKncORci7cyMp/d/r7bXxrdTue/x2Tu3O96UggM0az/tK+lVLIy4PqEV/un YiF+9iAmfBlXXJFqMMpZK8s1Tc6EKA1gIADpINMMh6OJ1N+klyin/o1cyTD/9da38sQE x7dsHDKAvddX9iJ5RTr8WJOxmCLwgnmdBdaPsmaO1m7kFRS4R0pQ1iHhO02V7ENnIhlB /aCr5iUwSc/LYc0ahU2jqWvvkrNhhZ+h2Vwa0G1M4D8uS4rqIKW2KpzQHo2IUFGZb3cJ UCdg== X-Gm-Message-State: AFqh2kogLWRGET0HJOuMoNsZZs6ARceiqILUBt6wR+5YsdGiUoewWfzd FW+MGMb+85qDfFXL2UaqEYlgTA== X-Google-Smtp-Source: AMrXdXv9qi1N85sZlpigVoLJndu6Fsv9qDhYa5Aj0qGTG6DPng0ezlSDeQmwKN4aLjibOKFQ5KWGrw== X-Received: by 2002:a05:6214:5611:b0:532:3105:a329 with SMTP id mg17-20020a056214561100b005323105a329mr13374836qvb.46.1673445557016; Wed, 11 Jan 2023 05:59:17 -0800 (PST) Received: from bill-the-cat (2603-6081-7b00-6400-6c6c-38e9-6d60-4422.res6.spectrum.com. [2603:6081:7b00:6400:6c6c:38e9:6d60:4422]) by smtp.gmail.com with ESMTPSA id t5-20020a05620a450500b006fa8299b4d5sm9187986qkp.100.2023.01.11.05.59.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 05:59:16 -0800 (PST) Date: Wed, 11 Jan 2023 08:59:14 -0500 From: Tom Rini To: Heinrich Schuchardt Cc: Simon Glass , ilias.apalodimas@linaro.org, liviu.dudau@foss.arm.com, sr@denx.de, patrick.delaunay@foss.st.com, jh80.chung@samsung.com, michal.simek@amd.com, patrice.chotard@foss.st.com, ashok.reddy.soma@xilinx.com, u-boot@lists.denx.de, Mark Kettenis Subject: Re: [PATCH v2 3/3] lmb: consider EFI memory map Message-ID: <20230111135914.GL3787616@bill-the-cat> References: <20230105202536.190392-1-heinrich.schuchardt@canonical.com> <20230105202536.190392-4-heinrich.schuchardt@canonical.com> <87bkn7sbng.fsf@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="b6hkf6cPMAmARrKN" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 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.6 at phobos.denx.de X-Virus-Status: Clean --b6hkf6cPMAmARrKN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2023 at 08:43:37AM +0100, Heinrich Schuchardt wrote: >=20 >=20 > On 1/11/23 01:15, Simon Glass wrote: > > Hi Heinrich, > >=20 > > On Mon, 9 Jan 2023 at 13:53, Heinrich Schuchardt > > wrote: > > >=20 > > >=20 > > >=20 > > > On 1/9/23 21:31, Simon Glass wrote: > > > > Hi Mark, > > > >=20 > > > > On Mon, 9 Jan 2023 at 13:20, Mark Kettenis wrote: > > > > >=20 > > > > > > From: Simon Glass > > > > > > Date: Mon, 9 Jan 2023 13:11:01 -0700 > > > > > >=20 > > > > > > Hi Heinrich, > > > > > >=20 > > > > > >=20 > > > > > > We need to fix how EFI does addresses. It seems to use them as > > > > > > pointers but store them as u64 ? > > >=20 > > > That is similar to what you have been doing with physical addresses. > > >=20 > > > > >=20 > > > > > They're defined to a 64-bit unsigned integer by the UEFI > > > > > specification, so you can't change it. > > > >=20 > > > > I don't mean changing the spec, just changing the internal U-Boot > > > > implementation, which is very confusing. This confusion is spreading > > > > out, too. > > > >=20 > > > > Regards, > > > > Simon > > >=20 > > > The real interesting thing is how memory should be managed in U-Boot: > > >=20 > > > I would prefer to create a shared global memory management on 4KiB pa= ge > > > level used both for EFI and the rest of U-Boot. > >=20 > > Sounds good. > >=20 > > >=20 > > > What EFI adds to the requirements is that you need more than free > > > (EfiConventionalMemory) and used memory. EFI knows 16 different types= of > > > memory usage (see enum efi_memory_type). > >=20 > > That's a shame. How much of this is legacy and how much is useful? > >=20 > > >=20 > > > When loading a file (e.g. with the "load" command) this should lead t= o a > > > memory reservation. You should not be able to load a second file into= an > > > overlapping memory area without releasing the allocated memory first. > > >=20 > > > This would replace lmb which currently tries to recalculate available > > > memory ab initio again and again. > > >=20 > > > With managed memory we should be able to get rid of all those constan= ts > > > like $loadaddr, $fdt_addr_r, $kernel_addr_r, etc. and instead use a > > > register of named loaded files. > >=20 > > This is where standard boot comes in, since it knows what it has > > loaded and has pointers to it. > >=20 > > I see a future where we don't use these commands when we want to save > > space. It can save 300KB from the U-Boot size. > >=20 > > But this really has to come later, since there is so much churn already! > >=20 > > For now, please don't add EFI allocation into lmb..that is just odd. >=20 > It is not odd but necessary. Without it the Odroid C2 does not boot but > crashes. It's not Odroid C2, it's anything that with the bad luck to relocate over the unprotected EFI structures. --=20 Tom --b6hkf6cPMAmARrKN Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmO+wK4ACgkQFHw5/5Y0 tywq1QwAnWZTJsG3YFTTgwcTCzMehlDzrjBQnw6PUcOgqIUAXsJ8AMvoo4baHp53 ZCqT1u+DSC3UuG9xq+DMknO50fGG+Nvf7j7cEKpQpD4zuV2Mm8uNb31dQVDPSOnR WqEjF4i/bLCwS/23Bu0CNC83562OmcRpRIy+y3EckdfzkywhSJXeGGr850JjrsBK O4ICnIWIxbM4xyeQjilghL+Yy7d5TDH9LKWTiZb34jXv8pZDeN5GGIQ8o3oMP3Mg 3Oc4Jg3++/uTVkLSJWdOm32eQI9I0ul2Aic4ikXmoZPudGSom5zqc14g45P8a/bq cvnahGgr954TG2b1K5rx9yTKcqw1GpZc10ejiCKHlZ1Q8uiFVUWWcPIlWABPkniM iLyibEqOHmWVsoNiPG1eLDwzVe0o4HnAFtDwD7c7uvSV/419Wokn2ludEF0eMFZ2 AAxx4WUSctPIv3cIqjs2hOi3thi1m2a3OuZWdwTsto7zMPob5gqdRBmRUELnyNHl bf9cLjX5 =XqcB -----END PGP SIGNATURE----- --b6hkf6cPMAmARrKN--