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 1FBF4C5479D for ; Thu, 12 Jan 2023 01:13:14 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 5F7BC85408; Thu, 12 Jan 2023 02:13:12 +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="ZECfOUwJ"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 6D6AD85405; Thu, 12 Jan 2023 02:13:10 +0100 (CET) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 378B485350 for ; Thu, 12 Jan 2023 02:13:07 +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-qt1-x834.google.com with SMTP id h21so15226617qta.12 for ; Wed, 11 Jan 2023 17:13:07 -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=pCov2Ojr15/EJoEW7HLPQqEeXwbSPxDgyi0I2KsqQJU=; b=ZECfOUwJBiTdOkadnLL8TTdbOMWZiKlv5JOzHO9hvJ3GExGdc+i22BhMe+FRZ43nUa 5inPi+cBrBPatKZTGRxr+P6zSTU5ivi6EEorf6mk2DhnumpFMFzcl3d3mdlISh9wys1E xKP89umYpmDimklrB9JLtj76n9Z8MvzRD8B8A= 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=pCov2Ojr15/EJoEW7HLPQqEeXwbSPxDgyi0I2KsqQJU=; b=n2fdSck/gJeTy6wZ70IzspqfSLDgwFVIxJ/G3VymhI1BeqhdpwVs8PEt3fzWDKiNMT pevGR2NBp8fRrK22tWYgrY9cg+vQpMxlcSLyNtoEFsSSw0puFNbKVlhJPPmYMwCN/CV4 eBTsh+kgjnYdVAVx1D0Bi0W1sgvlDzne+Fm60wVmBu/8moWZfakYxjEV8iE2fZ0KL8vx 0I0P77iBKJ21r3iwKeRe+l1nFGRJ1UrlndpGO2iSfrp1jmcgRbFC+B9OKM2a6JPibzzD c2NQrW0k632M+y/EKHkdND/JKf6NqlDJKzrbzCy6vG+++KUXGSSIeb49Hxedei9JO65x Zeqg== X-Gm-Message-State: AFqh2kpgTx7+iIQYi3jgDBF5CYqrSYTHe9g2r9gHe/pkRlLx+HzG+kGm eAhn8eI039TBLQO8Av4st3PHwEeNIaU/aYwnLgc= X-Google-Smtp-Source: AMrXdXtV8c++2gTbg8F31yvAog5lZ88zK0tTpiOdx2n8zp9pUD8LcWqCD3q2d9tQPwRot49+AEofLA== X-Received: by 2002:a05:622a:a19:b0:3ab:97cc:6ed6 with SMTP id bv25-20020a05622a0a1900b003ab97cc6ed6mr14694575qtb.48.1673485985887; Wed, 11 Jan 2023 17:13:05 -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 i18-20020ac84f52000000b003ae33f9260dsm4335873qtw.49.2023.01.11.17.13.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 11 Jan 2023 17:13:05 -0800 (PST) Date: Wed, 11 Jan 2023 20:13:02 -0500 From: Tom Rini To: Heinrich Schuchardt Cc: Mark Kettenis , 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, Simon Glass Subject: Re: [PATCH v2 3/3] lmb: consider EFI memory map Message-ID: <20230112011302.GT3787616@bill-the-cat> References: <20230111135914.GL3787616@bill-the-cat> <6a9c9564-3013-a260-c437-bab7b8e1fe96@canonical.com> <87v8lcr83v.fsf@bloch.sibelius.xs4all.nl> <0933d03c-4c35-6094-2a94-804530222c0e@canonical.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="dDzM5J4ayu2Qmwev" Content-Disposition: inline In-Reply-To: <0933d03c-4c35-6094-2a94-804530222c0e@canonical.com> 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 --dDzM5J4ayu2Qmwev Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2023 at 12:35:15AM +0100, Heinrich Schuchardt wrote: >=20 >=20 > On 1/11/23 23:59, Mark Kettenis wrote: > > > From: Simon Glass > > > Date: Wed, 11 Jan 2023 14:08:27 -0700 > >=20 > > Hi Simon, > >=20 > > > Hi Heinrich, > > >=20 > > > On Wed, 11 Jan 2023 at 11:03, Heinrich Schuchardt > > > wrote: > > > >=20 > > > >=20 > > > >=20 > > > > On 1/11/23 18:55, Simon Glass wrote: > > > > > Hi Heinrich, > > > > >=20 > > > > > On Wed, 11 Jan 2023 at 09:59, Heinrich Schuchardt > > > > > wrote: > > > > > >=20 > > > > > >=20 > > > > > >=20 > > > > > > On 1/11/23 17:48, Simon Glass wrote: > > > > > > > Hi, > > > > > > >=20 > > > > > > > On Wed, 11 Jan 2023 at 06:59, Tom Rini w= rote: > > > > > > > >=20 > > > > > > > > On Wed, Jan 11, 2023 at 08:43:37AM +0100, Heinrich Schuchar= dt 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 phys= ical addresses. > > > > > > > > > > >=20 > > > > > > > > > > > > >=20 > > > > > > > > > > > > > They're defined to a 64-bit unsigned integer by t= he UEFI > > > > > > > > > > > > > specification, so you can't change it. > > > > > > > > > > > >=20 > > > > > > > > > > > > I don't mean changing the spec, just changing the i= nternal U-Boot > > > > > > > > > > > > implementation, which is very confusing. This confu= sion is spreading > > > > > > > > > > > > out, too. > > > > > > > > > > > >=20 > > > > > > > > > > > > Regards, > > > > > > > > > > > > Simon > > > > > > > > > > >=20 > > > > > > > > > > > The real interesting thing is how memory should be ma= naged in U-Boot: > > > > > > > > > > >=20 > > > > > > > > > > > I would prefer to create a shared global memory manag= ement on 4KiB page > > > > > > > > > > > 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 mo= re 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) th= is should lead to a > > > > > > > > > > > memory reservation. You should not be able to load a = second file into an > > > > > > > > > > > overlapping memory area without releasing the allocat= ed memory first. > > > > > > > > > > >=20 > > > > > > > > > > > This would replace lmb which currently tries to recal= culate available > > > > > > > > > > > memory ab initio again and again. > > > > > > > > > > >=20 > > > > > > > > > > > With managed memory we should be able to get rid of a= ll those constants > > > > > > > > > > > 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 wh= at it has > > > > > > > > > > loaded and has pointers to it. > > > > > > > > > >=20 > > > > > > > > > > I see a future where we don't use these commands when w= e 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 mu= ch 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 doe= s not boot but > > > > > > > > > crashes. > > > > > > > >=20 > > > > > > > > It's not Odroid C2, it's anything that with the bad luck to= relocate > > > > > > > > over the unprotected EFI structures. > > > > > > >=20 > > > > > > > So can EFI use the lmb calls to reserve its memory? This patc= h is backwards. > > > > > >=20 > > > > > > Simon, the EFI code can manage memory, LMB cannot. > > > > > >=20 > > > > > > Every time something in U-Boot invokes LMB it recalculates rese= rvations > > > > > > *ab initio*. > > > > > >=20 > > > > > > You could use lib/efi_loader/efi_memory to replace LMB but not = the other > > > > > > way round. > > > > > >=20 > > > > > > We should discard LMB and replace it by proper memory managemen= t. > > > > >=20 > > > > > We have malloc() but in general this is not used (so far) except = with > > > > > some parts of standard boot, and even there we are maintaining > > > > > compatibility with existing fdt_addr_r vars, etc. > > > >=20 > > > > malloc() currently manages a portion of the memory defined by > > > > CONFIG_SYS_MALLOC_LEN. It cannot manage reserved memory. I don't kn= ow if > > > > it can allocate from non-consecutive memory areas. > > >=20 > > > This depends on whether we do what you were talking about above, i.e. > > > get rid of the env vars and allocate things. One way to allocate would > > > be with malloc(). > >=20 > > Almost certainly not a good idea. There are all sorts of constraints > > an things like the address where you load your kernel. Something > > like: "128M of memory, 2MB aligned not crossing a 1GB boundary". > >=20 > > Now *I* would argue that encoding the specific requirements of an OS > > into U-Boot is the wrong approach to start with and that you're better > > off having U-Boot load an OS-specific 2nd (or 3rd or 4th) stage loader > > that loads the actual OS kernel. Which is why providing an interface > > like EFI that provides a lot of control over memory allocation is so > > useful. >=20 > These 2nd stage boot loader are the EFI stubs of the different operating > systems. >=20 > The non-EFI boot commands are used to call Linux' legacy entry point. We > will have to manage the architecture specific rules in U-Boot. This requi= res > a memory allocator to which we can pass an upper address and an alignment > requirement. Or we just say that $range is available for at-will usage. So yes, a design document, that states the goals of what we're trying to do here, is really the next step. --=20 Tom --dDzM5J4ayu2Qmwev Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmO/XpsACgkQFHw5/5Y0 tyzALAv/cubkmjLRppqVbbzBXBsIoABOeO5rvULEjbdKjMrujgsGwIfz7pLIOPPU g81zGMDue4iVz7yciz4QDWMGdk9Wcj7w+Y7sJ6FEZfRRHYjZR2s0nKxVP7dyaCsO CktCSii0KbBubqa2j+TX65quYPhEkJHA5u0WM2pLZBCNTWOUGMVhEKyA7rhPnXz4 HgewZtBM/705aBKfCAPftNDKT1HodYQxyKCj/jcBHBba1XyNVpj5VSCz/jeTJ0JI lOAKTtxUdgl/sjfBb2qpQLwqL6GVmqII79i/T/QnwaARd8dW0YiPE6etrkqdd7qs 1oN0MSZQ1s6a+WDrq6edXVWeQWYPFGP5Xs7CLw8TEdW0JRQ+ZC/ZsPHQlYKI3PXN U2g4jpFI0ijWMopvH7fn6tZvlS+8jUb1q75FqK6zCcQpqmxbM8f3Ns7jsPk4vchP 2eEE3GDzxOljnCotXezLmEHsbwMajdDjtm8MayXzNhtZ1Jvk0DciFvuDJ3OxQVzZ iFMoNOdc =DCki -----END PGP SIGNATURE----- --dDzM5J4ayu2Qmwev--