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 465C4C43334 for ; Mon, 11 Jul 2022 06:42:21 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id D699A83F4C; Mon, 11 Jul 2022 08:42:18 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=gmx.de 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; secure) header.d=gmx.net header.i=@gmx.net header.b="FdGok2KW"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id A2BDE83FF6; Mon, 11 Jul 2022 08:42:17 +0200 (CEST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 56C5283C28 for ; Mon, 11 Jul 2022 08:42:14 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=xypron.glpk@gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1657521732; bh=fLrZIzl5z/curdfx+HBOJCvoJw0qniv52rQi5HLAoiU=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=FdGok2KWOB3LuLjKWseJfrIXm0zPum/iDH2A6TppfE5lHsGRdxuwqC+6IMCSDCs+u oI45ymamJx3lrv9D7j8RfiUp0aBjFRDYMlWbRJl1Rs0U6b42sJl+brtmYUTQbvTGNV GhTdFvc0nrRqtZazrMi0V0fA1LT/v5QaiF4ZMwaQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from [192.168.123.94] ([62.143.94.109]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mj8qd-1nghAP2Rc5-00fAmd; Mon, 11 Jul 2022 08:42:12 +0200 Message-ID: <847a24ba-845c-1a4e-f2b7-c4611a27f7bd@gmx.de> Date: Mon, 11 Jul 2022 08:42:08 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0.1 Subject: Re: [PATCH 3/3] doc: environment: Further expand on Image locations and provide example To: Tom Rini Cc: U-Boot Mailing List , Simon Glass References: <20220620143129.1772880-1-trini@konsulko.com> <20220620143129.1772880-3-trini@konsulko.com> <20220710161733.GM1146598@bill-the-cat> Content-Language: en-US From: Heinrich Schuchardt In-Reply-To: <20220710161733.GM1146598@bill-the-cat> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:5X5hKPkq9XPNA4fOtC7euvgUzPpiqJlOXDMh3W6VuOmd0CHhJeD JwVzjRa9/DiLh4yJAw2gl2TYjWSFk2UvM9FX/Gjwk7420nT4AmtoRH/cNTxYTtI0oCvTPNa yi09ZzrCy+A3kxRBHiUGnbM+1J5EE+lQ19P5J6STeYTpOJVsgjqCYLyrnUS65bC5pAATfa8 sd1ryj555nrd9n/erFg/w== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ie6m5YudJBM=:JDeat3tFUidlI+tlVjrrHC 6fUZi30AjLxeiYtmpAFvK8SLe2DgRNdboj4DaRZsq3eSca2QdWQz4HM2hZWyMFHnyl8VJEPg3 8PL40dcSVlMCraqSb689h+BUH0kOYyyHtLR+o2l9+Hu8o8TfZW3XwFFsw8xr5pD+05GiaPZaX ME9YSIjAH4Sk8FHU/2sX/4kc871kYY+5uLy+nZ+fEOu60qnp6IYxBlXEZFOKrSR4iCxe0AdaI FW7iS6dNHxJ+viDggfC2NzqyK+ETrRA5tmoNBHxZm0H15qo+9d7CWU/7Vp7V7XrFEH00ESqjB yRilAPCRvOeSzRLOja5Bqo9y0fv1td/Lx1WXCTQceiZlrf3SyvXpBjA14tkitNADPpEM282qD hA+VxHZJqoHYfJrpJ7/sDBh8t2t54bfqZgVsGeXNhJCXACc8zKmNWbHsTnM/tN5r6OsxcHhI0 Mw9XMacSTSNutHVvAcSswKvcz7ult9v5fAHZcqV/PXERAdLcGFk9yhOElWnxR55ePqp7yqyUR a2rb805SFnDrccAuB2Wby942elA3be8iOQWQyFBHbiE4NTmh96aq65WQBCGRJen2HlUqX4itQ dyBekijrSSpADEZwQVN4mcgZY5OIGJsu5UTod/riWj1G04dzWxhjHPS0A+AEmjWcHeHdQ3gly wuAp52U6TC4vT4lKQYvRGVYvlGDcqqKVQZMy5QwjdiCshfar8P0VQbLMIY9qIH5jDqZxonv1s LSgSeQaiMjPAMCzE/CK2KFfyyKckkhEWpUZBbgRkAPGh7+9BDUgNUEb+sZAnZ7dfcjlFZraMj 2EZySGriZKXJslvzrOqOBK9TtdhrEBxK+96tgh/lTcAp4NiBcslP7e92wdTvkDq2F/gXwY3So jk5SOhr85bKU3vgwmlIeWigp3dRHlGogn1Xwji3W8Y9kjvkceXHSve4g7wt68R2eOnn/fxvu/ ZOYTvsL3w0lhZVatWFMCSz7YcPOOFEVDlPTgFDqj8usfN47rkoTMrR8c2L6ra8FcFNDAVuY61 /6VTdpjndQr3BaEExUEcE7Cwujpte4egE8MpgTHOqF2rH5wNjnwXO+VLTOolad8z8lTHkRUoj urcY7U9cyum+Ug7Thr4gCECSm+OSwk/tKxtAwY8rIGk00wVJ0pXjSvGXw== 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 On 7/10/22 18:17, Tom Rini wrote: > On Sun, Jul 10, 2022 at 02:26:04PM +0200, Heinrich Schuchardt wrote: >> On 6/30/22 12:06, Simon Glass wrote: >>> On Mon, 20 Jun 2022 at 08:32, Tom Rini wrote: >>>> >>>> Start by elaborating on what some of our constraints tend to be with >>>> image location values, and document where these external constraints >>>> come from. Provide a new subsection, an example based on the TI ARMv= 7 >>>> OMAP2PLUS families of chips, that gives sample values and explains wh= y >>>> we use these particular values. This is based on what is in >>>> include/configs/ti_armv7_common.h as of fb3ad9bd923d ("TI: Add, use a >>>> DEFAULT_LINUX_BOOT_ENV environment string") as this contains just the >>>> values referenced in this document now and not some of the further >>>> additions that are less generic. >>>> >>>> Signed-off-by: Tom Rini >>>> --- >>>> doc/usage/environment.rst | 39 +++++++++++++++++++++++++++++++++++= ++++ >>>> 1 file changed, 39 insertions(+) >>> >>> Reviewed-by: Simon Glass >> >> Below you want a change? > > Yes, often Simon does that (and it's fine) to both offer a tag but if > another iteration is needed to make a minor adjustment to some wording > or another, or to make when applying. Which is fine with me. > >>>> diff --git a/doc/usage/environment.rst b/doc/usage/environment.rst >>>> index a9a4702632d2..f70ccd6a58ee 100644 >>>> --- a/doc/usage/environment.rst >>>> +++ b/doc/usage/environment.rst >>>> @@ -404,6 +404,42 @@ device tree blob fdtfile fdt_addr_r = fdt_addr >>>> ramdisk ramdiskfile ramdisk_addr_r ramdisk_addr >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> >>>> +When setting the RAM addresses for `kernel_addr_r`, `fdt_addr_r` and >>>> +`ramdisk_addr_r` there are several constraints to keep in mind. When= booting >>>> +Linux, the `Booting ARM Linux`_ and `Booting AArch64 Linux`_ documen= ts lay out >>>> +the requirements for booting all ARM platforms, including both align= ment and >>>> +where within memory various things must be. These guidelines tend t= o also be >>>> +correct for other OSes and unless specifically contradicted by docum= entation >> >> What makes you think that BSD or Haiku have the same constraints as Lin= ux? > > Because of what I said, and experience? Now, one may be a subset of > another, but that still means it will work for both. This is intended > to be general best practices. If you follow this then it's likely > anything else will work too. The danger comes from trying to optimize > the sizes to be as small as possible, rather than as large/flexible as > will likely work anywhere. I will try and expand on that idea in the > next iteration. > >>>> +specific to another architecture, are good rules to follow for other >>>> +architectures as well. >> >> No. RISC-V does not have the same requirements as ARM. E.g. the initrd >> can be located anywhere in memory. > > Please point to documentation that confirms that, and some otherwise bad > examples that actually work. [PATCH 1/1] RISC-V: load initrd wherever it fits into memory https://lore.kernel.org/all/20210629134018.62859-1-xypron.glpk@gmx.de/ Please, have a look at efi_get_max_initrd_addr() in these files: arch/arm/include/asm/efi.h:73 arch/arm64/include/asm/efi.h:77 arch/loongarch/include/asm/efi.h:36 arch/riscv/include/asm/efi.h:31 MAX_UNCOMP_KERNEL_SIZE =3D 32 MiB is only enforced in drivers/firmware/efi/libstub/arm32-stub.c. > >>>> + >>>> +Example Image locations >>>> +^^^^^^^^^^^^^^^^^^^^^^^ >> >> You seem not to refer to a file 'Image'. >> >> %s/Image/image/ > > OK. > >>>> + >>>> +If we take the Texas Instruments OMAP2PLUS family of ARMv7 processor= s as an >>>> +example for the above listed variables, we would do:: >> >> %s/we would do/we chose/ ? > > Either? I don't see it mattering either way. > >>>> + >>>> + loadaddr=3D0x82000000 >>>> + kernel_addr_r=3D${loadaddr} >>>> + fdt_addr_r=3D0x88000000 >>>> + ramdisk_addr_r=3D0x88080000 >>>> + bootm_size=3D0x10000000 >>>> + >>>> +To explain this, we start by noting that DRAM starts at 0x80000000. = A 32MiB >>> >>> Should it say 'We use a 32MiB' ? >> >> Please, mention that MAX_UNCOMP_KERNEL_SIZE =3D 32 MiB is ARMv7 specifi= c. > > Sorry? As I understood it last, the maximum size was something like > 96MiB before you have to employ some funky tricks. Look at the use of MAX_UNCOMP_KERNEL_SIZE in handle_kernel_image() of the EFI stub (drivers/firmware/efi/libstub/arm32-stub.c). > >>>> +buffer from the start of memory as our default load address, and so = where the >>>> +kernel would also be loaded to. This will hopefully allow for us to= have the >> >> %s/allow for us/allow/ >> >>>> +whole of the compressed kernel image exist in memory above where the= whole of >>>> +the decompressed kernel image will be, and allow for a quicker boot.= Next, we > > We use 32MiB for the reason I said here. Which is only a slight > rewording of the arm32 Linux booting document, and the section starts > out by saying this is an example for ARMv7 platforms. You ask all other architectures to follow this example? > >> Please, mention that decompressor code otherwise will have to relocate >> the compressed kernel. > > I'm not sure. Perhaps it would be good to also link to some of the > articles expanding upon how Linux on ARM32 boots, as part of more > general documentation, rather than a specific example here. Just look at the comment above the definition of MAX_UNCOMP_KERNEL_SIZE in arch/arm/include/asm/efi.h. > >>>> +say that the device tree will be placed at 128MiB offset from the st= art of >> >> Please, mention that initrd must be >> >> * within 512 MiB (0x20000000) of the memory start on arm >> (which restricts initrd_high) >> * in a a 1 GB aligned region of size '1UL << (VA_BITS_MIN - 1)' that >> includes the kernel on arm64 > > No, because this is not intended to list every constraint on ARM32 (nor > arm64, which would benefit from an example that's not TI, as TI arm64 > platforms share the same base address for memory). You ask above to follow the example of ARMv7 on all architectures. Hence it is necessary to point out the differences. Best regards Heinrich > >> On RISC-V such a limitation does not exist. > > I do wish that RISC-V had a similar document to ARM/ARM64, in Linux. > >>>> +memory. This is suggested by the kernel documment as it is exceedin= gly >> >> %s/documment/document >> >>>> +unlikely to be overwritten by the kernel itself given other architec= tural >>>> +constraints. We then allow for the device tree to be up to 512KiB i= n size >>>> +before placing the ramdisk in memory. We then say that everything s= hould be >>>> +within the first 256MiB of memory so that U-Boot can relocate things= as needed >>>> +to ensure proper alignment. We pick 256MiB as our value here becaus= e we know >> >> If the load address ranges occupy the first 256 MiB, where will be the >> space for relocation on a 256 MiB board? Without mentioning initrd_high >> this paragraph is incomplete. > > You don't need initrd_high / fdt_high when bootm_size is used. Maybe > that needs to be clearer in this paragraph and also the rest of the > documentation. > >>>> +there are very few platforms on in this family with less memory. It= could be >>>> +as high as 768MiB and still ensure that everything would be visible = to the >>>> +kernel, but again we go with what we assume is the safest assumption= . >> >> A section per architecture clearly naming the architecture specific >> restrictions of Linux would be much more helpful. > > I did ask for further explained examples as it would indeed be good to > have at least one per architecture. >