Re: QEMU NUMA and U-Boot
Le mer. 7 juil. 2021 à 19:39, Heinrich Schuchardt a
écrit :
>
>
> On 7/7/21 5:15 PM, François Ozog wrote:
> > top posting what now works for me:
> > - changed calculation of memory size to loop through different memory
> nodes
> > - added numa_node to banks
> > - filter out banks that do not match the target mixup node (do not want
> > to change ABI to add node information)
> >
> > That's not satisfying overall but at least my code works with NUMA on
> Qemu.
>
> Do we expect real hardware with NUMA to be using U-Boot?
with new Apple M1 Ultra and NVidia Grace I think that we have examples of
what we will find in some automotive Domain Controller Units.
Are there other signs for NUMA requirements for U-Boot?
>
> If you have real ARM hardware in NUMA configuration, can the boot CPU
> access memory of dormant CPUs when U-Boot is entered?
>
> Best regards
>
> Heinrich
>
> >
> >
> > *diff --git a/Kconfig b/Kconfig*
> >
> > *index f8c1a77bed..4d3ab8cb49 100644*
> >
> > *--- a/Kconfig*
> >
> > *+++ b/Kconfig*
> >
> > @@ -192,7 +192,9 @@config NR_DRAM_BANKS
> >
> > default 1 if ARCH_SUNXI || ARCH_OWL
> >
> > default 4
> >
> > help
> >
> > - This defines the number of DRAM banks.
> >
> > +This defines the number of DRAM banks. For qemu with NUMA, you
> >
> > +may want to set this value to * .
> >
> > +for instance, for a 2 slot with 4 memdevs set NR_DRAM_BANKS to 8.
> >
> > config SYS_BOOT_GET_CMDLINE
> >
> > bool "Enable kernel command line setup"
> >
> > *diff --git a/arch/arm/lib/bootm-fdt.c b/arch/arm/lib/bootm-fdt.c*
> >
> > *index 29020bd1c6..2b28ab8108 100644*
> >
> > *--- a/arch/arm/lib/bootm-fdt.c*
> >
> > *+++ b/arch/arm/lib/bootm-fdt.c*
> >
> > @@ -42,12 +42,17 @@int arch_fixup_fdt(void *blob)
> >
> > u64 size[CONFIG_NR_DRAM_BANKS];
> >
> > for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> >
> > +unsigned char node = bd->bi_dram[bank].numa_node;
> >
> > start[bank] = bd->bi_dram[bank].start;
> >
> > size[bank] = bd->bi_dram[bank].size;
> >
> > #ifdef CONFIG_ARMV7_NONSEC
> >
> > ret = armv7_apply_memory_carveout([bank], [bank]);
> >
> > if (ret)
> >
> > return ret;
> >
> > +#endif
> >
> > +#ifdef CONFIG_OF_LIBFDT
> >
> > +/* add node info for the fdt_fixup_memory below */
> >
> > +start[bank] = (((phys_addr_t)node) << 56) | bd->bi_dram[bank].start;
> >
> > #endif
> >
> > }
> >
> > *diff --git a/common/fdt_support.c b/common/fdt_support.c*
> >
> > *index a9a32df1e7..3bca2ba888 100644*
> >
> > *--- a/common/fdt_support.c*
> >
> > *+++ b/common/fdt_support.c*
> >
> > @@ -415,16 +415,29 @@static int fdt_pack_reg(const void *fdt, void *buf,
> > u64 *address, u64 *size,
> >
> > return p - (char *)buf;
> >
> > }
> >
> > +static inline uint32_t fdt32_ld(const fdt32_t *p)
> >
> > +{
> >
> > +const uint8_t *bp = (const uint8_t *)p;
> >
> > +
> >
> > +return ((uint32_t)bp[0] << 24)
> >
> > + | ((uint32_t)bp[1] << 16)
> >
> > + | ((uint32_t)bp[2] << 8)
> >
> > + | bp[3];
> >
> > +}
> >
> > #if CONFIG_NR_DRAM_BANKS > 4
> >
> > #define MEMORY_BANKS_MAX CONFIG_NR_DRAM_BANKS
> >
> > #else
> >
> > #define MEMORY_BANKS_MAX 4
> >
> > #endif
> >
> > +/* NUMA has yet to be properly handled
> >
> > + * This code appends memory to the first memory node that matches the
> > NUMA node.
> >
> > + */
> >
> > int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int
> banks)
> >
> > {
> >
> > int err, nodeoffset;
> >
> > int len, i;
> >
> > u8 tmp[MEMORY_BANKS_MAX * 16]; /* Up to 64-bit address + 64-bit size */
> >
> > +unsigned int numa_node;
> >
> > if (banks > MEMORY_BANKS_MAX) {
> >
> > printf("%s: num banks %d exceeds hardcoded limit %d."
> >
> > @@ -444,6 +457,12 @@int fdt_fixup_memory_banks(void *blob, u64 start[],
> > u64 size[], int banks)
> >
> > if (nodeoffset < 0)
> >
> > return nodeoffset;
> >
> > +const __be32* numa_node_prop = fdt_getprop(blob, nodeoffset,
> > "numa-node-id", );
> >
> > +if (numa_node_prop != NULL && len == sizeof(__be32)) {
> >
> &
Re: Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Sahil, (and happy new year ;-) On Thu, 6 Jan 2022 at 07:09, Sahil Malhotra (OSS) < sahil.malho...@oss.nxp.com> wrote: > Hi Michael, > > > -Original Message- > > From: Michael Walle > > Sent: Thursday, December 23, 2021 3:05 PM > > To: Sahil Malhotra (OSS) > > Cc: ZHIZHIKIN Andrey ; Clément > Faure > > ; Gaurav Jain ; Pankaj Gupta > > ; Priyanka Jain ; u- > > b...@lists.denx.de; Varun Sethi ; Ye Li > > Subject: Re: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > feature > > > > Hi Sahil, > > > > Am 2021-12-23 09:46, schrieb Sahil Malhotra (OSS): > > >> -Original Message- > > >> From: U-Boot On Behalf Of Michael > > >> Walle > > >> Sent: Monday, December 20, 2021 6:23 PM > > >> To: Sahil Malhotra (OSS) > > >> Cc: ZHIZHIKIN Andrey ; Clément > > >> Faure ; Gaurav Jain ; > > >> Pankaj Gupta ; Priyanka Jain > > >> ; u-boot@lists.denx.de; Varun Sethi > > >> ; Ye Li > > >> Subject: [EXT] Re: [PATCH 1/2] fsl-layerscape: add dtb overlay > > >> feature > > >> > > >> Caution: EXT Email > > >> > > >> Hi Sahil, > > >> > > >> Am 2021-12-10 07:33, schrieb Sahil Malhotra (OSS): > > >> >> DT nodes can be statically disabled if we know that they are held > > >> >> by HAB and are not released to NS World. > > >> >> > > >> >> OP-TEE does set the status itself via dt_enable_secure_status(), > > >> >> which should present the properly configured FDT when U-Boot takes > > >> over. > > >> > Yes, OP-TEE set the status by dt_enable_secure_status() in DTB > > >> > overlay which gets merged with DTB provided for Linux bootup and > > >> > then Linux boots with merged DTB. > > >> > But u-boot uses the DTB embedded in its image. How can we modify > > >> > that DTB or merge DTB overlay passed by OP-TEE with uboot DTB ? > > >> > > >> But then u-boot has the "wrong" dtb. What is the reason, there is an > > >> overlay instead of a whole dtb? what if the overlay doesn't match the > > >> dtb? > > > "wrong" dtb means that uboot will not be aware of CAAM job ring which > > > is taken by OP-TEE and uboot on LS platforms currently use JR0, which > > > is not being used by any other entity in LS bootflow. > > > > I don't know I follow. u-boot and linux should have the same device tree; > > regardless if that device is used or not. So applying the overlay just > for linux isn't > > enough here. > Ok, I don't think that as of now, in all platforms uboot and linux have > same devie > tree. > But I will try to address your concern, but I don’t know how to apply > overlay to > dtb which is embedded in u-boot binary, Can you please point me to one > reference > which is doing this thing, I will take reference from there. > > > > We don't use DTB in OP-TEE, but when we use CAAM in OP-TEE, OP-TEE > > > reserves One Job Ring for its use and that is communicated to Kernel > > > using DTB overlay. > > > > > >> what if the overlay doesn't match the dtb? > > > I didn't get this point, can you please elaborate a little. > > > > You are merging a dtb fragment with an unknown dtb, right? Who says they > > match? you might have an old dtb where the supplied dtb fragment doesn't > > make any sense. > > > > I might be missing something here. Eg. where is the linux dtb supposed > to come > > from? This patchset is really missing an example and a description how > things > > should work. > If supplied DTB does not match with DTB overlay fragment. then overlay > will not get applied. > We don't have any control on where user picks the DTB, but we can only > make sure DTB > overlay feature must work with DTBs which are upstreamed > If user makes its own customized DTB, we cannot make sure that things will > work. > > Elaborating on a broader context: who is the user in U-Boot? In desktops/laptops context, I understand the user could be the desktop/laptop owner but based on my limited understanding of Chrome, users are quite constrained in what they can do (allowing the user to play with DT is a recipe for costly support). In the embedded case, is the user the one who makes a board based on the SoC ? the product maker that uses the board for a particular solution ? the integrator who places the board in a larger product ? the larger product maker ? the larger product owner ? the larger product maintenance guy? ultimately I think there is a need to empower a number of actors listed above who will take the responsibility based on consultation from the software value chain. All this to say I believe we lack vocabulary to identify actors in the firmware software value chain: has anyone already tried to formalize this? Regards, > Sahil Malhotra >
Re: efi bootmenu
HI Simon On Wed, 29 Dec 2021 at 14:36, Simon Glass wrote: > Hi François, > > On Tue, 28 Dec 2021 at 03:15, François Ozog > wrote: > > > > > > > > Le mar. 28 déc. 2021 à 09:32, Simon Glass a écrit : > >> > >> Hi Masahisa, > >> > >> On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > >> wrote: > >> > > >> > Hi Takahiro, > >> > > >> > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > >> > wrote: > >> > > > >> > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: > >> > > > Hi Heinrich, Ilias, Akashi-san, > >> > > > > >> > > > Ilias and I are now discussing to create efi bootmenu, almost > similar > >> > > > to UiApp in EDK2. > >> > > > >> > > Why not discuss this topic openly in ML? > >> > > >> > Yes, I included U-Boot ML.(Sorry, I should include from the the > beginning.) > >> > > >> > > > >> > > How is this feature related to Simon's bootmethod proposal? > >> > > >> > If I correctly understand Simon's bootmethod proposal, > >> > the difference is that efi bootmenu only targets to implement > >> > the menu based UI to select/edit/add/delete "Boot" and > "BootOrder". > >> > >> Yes, EFI would be one of the bootmethods. Others would be U-Boot > >> scripts, Chrome OS, Android, etc. plus people might add custom ones. > >> > >> Also I am thinking that (perhaps) the bootdev part of the standard > >> boot thing could be used to provide boot devices for EFI. > >> > >> If we do have a bootmenu, I wonder if it could be generic, instead of > >> tied to EFI? > > > > EFI Boot specify an array of device paths and boot options. A device > path is quite a unique construct despite its name. > > A device path is itself an array of elements, some elements can be a > file path , configuration information, or diverse metadata. An example of > configuration information element is UART baud,stop bits, parity along with > terminal (vt100, ansi…). Another device path element can cover IP address, > transport information (tcp, UDP and port number). > > The traditional EFI boot menu is quite crude and does not expose the > full capabilities of Boot (lacks edit of boot options for instance!). > > > > In the long run we will need to leverage all the Boot capabilities > and those are EFI specific while being OS agnostic. > > The other U-Boot boot methods (Android , ChromeOS…) are OS specific. > > The goals are thus very different and making a generic approach seems > quite compromised. If there is a fully generic framework available in the > future, it may be possible to integrate the EFI boot menu. But at least > there is a need to solve, code first, the EFI complexities to fuel the > generic architecture discussion. > > Despite this, the goal of standard boot is to encompass all of this > within U-Boot. I believe that it will be successful, even if the path > at present is a bit unclear. > So I would suggest we work bottom up. Starting by making EFI menu work, then extend it more generic or integrated it in a framework. Starting top down would require a long architecture process based on not enough known problems to solve for each environment. > > [..] > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: efi bootmenu
Le mar. 28 déc. 2021 à 09:32, Simon Glass a écrit : > Hi Masahisa, > > On Tue, 21 Dec 2021 at 00:37, Masahisa Kojima > wrote: > > > > Hi Takahiro, > > > > On Tue, 21 Dec 2021 at 11:47, Takahiro Akashi > > wrote: > > > > > > On Mon, Dec 20, 2021 at 06:25:05PM +0900, Masahisa Kojima wrote: > > > > Hi Heinrich, Ilias, Akashi-san, > > > > > > > > Ilias and I are now discussing to create efi bootmenu, almost similar > > > > to UiApp in EDK2. > > > > > > Why not discuss this topic openly in ML? > > > > Yes, I included U-Boot ML.(Sorry, I should include from the the > beginning.) > > > > > > > > How is this feature related to Simon's bootmethod proposal? > > > > If I correctly understand Simon's bootmethod proposal, > > the difference is that efi bootmenu only targets to implement > > the menu based UI to select/edit/add/delete "Boot" and "BootOrder". > > Yes, EFI would be one of the bootmethods. Others would be U-Boot > scripts, Chrome OS, Android, etc. plus people might add custom ones. > > Also I am thinking that (perhaps) the bootdev part of the standard > boot thing could be used to provide boot devices for EFI. > > If we do have a bootmenu, I wonder if it could be generic, instead of > tied to EFI? EFI Boot specify an array of device paths and boot options. A device path is quite a unique construct despite its name. A device path is itself an array of elements, some elements can be a file path , configuration information, or diverse metadata. An example of configuration information element is UART baud,stop bits, parity along with terminal (vt100, ansi…). Another device path element can cover IP address, transport information (tcp, UDP and port number). The traditional EFI boot menu is quite crude and does not expose the full capabilities of Boot (lacks edit of boot options for instance!). In the long run we will need to leverage all the Boot capabilities and those are EFI specific while being OS agnostic. The other U-Boot boot methods (Android , ChromeOS…) are OS specific. The goals are thus very different and making a generic approach seems quite compromised. If there is a fully generic framework available in the future, it may be possible to integrate the EFI boot menu. But at least there is a need to solve, code first, the EFI complexities to fuel the generic architecture discussion. > > > Regards, > Simon > > > > > > > > > > > Here is some background. > > > > === > > > > U-Boot's command line should be completely disabled on secure > devices. > > > > However since U-Boot doesn't (yet) support EFI runtime SetVariable > > > > for all supported devices, disabling the command line is hard, if > even possible. > > > > If we provide a boot menu, with access to very limited > functionality, e.g select > > > > a boot option and allow users to add/edit/delete existing options, > > > > we can enhance security and provide a usable alternative to the > users. > > > > > > > > In addition, if we can add options for managing EFI keys and enabling > > > > disabling secure boot, we can completely get rid of the u-boot cmd > line, > > > > greatly enhancing platform security > > > > > > Basically, it will be a good idea. > > > Please keep in mind, however, that add/deleting boot options, > > > [en|dis]abling secure boot or modifying secure variables should > > > belong to some sort of privileged operations. > > > I think that we need to have some mechanism to distinguish them > > > from other menus. It might be system specific, though. > > > > > > > === > > > > > > > > I am planning to hook the existing "bootefi bootmgr" boot process. > > > > In "bootefi bootmgr", the planned process will be as follows. > > > > 1) check "BootNext" > > > > > > What do you mean by "check"? > > > > I meant the existing bootmgr implementation. If "BootNext" is > > specified, system boots with "BootNext". > > > > > > > > > 2) show efi bootmenu (*NEW*) > > > > 3) if user quits efi bootmenu, then boot in accordance with > "BootOrder" > > > > It means efi bootmenu is native u-boot program. > > > > > > > > I would like to hear your opinion how this efi bootmenu should be > implemented. > > > > Is it better to implement as EFI application? > > > > > > In my personal opinion, we should implement the feature as a separate > > > EFI application. One of benefits of UEFI interfaces are the ability > > > to expand functionality with driver modules and applications without > > > modifying the core. > > > (One example is iPXE boot that Heinrich often picks up in his > comments.) > > > > > > If it is an EFI application, it can be easily replaced with others > > > per system and we may be able to use secure boot to authorise the app > > > itself. > > > > Thank you, I understand the benefit of implementing as EFI App. > > > > > > > > But implementing it as an EFI app is not the goal, and I think you can > > > start with what you want to do first. > > > > > > > Note that I tried to run edk2 UiApp on U-Boot, I found that the > > > >
Re: [PATCH 1/2] fsl-layerscape: add dtb overlay feature
Hi Michael Le lun. 29 nov. 2021 à 18:47, Michael Walle a écrit : > Hi Sahil, > > Am 2021-11-29 12:55, schrieb Sahil Malhotra (OSS): > > Am 2021-11-17 19:11, schrieb Sahil Malhotra (OSS): > >>> Could you please add some description what this is doing and for what > >>> this is intended? To have a "DTB overlay feature", it is enough to > >>> just enable CONFIG_OF_LIBFDT_OVERLAY. > >> I will add some description, and yes for DTB overlay feature, it is > >> enough to enable CONFIG_OF_LIBFDT_OVERLAY but we need to do this step > >> before booting the kernel that's why also have to enable > >> CONFIG_OF_SYSTEM_SETUP. > > > >> Ok. What will the overlay do? Could you give an example? > > This overlay will be disabling the crypto nodes which will be used by > > optee in secure world, so that linux should not use it. > > > > > >>> Apparently you're adding an overlay passed by optee. Doesn't this > >>> have to be applied to u-boot's control dtb too? > >> Yes, we will be applying the overlay passed by optee, yes it will be > >> applied to dtb which will be passed to uboot for kernel booting. > > > >> If I read this patch correctly, you're modifying the DT before you > >> jump to linux. But I was asking whether you also have to modify the DT > >> which is used by u-boot. Eg. if you disable some kind of crypto nodes > >> (because optee will use them in secure world), this also have to > >> communicated to u-boot, not only linux, no? > > Yes, I got your point now, and is very valid, but as of now for u-boot > > we are just using the first available node for communicating with CAAM > > leaving other job rings as it is. > > So we need not to apply overlay to DTB used by uboot. > > But we should do the correct thing, so that u-boot and linux > doesn't see a different version of the device tree. Outside any runtime context there should be a reference for hardware description. That non-runtime reference need to be firmware and OS agnostic and document what devices are seen by each. For instance a board with serdes should have serdes nodes and disabled nodes that corresponds to possible nodes (pci, network, storage…) created as a result of the serdes configuration. One would expect firmware does it but nothing prevent an OS to do it. Those nodes should not refer to U-Boot or Linux, just firmware and operating system. Furthermore, there may be multiple totally independent computing domains on a single board: Cortex-a + r/m, multiple cortex-a and cortex-r/m and other cores. So the reference hardware description should encompass all and provide consistent description of resources available in multiple domains (say some hardware mail box and why not some sram). To be consumed by different operating systems. Linux, if the operating system of choice for that platform, will only see a portion of the total hardware description. That part may be further reduced at runtime for various legislative reasons, one of them being presented by Sahil. For your above comment, were you referring to this reference hardware description of the cortex-a domain of the board ? > Also what do you mean with "the first available node"? > There is already a new CAAM driver for u-boot pending, > see > https://lore.kernel.org/u-boot/2025070014.17586-1-gaurav.j...@nxp.com/ > > -michael > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
Hi Simon On Mon, 6 Dec 2021 at 16:23, Simon Glass wrote: > Hi François, > > On Sat, 4 Dec 2021 at 18:15, François Ozog > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 18:42, Simon Glass a écrit : > >> > >> Hi François, > >> > >> On Sat, 4 Dec 2021 at 04:06, François Ozog > wrote: > >> > > >> > Hi Simon > >> > > >> > Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit : > >> >> > >> >> Hi Heinrich, > >> >> > >> >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt > wrote: > >> >> > > >> >> > On 12/3/21 9:13 PM, Simon Glass wrote: > >> >> > > Hi Heinrich, > >> >> > > > >> >> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt < > xypron.g...@gmx.de> wrote: > >> >> > >> > >> >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote: > >> >> > >>> On 12/2/21 16:58, Simon Glass wrote: > >> >> > >>>> At present some of the ideas and techniques behind devicetree > in U-Boot > >> >> > >>>> are assumed, implied or unsaid. Add some documentation to > cover how > >> >> > >>>> devicetree is build, how it can be modified and the rules > about using > >> >> > >>>> the various CONFIG_OF_... options. > >> >> > >>>> > >> >> > >>>> Signed-off-by: Simon Glass > >> >> > >>>> Reviewed-by: Marcel Ziswiler > >> >> > >>>> --- > >> >> > >>>> This patch attracted quite a bit of discussion here: > >> >> > >>>> > >> >> > >>>> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> >> > >>>> > >> >> > >>>> > >> >> > >>>> I have not included the text suggested by François. While I > agree that > >> >> > >>>> it would be useful to have an introduction in this space, I > do not agree > >> >> > >>>> that we should have two devicetrees or that U-Boot should not > have its > >> >> > >>>> own > >> >> > >>>> things in the devicetree, so it is not clear to me what we > should > >> >> > >>>> actually > >> >> > >>>> write. > >> >> > >>>> > >> >> > >>>> The 'Devicetree Control in U-Boot' docs were recently merged > and these > >> >> > >>>> provide some base info, for now. > >> >> > >>>> > >> >> > >>>> Changes in v6: > >> >> > >>>> - Fix description of OF_BOARD so it refers just to the > current state > >> >> > >>>> - Explain that the 'two devicetrees' refers to two *control* > devicetrees > >> >> > >>>> > >> >> > >>>> Changes in v5: > >> >> > >>>> - Bring into the OF_BOARD series > >> >> > >>>> - Rebase to master and drop mention of OF_PRIOR_STAGE, since > removed > >> >> > >>>> - Refer to the 'control' DTB in the first paragraph > >> >> > >>>> - Use QEMU instead of qemu > >> >> > >>>> > >> >> > >>>> Changes in v3: > >> >> > >>>> - Clarify the 'bug' refered to at the top > >> >> > >>>> - Reword 'This means that there' paragraph to explain > U-Boot-specific > >> >> > >>>> things > >> >> > >>>> - Move to doc/develop/devicetree now that OF_CONTROL is in > the docs > >> >> > >>>> > >> >> > >>>> Changes in v2: > >> >> > >>>> - Fix typos per Sean (thank you!) and a few others > >> >> > >>>> - Add a 'Use of U-Boot /config node' section > >> >> > >>>> - Drop mention of dm-verity since that actually uses the > kernel cmdline > >> >> > >>>> - Explain that OF_BOARD will still work after these changes > (in > >> >> > >>>> 'Once this bug is f
Re: [PATCH v7 14/31] arm: highbank: Add devicetree files
Hi On Tue, 7 Dec 2021 at 18:14, Andre Przywara wrote: > On Tue, 7 Dec 2021 09:21:40 -0700 > Simon Glass wrote: > > Hi Simon, > > > Hi Tom, > > > > On Tue, 7 Dec 2021 at 09:14, Tom Rini wrote: > > > > > > On Tue, Dec 07, 2021 at 09:09:54AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Tue, 7 Dec 2021 at 09:07, Tom Rini wrote: > > > > > > > > > > On Tue, Dec 07, 2021 at 09:02:23AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Tue, 7 Dec 2021 at 08:39, Tom Rini > wrote: > > > > > > > > > > > > > > On Tue, Dec 07, 2021 at 08:33:49AM -0700, Simon Glass wrote: > > > > > > > > Hi Andre, > > > > > > > > > > > > > > > > On Tue, 7 Dec 2021 at 08:25, Tom Rini > wrote: > > > > > > > > > > > > > > > > > > On Tue, Dec 07, 2021 at 12:59:48AM +, Andre Przywara > wrote: > > > > > > > > > > On Mon, 6 Dec 2021 17:11:52 -0700 > > > > > > > > > > Simon Glass wrote: > > > > > > > > > > > > > > > > > > > > > Sync these files, obtained from Linux v5.15. > > > > > > > > > > > > > > > > > > > > Sorry, but this would be wrong. > > > > > > > > > > How do you know which board it is? Highbank or Midway? > We use the > > > > > > > > > > same binary for both, and decide either by the DT nodes > we find in DRAM > > > > > > > > > > or by some autodetection (Cortex-A9 vs. Cortex-A15) if > there are > > > > > > > > > > differences. The memory size would possibly be wrong > (it's a DIMM slot). > > > > > > > > > > If you need *some* DT for build reasons, whatever, but > at least go with > > > > > > > > > > the empty stub. > > > > > > > > > > > > > > > > > > > > And I still don't get this whole development argument: > Why would > > > > > > > > > > anyone need some random or partial DT sample in the > U-Boot tree to do > > > > > > > > > > development? > > > > > > > > > > If people develop a driver, the document to code against > is the > > > > > > > > > > *binding* documentation, which describes what to expect > from the DT > > > > > > > > > > nodes. Then you *test* it against an actual tree, but on > the actual > > > > > > > > > > hardware, in which case you get the actual DTB, from the > board. > > > > > > > > > > If a developer needs to take a sneak peek into an actual > DTB, > > > > > > > > > > there are so many simple ways to do that: QEMU's > dumpdtb, RPi's SD > > > > > > > > > > card content, U-Boot's "fdt addr $fdtcontroladdr; fdt > print", the > > > > > > > > > > kernel's /sys/firmware/devicetree/base, ... When you > port U-Boot to a > > > > > > > > > > board, getting hands on the actual DT is probably the > least of your > > > > > > > > > > problems. > > > > > > > > > > > > > > > > > > > > So why would we need some mostly wrong DTs in the U-Boot > tree? > > > > > > > > > > It seems to suggest that you can hack the DT to make > things work, but > > > > > > > > > > this sounds bonkers, as the real DTB comes from > somewhere else (SPI > > > > > > > > > > flash, SD card, generated based on command line), and > patching U-Boot's > > > > > > > > > > copy to make things work is just wishful thinking. > > > > > > > > > > > > > > > > > > > > I can see the hacker's desire to play around with the > DTB from time > > > > > > > > > > to time (What happens if the GPIO is wrong? Can we deal > with two > > > > > > > > > > instances of the same device?), but for those > experiments there are > > > > > > > > > > plenty of ways to achieve this - and be it temporarily > replacing the > > > > > > > > > > empty DT stub. I just feel that bending the (board's) DT > design ideas > > > > > > > > > > for a hacker's pleasure is not justified. > > > > > > > > > > > > > > > > Andre, if you'd like to attend the U-Boot contributor call > in an hour, > > > > > > > > please do. > > > > > > > > > > > > > > > > https://bit.ly/3bFvwA1: > > > > > > > > > > > > > > > > > > > > > > > > > > This, largely, is why I still don't understand or agree > with the > > > > > > > > > direction this series is taking platforms that currently > use > > > > > > > > > CONFIG_OF_BOARD=y today. > > > > > > > > > > > > > > > > I am not sure what else to do at this point. For real > boards, there > > > > > > > > has to be some base devicetree somewhere that is put into the > > > > > > > > firmware. > > > > > > > > > > > > > > Yes, there is. It's in the firmware on the hardware. That's > where it > > > > > > > lives. > > > > > > > > > > > > > > > Just because it changes at runtime does not change that > > > > > > > > fact. So we can inject any DT into the firmware and the same > > > > > > > > transformations should happen. We just need to have the same > one as > > > > > > > > everyone else uses. > > > > > > > > > > > > > > I think you're missing the point here still. The DT lives IN > the > > > > > > > firmware. In that an official dts for that firmware exists > somewhere, > > > > > > > I gather it's not public, because it doesn't have to be. > > > > > > > > > > > > That was my question to François a while back and I gathered > from
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
Hi Simon Le sam. 4 déc. 2021 à 18:42, Simon Glass a écrit : > Hi François, > > On Sat, 4 Dec 2021 at 04:06, François Ozog > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit : > >> > >> Hi Heinrich, > >> > >> On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt > wrote: > >> > > >> > On 12/3/21 9:13 PM, Simon Glass wrote: > >> > > Hi Heinrich, > >> > > > >> > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt < > xypron.g...@gmx.de> wrote: > >> > >> > >> > >> On 12/3/21 13:34, Heinrich Schuchardt wrote: > >> > >>> On 12/2/21 16:58, Simon Glass wrote: > >> > >>>> At present some of the ideas and techniques behind devicetree in > U-Boot > >> > >>>> are assumed, implied or unsaid. Add some documentation to cover > how > >> > >>>> devicetree is build, how it can be modified and the rules about > using > >> > >>>> the various CONFIG_OF_... options. > >> > >>>> > >> > >>>> Signed-off-by: Simon Glass > >> > >>>> Reviewed-by: Marcel Ziswiler > >> > >>>> --- > >> > >>>> This patch attracted quite a bit of discussion here: > >> > >>>> > >> > >>>> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> > >>>> > >> > >>>> > >> > >>>> I have not included the text suggested by François. While I > agree that > >> > >>>> it would be useful to have an introduction in this space, I do > not agree > >> > >>>> that we should have two devicetrees or that U-Boot should not > have its > >> > >>>> own > >> > >>>> things in the devicetree, so it is not clear to me what we should > >> > >>>> actually > >> > >>>> write. > >> > >>>> > >> > >>>> The 'Devicetree Control in U-Boot' docs were recently merged and > these > >> > >>>> provide some base info, for now. > >> > >>>> > >> > >>>> Changes in v6: > >> > >>>> - Fix description of OF_BOARD so it refers just to the current > state > >> > >>>> - Explain that the 'two devicetrees' refers to two *control* > devicetrees > >> > >>>> > >> > >>>> Changes in v5: > >> > >>>> - Bring into the OF_BOARD series > >> > >>>> - Rebase to master and drop mention of OF_PRIOR_STAGE, since > removed > >> > >>>> - Refer to the 'control' DTB in the first paragraph > >> > >>>> - Use QEMU instead of qemu > >> > >>>> > >> > >>>> Changes in v3: > >> > >>>> - Clarify the 'bug' refered to at the top > >> > >>>> - Reword 'This means that there' paragraph to explain > U-Boot-specific > >> > >>>> things > >> > >>>> - Move to doc/develop/devicetree now that OF_CONTROL is in the > docs > >> > >>>> > >> > >>>> Changes in v2: > >> > >>>> - Fix typos per Sean (thank you!) and a few others > >> > >>>> - Add a 'Use of U-Boot /config node' section > >> > >>>> - Drop mention of dm-verity since that actually uses the kernel > cmdline > >> > >>>> - Explain that OF_BOARD will still work after these changes (in > >> > >>>> 'Once this bug is fixed...' paragraph) > >> > >>>> - Expand a bit on the reason why the 'Current situation' is bad > >> > >>>> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> > >>>> in 'To be clear, while U-Boot...' > >> > >>>> - Expand on why we should have rules for other projects in > >> > >>>> 'Devicetree in another project' > >> > >>>> - Add a comment as to why devicetree in U-Boot is not 'bad > design' > >> > >>>> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in > U-Boot' > >> > >>>> - Rewrite 'Devicetree generated on-the-fly in a
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le sam. 4 déc. 2021 à 18:35, Simon Glass a écrit : > Hi François, > > On Sat, 4 Dec 2021 at 09:55, François Ozog > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : > >> > >> Hi Tom, > >> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > >> > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > >> > > >> > [huge snip] > >> > > > There's things that need to be cleaned up because we have some > small > >> > > > number of platforms that went off and did their own thing. But > largely > >> > > > yes, things make sense to me. We have: > >> > > > - We embedded the device tree that will configure U-Boot, because > there > >> > > > is no way for the hardware to have provided us one. > >> > > > - We do not embed the device tree that will configure U-Boot, > because > >> > > > there is already one present in memory for us to use. > >> > > > > >> > > > Then we have the developer option of: > >> > > > - We embedded the device tree that will configure U-Boot, because > we're > >> > > > developing something. > >> > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > >> > > >> > But it's not possible. That's the problem we keep going around and > >> > around about. People keep raising real life examples where you cannot > >> > make a run time choice between "device tree we're passed at run time" > >> > and "device tree we're compiled with". > >> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > >> even added a test with it. What am I missing? > >> > >> > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > >> > to override the run time device tree with our own, because it's a > >> > developer developing things or it's a user / production case where we > >> > must use the provided tree. NOT doing that is what leads to madness > >> > like we see for example on Pi where if we don't use the passed tree we > >> > still need to copy X/Y/Z out of it. > >> > >> Aren't you talking about the distro DT there, rather than the the one > >> on the boot disk? That is my reading of that patch. If we need to do > >> that sort of thing, it doesn't matter where the the cointrol DT comes > >> from. You are still going to have to do that sort of thing. > >> > >> It is not ALWAYS the case. I've shown you how easy it is to disable > >> OF_BOARD and still boot / iterate. > >> > >> > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > >> > > > > provide a way to do that? But what is driving that desire? > >> > > > > >> > > > I'm looking for ways to convince you that we do not need to > include a > >> > > > device tree in the binary. There's a growing set of devices > where the > >> > > > device tree exists with the device. If it's missing, that's a > huge > >> > > > fatal error we can't do all that much about. If we need to do > something > >> > > > to that device tree for U-Boot, yes, fine, we should make it > straight > >> > > > forward for the developer to do that. But that's not the common > case! > >> > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > a > >> > > devicetree in u-boot.bin, if that would resolve this? > >> > > > >> > > I just want to make sure that we always build the devicetrees and > that > >> > > it is easy for a knowledgeable dev to switch over to use them, > without > >> > > spelunking through dozens of other projects to discover the secret > DT > >> > > that no one will tell us about. > >> > > >> > Should we demand better documentation for boards? Yes. But it's > still > >> > a valid case to have zero device trees for a given platform in-tree. > >> > Xen is an example of this. QEMU is an example of this. Platforms > need > >> > to work without adding special tweaks for us. Maybe that means some > >> > features can't be tested in QEMU-as-
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le sam. 4 déc. 2021 à 16:21, Simon Glass a écrit : > Hi Tom, > > On Sat, 4 Dec 2021 at 06:52, Tom Rini wrote: > > > > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > > > > [huge snip] > > > > There's things that need to be cleaned up because we have some small > > > > number of platforms that went off and did their own thing. But > largely > > > > yes, things make sense to me. We have: > > > > - We embedded the device tree that will configure U-Boot, because > there > > > > is no way for the hardware to have provided us one. > > > > - We do not embed the device tree that will configure U-Boot, because > > > > there is already one present in memory for us to use. > > > > > > > > Then we have the developer option of: > > > > - We embedded the device tree that will configure U-Boot, because > we're > > > > developing something. > > > > > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > > > > But it's not possible. That's the problem we keep going around and > > around about. People keep raising real life examples where you cannot > > make a run time choice between "device tree we're passed at run time" > > and "device tree we're compiled with". > > I haven't seen one. The most extreme case is QEMU and it works fine. I > even added a test with it. What am I missing? > > > > > And it's not helpful. It is ALWAYS the case that we know that we want > > to override the run time device tree with our own, because it's a > > developer developing things or it's a user / production case where we > > must use the provided tree. NOT doing that is what leads to madness > > like we see for example on Pi where if we don't use the passed tree we > > still need to copy X/Y/Z out of it. > > Aren't you talking about the distro DT there, rather than the the one > on the boot disk? That is my reading of that patch. If we need to do > that sort of thing, it doesn't matter where the the cointrol DT comes > from. You are still going to have to do that sort of thing. > > It is not ALWAYS the case. I've shown you how easy it is to disable > OF_BOARD and still boot / iterate. > > > > > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > > > > > provide a way to do that? But what is driving that desire? > > > > > > > > I'm looking for ways to convince you that we do not need to include a > > > > device tree in the binary. There's a growing set of devices where > the > > > > device tree exists with the device. If it's missing, that's a huge > > > > fatal error we can't do all that much about. If we need to do > something > > > > to that device tree for U-Boot, yes, fine, we should make it straight > > > > forward for the developer to do that. But that's not the common > case! > > > > > > Well we could add another Kconfig which tells U-Boot not to include a > > > devicetree in u-boot.bin, if that would resolve this? > > > > > > I just want to make sure that we always build the devicetrees and that > > > it is easy for a knowledgeable dev to switch over to use them, without > > > spelunking through dozens of other projects to discover the secret DT > > > that no one will tell us about. > > > > Should we demand better documentation for boards? Yes. But it's still > > a valid case to have zero device trees for a given platform in-tree. > > Xen is an example of this. QEMU is an example of this. Platforms need > > to work without adding special tweaks for us. Maybe that means some > > features can't be tested in QEMU-as-virtual-platform and only in > > QEMU-faithfully-emulating-specific-physical-platforms. > > You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > case, I think. How about we create a special Kconfig for that case? We > need to make some progress here. > > > > > > > I guess another part of the problem is that historically almost all > > > > platforms were in the first case I list above, no run time provided > > > > device tree, so we took the kernel one and added our bindings to it. > > > > Now we're being bit by the growing number of platforms that are the > > > > second case, and how do we get our properties in there, and which > ones > > > > even make sense to do that for. > > > > > > I think upstreaming the bindings is the solution there. I've made a > > > start, but we need to make progress with this series and all the other > > > things in flight. I think a lot of people want U-Boot to not have a > > > devicetree source files in it for ARMv8 platforms. I am strongly > > > opposed to that. I've laid out my reasons very clearly in the past. I > > > think this is a good summary: > > > > > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > > > > Yes, there are some ARMv8 platforms we will have to have the source > > files to, in tree, because they won't come to us at run time. But > > others we won't for practical reasons, namely that we can't statically > > provide something that
Re: [PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)
Hi Simon and Sandrine Le jeu. 2 déc. 2021 à 08:10, Sandrine Bailleux a écrit : > Hi Simon, > > On 12/1/21 5:51 PM, Simon Glass wrote: > > Hi Sandrine, > > > > On Wed, 1 Dec 2021 at 03:32, Sandrine Bailleux > > wrote: > >> > >> Hi everyone, > >> > >> I am Sandrine Bailleux, from the Trusted Firmware-A project. Ilias > >> Apalodimas CC'ed me on this thread. > >> > >> First of all, thanks for involving the TF-A developers in this thread > >> and my apologies for the delay in responding. > > > > Thank you for your response. > > > >> > >> On 11/25/21 6:01 PM, François Ozog wrote: > >>> Hi Simon, > >>> > >>> On Thu, 25 Nov 2021 at 17:49, Simon Glass >>> <mailto:s...@chromium.org>> wrote: > >>> > >>> Hi François, > >>> > >>> On Thu, 25 Nov 2021 at 08:11, François Ozog > >>> mailto:francois.o...@linaro.org>> > wrote: > >>> > > >>> > Hi Simon, > >>> > > >>> > > >>> > > >>> > > >>> > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas > >>> mailto:ilias.apalodi...@linaro.org>> > >>> wrote: > >>> >> > >>> >> +cc Sandrine > >>> >> > >>> >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > >>> >> >>> <mailto:ilias.apalodi...@linaro.org>> wrote: > >>> >> > > >>> >> > Hi Simon, > >>> >> > > >>> >> > > >>> >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass >>> <mailto:s...@chromium.org>> wrote: > >>> >> > > > >>> >> > > > >>> >> > > This series adds support for the FIP format as used by ARM > >>> Trusted > >>> >> > > Firmware (in particular TF-A). > >>> >> > > > >>> > > >>> > I will use a question you use often "what problem are you trying > >>> to solve?". If FIP format is used it means that TF-A/BL2 is going > to > >>> parse it and verify the hashes/signatures according to TF-A scheme. > >>> > > >>> > The packager will embed in a FIP components like Secure Monitor, > >>> Secure hypervisor, Secure partitions code and manifests. > >>> > > >>> > All in all, U-Boot will be representing a small percentage of the > >>> functionality offered by secure firmware as a whole and it feels > >>> odd to make another implementation that is more "accessory" rather > >>> than critical for the U-Boot community. It may be a good idea but I > >>> wish you could explain it. > >>> > >>> Here is a talk about Binman, its goals and how it works. > >>> > >>> https://www.youtube.com/watch?v=L84ujgUXBOQ > >>> > >>> Think of Binman as a separate tool that brings everything > together. It > >>> has grown out of U-Boot, largely because U-Boot is the main > firmware > >>> in most cases. Getting U-Boot to start up and boot successfully is > the > >>> goal of this packaging process. There are lots of instructions in > the > >>> tree and elsewhere about how to build an image comprising U-Boot > and > >>> various binary blobs. Binman aims to provide documentation for that > >>> process and an image description that can be used to build an image > >>> reliably. > >>> > >>> We are slowly converting these text instructions into an in-tree > image > >>> description. > >>> > >>> I believe that Binman can help bring order to the chaos that is > >>> otherwise only going to grow, with lots of shell scripts, manual > >>> instructions, obscure binary tools, etc. Binman brings everything > >>> together and makes it clear what is needing/missing to build an > image. > >>> > >>> > > >>> >> > > This allows images to be created containing a FIP, which > >>> itself contains > >>> >> > > various binaries. With this, image creat
Re: [PATCH v6 01/25] doc: Add documentation about devicetree usage
Hi Simon Le sam. 4 déc. 2021 à 02:02, Simon Glass a écrit : > Hi Heinrich, > > On Fri, 3 Dec 2021 at 13:28, Heinrich Schuchardt > wrote: > > > > On 12/3/21 9:13 PM, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Fri, 3 Dec 2021 at 06:09, Heinrich Schuchardt > wrote: > > >> > > >> On 12/3/21 13:34, Heinrich Schuchardt wrote: > > >>> On 12/2/21 16:58, Simon Glass wrote: > > At present some of the ideas and techniques behind devicetree in > U-Boot > > are assumed, implied or unsaid. Add some documentation to cover how > > devicetree is build, how it can be modified and the rules about > using > > the various CONFIG_OF_... options. > > > > Signed-off-by: Simon Glass > > Reviewed-by: Marcel Ziswiler > > --- > > This patch attracted quite a bit of discussion here: > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > > > > > > I have not included the text suggested by François. While I agree > that > > it would be useful to have an introduction in this space, I do not > agree > > that we should have two devicetrees or that U-Boot should not have > its > > own > > things in the devicetree, so it is not clear to me what we should > > actually > > write. > > > > The 'Devicetree Control in U-Boot' docs were recently merged and > these > > provide some base info, for now. > > > > Changes in v6: > > - Fix description of OF_BOARD so it refers just to the current state > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > Changes in v5: > > - Bring into the OF_BOARD series > > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > > - Refer to the 'control' DTB in the first paragraph > > - Use QEMU instead of qemu > > > > Changes in v3: > > - Clarify the 'bug' refered to at the top > > - Reword 'This means that there' paragraph to explain > U-Boot-specific > > things > > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > > > Changes in v2: > > - Fix typos per Sean (thank you!) and a few others > > - Add a 'Use of U-Boot /config node' section > > - Drop mention of dm-verity since that actually uses the kernel > cmdline > > - Explain that OF_BOARD will still work after these changes (in > > 'Once this bug is fixed...' paragraph) > > - Expand a bit on the reason why the 'Current situation' is bad > > - Clarify in a second place that Linux and U-Boot use the same > devicetree > > in 'To be clear, while U-Boot...' > > - Expand on why we should have rules for other projects in > > 'Devicetree in another project' > > - Add a comment as to why devicetree in U-Boot is not 'bad design' > > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in > U-Boot' > > - Rewrite 'Devicetree generated on-the-fly in another project' to > cover > > points raised on v1 > > - Add 'Why does U-Boot have its nodes and properties?' > > - Add 'Why not have two devicetrees?' > > > > doc/develop/devicetree/dt_update.rst | 555 > +++ > > doc/develop/devicetree/index.rst | 1 + > > 2 files changed, 556 insertions(+) > > create mode 100644 doc/develop/devicetree/dt_update.rst > > > > > [..] > > > > > + > > +- The other project may not provide a way to support U-Boot's > > requirements for > > + devicetree, such as the /config node. Note: On the U-Boot mailing > > linst, this > > >>> > > >>> Even if you remove these lines in 17/25 I would prefer not to > introduce > > >>> typos here: > > >>> > > >>> %s/linst/list/ > > >>> > > > > > > OK I can fix that. > > > > > > [..] > > > > > +Normally, supporting U-Boot's features is trivial, since the > > devicetree compiler > > +(dtc) can compile the source, including any U-Boot pieces. So the > > burden is > > +extremely low. > > + > > +In this case, the devicetree in the other project must track > U-Boot's > > use of > > +device tree, so that it remains compatible. See `Devicetree in > > another project`_ > > +for reasons why. > > >>> > > >>> Did you ever ask the QEMU community what they think about your ideas? > > >>> What was the reply? > > >> > > >> Looking at the thread > > >> https://lore.kernel.org/all/20210926183410.256484-1-...@chromium.org/ > > >> the QEMU project said NAK. This matches the expectation that I > expressed > > >> repeatedly. > > >> > > >> Why don't you mention the QEMU reply in this patch series and adjust > > >> your design accordingly? > > > > > > The QEMU maintainer may react when he sees a problem. > > > > Why are you unwilling to admit the problem? QEMU will never support > > U-Boot specific stuff. > > > >
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Le ven. 3 déc. 2021 à 21:14, Simon Glass a écrit : > Hi François, > > On Fri, 3 Dec 2021 at 10:03, François Ozog > wrote: > > > > > > > > On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > >> > > Hi François, > >> > > > >> > > On Thu, 2 Dec 2021 at 11:44, François Ozog < > francois.o...@linaro.org> wrote: > >> > > > > >> > > > Hi Simon > >> > > > > >> > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass > wrote: > >> > > >> > >> > > >> Hi François, > >> > > >> > >> > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog < > francois.o...@linaro.org> wrote: > >> > > >> > > >> > > >> > Hi Simon > >> > > >> > > >> > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass > wrote: > >> > > >> >> > >> > > >> >> Hi Tom, > >> > > >> >> > >> > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini > wrote: > >> > > >> >> > > >> > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr > Andrushchenko wrote: > >> > > >> >> > > Hi, Simon! > >> > > >> >> > > > >> > > >> >> > > Sorry for being late to the party > >> > > >> >> > > > >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > >> >> > > > Add an empty file to prevent build errors when building > with > >> > > >> >> > > > CONFIG_OF_SEPARATE enabled. > >> > > >> >> > > > > >> > > >> >> > > > The build instructions in U-Boot do not provide enough > detail to build a > >> > > >> >> > > > useful devicetree, unfortunately. > >> > > >> >> > > Xen guest doesn't use any built-in device trees as the > guest's device tree is provided > >> > > >> >> > > by the Xen hypervisor itself and is generated at the > virtual machine creation time: it is > >> > > >> >> > > populated with memory size, number of CPUs etc. based on > [1]. > >> > > >> >> > > So, even if we provide some device tree here it must not > be used by U-boot at > >> > > >> >> > > the end of the day. Thus, it might be a reasonable > solution to provide an empty device > >> > > >> >> > > tree as you do, but put a comment that it is not used. > >> > > >> >> > > >> > > >> >> > So another example of why this series is taking things in > the wrong > >> > > >> >> > direction. > >> > > >> >> > >> > > >> >> Why? > >> > > >> > > >> > > >> > I only had that comment in mind: "there is none so deaf as he > who will not hear." > >> > > >> > >> > > >> Hey, stop the pile-on. It's not useful. > >> > > >> > >> > > >> I've guided U-Boot's use of devicetree for 10 years > successfully. The > >> > > >> current state is a mess and I just to straighten it out. > >> > > >> > >> > > > I admire your talent and knowledge. > >> > > > I know you are 99,99% of the time correct and spot on for your > comments in many meetings we were attending. > >> > > > When you questioned a number of points I made, I first tried to > understand what I got wrong because you said it. > >> > > > And you were right ;-) > >> > > > For this topic, I made every effort to come to your position, but > definitively can't. > >> > > > >> > > Thank you. I think this will come together in a few years when > >> > > devicetree is sorted out in U-Boot and Binman is more widely used. > >> > > > >> > > For this series, if and when it is applied, I predict: > >> > > - it will
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Fri, 3 Dec 2021 at 17:04, Simon Glass wrote: > Hi Tom, > > On Fri, 3 Dec 2021 at 05:14, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 12:23:10PM -0700, Simon Glass wrote: > > > Hi François, > > > > > > On Thu, 2 Dec 2021 at 11:44, François Ozog > wrote: > > > > > > > > Hi Simon > > > > > > > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Thu, 2 Dec 2021 at 11:17, François Ozog < > francois.o...@linaro.org> wrote: > > > >> > > > > >> > Hi Simon > > > >> > > > > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass > wrote: > > > >> >> > > > >> >> Hi Tom, > > > >> >> > > > >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini > wrote: > > > >> >> > > > > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr > Andrushchenko wrote: > > > >> >> > > Hi, Simon! > > > >> >> > > > > > >> >> > > Sorry for being late to the party > > > >> >> > > > > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: > > > >> >> > > > Add an empty file to prevent build errors when building > with > > > >> >> > > > CONFIG_OF_SEPARATE enabled. > > > >> >> > > > > > > >> >> > > > The build instructions in U-Boot do not provide enough > detail to build a > > > >> >> > > > useful devicetree, unfortunately. > > > >> >> > > Xen guest doesn't use any built-in device trees as the > guest's device tree is provided > > > >> >> > > by the Xen hypervisor itself and is generated at the virtual > machine creation time: it is > > > >> >> > > populated with memory size, number of CPUs etc. based on [1]. > > > >> >> > > So, even if we provide some device tree here it must not be > used by U-boot at > > > >> >> > > the end of the day. Thus, it might be a reasonable solution > to provide an empty device > > > >> >> > > tree as you do, but put a comment that it is not used. > > > >> >> > > > > >> >> > So another example of why this series is taking things in the > wrong > > > >> >> > direction. > > > >> >> > > > >> >> Why? > > > >> > > > > >> > I only had that comment in mind: "there is none so deaf as he who > will not hear." > > > >> > > > >> Hey, stop the pile-on. It's not useful. > > > >> > > > >> I've guided U-Boot's use of devicetree for 10 years successfully. > The > > > >> current state is a mess and I just to straighten it out. > > > >> > > > > I admire your talent and knowledge. > > > > I know you are 99,99% of the time correct and spot on for your > comments in many meetings we were attending. > > > > When you questioned a number of points I made, I first tried to > understand what I got wrong because you said it. > > > > And you were right ;-) > > > > For this topic, I made every effort to come to your position, but > definitively can't. > > > > > > Thank you. I think this will come together in a few years when > > > devicetree is sorted out in U-Boot and Binman is more widely used. > > > > > > For this series, if and when it is applied, I predict: > > > - it will not cause any confusion > > > - it will aid development > > > - it will help with discoverability, pressuring people to explain how > > > to build for their systems > > > - it will be a good basis for future work (we have a long list) > > > - everyone will wonder what the fuss was about > > > > > > Here is the commit that introduced OF_PRIOR_STAGE. It attracted no > > > such push-back. > > > > > > commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 > > > Author: Thomas Fitzsimmons > > > Date: Fri Jun 8 17:59:45 2018 -0400 > > > > > > board: arm: Add support for Broadcom BCM7445 > > > > > > Add support for loading U-Boot on the Broadcom 7445 SoC. This port > > > as
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon,Tom Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > a écrit : > > > > > > > > > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is > built and > > > > > > > > > appended to U-Boot > > > > > > > > >- OF_EMBED - for development purposes, the devicetree > is embedded in > > > > > > > > > the ELF file (also used for EFI) > > > > > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > > > > > > > > > The last one is currently set up so that no devicetree is > needed at all > > > > > > > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > > > > > > don't even provide instructions on how to boot on the > board. > > > > > > > > > > > > > > > > > > The problems with this approach are documented in another > patch in this > > > > > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > > > > > > > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > > > > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > > > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > > > > > caller may have a better idea about the hardware available > in the machine. > > > > > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > > > > > > > > > This series makes this change, adding various missing > devicetree files > > > > > > > > > (and placeholders) to make the build work. > > > > > > > > > > > > > > > > > > Note: If board maintainers are able to add their own patch > to add the > > > > > > > > > files, some patches in this series can be dropped. > > > > > > > > > > > > > > > > > > It also provides a few qemu clean-ups discovered along the > way. The > > > > > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > > > > > > > > > Changes in v6: > > > > > > > > > - Fix description of OF_BOARD so it refers just to the > current state > > > > > > > > > - Explain that the 'two devicetrees' refers to two > *control* devicetrees > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > - Expand the commit message based on comments > > > > > > > > > > > > > > > > You haven’t addressed a
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: > Hi François, > > On Thu, 2 Dec 2021 at 11:17, François Ozog > wrote: > > > > Hi Simon > > > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > >> > >> Hi Tom, > >> > >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > >> > > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko > wrote: > >> > > Hi, Simon! > >> > > > >> > > Sorry for being late to the party > >> > > > >> > > On 02.12.21 17:59, Simon Glass wrote: > >> > > > Add an empty file to prevent build errors when building with > >> > > > CONFIG_OF_SEPARATE enabled. > >> > > > > >> > > > The build instructions in U-Boot do not provide enough detail to > build a > >> > > > useful devicetree, unfortunately. > >> > > Xen guest doesn't use any built-in device trees as the guest's > device tree is provided > >> > > by the Xen hypervisor itself and is generated at the virtual > machine creation time: it is > >> > > populated with memory size, number of CPUs etc. based on [1]. > >> > > So, even if we provide some device tree here it must not be used by > U-boot at > >> > > the end of the day. Thus, it might be a reasonable solution to > provide an empty device > >> > > tree as you do, but put a comment that it is not used. > >> > > >> > So another example of why this series is taking things in the wrong > >> > direction. > >> > >> Why? > > > > I only had that comment in mind: "there is none so deaf as he who will > not hear." > > Hey, stop the pile-on. It's not useful. > > I've guided U-Boot's use of devicetree for 10 years successfully. The > current state is a mess and I just to straighten it out. > > I admire your talent and knowledge. I know you are 99,99% of the time correct and spot on for your comments in many meetings we were attending. When you questioned a number of points I made, I first tried to understand what I got wrong because you said it. And you were right ;-) For this topic, I made every effort to come to your position, but definitively can't. >> > >> At least we might figure out where to get the DT and how to run > >> Xen with U-Boot. I don't see any down-side to having a basic DT in the > >> tree along with instructions on how to run Xen. > > > > If an EMPTY device is what is required to pass current build > constraints, so be it, and let's correct that in a later patch. And EMPTY > is not basic. > > The problem here is a difference in philosophy around device tree. > > Indeed! > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit > : > > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE > so > > > > > there are only three ways to obtain a devicetree: > > > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built > and > > > > > appended to U-Boot > > > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > > > > > the ELF file (also used for EFI) > > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > > > The last one is currently set up so that no devicetree is needed > at all > > > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > > > > > don't even provide instructions on how to boot on the board. > > > > > > > > > > The problems with this approach are documented in another patch in > this > > > > > series: "doc: Add documentation about devicetree usage" > > > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > > caller may have a better idea about the hardware available in the > machine. > > > > > This is the case with a few QEMU boards, for example. > > > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > > (and placeholders) to make the build work. > > > > > > > > > > Note: If board maintainers are able to add their own patch to add > the > > > > > files, some patches in this series can be dropped. > > > > > > > > > > It also provides a few qemu clean-ups discovered along the way. The > > > > > qemu-riscv64_spl problem is fixed. > > > > > > > > > > [1] > > > > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > > > > > Changes in v6: > > > > > - Fix description of OF_BOARD so it refers just to the current > state > > > > > - Explain that the 'two devicetrees' refers to two *control* > devicetrees > > > > > - Expand the commit message based on comments > > > > > - Expand the commit message based on comments > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'.
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Hi Mark,
On Thu, 2 Dec 2021 at 18:34, Mark Kettenis wrote:
> > From: Simon Glass
> > Date: Thu, 2 Dec 2021 08:59:01 -0700
> >
> > Add this file, obtained from the Raspbian boot disk, so there is a
> > reference devicetree in the U-Boot tree. The same one is used for
> > 32- and 64-bit variants.
> >
> > Note that U-Boot does not normally need this at runtime, since
> > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> > devicetree at runtime.
> >
> > Signed-off-by: Simon Glass
> > ---
> >
> > (no changes since v1)
> >
> > arch/arm/dts/Makefile|3 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> > configs/rpi_4_32b_defconfig |1 +
> > configs/rpi_4_defconfig |1 +
> > configs/rpi_arm64_defconfig |1 +
> > 5 files changed, 1963 insertions(+), 1 deletion(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> >
> > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> > index 2d92b2f940d..9cddab37207 100644
> > --- a/arch/arm/dts/Makefile
> > +++ b/arch/arm/dts/Makefile
> > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> > bcm2837-rpi-3-a-plus.dtb \
> > bcm2837-rpi-3-b.dtb \
> > bcm2837-rpi-3-b-plus.dtb \
> > - bcm2837-rpi-cm3-io3.dtb
> > + bcm2837-rpi-cm3-io3.dtb \
> > + bcm2711-rpi-4-b.dtb
> >
> > dtb-$(CONFIG_ARCH_BCM63158) += \
> > bcm963158.dtb
> > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > new file mode 100644
> > index 000..425e9fb91c4
> > --- /dev/null
> > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> > @@ -0,0 +1,1958 @@
> > +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> > +/*
> > + * Sample device tree for rpi_4
> > +
> > + * Copyright 2021 Google LLC
> > + */
>
> This is of course an utter lie. This wasn't written from scratch by a
> Google employee.
>
> The original copyright and license for the dtb files you
> "disassembled" applies. You don't specify exactly where you obtained
> the file from, but it probably came from here:
>
> https://github.com/raspberrypi/firmware
>
> And the README.md for that repo states that:
>
> "The dtbs, overlays and associated README are built from Linux
>kernel sources, released under the GPL (see boot/COPYING.linux)"
>
> That's quite a point! thanks for bringing this additional "legal"
standpoint.
> They're probably talking about their own fork of the Linux kernel
> sources here as there are still differences between their device trees
> and the the device trees in the official Linux tree. But if you
> insist on having a device tree in the U-Boot tree, that's where you
> should look.
> > +
> > +/dts-v1/;
> > +
> > +/memreserve/ 0x 0x1000;
> > +/ {
> > + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> > + model = "Raspberry Pi 4 Model B";
> > + interrupt-parent = <0x01>;
> > + #address-cells = <0x02>;
> > + #size-cells = <0x01>;
> > +
> > + aliases {
> > + serial0 = "/soc/serial@7e215040";
> > + serial1 = "/soc/serial@7e201000";
> > + audio = "/soc/audio";
> > + aux = "/soc/aux@7e215000";
> > + sound = "/soc/sound";
> > + soc = "/soc";
> > + dma = "/soc/dma@7e007000";
> > + watchdog = "/soc/watchdog@7e10";
> > + random = "/soc/rng@7e104000";
> > + mailbox = "/soc/mailbox@7e00b880";
> > + gpio = "/soc/gpio@7e20";
> > + uart0 = "/soc/serial@7e201000";
> > + sdhost = "/soc/mmc@7e202000";
> > + mmc0 = "/soc/emmc2@7e34";
> > + i2s = "/soc/i2s@7e203000";
> > + spi0 = "/soc/spi@7e204000";
> > + i2c0 = "/soc/i2c@7e205000";
> > + uart1 = "/soc/serial@7e215040";
> > + spi1 = "/soc/spi@7e215080";
> > + spi2 = "/soc/spi@7e2150c0";
> > + mmc = "/soc/mmc@7e30";
> > + mmc1 = "/soc/mmcnr@7e30";
> > + i2c1 = "/soc/i2c@7e804000";
> > + i2c2 = "/soc/i2c@7e805000";
> > + usb = "/soc/usb@7e98";
> > + leds = "/leds";
> > + fb = "/soc/fb";
> > + thermal = "/soc/thermal@7d5d2200";
> > + axiperf = "/soc/axiperf";
> > + mmc2 = "/soc/mmc@7e202000";
> > + ethernet0 = "/scb/genet@7d58";
> > + };
> > +
> > + chosen {
> > + bootargs = "8250.nr_uarts=1 cma=64M";
> > + };
> > +
> > + thermal-zones {
> > +
> > + cpu-thermal {
> > + polling-delay-passive = <0x00>;
> > + polling-delay = <0x3e8>;
> > + thermal-sensors = <0x02>;
> > + coefficients = <0xfe19 0x641b8>;
> > + phandle = <0x2f>;
> > +
> > + cooling-maps {
> > + };
> > +
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to > build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide > an empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? I only had that comment in mind: "there is none so deaf as he who will not hear." > At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. > If an EMPTY device is what is required to pass current build constraints, so be it, and let's correct that in a later patch. And EMPTY is not basic. > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:40, Simon Glass a écrit : > Hi François, > > On Thu, 2 Dec 2021 at 09:34, François Ozog > wrote: > > > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >>- OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >>- OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >>- OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. The > >> qemu-riscv64_spl problem is fixed. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v6: > >> - Fix description of OF_BOARD so it refers just to the current state > >> - Explain that the 'two devicetrees' refers to two *control* devicetrees > >> - Expand the commit message based on comments > >> - Expand the commit message based on comments > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > not in favor of this new version either. > > Please see the change log. I have addressed everything except the > fundamental disagreement we have. > > > If you make a version without « fake DTs » as you name them, there are > good advances in the documentation and other areas that would be better in > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > would love there is a warning in capital letters at the top of the DTS fake > files that explains the intent of this fake DT, the possible outcomes of > not using the one provided by the platform and the right way of dealing > with DTs for the platform. > > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), Qemu is another one, and then you will have all SystemReady compliant boards. > where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! > > Anyway yes I can add a comment to all the files, but please try to ask > for everything at once as there is a cost to continually reworking > this series. I proposed this as a last resort if I was the only one with concerns. But sounds like I am not the only one strongly opinionated here. Another trick would be to use a “.dts.doc” extension so that it is not compiled unless someone is knowingly deciding to use the fake DT for debug purposes (the warning message is still valid). (This is an effort to advance on the good things of the patch) > > > Regards, > Simon > > >> > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that ther
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > >- OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot >- OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) >- OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. The > qemu-riscv64_spl problem is fixed. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > Changes in v6: > - Fix description of OF_BOARD so it refers just to the current state > - Explain that the 'two devicetrees' refers to two *control* devicetrees > - Expand the commit message based on comments > - Expand the commit message based on comments You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt:
Re: [PATCH 00/40] RFC: rpi: Enable ACPI booting on ARM with Raspberry Pi 4
Hi Le mer. 1 déc. 2021 à 18:16, Andy Shevchenko a écrit : > On Wed, Dec 1, 2021 at 6:56 PM Simon Glass wrote: > > > > At present in U-Boot ACPI tables are only generated for x86 devices. It > is > > possible to build them for ARM as well. That is the subject of this > > series. > > in the case of RPI4 what is needed is a translator from DT handed by Videocore. If you mean generated from an assumed configuration, that may not be good. Doing static ACPI based on assumptions as a first step is a dangerous path. > > > The goal is to allow a rpi4 boot into Linux on ARM using ACPI rather than > > devicetree. This is not due to any feeling that ACPI offers advantages to > > the boot flow, merely because it can be done. > > > > This goal is not yet achieved. Mostly all that is achieved is some > > refactoring of the ACPI code, but that is enough to get things at least > > building on ARM. The rpi-4 the tables are installed and the board boots > > to grub, where it is then unable to find the OS on the USB stick that is > > inserted. Further work is needed to complete things, but the ACPI changes > > can be applied as is. > > > > In terms of review, please ignore the RFC/WIP patches as they need to be > > reworked. I am sending this series in this state to avoid sitting on > > patches for too long and risking duplicate effort. > > > > The following tables are emitted with this series: > > > >- GTDT - Generic Timer Description Table > >- APIC - Multiple Advanced Programmable Interrupt Controller > > Description Table (some new records for ARM) > >- DSDT - Differentiated System Description Table > >- DBG2 - Debug Port Table 2 > >- FACP - Firmware ACPI Control Structure > >- CSRT - Core System Resource Table > >- PPTT - Processor Properties Topology Table > > > > Missing still are: > >- SSDR - Secondary System Description Table > > SSDT > > >- BGRT - Boot Graphics Resource Table > > And SPCR > > > > > Future work is needed to: > > - Finish the remaining two tables > > - Get things booting nicely on rpi4 > > - Find a nice way to select between ACPI and devicetree at runtime > > - Obtain the ACPI information from the devicetree instead of #defines > > - Use the U-Boot bcm headers instead of importing new ones > > - Drop the unused files > > - Add some documentation > > > > To test it, boot U-Boot on a rpi_4 with a suitable distribution. > > > > This series is available at u-boot-dm/acpi-working > > > > > > Simon Glass (40): > > Makefile: Allow LTO to be disabled for a build > > x86: Allow any arch to generate ACPI tables > > x86: Move the acpi table to generic global_data > > arm: Allow supporting ACPI-table generation > > x86: Tidy up use of CONFIG_ACPIGEN > > sandbox: Allow building with GENERATE_ACPI_TABLE > > efi: Correct call to write_acpi_tables() > > efi: Correct address handling with ACPI tables > > acpi: Use finer-grained control of ACPI-table generation > > acpi: Allow include files within the board directory > > acpi: Move acpi_fill_header() to the generic header > > acpi: Add a table start > > acpi: Add a linker list for ACPI tables > > x86: acpi: Split out context creation from base tables > > x86: Use the ACPI table writer > > x86: Move base tables to a writer function > > x86: Move FACS table to a writer function > > x86: Move DSDT table to a writer function > > x86: Move GNVS table to a writer function > > x86: Move FADT table to a writer function > > x86: Move FACP table into separate functions > > x86: Move SSDT table to a writer function > > x86: Move TPM2 table to a writer function > > x86: Move MADT table to a writer function > > x86: Move TCPA table to a writer function > > x86: Move CSRT table to a writer function > > x86: acpi: Update acpi_fill_csrt() to use acpi_ctx > > x86: Move device-specific ACPI tables to a writer function > > x86: Move acpi_get_rsdp_addr() ACPI tables to the writer > > acpi: Collect tables in the acpi_item list > > acpi: Tidy up the item list > > acpi: Tidy up the table list > > doc: Add usage information for the acpi command > > acpi: Add some tables needed by ARM devices > > acpi: Add myself as maintainer > > WIP: Add debugging for ACPI emission > > RFC: Allow passing ACPI tables to bootefi > > WIP: Add ASL files from tianocore > > WIP: Bring in some header files from tianocore > > RFC: rpi: Enable booting with ACPI tables > > > > MAINTAINERS | 6 + > > Makefile | 18 +- > > arch/Kconfig | 6 +- > > arch/arm/config.mk| 4 +- > > arch/arm/include/asm/acpi_table.h | 15 + > > arch/arm/include/asm/global_data.h| 2 +- > > .../mach-bcm283x/include/mach/acpi/bcm2711.h | 93 +++ > > .../mach-bcm283x/include/mach/acpi/bcm2836.h | 124 +++ > >
Re: [PATCH 04/40] arm: Allow supporting ACPI-table generation
Hi Le mer. 1 déc. 2021 à 18:11, Tom Rini a écrit : > On Wed, Dec 01, 2021 at 05:49:54PM +0100, Mark Kettenis wrote: > > > From: Simon Glass > > > Date: Wed, 1 Dec 2021 09:02:38 -0700 > > > > > > Some ARM boards are using ACPI now. It seems that U-Boot should support > > > this method. Add ARM to the list of archs which can generate ACPI > tables. > > > > Can you explain why you think U-Boot should care? > > > > Because I think promoting ACPI as a viable firmware interface for the > > type of boards supported by U-Boot would be a serious mistake... > > Given the large overlap of SoCs that support both SystemReady IR and > SystemReady ES, I asked Simon how hard it would be to pass ACPI tables, > instead of DTB. Are there going to be some challenges to be able to get > ES certified under U-Boot? Certainly. But I'm not convinced that > U-Boot is just a wrong-fit for the ES case when part of the whole point > of these certifications is that it doesn't matter what's implementing > it, it's a standard. > looks like an exciting endeavor ! If we factor in safety certification, there are probably more chances to achieve this with U-Boot that EDK2. That said, AML implementation in U-Boot, which may end up being necessary, need special care. > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)
Hi Simon, On Thu, 25 Nov 2021 at 17:49, Simon Glass wrote: > Hi François, > > On Thu, 25 Nov 2021 at 08:11, François Ozog > wrote: > > > > Hi Simon, > > > > > > > > > > On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas < > ilias.apalodi...@linaro.org> wrote: > >> > >> +cc Sandrine > >> > >> On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > >> wrote: > >> > > >> > Hi Simon, > >> > > >> > > >> > On Wed, 24 Nov 2021 at 06:09, Simon Glass wrote: > >> > > > >> > > > >> > > This series adds support for the FIP format as used by ARM Trusted > >> > > Firmware (in particular TF-A). > >> > > > > > > I will use a question you use often "what problem are you trying to > solve?". If FIP format is used it means that TF-A/BL2 is going to parse it > and verify the hashes/signatures according to TF-A scheme. > > > > The packager will embed in a FIP components like Secure Monitor, Secure > hypervisor, Secure partitions code and manifests. > > > > All in all, U-Boot will be representing a small percentage of the > functionality offered by secure firmware as a whole and it feels odd to > make another implementation that is more "accessory" rather than critical > for the U-Boot community. It may be a good idea but I wish you could > explain it. > > Here is a talk about Binman, its goals and how it works. > > https://www.youtube.com/watch?v=L84ujgUXBOQ > > Think of Binman as a separate tool that brings everything together. It > has grown out of U-Boot, largely because U-Boot is the main firmware > in most cases. Getting U-Boot to start up and boot successfully is the > goal of this packaging process. There are lots of instructions in the > tree and elsewhere about how to build an image comprising U-Boot and > various binary blobs. Binman aims to provide documentation for that > process and an image description that can be used to build an image > reliably. > > We are slowly converting these text instructions into an in-tree image > description. > > I believe that Binman can help bring order to the chaos that is > otherwise only going to grow, with lots of shell scripts, manual > instructions, obscure binary tools, etc. Binman brings everything > together and makes it clear what is needing/missing to build an image. > > > > >> > > This allows images to be created containing a FIP, which itself > contains > >> > > various binaries. With this, image creation can be handled from an > in-tree > >> > > image description instead of needing to perform a lot of manual > steps or > >> > > custom scripts to build the FIP. > >> > > > > > > That's not my experience of building a fip. Packaging even Linux as a > BL33 (instead of U-Boot) is very simple. > > But not automatic. With Binman you don't need to worry about the > packaging. It is done for you. You just need to find all the binary > blobs that are needed. This ability is quite important as firmware is > fragmenting and getting very complicated these days. > > Binman runs twice...once in the U-Boot tree to do a build and again > later to repackage, put in a final fdtmap, add signatures and any > final pieces needed. > > See this patch for an example of complicated build instructions with > Odroid-C2 (>10 binary blobs!) and how Binman can help (see the changes > in the .rst file): > > > https://patchwork.ozlabs.org/project/uboot/patch/20211124040954.699821-8-...@chromium.org/ > > That's indeed complicated! I can't comment whether this build process is "canonical" as per TF-A standards so I'll let TF-A community comment. Have you factored in the signature issues that Jan@Siemens has in the overall process? > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 0/2] binman: Add support for ATF Firmware Image Package (FIP)
Hi Simon, On Thu, 25 Nov 2021 at 15:47, Ilias Apalodimas wrote: > +cc Sandrine > > On Thu, 25 Nov 2021 at 11:42, Ilias Apalodimas > wrote: > > > > Hi Simon, > > > > > > On Wed, 24 Nov 2021 at 06:09, Simon Glass wrote: > > > > > > > > > This series adds support for the FIP format as used by ARM Trusted > > > Firmware (in particular TF-A). > > > > I will use a question you use often "what problem are you trying to solve?". If FIP format is used it means that TF-A/BL2 is going to parse it and verify the hashes/signatures according to TF-A scheme. The packager will embed in a FIP components like Secure Monitor, Secure hypervisor, Secure partitions code and manifests. All in all, U-Boot will be representing a small percentage of the functionality offered by secure firmware as a whole and it feels odd to make another implementation that is more "accessory" rather than critical for the U-Boot community. It may be a good idea but I wish you could explain it. > > This allows images to be created containing a FIP, which itself contains > > > various binaries. With this, image creation can be handled from an > in-tree > > > image description instead of needing to perform a lot of manual steps > or > > > custom scripts to build the FIP. > > > > That's not my experience of building a fip. Packaging even Linux as a BL33 (instead of U-Boot) is very simple. > > > > > > Simon Glass (2): > > > binman: Add a utility module for ATF FIP > > > binman: Add support for ATF FIP > > > > > > scripts/pylint.base | 9 +- > > > tools/binman/entries.rst | 154 ++ > > > tools/binman/etype/atf_fip.py| 273 ++ > > > tools/binman/fip_util.py | 653 +++ > > > tools/binman/fip_util_test.py| 405 ++ > > > tools/binman/ftest.py| 217 > > > tools/binman/main.py | 4 +- > > > tools/binman/test/203_fip.dts| 21 + > > > tools/binman/test/204_fip_other.dts | 22 + > > > tools/binman/test/205_fip_no_type.dts| 15 + > > > tools/binman/test/206_fip_uuid.dts | 22 + > > > tools/binman/test/207_fip_ls.dts | 25 + > > > tools/binman/test/208_fip_replace.dts| 33 ++ > > > tools/binman/test/209_fip_missing.dts| 19 + > > > tools/binman/test/210_fip_size.dts | 19 + > > > tools/binman/test/211_fip_bad_align.dts | 18 + > > > tools/binman/test/212_fip_collection.dts | 24 + > > > 17 files changed, 1929 insertions(+), 4 deletions(-) > > > create mode 100644 tools/binman/etype/atf_fip.py > > > create mode 100755 tools/binman/fip_util.py > > > create mode 100755 tools/binman/fip_util_test.py > > > create mode 100644 tools/binman/test/203_fip.dts > > > create mode 100644 tools/binman/test/204_fip_other.dts > > > create mode 100644 tools/binman/test/205_fip_no_type.dts > > > create mode 100644 tools/binman/test/206_fip_uuid.dts > > > create mode 100644 tools/binman/test/207_fip_ls.dts > > > create mode 100644 tools/binman/test/208_fip_replace.dts > > > create mode 100644 tools/binman/test/209_fip_missing.dts > > > create mode 100644 tools/binman/test/210_fip_size.dts > > > create mode 100644 tools/binman/test/211_fip_bad_align.dts > > > create mode 100644 tools/binman/test/212_fip_collection.dts > > > > > > -- > > > 2.34.0.rc2.393.gf8c9666880-goog > > > > > > > My python is mediocre at best. I'll try having a look, but CC'ing > > TF-A developers would be a good idea. > > > > Thanks > > /Ilias > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/16] tools: Add support for signing devicetree blobs
Hi Simon Le sam. 13 nov. 2021 à 14:57, Simon Glass a écrit : > Hi Heinrich, > > On Sat, 13 Nov 2021 at 04:57, Heinrich Schuchardt > wrote: > > > > > > > > On 11/13/21 04:30, Simon Glass wrote: > > > Hi Heinrich, > > > > > > On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt > wrote: > > >> > > >> > > >> > > >> On 11/12/21 20:49, François Ozog wrote: > > >>> Hi Simon > > >>> > > >>> Le ven. 12 nov. 2021 à 20:36, Simon Glass > >>> <mailto:s...@chromium.org>> a écrit : > > >>> > > >>> At present mkimage supports signing FITs, the standard U-Boot > image > > >>> type. > > >>> > > >>> Various people are opposed to using FIT since: > > >>> > > >>> just to be sure: I am not one of those. > > >>> > > >>> > > >>> a) it requires adding support for FIT into other bootloaders, > notably > > >>> UEFI > > >>> > > >>> whatever happens to FIT is entirely orthogonal to U-Boot UEFI > subsystem. > > >>> FIT can evolve, U-Boot UEFI does not have to change. > > >> > > >> We already can create signed FIT images containing a UEFI binary and a > > >> devcie-tree and launch the FIT image with the bootm command. > > >> > > >> Cf. > > >> CONFIG_BOOTM_EFI > > >> test/py/tests/test_efi_fit.py > > >> doc/usage/bootefi.rst > > >> > > >> Simon, what are you missing? > > > > > > Some people don't want to use FIT. > > > > The problem with FIT is that other firmware like EDK II does not support > it. > > > > Why do you expect those people to like your new tool better? > > I believe the EDK decision is not so much that it *does* not support > FIT, which is after all not a lot of code, but that it *should* not. > If I have that wrong, please let me know. > UEFI (EDK2 and now U-Boot) design choice is that it does not include *any* technologies for OS: UEFI launches an OS loader that know about those. A possible way to introduce a FIT is by adding a protocol that can register a vendor media file , assign a UUID to a FIT. Add support for this in the UEFI stub of the kernel. Another way would be a minimalistic UEFI app that will fetch the second parameter as a FIT. The FIT format parsing code is only in this minimalistic loader. U-Boot can play this role based on your efforts to have U-Boot as UEFI application. You could also promote FIT in the systemd-boot UeFi application. I believe this is a very good option BTW. > > The goal here is to support signing in an FDT without FIT. I believe > EDK supports FDT, at least. > > > > > > > > >> > > >>> > > >>> > > >>> b) it requires packaging a kernel in this standard U-Boot > format, > > >>> meaning > > >>> that distros must run 'mkimage' and deal with the kernel > and initrd > > >>> being inside a FIT > > >> > > >> U-Boot tools are contained in distros like Debian and Ubuntu. > > >> Package flash-kernel uses a script in /etc/initramfs/post-update.d/ > for > > >> a similar purpose. The same hook directory can be used to create a FIT > > >> image with a simple bash script. > > >> > > >> Why do we need a new tool for signing device-trees? > > >> > > >> The real problem to solve is the protection of the private key used > for > > >> signing any file containing an initrd. > > > > > > Well FIT already solves that one. Either FIT is not being used, in > > > which case this series is useful, or it is being used, in which case > > > the initrd problem is solved. > > > > The question was: > > > > How do you protect the private key used by Linux to sign the FIT image > > with the updated initrd generated by intramfs-tools? > > Well, if it is a FIT we can add a seperate signature at the time the > initramfs-tools runs. It does support multiple signatures. If that is > not suitable I am sure something else can be devised. What are the > constraints / requirements? > > Regards, > Simon > > > > > Best regards > > > > Heinrich > > > > > > > >> > > >>> > > >>> The kernel and initrd can be dealt with in other ways. But > without FIT, > &g
Re: [PATCH 00/16] tools: Add support for signing devicetree blobs
Hi Simon Le sam. 13 nov. 2021 à 14:57, Simon Glass a écrit : > Hi François, > On Sat, 13 Nov 2021 at 03:18, François Ozog > wrote: > > > > Hi Simon, > > > > Le sam. 13 nov. 2021 à 04:31, Simon Glass a écrit : > >> > >> Hi Heinrich, > >> > >> On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt > wrote: > >> > > >> > > >> > > >> > On 11/12/21 20:49, François Ozog wrote: > >> > > Hi Simon > >> > > > >> > > Le ven. 12 nov. 2021 à 20:36, Simon Glass >> > > <mailto:s...@chromium.org>> a écrit : > >> > > > >> > > At present mkimage supports signing FITs, the standard U-Boot > image > >> > > type. > >> > > > >> > > Various people are opposed to using FIT since: > >> > > > >> > > just to be sure: I am not one of those. > >> > > > >> > > > >> > > a) it requires adding support for FIT into other bootloaders, > notably > >> > > UEFI > >> > > > >> > > whatever happens to FIT is entirely orthogonal to U-Boot UEFI > subsystem. > >> > > FIT can evolve, U-Boot UEFI does not have to change. > >> > > >> > We already can create signed FIT images containing a UEFI binary and a > >> > devcie-tree and launch the FIT image with the bootm command. > >> > > >> > Cf. > >> > CONFIG_BOOTM_EFI > >> > test/py/tests/test_efi_fit.py > >> > doc/usage/bootefi.rst > >> > > >> > Simon, what are you missing? > >> > >> Some people don't want to use FIT. > >> > >> > > >> > > > >> > > > >> > > b) it requires packaging a kernel in this standard U-Boot > format, > >> > > meaning > >> > > that distros must run 'mkimage' and deal with the kernel > and initrd > >> > > being inside a FIT > >> > > >> > U-Boot tools are contained in distros like Debian and Ubuntu. > >> > Package flash-kernel uses a script in /etc/initramfs/post-update.d/ > for > >> > a similar purpose. The same hook directory can be used to create a FIT > >> > image with a simple bash script. > >> > > >> > Why do we need a new tool for signing device-trees? > >> > > >> > The real problem to solve is the protection of the private key used > for > >> > signing any file containing an initrd. > >> > >> Well FIT already solves that one. Either FIT is not being used, in > >> which case this series is useful, or it is being used, in which case > >> the initrd problem is solved. > >> > >> > > >> > > > >> > > The kernel and initrd can be dealt with in other ways. But > without FIT, > >> > > >> > How can the initrd be checked without FIT? > >> > >> I don't know. Please check with the EFI people. > > > > Ilias has made a proposal to “measure” files that do not have signatures > until files include signature. > > OK > > >> > >> > >> > > >> > > we have no standard way of signing and grouping FDT files. > Instead > >> > > we must > >> > > include them in the distro as separate files. > >> > > > >> > > In particular, some sort of mechanism for verifying FDT files > is needed. > >> > > One option would be to tack a signature on before or after the > file, > >> > > processing it accordingly. But due to the nature of the FDT > binary > >> > > format, > >> > > it is possible to embed a signature inside the FDT itself, > which is very > >> > > convenient. > >> > > > >> > > This series provides a tool, fdt_sign, which can add a > signature to an > >> > > FDT. The signature can be checked later, preventing any change > to > >> > > the FDT, > >> > > other than in permitted nodes (e.g. /chosen). > >> > > > > > Shouldn’t devicetree.org and kernel.org folks involved in this DT > signing effort ? I believe there are parrallel efforts in this area. Or is > it a private ? in that case, they do not need to be > involved. Depending on the case, you may want to spli
Re: [PATCH 00/16] tools: Add support for signing devicetree blobs
Hi Simon, Le sam. 13 nov. 2021 à 04:31, Simon Glass a écrit : > Hi Heinrich, > > On Fri, 12 Nov 2021 at 17:02, Heinrich Schuchardt > wrote: > > > > > > > > On 11/12/21 20:49, François Ozog wrote: > > > Hi Simon > > > > > > Le ven. 12 nov. 2021 à 20:36, Simon Glass > > <mailto:s...@chromium.org>> a écrit : > > > > > > At present mkimage supports signing FITs, the standard U-Boot image > > > type. > > > > > > Various people are opposed to using FIT since: > > > > > > just to be sure: I am not one of those. > > > > > > > > > a) it requires adding support for FIT into other bootloaders, > notably > > > UEFI > > > > > > whatever happens to FIT is entirely orthogonal to U-Boot UEFI > subsystem. > > > FIT can evolve, U-Boot UEFI does not have to change. > > > > We already can create signed FIT images containing a UEFI binary and a > > devcie-tree and launch the FIT image with the bootm command. > > > > Cf. > > CONFIG_BOOTM_EFI > > test/py/tests/test_efi_fit.py > > doc/usage/bootefi.rst > > > > Simon, what are you missing? > > Some people don't want to use FIT. > > > > > > > > > > > > b) it requires packaging a kernel in this standard U-Boot format, > > > meaning > > > that distros must run 'mkimage' and deal with the kernel and > initrd > > > being inside a FIT > > > > U-Boot tools are contained in distros like Debian and Ubuntu. > > Package flash-kernel uses a script in /etc/initramfs/post-update.d/ for > > a similar purpose. The same hook directory can be used to create a FIT > > image with a simple bash script. > > > > Why do we need a new tool for signing device-trees? > > > > The real problem to solve is the protection of the private key used for > > signing any file containing an initrd. > > Well FIT already solves that one. Either FIT is not being used, in > which case this series is useful, or it is being used, in which case > the initrd problem is solved. > > > > > > > > > The kernel and initrd can be dealt with in other ways. But without > FIT, > > > > How can the initrd be checked without FIT? > > I don't know. Please check with the EFI people. > Ilias has made a proposal to “measure” files that do not have signatures until files include signature. > > > > > > we have no standard way of signing and grouping FDT files. Instead > > > we must > > > include them in the distro as separate files. > > > > > > In particular, some sort of mechanism for verifying FDT files is > needed. > > > One option would be to tack a signature on before or after the > file, > > > processing it accordingly. But due to the nature of the FDT binary > > > format, > > > it is possible to embed a signature inside the FDT itself, which > is very > > > convenient. > > > > > > This series provides a tool, fdt_sign, which can add a signature > to an > > > FDT. The signature can be checked later, preventing any change to > > > the FDT, > > > other than in permitted nodes (e.g. /chosen). > > Shouldn’t devicetree.org and kernel.org folks involved in this DT signing effort ? I believe there are parrallel efforts in this area. Or is it a private ? in that case, they do not need to be involved. Depending on the case, you may want to split the patch series in a number of chunks. > > > I am not aware of any standard defining which nodes may be changed in > > the FDT fixup and which may not be changed. > > > > How can we discover which nodes were excluded from the signature after > > the signature? > > There is no way at present. I decided against adding a list of signed > nodes. We can of course add whatever is useful here. > > > > > > > > > This series also provides a fdt_check_sign tool, used to check > > > signatures. > > > > > > Both of these tools are stand-alone do not require mkimage or FIT. > > > > > > As with FIT signing, multiple signatures are possible, but in this > case > > > that requires that fit_sign be called once for each signature. To > > > make the > > > check fail if a signature does not match, it should be marked as > > > 'required' using the -r flag to fdt_sign. > > > > > > Run-time suppor
Re: [PATCH 00/16] tools: Add support for signing devicetree blobs
Hi Simon
Le ven. 12 nov. 2021 à 20:36, Simon Glass a écrit :
> At present mkimage supports signing FITs, the standard U-Boot image type.
>
> Various people are opposed to using FIT since:
>
just to be sure: I am not one of those.
>
> a) it requires adding support for FIT into other bootloaders, notably
>UEFI
whatever happens to FIT is entirely orthogonal to U-Boot UEFI subsystem.
FIT can evolve, U-Boot UEFI does not have to change.
>
> b) it requires packaging a kernel in this standard U-Boot format, meaning
>that distros must run 'mkimage' and deal with the kernel and initrd
>being inside a FIT
>
> The kernel and initrd can be dealt with in other ways. But without FIT,
> we have no standard way of signing and grouping FDT files. Instead we must
> include them in the distro as separate files.
>
> In particular, some sort of mechanism for verifying FDT files is needed.
> One option would be to tack a signature on before or after the file,
> processing it accordingly. But due to the nature of the FDT binary format,
> it is possible to embed a signature inside the FDT itself, which is very
> convenient.
>
> This series provides a tool, fdt_sign, which can add a signature to an
> FDT. The signature can be checked later, preventing any change to the FDT,
> other than in permitted nodes (e.g. /chosen).
>
> This series also provides a fdt_check_sign tool, used to check signatures.
>
> Both of these tools are stand-alone do not require mkimage or FIT.
>
> As with FIT signing, multiple signatures are possible, but in this case
> that requires that fit_sign be called once for each signature. To make the
> check fail if a signature does not match, it should be marked as
> 'required' using the -r flag to fdt_sign.
>
> Run-time support for checking FDT signatures could be added to U-Boot
> fairly easily, but needs further discussion as the correct plumbing needs
> to be determined.
>
> For now there is absolutely no configurability in the signature mechanism.
> It would of course be possible to adjust which nodes are signed, as is
> done for FIT, but that needs further discussion also. The omission of the
> /chosen node is implemented in h_exclude_nodes() like this:
>
>if (type == FDT_IS_NODE) {
> /* Ignore the chosen node as well as /signature and subnodes */
> if (!strcmp("/chosen", data) || !strncmp("/signature", data, 10))
> return 0;
>}
>
> Man pages are provided with example usage of the tools. Use this to view
> them:
>
>man -l doc/fdt_check_sign.1
>
> This series also includes various clean-ups noticed along the way, as well
> as refactoring to avoid code duplication with the new tools. The last four
> patches are the new code.
>
> This series is available at u-boot-dm/fdt-sign-working :
>
>
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/tree/fdt-sign-working
>
>
> Simon Glass (16):
> rsa: Add debugging for failure cases
> fit_check_sign: Update help to mention the key is in a dtb
> tools: Move copyfile() into a common file
> tools: Avoid leaving extra data at the end of copied files
> tools: Improve comments in signing functions
> tools: Drop unused name in image-host
> tools: Avoid confusion between keys and signatures
> tools: Tidy up argument order in fit_config_check_sig()
> tools: Pass the key blob around
> image: Return destination node for add_verify_data() method
> tools: Pass public-key node through to caller
> tools: mkimage: Show where signatures/keys are written
> tools: Add a new tool to sign FDT blobs
> tools: Add a new tool to check FDT-blob signatures
> test: Add a test for FDT signing
> tools: Add man pages for fdt_sign and fdt_check_sign
>
> MAINTAINERS | 7 +
> boot/image-fit-sig.c | 151 +
> boot/image-fit.c | 12 +-
> common/spl/spl_fit.c | 3 +-
> doc/fdt_check_sign.1 | 74 +++
> doc/fdt_sign.1 | 111 ++
> include/image.h | 80 ++-
> include/u-boot/ecdsa.h | 5 +-
> include/u-boot/rsa.h | 5 +-
> lib/ecdsa/ecdsa-libcrypto.c | 4 +-
> lib/rsa/rsa-sign.c | 5 +-
> lib/rsa/rsa-verify.c | 13 +-
> test/py/tests/test_fdt_sign.py | 83
> test/py/tests/test_vboot.py | 21 +-
> test/py/tests/vboot/sign-fdt.dts | 23 ++
> test/py/tests/vboot_comm.py | 22 ++
> tools/Makefile | 10 +-
> tools/fdt-host.c | 353 +++
> tools/fdt_check_sign.c | 85
> tools/fdt_host.h | 46
> tools/fdt_sign.c | 210 ++
> tools/fit_check_sign.c | 4 +-
> tools/fit_common.c | 69 ++
> tools/fit_common.h | 23 ++
> tools/fit_image.c| 59 +-
> tools/image-fdt-sig.c| 254 ++
>
Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
Hi Jan Le mer. 10 nov. 2021 à 17:48, Jan Kiszka a écrit : > On 10.11.21 17:31, Simon Glass wrote: > > Hi Jan, > > > > On Tue, 9 Nov 2021 at 23:44, Jan Kiszka wrote: > >> > >> On 10.11.21 01:58, Simon Glass wrote: > >>> Hi Jan, > >>> > >>> On Tue, 9 Nov 2021 at 03:07, Jan Kiszka > wrote: > > On 09.11.21 10:37, Roman Kopytin wrote: > > Can we have discussion with code lines? For me it is not very clear, > because it isn't my code. > > > > Please do not top-post. > > > -Original Message- > > From: Jan Kiszka > > Sent: Tuesday, November 9, 2021 12:17 PM > > To: Roman Kopytin ; > u-boot@lists.denx.de; Rasmus Villemoes > > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > > > > On 08.11.21 16:28, Roman Kopytin wrote: > >> In order to reduce the coupling between building the kernel and > >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb > >> without simultaneously signing a FIT image. That tool doesn't seem > to > >> exist, so I stole the necessary pieces from mkimage et al and put it > >> in a single .c file. > >> > >> I'm still working on the details of my proposed "require just k out > >> these n required keys" and how it should be implemented, but it will > >> probably involve teaching this tool a bunch of new options. These > >> patches are not necessarily ready for inclusion (unless someone else > >> finds fdt_add_pubkey useful as is), but I thought I might as well > send > >> it out for early comments. > > > > I'd also like to see the usage of this hooked into the build process. > > > > And to my understanding of [1], that approach will provide a feature > that permits hooking with the build but would expect the key as dtsi > fragment. Can we consolidate the approaches? > > > > My current vision of a user interface would be a Kconfig option that > takes a list of key files to be injected. Maybe make that three lists, one > for "required=image", one for "required=conf", and one for optional keys > (if that has a use case in practice, no idea). > > > > Jan > > > > [1] > > > https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villem...@prevas.dk/ > > > > -- > > Siemens AG, T RDA IOT > > Corporate Competence Center Embedded Linux > > > > For what would you like to have code? The kconfig addition? > > diff --git a/common/Kconfig.boot b/common/Kconfig.boot > index d3a12be228..a9ed4d4ec4 100644 > --- a/common/Kconfig.boot > +++ b/common/Kconfig.boot > @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR > > endif # SPL > > +config FIT_SIGNATURE_PUB_KEYS > + string "Public keys to use for FIT image verification" > + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE > + help > + Public keys, or certificate files to extract them from, > that shall > + be used to verify signed FIT images. The keys will be > embedded into > + the control device tree of U-Boot. > + > endif # FIT > > config LEGACY_IMAGE_FORMAT > > > But note that we are in a design discussion here, and I'm at least > reluctant to code up n-versions without having some common idea where > things should move. > >>> > >>> I'm not sure we want this built into U-Boot. I see signing of a > >>> firmware image as a final step, with the keys being added then, e.g. > >>> by binman. > >> > >> This is not signing, this in embedding public key information into build > >> artifacts before they can be signed. As pointed out in my other thread, > >> not having an embedding feature is a major drawback of the current > >> workflow. It easily forces you to rebuild existing build flows in > >> out-of-tree scripts. > > > > The public key is not needed for signing to work, right? I don't > > understand what you are getting at here. If you want to add the public > > key to the image before it is signed, that's fine. I just don't > > understand why you want to do that. Why not have the signer do > > everything? > > A) Because sensitive signing environments will not run arbitrary logic. >They will hand out the public key, but they may not give you the >chance to run mkimage with the private key, like you would do during >development. > thanks for bringing this very important topic on the list. In this case nobody may have the private key handy as it sits hidden inside an HSM: correct ? > > B) It avoids having to run the signing process in a specific order >because it already embeds the public key during build, thus >generates everything that shall be signed upfront. > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
Hi Jan, On Tue, 9 Nov 2021 at 15:00, Jan Kiszka wrote: > On 09.11.21 14:16, François Ozog wrote: > > Hi Jan > > > > On Tue, 9 Nov 2021 at 13:58, Jan Kiszka > <mailto:jan.kis...@siemens.com>> wrote: > > > > On 09.11.21 13:43, François Ozog wrote: > > > Hi > > > > > > as we are in design discussions, I would promote the idea of not > > pushing > > > non hardware related things in the DTB that is passed to the > kernel. > > > > This was never proposed. The public keys go into the *control* FDTs. > > > > great ;-) > > > > > Is your use case to allow U-Boot to verify the kernel's signature ? > > > Why not putting it into an environment variable? > > > > This is both about validating OS FIT containers as well as SPL > checking > > U-Boot proper before continuing the boot there. The former case can > be > > replaced with UEFI logic and likely taking the key from TEE (we do > that > > as well in first prototypes), but the latter can't (yet). > > > > > > > > If your use case is on Arm or RISC-V, both environments are working > > > heavily to make https://arm-software.github.io/ebbr/ > > <https://arm-software.github.io/ebbr/> > > > <https://arm-software.github.io/ebbr/ > > <https://arm-software.github.io/ebbr/>> standard available on a > large > > > number of boards. > > > This offers UEFI interface and SecureBoot (and later MeasuredBoot) > > > services. For Arm boards just check for SystemReady compliance. > > > In this context, traditional UEFI secure variables are used to > > deal with > > > certificates and hashes: PK, KEK, db... > > > You can obviously do differently but you will be on your own to > extend > > > the chain of trust to IMA, secure containers (rooted down to hRoT) > and > > > other security facilities in the Linux side. > > > Could you describe your use case in more details? > > > > doc/uImage.FIT/signature.txt ;) > > > > More concrete: We are currently massaging board/siemens/iot2050 to > close > > its static chain of trust between SPL and U-Boot main, using software > > means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot > > key). > > > > And will the chain of trust be continuous or with a very brief breakage > > with this approach? > > I other words, can you enroll the TF-A/TEE/U-Boot key so that it can be > > trusted by FSBL key? > > The chain will be continuous. Both FSBL and TF-A/TEE/SPL will be > OTP-anchored (but deployed at different times / by different > authorities), FSBL will validate based on OTP, SPL should do that based > on control FDT key. Therefore, we need embedding into the SPL FDT in > this case. > > If the user decides to continue "classically" by loading the OS from a > signed FIT image, also U-Boot proper needs the public key in its control > FDT. > > That's just one (likely more special) scenario, but I bet there are > plenty others on other SOCs / systems. > > Get it. Thanks for detailing the case, its very useful for me. > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
Hi Jan On Tue, 9 Nov 2021 at 13:58, Jan Kiszka wrote: > On 09.11.21 13:43, François Ozog wrote: > > Hi > > > > as we are in design discussions, I would promote the idea of not pushing > > non hardware related things in the DTB that is passed to the kernel. > > This was never proposed. The public keys go into the *control* FDTs. > > great ;-) > > Is your use case to allow U-Boot to verify the kernel's signature ? > > Why not putting it into an environment variable? > > This is both about validating OS FIT containers as well as SPL checking > U-Boot proper before continuing the boot there. The former case can be > replaced with UEFI logic and likely taking the key from TEE (we do that > as well in first prototypes), but the latter can't (yet). > > > > > If your use case is on Arm or RISC-V, both environments are working > > heavily to make https://arm-software.github.io/ebbr/ > > <https://arm-software.github.io/ebbr/> standard available on a large > > number of boards. > > This offers UEFI interface and SecureBoot (and later MeasuredBoot) > > services. For Arm boards just check for SystemReady compliance. > > In this context, traditional UEFI secure variables are used to deal with > > certificates and hashes: PK, KEK, db... > > You can obviously do differently but you will be on your own to extend > > the chain of trust to IMA, secure containers (rooted down to hRoT) and > > other security facilities in the Linux side. > > Could you describe your use case in more details? > > doc/uImage.FIT/signature.txt ;) > > More concrete: We are currently massaging board/siemens/iot2050 to close > its static chain of trust between SPL and U-Boot main, using software > means (vendor means do not work because FSBL key != TF-A/TEE/U-Boot key). > > And will the chain of trust be continuous or with a very brief breakage with this approach? I other words, can you enroll the TF-A/TEE/U-Boot key so that it can be trusted by FSBL key? Jan > > > > > On Tue, 9 Nov 2021 at 11:07, Jan Kiszka > <mailto:jan.kis...@siemens.com>> wrote: > > > > On 09.11.21 10:37, Roman Kopytin wrote: > > > Can we have discussion with code lines? For me it is not very > > clear, because it isn't my code. > > > > > > > Please do not top-post. > > > > > -Original Message- > > > From: Jan Kiszka > <mailto:jan.kis...@siemens.com>> > > > Sent: Tuesday, November 9, 2021 12:17 PM > > > To: Roman Kopytin > <mailto:roman.kopy...@kaspersky.com>>; u-boot@lists.denx.de > > <mailto:u-boot@lists.denx.de>; Rasmus Villemoes > > mailto:rasmus.villem...@prevas.dk>> > > > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > > > > > > On 08.11.21 16:28, Roman Kopytin wrote: > > >> In order to reduce the coupling between building the kernel and > > >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb > > >> without simultaneously signing a FIT image. That tool doesn't > > seem to > > >> exist, so I stole the necessary pieces from mkimage et al and put > it > > >> in a single .c file. > > >> > > >> I'm still working on the details of my proposed "require just k > out > > >> these n required keys" and how it should be implemented, but it > will > > >> probably involve teaching this tool a bunch of new options. These > > >> patches are not necessarily ready for inclusion (unless someone > else > > >> finds fdt_add_pubkey useful as is), but I thought I might as well > > send > > >> it out for early comments. > > > > > > I'd also like to see the usage of this hooked into the build > process. > > > > > > And to my understanding of [1], that approach will provide a > > feature that permits hooking with the build but would expect the key > > as dtsi fragment. Can we consolidate the approaches? > > > > > > My current vision of a user interface would be a Kconfig option > > that takes a list of key files to be injected. Maybe make that three > > lists, one for "required=image", one for "required=conf", and one > > for optional keys (if that has a use case in practice, no idea). > > > > > > Jan > > > > > > [1] > > > > > > https://lore.kernel.org/u-boot/202
Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool
Hi as we are in design discussions, I would promote the idea of not pushing non hardware related things in the DTB that is passed to the kernel. Is your use case to allow U-Boot to verify the kernel's signature ? Why not putting it into an environment variable? If your use case is on Arm or RISC-V, both environments are working heavily to make https://arm-software.github.io/ebbr/ standard available on a large number of boards. This offers UEFI interface and SecureBoot (and later MeasuredBoot) services. For Arm boards just check for SystemReady compliance. In this context, traditional UEFI secure variables are used to deal with certificates and hashes: PK, KEK, db... You can obviously do differently but you will be on your own to extend the chain of trust to IMA, secure containers (rooted down to hRoT) and other security facilities in the Linux side. Could you describe your use case in more details? On Tue, 9 Nov 2021 at 11:07, Jan Kiszka wrote: > On 09.11.21 10:37, Roman Kopytin wrote: > > Can we have discussion with code lines? For me it is not very clear, > because it isn't my code. > > > > Please do not top-post. > > > -Original Message- > > From: Jan Kiszka > > Sent: Tuesday, November 9, 2021 12:17 PM > > To: Roman Kopytin ; u-boot@lists.denx.de; > Rasmus Villemoes > > Subject: Re: [PATCH 0/2] RFC: add fdt_add_pubkey tool > > > > On 08.11.21 16:28, Roman Kopytin wrote: > >> In order to reduce the coupling between building the kernel and > >> U-Boot, I'd like a tool that can add a public key to U-Boot's dtb > >> without simultaneously signing a FIT image. That tool doesn't seem to > >> exist, so I stole the necessary pieces from mkimage et al and put it > >> in a single .c file. > >> > >> I'm still working on the details of my proposed "require just k out > >> these n required keys" and how it should be implemented, but it will > >> probably involve teaching this tool a bunch of new options. These > >> patches are not necessarily ready for inclusion (unless someone else > >> finds fdt_add_pubkey useful as is), but I thought I might as well send > >> it out for early comments. > > > > I'd also like to see the usage of this hooked into the build process. > > > > And to my understanding of [1], that approach will provide a feature > that permits hooking with the build but would expect the key as dtsi > fragment. Can we consolidate the approaches? > > > > My current vision of a user interface would be a Kconfig option that > takes a list of key files to be injected. Maybe make that three lists, one > for "required=image", one for "required=conf", and one for optional keys > (if that has a use case in practice, no idea). > > > > Jan > > > > [1] > > > https://lore.kernel.org/u-boot/20210928085651.619892-1-rasmus.villem...@prevas.dk/ > > > > -- > > Siemens AG, T RDA IOT > > Corporate Competence Center Embedded Linux > > > > For what would you like to have code? The kconfig addition? > > diff --git a/common/Kconfig.boot b/common/Kconfig.boot > index d3a12be228..a9ed4d4ec4 100644 > --- a/common/Kconfig.boot > +++ b/common/Kconfig.boot > @@ -279,6 +279,14 @@ config SPL_FIT_GENERATOR > > endif # SPL > > +config FIT_SIGNATURE_PUB_KEYS > + string "Public keys to use for FIT image verification" > + depends on FIT_SIGNATURE || SPL_FIT_SIGNATURE > + help > + Public keys, or certificate files to extract them from, that > shall > + be used to verify signed FIT images. The keys will be embedded > into > + the control device tree of U-Boot. > + > endif # FIT > > config LEGACY_IMAGE_FORMAT > > > But note that we are in a design discussion here, and I'm at least > reluctant to code up n-versions without having some common idea where > things should move. > > Jan > > -- > Siemens AG, T RDA IOT > Corporate Competence Center Embedded Linux > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
On Fri, 5 Nov 2021 at 18:17, Simon Glass wrote: > ) to signal Hi François, > > On Fri, 5 Nov 2021 at 10:31, François Ozog > wrote: > > > > Hi Simon, > > > > Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : > >> > >> Hi François, > >> > >> On Fri, 5 Nov 2021 at 02:27, François Ozog > wrote: > >> > > >> > > >> > > >> > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog > wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > >> >> >> > >> >> >> Hi François, > >> >> >> > >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog < > francois.o...@linaro.org> wrote: > >> >> >> > > >> >> >> > Hi Simon, > >> >> >> > > >> >> >> > this seems a great endeavor. I'd like to better understand the > scope of it. > >> >> >> > > >> >> >> > Is it to be used as part of what could become a U-Boot entry > ABI scheme? By that I mean giving some fixed aspects > >> >> >> > to U-Boot entry while letting boards to have flexibility (say > for instance that the first 5 architecture ABI > >> >> >> > parameter registers are reserved for U-Boot), and the Passage > is about specifying either those reserved registers > >> >> >> > or one of them? > >> >> >> > >> >> >> The goal is to provide a standard entry scheme for all firmware > >> >> >> binaries. Whether it achieves that (or can with some mods) is up > for > >> >> >> discussion. > >> >> >> > >> >> > If you say > >> >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware > information passing facility which would be part of all firmware ABIs (as > the projects decide to define their own ABI) it looks good. > >> >> > but If you say > >> >> > >> >> It is an ABI to be adopted by U-Boot but also other firmware. For > >> >> example, if TF-A calls U-Boot it should use standard passage. If > >> >> U-Boot calls TF-A or Optee it should use standard passage. > >> >> > >> >> > b) define a standard entry scheme (register map, processor state, > MMU state, SMMU state, GIC state...) that does not look realistic. > >> >> > >> >> No I don't mean that. This data structure could be used in any state, > >> >> so long as the two registers are set correctly. > >> >> > >> >> > I think you mean a) but just want to be sure. > >> >> > >> >> Yes I think so. > >> >> > >> >> >> > >> >> >> Re the registers, do you think we need 5? > >> >> >> > >> >> > >> >> I don't :-) > >> >> > >> >> >> > > >> >> >> > Thinking entry ABI, here is what I observed on Arm: > >> >> >> > > >> >> >> > Linux has two entry ABIs: > >> >> >> > - plain: x0 = dtb; > >> >> >> > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > >> >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; > >> >> >> >dtb = EFI_UUID config table; initrd = > efi: image_protocol::load_options > >> >> >> > > >> >> >> > U-Boot (proper) has plenty of schemes: > >> >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which > is bad in itself), or other registers > >> >> >> > - additional information passing: board specific register > scheme, SMC calls > >> >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to > be launched by Videocore firmware > >> >> >> > > >> >> >> > Based on all the above, I would tend to think that RPI scheme > is a good idea but also > >> >> >> > shall not prevent additional schemes for the boards. > >> >> >> > >> >> >>
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Simon, Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : > Hi François, > > On Fri, 5 Nov 2021 at 02:27, François Ozog > wrote: > > > > > > > > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 2 Nov 2021 at 10:03, François Ozog > wrote: > >> > > >> > Hi Simon, > >> > > >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog > wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > this seems a great endeavor. I'd like to better understand the > scope of it. > >> >> > > >> >> > Is it to be used as part of what could become a U-Boot entry ABI > scheme? By that I mean giving some fixed aspects > >> >> > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > >> >> > parameter registers are reserved for U-Boot), and the Passage is > about specifying either those reserved registers > >> >> > or one of them? > >> >> > >> >> The goal is to provide a standard entry scheme for all firmware > >> >> binaries. Whether it achieves that (or can with some mods) is up for > >> >> discussion. > >> >> > >> > If you say > >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware > information passing facility which would be part of all firmware ABIs (as > the projects decide to define their own ABI) it looks good. > >> > but If you say > >> > >> It is an ABI to be adopted by U-Boot but also other firmware. For > >> example, if TF-A calls U-Boot it should use standard passage. If > >> U-Boot calls TF-A or Optee it should use standard passage. > >> > >> > b) define a standard entry scheme (register map, processor state, MMU > state, SMMU state, GIC state...) that does not look realistic. > >> > >> No I don't mean that. This data structure could be used in any state, > >> so long as the two registers are set correctly. > >> > >> > I think you mean a) but just want to be sure. > >> > >> Yes I think so. > >> > >> >> > >> >> Re the registers, do you think we need 5? > >> >> > >> > >> I don't :-) > >> > >> >> > > >> >> > Thinking entry ABI, here is what I observed on Arm: > >> >> > > >> >> > Linux has two entry ABIs: > >> >> > - plain: x0 = dtb; > >> >> > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; > >> >> >dtb = EFI_UUID config table; initrd = > efi: image_protocol::load_options > >> >> > > >> >> > U-Boot (proper) has plenty of schemes: > >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is > bad in itself), or other registers > >> >> > - additional information passing: board specific register scheme, > SMC calls > >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > >> >> > > >> >> > Based on all the above, I would tend to think that RPI scheme is a > good idea but also > >> >> > shall not prevent additional schemes for the boards. > >> >> > >> >> I was not actually considering Linux since I believe/assume its entry > >> >> scheme is fixed and not up for discussion. > >> >> > >> >> I also did not think about the EFI case. As I understand it we cannot > >> >> touch it as it is used by UEFI today. Maybe it is even in the > >> >> standard? > >> > > >> > It is in the spec and we are making it evolve, or its understanding > evolve (jurisprudence) for instance on initrd standard handling. > >> > >> Well perhaps we could merge it with standard passage. But EFI is not > >> going to want to use a bloblist, it will want to use a HOB. > >> > >> >> > >> >> > >> >> Really I am hoping we can start afresh...? > >> >> > >> >> > > >
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: > Hi François, > > On Tue, 2 Nov 2021 at 10:03, François Ozog > wrote: > > > > Hi Simon, > > > > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Mon, 1 Nov 2021 at 02:53, François Ozog > wrote: > >> > > >> > Hi Simon, > >> > > >> > this seems a great endeavor. I'd like to better understand the scope > of it. > >> > > >> > Is it to be used as part of what could become a U-Boot entry ABI > scheme? By that I mean giving some fixed aspects > >> > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > >> > parameter registers are reserved for U-Boot), and the Passage is > about specifying either those reserved registers > >> > or one of them? > >> > >> The goal is to provide a standard entry scheme for all firmware > >> binaries. Whether it achieves that (or can with some mods) is up for > >> discussion. > >> > > If you say > > a) define a U-Boot entry ABI and providing a firmware-to-firmware > information passing facility which would be part of all firmware ABIs (as > the projects decide to define their own ABI) it looks good. > > but If you say > > It is an ABI to be adopted by U-Boot but also other firmware. For > example, if TF-A calls U-Boot it should use standard passage. If > U-Boot calls TF-A or Optee it should use standard passage. > > > b) define a standard entry scheme (register map, processor state, MMU > state, SMMU state, GIC state...) that does not look realistic. > > No I don't mean that. This data structure could be used in any state, > so long as the two registers are set correctly. > > > I think you mean a) but just want to be sure. > > Yes I think so. > > >> > >> Re the registers, do you think we need 5? > >> > > I don't :-) > > >> > > >> > Thinking entry ABI, here is what I observed on Arm: > >> > > >> > Linux has two entry ABIs: > >> > - plain: x0 = dtb; > >> > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > >> > - EFI: x0=handle, x1=systemtable, x30=return address; > >> >dtb = EFI_UUID config table; initrd = > efi: image_protocol::load_options > >> > > >> > U-Boot (proper) has plenty of schemes: > >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is > bad in itself), or other registers > >> > - additional information passing: board specific register scheme, SMC > calls > >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > >> > > >> > Based on all the above, I would tend to think that RPI scheme is a > good idea but also > >> > shall not prevent additional schemes for the boards. > >> > >> I was not actually considering Linux since I believe/assume its entry > >> scheme is fixed and not up for discussion. > >> > >> I also did not think about the EFI case. As I understand it we cannot > >> touch it as it is used by UEFI today. Maybe it is even in the > >> standard? > > > > It is in the spec and we are making it evolve, or its understanding > evolve (jurisprudence) for instance on initrd standard handling. > > Well perhaps we could merge it with standard passage. But EFI is not > going to want to use a bloblist, it will want to use a HOB. > > >> > >> > >> Really I am hoping we can start afresh...? > >> > >> > > >> > What about a U-Boot Arm entry ABI like: > >> > - plain: x0=dtb, x1=, x2-x5 = , other > registers are per platform, SMC calls allowed too > >> > >> Hmm we don't actually need the dtb as it is available in the bloblist. > > > > If you don't have x0=dtb, then you will not be able to use U-Boot on > RPI4. > > Unless you want to redo everything the RPI firmware is doing. > > That's right, RPI cannot support standard passage. It is not > open-source firmware so it isn't really relevant to this discussion. > It will just do what it does and have limited functionality, with > work-arounds to deal with the pain, as one might expect. > > So you are seeing two "all-or-nothing" options: : U-Boot entry is board specific as it is today : A new form where the only parameter is a head of bloblist, one of those blobs contain a DT You propose to mand
Re: [PATCH 1/1] sysreset: watchdog: watchdog cannot power off
Hi Heinrich, Le jeu. 4 nov. 2021 à 12:45, Heinrich Schuchardt < heinrich.schucha...@canonical.com> a écrit : > On 11/4/21 10:55, François Ozog wrote: > > Hi Heinrich, > > > > On Thu, 4 Nov 2021 at 10:31, Heinrich Schuchardt > > > <mailto:heinrich.schucha...@canonical.com>> wrote: > > > > The watchdog system reset driver can reboot the device but it cannot > > power > > it off. If power off is requested, the driver should not reset the > > system > > but leave powering off to one of the other system reset drivers. > > > > As power cycling is typically not a feature of a watchdog driver the > > reset > > types SYSRESET_POWER and SYSRESET_POWER_OFF shall both be excluded. > > > > A candid question here. I know that IPMI can powercycle a platform. > > How would we handle that should there be a way to make the power cycle > > happen? > > (for instance we could define a PSCI extension of SYSTEM_RESET2 to have > > a power cycle effect) > > Your comment seems not to relate to the validity of the current patch. > yes. It was a related question to understand more about the topic. > > For PSCI we have a separate sysreset driver > drivers/sysreset/sysreset_psci.c. That driver currently does not support > SYSRESET_POWER. > > Once such an extension is offered by PSCI you should define a > device-tree node property for it in Linux' > Documentation/devicetree/bindings/arm/psci.yaml. Next implement a probe > function in the driver code to detect that property. In > psci_sysreset_request(), if type=SYSRESET_POWER, call the appropriate > PSCI method if the extension is enabled or return -ENOSYS if the > extension is not available. > > Currently in U-Boot I see no code invoking a reset with SYSRESET_POWER. > You would have to change function do_reset() in > drivers/sysreset/sysreset-uclass.c to accept a new argument to select > this reset type. > > Best regards > > Heinrich > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Peter Le jeu. 4 nov. 2021 à 12:41, Peter Maydell a écrit : > On Thu, 4 Nov 2021 at 11:22, François Ozog > wrote: > > Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a > écrit : > >> > >> Well, our recommendation really was that the ideal thing would > >> be "you take the dtb that QEMU passes you at runtime, and at > >> runtime combine that with whatever extra information you want". > > > > That looks just reasonable this way. > > > So we need a « -mergedtb » option for Qemu to have the same > > capability. This would merge the QEMU generated one with the > > command line provided. > > No, I mean that the guest, ie u-boot, should do the merging, > not QEMU. for most of the cases it works. But, as I tried to explain some cases need earlier merging hence trying to get QEMU do the same thing as TFA as « prior loaders » in the boot chain. Worst case we can have the behavior by booting TFA then U-Boot then Linux under QEMU, but the best would be to get the facility directly when TFA is not on the path of the boot like with the VBE boot flow. > > > -- PMM > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
hi Peter Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a écrit : > On Wed, 3 Nov 2021 at 14:41, Tom Rini wrote: > > > > On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote: > > [snip] > > > > 3. Anything else? > > > > > > > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties > > > > are present. There is no easy way to fix this. > > > > > > one clean and easy way would be to upstream a Qemu change to merge a > > > supplied overlay to the generated one. This the same idea as applying > the > > > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders > do > > > their job properly for U-Boot : setting up the stage as needed. > > > > For the record, I believe Simon did propose this and the QEMU response > > was that no, you should dumpdtb, combine externally and pass that > > directly. > > Well, our recommendation really was that the ideal thing would > be "you take the dtb that QEMU passes you at runtime, and at > runtime combine that with whatever extra information you want". That looks just reasonable this way. Runtime merging may need to be done before control is actually transferred. We have that problem on real board where we need to inject a TPM device for measured boot and it is not énumerable and pluggable. With TFA we have the option to add the TPM description in the NT_FW_CONFIG and merge it at run time. So we need a « -mergedtb » option for Qemu to have the same capability. This would merge the QEMU generated one with the command line provided. > > The dumpdtb option is primarily intended as a debug feature, > so you can have a look at the dtb QEMU created to see why your > OS isn't booting; although you can script stuff up that does > a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the > need to invoke QEMU twice with matching arguments both times. > > -- PMM > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 1/1] sysreset: watchdog: watchdog cannot power off
Hi Heinrich,
On Thu, 4 Nov 2021 at 10:31, Heinrich Schuchardt <
heinrich.schucha...@canonical.com> wrote:
> The watchdog system reset driver can reboot the device but it cannot power
> it off. If power off is requested, the driver should not reset the system
> but leave powering off to one of the other system reset drivers.
>
> As power cycling is typically not a feature of a watchdog driver the reset
> types SYSRESET_POWER and SYSRESET_POWER_OFF shall both be excluded.
>
A candid question here. I know that IPMI can powercycle a platform.
How would we handle that should there be a way to make the power cycle
happen?
(for instance we could define a PSCI extension of SYSTEM_RESET2 to have a
power cycle effect)
>
> Fixes: 17a0c14164dc ("dm: sysreset: add watchdog-reboot driver")
> Signed-off-by: Heinrich Schuchardt
> ---
> drivers/sysreset/sysreset_watchdog.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/sysreset/sysreset_watchdog.c
> b/drivers/sysreset/sysreset_watchdog.c
> index 35efcac59d..8a659ee9b9 100644
> --- a/drivers/sysreset/sysreset_watchdog.c
> +++ b/drivers/sysreset/sysreset_watchdog.c
> @@ -20,9 +20,16 @@ static int wdt_reboot_request(struct udevice *dev, enum
> sysreset_t type)
> struct wdt_reboot_plat *plat = dev_get_plat(dev);
> int ret;
>
> - ret = wdt_expire_now(plat->wdt, 0);
> - if (ret)
> - return ret;
> + switch (type) {
> + case SYSRESET_COLD:
> + case SYSRESET_WARM:
> + ret = wdt_expire_now(plat->wdt, 0);
> + if (ret)
> + return ret;
> + break;
> + default:
> + return -ENOSYS;
> + }
>
> return -EINPROGRESS;
> }
> --
> 2.32.0
>
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Simon I don't know if this is correct etiquette but at this moment it feels just right to do this: The problem is not confusion it is that the patch set goes in a direction that makes no sense. On Tue, 26 Oct 2021 at 02:24, Simon Glass wrote: > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > >- OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot >- OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) >- OF_BOARD - the board figures it out on its own > > YES! perfect! Default config for boards like RPI4, Qemu and SystemReady ones should be OF_BOARD. There may be an override for the advanced developer that need a playground for those boards; with a warning: "for debug purposes, turning on this option for this platform assumes you know exactly what you are doing." The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Rightfully as you write below "it comes from an entity that "have a better idea about the hardware". > Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > That is a documentation problem. > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. That statement is I think the start of problems. > This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > YES! exactly. Why would you ever embed a DT in U-Boot if it comes from an entity that "have a better idea about the hardware"? For advanced debugging yes. Otherwise no reasons. > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > Problem starts to grow. > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. > > Note: This breaks the qemu-riscv64_spl test, which still needs > investigation. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Ilias Apalodimas (1): > sandbox: Remove OF_HOSTFILE > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon, and team On Wed, 3 Nov 2021 at 06:29, François Ozog wrote: > Hi Simon > > Le mer. 3 nov. 2021 à 02:30, Simon Glass a écrit : > >> Hi Tom, >> >> On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: >> > >> > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: >> > > Hi Tom, >> > > >> > > On Mon, 1 Nov 2021 at 12:07, Tom Rini wrote: >> > > > >> > > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: >> > > > > Hi Simon >> > > > > >> > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a >> écrit : >> > > > > >> > > > > > Hi Peter, >> > > > > > >> > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell < >> peter.mayd...@linaro.org> >> > > > > > wrote: >> > > > > > > >> > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass >> wrote: >> > > > > > > > >> > > > > > > > Add this file, generated from qemu, so there is a reference >> devicetree >> > > > > > > > in the U-Boot tree. >> > > > > > > > >> > > > > > > > Signed-off-by: Simon Glass >> > > > > > > >> > > > > > > Note that the dtb you get from QEMU is only guaranteed to >> work if: >> > > > > > > 1) you run it on the exact same QEMU version you generated >> it with >> > > > > > > 2) you pass QEMU the exact same command line arguments you >> used >> > > > > > > when you generated it >> > > > > > >> > > > > > Yes, I certainly understand that. In general this is not safe, >> but in >> > > > > > practice it works well enough for development and CI. >> > > > > >> > > > > You recognize that you hijack a product directory with >> development hack >> > > > > facility. There is a test directory to keep things clear. There >> can be a >> > > > > dev-dts or something similar for Dev time tools. >> > > > > I have only seen push back on those fake dts files in the dts >> directory: I >> > > > > guess that unless someone strongly favors a continuation of the >> discussion, >> > > > > you may consider re-shaping the proposal to address concerns. >> > > > >> > > > Yes. We need to document how to make development easier. But I'm >> still >> > > > not on board with the notion of including DTS files for platforms >> where >> > > > the source of truth for the DTB is elsewhere. That's going to >> bring us >> > > > a lot more pain. >> > > >> > > Are you talking about QEMU specifically, or Raspberry Pi? >> > >> > I was using two of the more common and readily available platforms where >> > the source of truth for the DTS/DTB is not (and will not be) U-Boot. >> > >> > > How can we get this resolved? I very much want to get to just having >> > > OF_SEPARATE and OF_EMBED as the only available build-time options, >> > > with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for >> > > runtime support. I feel that separating the build-time and run-time >> > > behaviour is very important. Over time perhaps we will have some >> > > success in upstreaming bindings, but for now we have what we have. >> > > There is still a lot of pushback on U-Boot having things in the >> > > devicetree, although I do see that softening somewhat. >> > >> > >> > To reiterate, the uniform bit of feedback on this series has been that >> > everyone else disagrees with your notion that we _must_ have a dts >> > in-tree. >> >> [I would like everyone to take a deep breath and think about what this >> actually impacts. I argue the impact outside U-Boot is approximately >> zero. What are we actually discussing here?] >> >> A few have responded that they can just add the files. I think that is >> the case for everything except QEMU, right? I think even François >> agrees with the documentation argument. > > I do providing that the sample goes into documentation, not actionable as > a build artifact in the dts directory. > >> There is no real burden in >> adding the files so we can see wh
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon Le mer. 3 nov. 2021 à 02:30, Simon Glass a écrit : > Hi Tom, > > On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: > > > > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Mon, 1 Nov 2021 at 12:07, Tom Rini wrote: > > > > > > > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a > écrit : > > > > > > > > > > > Hi Peter, > > > > > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell < > peter.mayd...@linaro.org> > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass > wrote: > > > > > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > devicetree > > > > > > > > in the U-Boot tree. > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > > Note that the dtb you get from QEMU is only guaranteed to work > if: > > > > > > > 1) you run it on the exact same QEMU version you generated it > with > > > > > > > 2) you pass QEMU the exact same command line arguments you > used > > > > > > > when you generated it > > > > > > > > > > > > Yes, I certainly understand that. In general this is not safe, > but in > > > > > > practice it works well enough for development and CI. > > > > > > > > > > You recognize that you hijack a product directory with development > hack > > > > > facility. There is a test directory to keep things clear. There > can be a > > > > > dev-dts or something similar for Dev time tools. > > > > > I have only seen push back on those fake dts files in the dts > directory: I > > > > > guess that unless someone strongly favors a continuation of the > discussion, > > > > > you may consider re-shaping the proposal to address concerns. > > > > > > > > Yes. We need to document how to make development easier. But I'm > still > > > > not on board with the notion of including DTS files for platforms > where > > > > the source of truth for the DTB is elsewhere. That's going to bring > us > > > > a lot more pain. > > > > > > Are you talking about QEMU specifically, or Raspberry Pi? > > > > I was using two of the more common and readily available platforms where > > the source of truth for the DTS/DTB is not (and will not be) U-Boot. > > > > > How can we get this resolved? I very much want to get to just having > > > OF_SEPARATE and OF_EMBED as the only available build-time options, > > > with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for > > > runtime support. I feel that separating the build-time and run-time > > > behaviour is very important. Over time perhaps we will have some > > > success in upstreaming bindings, but for now we have what we have. > > > There is still a lot of pushback on U-Boot having things in the > > > devicetree, although I do see that softening somewhat. > > > > > > To reiterate, the uniform bit of feedback on this series has been that > > everyone else disagrees with your notion that we _must_ have a dts > > in-tree. > > [I would like everyone to take a deep breath and think about what this > actually impacts. I argue the impact outside U-Boot is approximately > zero. What are we actually discussing here?] > > A few have responded that they can just add the files. I think that is > the case for everything except QEMU, right? I think even François > agrees with the documentation argument. I do providing that the sample goes into documentation, not actionable as a build artifact in the dts directory. > There is no real burden in > adding the files so we can see what is going on, add a binman node, > SPL nodes, etc. > > So I am going to stand my ground on that one. It affects: > > - highbank > - qemu-ppce500 > - rpi_4 > - xilinx_versal_virt > - octeontx > - xenguest_arm64 > - juno > > So that is just 7 boards that I want to add devicetree files for. I > think that is reasonable and not a burden on these maintainers. > > Let me deal with QEMU. > > Let's imagi
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Simon
Le mer. 3 nov. 2021 à 02:21, Simon Glass a écrit :
> Hi François,
>
> On Wed, 27 Oct 2021 at 14:07, François Ozog
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 27 oct. 2021 à 20:23, Simon Glass a écrit :
> >>
> >> Hi François,
> >>
> >> On Wed, 27 Oct 2021 at 09:14, François Ozog
> wrote:
> >> >
> >> >
> >> >
> >> > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote:
> >> >>
> >> >> Hi François,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog <
> francois.o...@linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon
> >> >> >
> >> >> > Position unchanged on this series: adding fake dts for boards that
> generate their device tree in the dts directory is not good. If you have
> them in documentation the it is acceptable.
> >> >>
> >> >> I think we are going to have to disagree on this one. I actually used
> >> >> the qemu one in testing/development recently. We have to have a way
> to
> >> >> develop in-tree with U-Boot. It does not impinge on any of your use
> >> >> cases, so far as I know.
> >> >
> >> > I am not the only one in disagreement... You just saw Alex Bénée from
> Qemu saying the same thing.
> >> > I understand the advanced debug/development scenario you mention.
> >> > But locating the DT files in the dts directory is mis-leading the
> contributors to think that they need to compile the DT for the targeted
> platforms.
> >> > For your advanced scenario, you can still have the dts in the
> documentation area, or whatever directory (except dts). compile it and
> supply to U-Boot.
> >>
> >> We have this situation with rpi 1, 2 and 3 and I don't believe anyone
> >> has noticed. U-Boot handles the build automatically. If you turn off
> >> OF_BOARD, it will use the U-Boot devicetree always so you know what is
> >> going on.
> >>
> >> We can add a message to U-Boot indicating where the devicetree came
> >> from, perhaps? That might be useful given everything that is going on.
> >>
> >> As in this case, quite often in these discussions I struggle to
> >> understand what is behind the objection. Is it that your customers are
> >> demanding that devicetrees become private, secret data, not included
> >> in open-source projects? Or is it just the strange case of QEMU that
> >> is informing your thinking? I know of at least one project where the
> >> first-stage bootloader produces a devicetree and no one has the source
> >> for it. I believe TF-A was created for licensing reasons...so can you
> >> be a bit clearer about what the problem actually is?
> >
> > there are situations where U-Boot must have a dtb. Then those dTB
> sources are logically found in the dts directory.
> > There are situations where U-Boot should not have a dtb. In that case
> there should be no element in the dts directory. Otherwise it creates
> confusion.
> > Now as you point out, we need “playgrounds” to deal with some situation.
> So having examples in an ad-hoc directory, different from dts is fine. I
> proposed documentation but you may find a better place.
> > In other words, dts shall host only dt source when U-Boot cannot do but
> make a dTB for a platform.
> > As you have seen in different mail thread (firmware sustainability and
> OCP checklist) freedom is important to Linaro and there are no hidden
> Trojan horse for licensing.
>
> I don't understand what you are getting at with the Trojan horse.
I was referring to your statement that “TFA was created for licensing “
reasons. That’s not the case. It was created to address fragmentation in
the secure firmware for which there was no open source at all. SPL is
definitely not architected to be the basis of Arm secure firmware {
TFA/BL31 (secure monitor), TFA/BL32 (OP-TEE), TFA/SEL2(Hafnium), TFA/SCMI
server, SCP…}. That said SPL and TFA/BL2 have similar roles from a
10,000ft perspective.
I felt your comment was alluding to TFA was created to promote binary
components integration, which is also not the case. Hence my reference to
Trojan Horse.
> But
> you have no objection to requiring boards to supply a DT (whether in
> documentation or arch/arm/dts) to be in U-Boot?
I agree that boards need to properly document their DT. For (a) boards that
have defined their standard boot flow to assume U-Boot will only do fix ups
and overlays, the DT shall be in the U-Boot documentation part (either in
full or pointing to their proje
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Simon, On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: > Hi François, > > On Mon, 1 Nov 2021 at 02:53, François Ozog > wrote: > > > > Hi Simon, > > > > this seems a great endeavor. I'd like to better understand the scope of > it. > > > > Is it to be used as part of what could become a U-Boot entry ABI scheme? > By that I mean giving some fixed aspects > > to U-Boot entry while letting boards to have flexibility (say for > instance that the first 5 architecture ABI > > parameter registers are reserved for U-Boot), and the Passage is about > specifying either those reserved registers > > or one of them? > > The goal is to provide a standard entry scheme for all firmware > binaries. Whether it achieves that (or can with some mods) is up for > discussion. > > If you say a) define a U-Boot entry ABI and providing a firmware-to-firmware information passing facility which would be part of all firmware ABIs (as the projects decide to define their own ABI) it looks good. but If you say b) define a standard entry scheme (register map, processor state, MMU state, SMMU state, GIC state...) that does not look realistic. I think you mean a) but just want to be sure. > Re the registers, do you think we need 5? > > > > > Thinking entry ABI, here is what I observed on Arm: > > > > Linux has two entry ABIs: > > - plain: x0 = dtb; > > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > > - EFI: x0=handle, x1=systemtable, x30=return address; > >dtb = EFI_UUID config table; initrd = efi: vendor media UUID); command line = efi: image_protocol::load_options > > > > U-Boot (proper) has plenty of schemes: > > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad > in itself), or other registers > > - additional information passing: board specific register scheme, SMC > calls > > - U-Boot for RPI boards implement a Linux shaped entry ABI to be > launched by Videocore firmware > > > > Based on all the above, I would tend to think that RPI scheme is a good > idea but also > > shall not prevent additional schemes for the boards. > > I was not actually considering Linux since I believe/assume its entry > scheme is fixed and not up for discussion. > > I also did not think about the EFI case. As I understand it we cannot > touch it as it is used by UEFI today. Maybe it is even in the > standard? > It is in the spec and we are making it evolve, or its understanding evolve (jurisprudence) for instance on initrd standard handling. > > Really I am hoping we can start afresh...? > > > > > What about a U-Boot Arm entry ABI like: > > - plain: x0=dtb, x1=, x2-x5 = , other > registers are per platform, SMC calls allowed too > > Hmm we don't actually need the dtb as it is available in the bloblist. > If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. Unless you want to redo everything the RPI firmware is doing. > But I added an offset to it as a convenience. > > > - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is > launched as an EFI app) > >dtb = EFI_UUID config table, + Passage = Passage UUID config table > > I don't understand the last line. Where is the passage info / > bloblist? Do you mean it goes in the HOB list with a UUID? I suppose > that is the most EFI-compatible way. > The Passage config table could just contain the "head" of the bloblist/Passage information. > > What do you think about the idea of using an offset into the bloblist > for the dtb? It is possible but as I said, failing to mimic Linux entry ABI would miss the opportunity to just boot without changes on RPI4. > Also, can we make the standard passage ABI a build-time > option, so it is deterministic? > > Looks good. I would look into stating that for SystemReady we would advise to use that option and make it standard for Trusted Substrate (Linaro recipes that we upstreaming to make SystemReady compliance easy and consistent across platforms). > > > > We could further leverage Passage to pass Operating Systems parameters > that could be removed from device tree (migration of /chosen to Passage). > Memory inventory would still be in DT but allocations for CMA or GPUs would > be in Passage. This idea is to reach a point where device tree is a > "pristine" hardware description. > > I'm worried about this becoming a substitute for devicetree. Really my > intent is to provide a way to pass simple info, whereas what you talk > about there seems like something that should be DT, just that it might > need suitable bindings. > > I see your point and I agre
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Tue, 2 Nov 2021 at 11:07, Michael Walle wrote: > Hi, > > > On Thu, 28 Oct 2021 at 05:51, Simon Glass wrote: > > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas > > > wrote: > > .. > > > > Linux actually doesn't care if the U-Boot properties are in the tree, > > > so long as we have proper bindings. My point here is we only need > > > either: > > > > > > a. one devicetree, shared with Linux and U-Boot (and TF-A?) > > > b. two devicetrees, one for use in firmware and one for passing to > Linux > > > > > > We don't need to separate out the U-Boot properties into a second (or > > > third) devicetree. There just isn't any point. > > > > Again if we are talking about bindings that are upstream in the spec, > > then we agree. Depending on the SRAM limitation we can even do (a). > > If the vendor messes up the DT backwards compatibility then we can do > > (b). If you expect TF-A and FIP to go pick up the special bindings > > U-Boot needs, then we disagree. > > *puts developer at board vendor hat on* Sometimes (personally I'd say > usually) it isn't possible to have a backwards compatible tree. Also, > like it or not, in the device tree there *are* configuration options > which are not hardware dependent (eg. internal ethernet connection on > the ls1028a). Are you referring to DPAA2 configuration to create the ethernet port itself ? This is indeed configuration. There are many ways to handle those ones. As well as SerDes configuration to make PCI lanes or MDIO lanes. Yet the two are different in nature: SerDes configuration must match board layout, so it is about "no user choice" configuration. This configuration could be statically defined and attached with the board. But it there is a SoM with a carrier board, we may need to compose that at runtime for development, or make it static build for product packaging. DPAA2 configuration is user choice driven. Those choices can be merged in the DT to be passed to the OS at runtime. There are multiple ways to deal with that, from DT overlays to U-Boot DPAA2 command line extensions that would inject the DT necessary nodes. > So a vendor doesn't necessarily need to "mess things up" > to need (b). And as you know, my point is, that this device tree has > to come from the distribution, it must not be compiled in into the > firmware. > I wouldn't bet that all distro providers will always come with a DT... > > I feel like I've repeated this far too many times. Therefore, this > will be my last comment about it and I would really like to see that > this - very real - scenario is treated as a valid use case and will be > supported in your systemready vision. > I have been building (shared it on the list) a deck to go into those details. I am almost ready to talk to it. > > -michael > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Mark, Le lun. 1 nov. 2021 à 19:19, Mark Kettenis a écrit : > > From: François Ozog > > Date: Mon, 1 Nov 2021 09:53:40 +0100 > > [...] > > > We could further leverage Passage to pass Operating Systems parameters > that > > could be removed from device tree (migration of /chosen to Passage). > Memory > > inventory would still be in DT but allocations for CMA or GPUs would be > in > > Passage. This idea is to reach a point where device tree is a "pristine" > > hardware description. > > I wanted to react on something you said in an earlier thread, but this > discussion seems to be appropriate as well: > > The notion that device trees only describe the hardware isn't really > correct. Device trees have always been used to configure firmware > options (through the /options node) and between firmware and the OS > (through the /chosen node) and to describe firmware interfaces > (e.g. OpenFirmware calls, PSCI (on ARM), RTAS (on POWER)). This was > the case on the original Open Firmware systems, and is still done on > PowerNV systems that use flattened device trees. > I understand and agree with the above. Yet, PSCI is different from /options and /chosen: those are platform services made available to the OS when the boot firmware code has been unloaded/neutralized. What I (not just myself but let’s simplify) am trying to decouple the supply chain: loosely coupled platform provider (ODM), the firmware provider, OS provider, application provider. So it is not to prevent presence of those existing nodes, it is to be able introduce some rationalization in their use: Platform interfaces such as PSCI: The question is “who” injects them in the DT (build time or runtime). There is no single good answer and you may want the authoritative entity that implements the service to actually inject itself in the DT passed to the OS. I know some platforms are using SMC calls from U-Boot to know what to inject in the DT. I see those as the same nature of DIMM sensing and injection in the DT. /chosen: a must have when you do not have UEFI but not necessary with UEFI. /options: it should be possible for the end customer to make the decision of integration: at build time or at runtime based on a separate flattened device tree file. This decoupling should result for instance, in the long run, in adjustable memory layouts without headaches. changing the secure dram size is simple from hardware perspective but a massive issue from a firmware perspective: multiple firmware projects sources need to be adjusted, making manual calculations on explicit constants or “hidden” ones. It should even be possible to adjust it at runtime on the field (user selected firmware parameter). > I don't see what the benefits are from using Passage instead. It > would only fragment things even more. > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > Hi Peter, > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > wrote: > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > in the U-Boot tree. > > > > > > Signed-off-by: Simon Glass > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > 1) you run it on the exact same QEMU version you generated it with > > 2) you pass QEMU the exact same command line arguments you used > > when you generated it > > Yes, I certainly understand that. In general this is not safe, but in > practice it works well enough for development and CI. You recognize that you hijack a product directory with development hack facility. There is a test directory to keep things clear. There can be a dev-dts or something similar for Dev time tools. I have only seen push back on those fake dts files in the dts directory: I guess that unless someone strongly favors a continuation of the discussion, you may consider re-shaping the proposal to address concerns. > I am able to use > QEMU versions that differ by two years, partly because I am not trying > to do anything clever. > > I have sent a patch to add an indication of where the devicetree came > from, to help with visibility on this. > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi Simon, this seems a great endeavor. I'd like to better understand the scope of it. Is it to be used as part of what could become a U-Boot entry ABI scheme? By that I mean giving some fixed aspects to U-Boot entry while letting boards to have flexibility (say for instance that the first 5 architecture ABI parameter registers are reserved for U-Boot), and the Passage is about specifying either those reserved registers or one of them? Thinking entry ABI, here is what I observed on Arm: Linux has two entry ABIs: - plain: x0 = dtb; command line = dtb:/chosen/bootargs; initrd = dtb:/chosen/linux,initrd-* - EFI: x0=handle, x1=systemtable, x30=return address; dtb = EFI_UUID config table; initrd = efi:, x2-x5 = , other registers are per platform, SMC calls allowed too - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is launched as an EFI app) dtb = EFI_UUID config table, + Passage = Passage UUID config table We could further leverage Passage to pass Operating Systems parameters that could be removed from device tree (migration of /chosen to Passage). Memory inventory would still be in DT but allocations for CMA or GPUs would be in Passage. This idea is to reach a point where device tree is a "pristine" hardware description. Cheers PS: as Ilias mentions, this patch set contains bug fixes, non immediately related additional functions (DM stats). It would be great to carve those out to fast path them and keep this one with the very core of your idea. On Mon, 1 Nov 2021 at 02:17, Simon Glass wrote: > > This series adds a standard way of passing information between different > firmware phases. This already exists in U-Boot at a very basic level, in > the form of a bloblist containing an spl_handoff structure, but the intent > here is to define something useful across projects. > > The need for this is growing as firmware fragments into multiple binaries > each with its own purpose. Without any run-time connection, we must rely > on build-time settings which are brittle and painful to keep in sync. > > This feature is named 'standard passage' since the name is more unique > than many others that could be chosen, it is a passage in the sense that > information is flowing from one place to another and it is standard, > because that is what we want to create. > > The implementation is simply a pointer to a bloblist in a register, with > an extra register to point to a devicetree, for more complex data, if one > is present in the bloblist. This should cover all cases (small memory > footprint as well as complex data flow) and be easy enough to implement on > all architectures. > > The core bloblist code is relicensed to BSD-3-Clause in case it is useful > in non-GPL projects but there is no requirement to use the same code. > > This series includes tweaks to the bloblist implementation in U-Boot to > make it more suitable for the task, including: > >- Allocate tags explicitly in the enum >- Put the magic number first >- Define a process for adding tags > > The emphasis is on enabling open communcation between binaries, not > enabling passage of secret, undocumented data, although this is possible > in a private environment. > > This series is built on the OF_BOARD series It is available at > u-boot-dm/pass-working or: > > > https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222c69a98b8ebcaa563d1ff10eb217 > > > Simon Glass (31): > Makefile: Correct TPL rule for OF_REAL > kconfig: Add support for conditional values > dm: core: Allow getting some basic stats > stddef: Avoid warning with clang with offsetof() > fdt: Drop SPL_BUILD macro > bloblist: Put the magic number first > bloblist: Rename the SPL tag > bloblist: Drop unused tags > bloblist: Use explicit numbering for the tags > bloblist: Support allocating the bloblist > bloblist: Use LOG_CATEGORY to simply logging > bloblist: Use 'phase' consistently for bloblists > bloblist: Refactor Kconfig to support alloc or fixed > arm: qemu: Add an SPL build > bloblist: Add functions to obtain base address and size > passage: Support an incoming passage > passage: Support a control devicetree > passage: arm: Accept a passage from the previous phase > passage: spl: Support adding the dtb to the passage bloblist > passage: spl: Support passing the passage to U-Boot > passage: Record where the devicetree came from > passage: Report the devicetree source > passage: Add a qemu test for ARM > bloblist: doc: Bring in the API documentation > bloblist: Relicense to allow BSD-3-Clause > sandbox: Add a way of checking structs for standard passage > passage: Add documentation > passage: Add docs for spl_handoff > x86: Move Intel GNVS file into the common include directory > passage: Add checks for pre-existing blobs > WIP: RFC: Add a gitlab test > > .gitlab-ci.yml| 6 + > MAINTAINERS
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon (I keep getting messages about delivery problems so I don't know what went through or not) On Wed, 27 Oct 2021 at 21:52, Simon Glass wrote: > > Hi Ilias, > > On Wed, 27 Oct 2021 at 13:13, Ilias Apalodimas > wrote: > > > > On Wed, 27 Oct 2021 at 21:33, Simon Glass wrote: > > > > > > Hi François, > > > > > > On Wed, 27 Oct 2021 at 09:38, François Ozog > > > wrote: > > > > > > > > Hi Simon, > > > > > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > > > >> wrote: > > > >> > > > > >> > > > > >> > > > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > > >> >> > > > >> >> Hi François, > > > >> >> > > > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog > > > >> >> wrote: > > > >> >> > > > > >> >> > Hi Simon, > > > >> >> > > > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > > > >> >> > wrote: > > > >> >> >> > > > >> >> >> At present some of the ideas and techniques behind devicetree in > > > >> >> >> U-Boot > > > >> >> >> are assumed, implied or unsaid. Add some documentation to cover > > > >> >> >> how > > > >> >> >> devicetree is build, how it can be modified and the rules about > > > >> >> >> using > > > >> >> >> the various CONFIG_OF_... options. > > > >> >> >> > > > >> > > > >> [..] > > > >> > > > >> >> >> +Why not have two devicetrees? > > > >> >> >> +- > > > >> >> >> + > > > >> >> >> +Setting aside the argument for restricting U-Boot from having > > > >> >> >> its own nodes and > > > >> >> >> +properties, another idea proposed is to have two devicetrees, > > > >> >> >> one for the > > > >> >> >> +U-Boot-specific bits (here called `special`) and one for > > > >> >> >> everything else (here > > > >> >> >> +called `linux`). > > > >> >> >> + > > > >> >> >> +On the positive side, it might quieten the discussion alluded > > > >> >> >> to in the section > > > >> >> >> +above. But there are many negatives to consider and many open > > > >> >> >> questions to > > > >> >> >> +resolve. > > > >> >> >> + > > > >> >> >> +- **Bindings** - Presumably the special devicetree would have > > > >> >> >> its own bindings. > > > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > > > >> >> >> anything. People coming > > > >> >> >> + across the devicetree source would wonder how it fits in with > > > >> >> >> the Linux > > > >> >> >> + devicetree. > > > >> >> >> + > > > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > > >> >> >> devicetree. This > > > >> >> >> + would need to be expanded to support two trees. Features > > > >> >> >> which need to access > > > >> >> >> + both (such as a device driver which reads the special > > > >> >> >> devicetree to get some > > > >> >> >> + configuration info) could become quite confusing to read and > > > >> >> >> write. > > > >> >> >> + > > > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > > > >> >> >> desires it? If > > > >> >> >> + so, how is this managed in tooling? Does it happen during the > > > >> >> >> build, in which > >
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom Le jeu. 28 oct. 2021 à 20:27, Tom Rini a écrit : > On Thu, Oct 28, 2021 at 08:17:50PM +0200, François Ozog wrote: > > Hi Tom, > > > > Le jeu. 28 oct. 2021 à 19:59, Tom Rini a écrit : > > > > > On Thu, Oct 28, 2021 at 06:50:02PM +0100, Peter Robinson wrote: > > > > On Thu, Oct 28, 2021 at 6:47 PM Tom Rini wrote: > > > > > > > > > > On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote: > > > > > > On Wed, Oct 27, 2021 at 3:11 PM Simon Glass > > > wrote: > > > > > > > > > > > > > > Hi Heinrich, > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/24/21 01:25, Simon Glass wrote: > > > > > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > > > automatically > > > > > > > > > boot an Operating System without custom scripting and other > > > customisation. > > > > > > > > > This is called 'standard boot' since it provides a standard > > > way for > > > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > > > > > > - bootdev - a device which can hold a distro > > > > > > > > > - bootmeth - a method to scan a bootdev to find > bootflows > > > (owned by > > > > > > > > > U-Boot) > > > > > > > > > - bootflow - a description of how to boot (owned by the > > > distro) > > > > > > > > > > > > > > > > Please, describe why you are suggesting this change. > > > > > > > > > > > > > > > > Replacing a script by a devicetree chunk is just decreasing > > > flexibility > > > > > > > > and increasing complexity. Where is the benefit? > > > > > > > > > > > > > > > > I am missing a description here of where and how a boot flow > > > shall be > > > > > > > > defined. Describing some device-tree binding in patch 40/41 > does > > > not > > > > > > > > replace describing the development and usage workflow. Who > will > > > provide > > > > > > > > which bootflow information when? > > > > > > > > > > > > > > > > You still have an open discussion with Linaro about the > source of > > > > > > > > devicetrees. This discussion needs to be finalized before > > > considering > > > > > > > > this series. > > > > > > > > > > > > > > > > In my view bootflows cannot be defined in the devicetree > because > > > prior > > > > > > > > firmware providing a devicetree is completely independent of > any > > > distro > > > > > > > > and therefore cannot provide a distro specific bootflow. > > > > > > > > > > > > > > There is actually no need to use devicetree here. I think you > might > > > > > > > have the wrong end of the stick. It is certainly possible to > add > > > nodes > > > > > > > to configure things, if needed, but it works find without any > > > changes > > > > > > > to the devicetree, as you can see from the rpi_3 patch. > > > > > > > > > > > > > > There are several aims with this effort: > > > > > > > > > > > > > > - Provide a standard way to boot anything on U-Boot, that > everyone > > > can > > > > > > > plug into (distros, board vendors, people using a custom flow) > > > > > > > > > > > > I as a distro maintainer don't want this, we already get the > > > "standard > > > > > > way to boot" from UEFI, this just feels like another unnecessary > > > > > > abstraction to that. > > > > > > > > > > Right. But part of the problem is "How do I find UEFI". Something > > > > > somewhere needs to be configurable to say where to look, yes? > > > > > > > > Is this question from the board PoV, the developer of U-Boot or the > > > > distro trying to boot? > > > > > > > > If you mean from a boot flow PoV for UEFI to find the HW that > contains > > > > the OS to boot I thought that was handled elsewhere in the series. > > > > > > What I mean is that today looking at Pi we have: > > > #define BOOT_TARGET_DEVICES(func) \ > > > BOOT_TARGET_MMC(func) \ > > > BOOT_TARGET_USB(func) \ > > > BOOT_TARGET_PXE(func) \ > > > BOOT_TARGET_DHCP(func) > > > > > > As the board maintainer set that as the list of places to start looking > > > for the next payload (say the GRUB EFI binary). Simon's series > replaces > > > that with I think he said "bootflow scan -b". And then the above env > > > portion is replaced with, well, what's documented in patch #40 if you > > > don't just want to rely on device probe order. > > > > > > Because we need to have _something_ that says where to look for what, > > > yes? > > > > Shouldn’t we describe the user point of view ? > > No, because to extend the x86 metaphor we're talking about the defaults > here, not what the user has configured later on. The user has and > continues to be able to configure the system afterwards, if desired. > Sorry , missed this “detail”… > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom, Le jeu. 28 oct. 2021 à 19:59, Tom Rini a écrit : > On Thu, Oct 28, 2021 at 06:50:02PM +0100, Peter Robinson wrote: > > On Thu, Oct 28, 2021 at 6:47 PM Tom Rini wrote: > > > > > > On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote: > > > > On Wed, Oct 27, 2021 at 3:11 PM Simon Glass > wrote: > > > > > > > > > > Hi Heinrich, > > > > > > > > > > On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 10/24/21 01:25, Simon Glass wrote: > > > > > > > > > > > > > > The bootflow feature provide a built-in way for U-Boot to > automatically > > > > > > > boot an Operating System without custom scripting and other > customisation. > > > > > > > This is called 'standard boot' since it provides a standard > way for > > > > > > > U-Boot to boot a distro, without scripting. > > > > > > > > > > > > > > It introduces the following concepts: > > > > > > > > > > > > > > - bootdev - a device which can hold a distro > > > > > > > - bootmeth - a method to scan a bootdev to find bootflows > (owned by > > > > > > > U-Boot) > > > > > > > - bootflow - a description of how to boot (owned by the > distro) > > > > > > > > > > > > Please, describe why you are suggesting this change. > > > > > > > > > > > > Replacing a script by a devicetree chunk is just decreasing > flexibility > > > > > > and increasing complexity. Where is the benefit? > > > > > > > > > > > > I am missing a description here of where and how a boot flow > shall be > > > > > > defined. Describing some device-tree binding in patch 40/41 does > not > > > > > > replace describing the development and usage workflow. Who will > provide > > > > > > which bootflow information when? > > > > > > > > > > > > You still have an open discussion with Linaro about the source of > > > > > > devicetrees. This discussion needs to be finalized before > considering > > > > > > this series. > > > > > > > > > > > > In my view bootflows cannot be defined in the devicetree because > prior > > > > > > firmware providing a devicetree is completely independent of any > distro > > > > > > and therefore cannot provide a distro specific bootflow. > > > > > > > > > > There is actually no need to use devicetree here. I think you might > > > > > have the wrong end of the stick. It is certainly possible to add > nodes > > > > > to configure things, if needed, but it works find without any > changes > > > > > to the devicetree, as you can see from the rpi_3 patch. > > > > > > > > > > There are several aims with this effort: > > > > > > > > > > - Provide a standard way to boot anything on U-Boot, that everyone > can > > > > > plug into (distros, board vendors, people using a custom flow) > > > > > > > > I as a distro maintainer don't want this, we already get the > "standard > > > > way to boot" from UEFI, this just feels like another unnecessary > > > > abstraction to that. > > > > > > Right. But part of the problem is "How do I find UEFI". Something > > > somewhere needs to be configurable to say where to look, yes? > > > > Is this question from the board PoV, the developer of U-Boot or the > > distro trying to boot? > > > > If you mean from a boot flow PoV for UEFI to find the HW that contains > > the OS to boot I thought that was handled elsewhere in the series. > > What I mean is that today looking at Pi we have: > #define BOOT_TARGET_DEVICES(func) \ > BOOT_TARGET_MMC(func) \ > BOOT_TARGET_USB(func) \ > BOOT_TARGET_PXE(func) \ > BOOT_TARGET_DHCP(func) > > As the board maintainer set that as the list of places to start looking > for the next payload (say the GRUB EFI binary). Simon's series replaces > that with I think he said "bootflow scan -b". And then the above env > portion is replaced with, well, what's documented in patch #40 if you > don't just want to rely on device probe order. > > Because we need to have _something_ that says where to look for what, > yes? Shouldn’t we describe the user point of view ? Even before EFI existed on x86 it went like (this is not intending to be exhaustive or even exact): Start a non installed system: the boot goes through a device list much like distro_boot_CMd works except if the user select a manual boot selection (the boot devices goes into a menu) When the installer finishes it “informs” the firmware with the desired boot target. When the OS runs it can select the next boot (transient or permanent) option. This usually involves grub rather than firmware but the user can decide if the boot target change is driven by the firmware. (For SystemReady we want to have an option to live without shim and grub so the boot target change will involve setting Boot.) I think it is first important to describe the observable behavior before jumping into implementation. Scenarios involving développer systems may be different from the ones for consumer products. Or should that be replaced entirely with efi vars
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon
Le jeu. 28 oct. 2021 à 17:44, Simon Glass a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 08:50, François Ozog
> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass a écrit :
> >>
> >> Hi François,
> >>
> >> On Thu, 28 Oct 2021 at 02:21, François Ozog
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit
> :
> >> >>
> >> >> Hi Ilias,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> >> wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > A bit late to the party, sorry!
> >> >>
> >> >> (Did you remember the beer? I am replying to this but I don't think
> it
> >> >> is all that helpful for me to reply to a lot of things on this
> thread,
> >> >> since I would not be adding much to my cover letter and patches)
> >> >>
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > > >
> >> >> > > > I really want to see what the binary case looks like since we
> could then
> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> >> > > > then also do a rpi_arm32_defconfig too.
> >> >> > > >
> >> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> >> > > > functionally correct from the hardware/our caller.
> >> >> > > >
> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> >> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> >> > > > tree provided to us at run time by the caller.
> >> >> > >
> >> >> > > Firstly I should say that I find building firmware very messy and
> >> >> > > confusing these days. Lots of things to build and it's hard to
> find
> >> >> > > the instructions. It doesn't have to be that way, but if we
> carry on
> >> >> > > as we are, it will continue to be messy and in five years you
> will
> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> >> > > objective here is to simplify things, bringing some consistency
> to the
> >> >> > > different components. Binman was one effort there. I feel that
> putting
> >> >> > > at least the U-Boot house in order, in my role as devicetree
> >> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> >> > > 2011), is the next step.
> >> >> > >
> >> >> > > If we set things up correctly and agree on the bindings,
> devicetree
> >> >> > > can be the unifying configuration mechanism through the whole of
> >> >> > > firmware (except for very early bits) and into the OS, this will
> set
> >> >> > > us up very well to deal with the complexity that is coming.
> >> >> > >
> >> >> > > Anyway, here are the mental steps that I've gone through over
> the past
> >> >> > > two months:
> >> >> > >
> >> >> > > Step 1: At present, some people think U-Boot is not even allowed
> to
> >> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> >> > > devicetree standard, like the /chosen node but with less
> history. We
> >> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> >> > > of 'devicetree is a hardware description'. How do we get over
> that
> >> >> > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> >> >> > > for its own purposes, as well as for booting the OS. I am not
> saying
> >> >> > > it always has to have those properties, but with existing
> features
> >> >> > > like verified boot, SPL as well as complex firmware images where
> >> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> >> > > So let's just assume tha
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon
Le jeu. 28 oct. 2021 à 16:30, Simon Glass a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 02:21, François Ozog
> wrote:
> >
> > Hi Simon,
> >
> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit :
> >>
> >> Hi Ilias,
> >>
> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > A bit late to the party, sorry!
> >>
> >> (Did you remember the beer? I am replying to this but I don't think it
> >> is all that helpful for me to reply to a lot of things on this thread,
> >> since I would not be adding much to my cover letter and patches)
> >>
> >> >
> >> > [...]
> >> >
> >> > > >
> >> > > > I really want to see what the binary case looks like since we
> could then
> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> > > > then also do a rpi_arm32_defconfig too.
> >> > > >
> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> > > > functionally correct from the hardware/our caller.
> >> > > >
> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> > > > tree provided to us at run time by the caller.
> >> > >
> >> > > Firstly I should say that I find building firmware very messy and
> >> > > confusing these days. Lots of things to build and it's hard to find
> >> > > the instructions. It doesn't have to be that way, but if we carry on
> >> > > as we are, it will continue to be messy and in five years you will
> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> > > objective here is to simplify things, bringing some consistency to
> the
> >> > > different components. Binman was one effort there. I feel that
> putting
> >> > > at least the U-Boot house in order, in my role as devicetree
> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> > > 2011), is the next step.
> >> > >
> >> > > If we set things up correctly and agree on the bindings, devicetree
> >> > > can be the unifying configuration mechanism through the whole of
> >> > > firmware (except for very early bits) and into the OS, this will set
> >> > > us up very well to deal with the complexity that is coming.
> >> > >
> >> > > Anyway, here are the mental steps that I've gone through over the
> past
> >> > > two months:
> >> > >
> >> > > Step 1: At present, some people think U-Boot is not even allowed to
> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> > > devicetree standard, like the /chosen node but with less history. We
> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> > > of 'devicetree is a hardware description'. How do we get over that
> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> >> > > for its own purposes, as well as for booting the OS. I am not saying
> >> > > it always has to have those properties, but with existing features
> >> > > like verified boot, SPL as well as complex firmware images where
> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> > > So let's just assume that we need this everywhere, since we
> certainly
> >> > > need it in at least some places.
> >> > >
> >> > > (stop reading here if you disagree, because nothing below will make
> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> >> > > OF_CONTROL :-)
> >> >
> >> > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> >> > that to the DTs that are copied over from linux isn't imho. There are
> >> > various reasons for that. First of all syncing device trees is a
> huge pain
> >> > and that's probably one of the main reasons our DTs are out of sync
> for a
> >> > large number of boards.
> >> > The point is this was fine in 2011 were we had SPL
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon,
Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit :
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer? I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?
I am going to change my position in all mail threads I participate.
I was trying to make patches relevant in the future and conceptually clean.
That may not be the most effective position: I should just care about
Linaro and its members being able to implement SystemReady concepts.
If you mandate U-Boot has nodes in the device tree passed to the OS, we can
put DT fragment in the nt_fw_config section of the fip and merge it at
boot time. So there is a solution compatible with SystemReady.
If you
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Tom Le mer. 27 oct. 2021 à 21:06, Tom Rini a écrit : > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis > wrote: > > > > > > From: François Ozog > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini > > > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > > > s...@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > > > tr...@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > > > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > s...@chromium.org> wrote: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE > > > and > > > > > OF_HOSTFILE so > > > > > > > > > > >> > > > there are only three ways to obtain a > devicetree: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > > > devicetree > > > > > is built and > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > > > devicetree is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its > own > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > > > devicetree > > > > > is needed at all > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but > > > > > some don't. Some > > > > > > > > > > >> > > > don't even provide instructions on how to boot > on > > > the > > > > > board. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The problems with this approach are documented > at > > > [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from > > > > > OF_SEPARATE. Any board > >
Re: [PATCH v5 26/26] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
Hi Tom
Le mer. 27 oct. 2021 à 21:12, Tom Rini a écrit :
> On Wed, Oct 27, 2021 at 10:17:05AM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > On Tue, 26 Oct 2021 at 18:27, Simon Glass wrote:
> > >
> > > Hi Ilias,
> > >
> > > On Tue, 26 Oct 2021 at 07:56, Ilias Apalodimas
> > > wrote:
> > > >
> > > > Hi Simon,
> > > >
> > > > As I said here [1], this is moving on an entirely different
> direction I had
> > > > in mind. I'd much prefer starting the discussions for a solution that
> > > > allows us to scale.
> > >
> > > I am missing the point here. Is there something in the plans that I
> > > don't know about?
> >
> > I have some ideas, but haven't found time to code it and send patches
> yet.
> >
> > >
> > > > FWIW I think the current code is still not clean for my taste.
> Commit
> > > > 3b595da441cf ("fdtdec: allow board to provide fdt for
> CONFIG_OF_SEPARATE")
> > > > allowed this function to be used regardless of the config options.
> IMHO we
> > > > should have 2 clear options:
> > > > - U-Boot provides the DTB
> > >
> > > Supported with: OF_SEPARATE
> > >
> > > > - It's somehow passed over to U-Boot
> > >
> > > Supported with: OF_SEPARATE + OF_BOARD
> >
> > That's exactly what I don't personally like. In your example OF_BOARD
> > means "U-Boot has a DTB and here's a way to override it". In my head
>
> In some ways this is just highlighting a long standing problem of
> working with DTB. There's certainly been some places where splitting
> the data from the driver has helped. But in some other places, my
> goodness has it made the development cycle worse. Doing this on QEMU
> probably is on one of the most annoying cases too since yes, you start
> by dumping the dtb you would get, then iterating the dts outside of the
> rest of the scope of your build. In the kernel you can "make dtbs" at
> least and get things spit out. I'm just repeating over here that the
> development cycle of working on device trees is at times not great.
In general you do this only once, unless you use the virt machine and in
that case there is no documentation about DT generated for each device
added on the command line.
I had lots of difficulties getting all UART possibilities: virtio <1.0,
1.0,1.1; mmio or pci.
But once you get the command line, the dTB is fixed.
Of course it would be better to get Qemu document DT generation of its
devices.
>
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Tom Le mer. 27 oct. 2021 à 21:48, Tom Rini a écrit : > On Wed, Oct 27, 2021 at 05:38:28PM +0200, François Ozog wrote: > > Hi Simon, > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > > > > > Hi François, > > > > > > On Tue, 26 Oct 2021 at 09:57, François Ozog > > > wrote: > > > > > > > > > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > > > >> > > > >> Hi François, > > > >> > > > >> On Tue, 26 Oct 2021 at 08:31, François Ozog < > francois.o...@linaro.org> > > > wrote: > > > >> > > > > >> > Hi Simon, > > > >> > > > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > wrote: > > > >> >> > > > >> >> At present some of the ideas and techniques behind devicetree in > > > U-Boot > > > >> >> are assumed, implied or unsaid. Add some documentation to cover > how > > > >> >> devicetree is build, how it can be modified and the rules about > using > > > >> >> the various CONFIG_OF_... options. > > > >> >> > > > > > > [..] > > > > > > >> >> +Why not have two devicetrees? > > > >> >> +- > > > >> >> + > > > >> >> +Setting aside the argument for restricting U-Boot from having > its > > > own nodes and > > > >> >> +properties, another idea proposed is to have two devicetrees, > one > > > for the > > > >> >> +U-Boot-specific bits (here called `special`) and one for > everything > > > else (here > > > >> >> +called `linux`). > > > >> >> + > > > >> >> +On the positive side, it might quieten the discussion alluded > to in > > > the section > > > >> >> +above. But there are many negatives to consider and many open > > > questions to > > > >> >> +resolve. > > > >> >> + > > > >> >> +- **Bindings** - Presumably the special devicetree would have > its > > > own bindings. > > > >> >> + It would not be necessary to put a `u-boot,` prefix on > anything. > > > People coming > > > >> >> + across the devicetree source would wonder how it fits in with > the > > > Linux > > > >> >> + devicetree. > > > >> >> + > > > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > > > devicetree. This > > > >> >> + would need to be expanded to support two trees. Features which > > > need to access > > > >> >> + both (such as a device driver which reads the special > devicetree > > > to get some > > > >> >> + configuration info) could become quite confusing to read and > > > write. > > > >> >> + > > > >> >> +- **Merging** - Can the two devicetree be merged if a platform > > > desires it? If > > > >> >> + so, how is this managed in tooling? Does it happen during the > > > build, in which > > > >> >> + case they are not really separate at all. Or does U-Boot merge > > > them at > > > >> >> + runtime, in which case this adds time and memory? > > > >> >> + > > > >> >> +- **Efficiency** - A second device tree adds more code and more > > > code paths. It > > > >> >> + requires that both be made available to the code in U-Boot, > e.g. > > > via a > > > >> >> + separate pointer or argument or API. Overall the separation > would > > > certainly > > > >> >> + not speed up U-Boot, nor decrease its size. > > > >> >> + > > > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > > > pieces needed for > > > >> >> + U-Boot for a particular board. Would we use these same files > for > > > the special > > > >> >> + devicetree? > > > >> >> + > > > >> >> +- **Complexity** - Two devicetrees complicates the build system > > > since it must > > > >> >> + build and package them both. Errors must be reported in such a > > > w
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Simon Le mer. 27 oct. 2021 à 20:23, Simon Glass a écrit : > Hi François, > > On Wed, 27 Oct 2021 at 09:14, François Ozog > wrote: > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > wrote: > >> > > >> > Hi Simon > >> > > >> > Position unchanged on this series: adding fake dts for boards that > generate their device tree in the dts directory is not good. If you have > them in documentation the it is acceptable. > >> > >> I think we are going to have to disagree on this one. I actually used > >> the qemu one in testing/development recently. We have to have a way to > >> develop in-tree with U-Boot. It does not impinge on any of your use > >> cases, so far as I know. > > > > I am not the only one in disagreement... You just saw Alex Bénée from > Qemu saying the same thing. > > I understand the advanced debug/development scenario you mention. > > But locating the DT files in the dts directory is mis-leading the > contributors to think that they need to compile the DT for the targeted > platforms. > > For your advanced scenario, you can still have the dts in the > documentation area, or whatever directory (except dts). compile it and > supply to U-Boot. > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > has noticed. U-Boot handles the build automatically. If you turn off > OF_BOARD, it will use the U-Boot devicetree always so you know what is > going on. > > We can add a message to U-Boot indicating where the devicetree came > from, perhaps? That might be useful given everything that is going on. > > As in this case, quite often in these discussions I struggle to > understand what is behind the objection. Is it that your customers are > demanding that devicetrees become private, secret data, not included > in open-source projects? Or is it just the strange case of QEMU that > is informing your thinking? I know of at least one project where the > first-stage bootloader produces a devicetree and no one has the source > for it. I believe TF-A was created for licensing reasons...so can you > be a bit clearer about what the problem actually is? there are situations where U-Boot must have a dtb. Then those dTB sources are logically found in the dts directory. There are situations where U-Boot should not have a dtb. In that case there should be no element in the dts directory. Otherwise it creates confusion. Now as you point out, we need “playgrounds” to deal with some situation. So having examples in an ad-hoc directory, different from dts is fine. I proposed documentation but you may find a better place. In other words, dts shall host only dt source when U-Boot cannot do but make a dTB for a platform. As you have seen in different mail thread (firmware sustainability and OCP checklist) freedom is important to Linaro and there are no hidden Trojan horse for licensing. If a board is > in-tree in U-Boot I would like it to have a devicetree there, at least > until we have a better option. At the very least, it MUST be > discoverable and it must be possible to undertake U-Boot development > easily without a lot of messing around. You can if you keep two dts directories separate: dts for boards for which U-Boot must have one debug-dts for boards for which U-Boot get the DT at runtime but for which you want a playground for debug/easier development. > > >> > >> > >> But trying to do any driver / core work for a board where you don't > >> have the devicetree is currently not possible. The devicetree is a > >> core component and being unable to modify it is simply not practical. > >> We are talking here about an option that can be enabled or disabled. > >> In my case I am able to disable it locally and do my development work. > >> > >> > >> BTW I've got the bloblist handoff working with a devicetree inside it, > >> for qemu_arm. I need to try it on a real board to figure out what the > >> difference is. > >> > > That's great news and much needed for stabilizing the inbound ABI from > prior loader to U-Boot. Let's create another thread to discuss this > important topic. > >> > > My scenario is not all that advanced and I am using qemu_arm to test > the bloblist handoff stuff and include it in CI, with a suitable > devicetree and a binman node. > > Regards, > Simon > > >> > > >> > Cheers > >> > > >> > FF > >> > > >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass a écrit > : > >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, Le mer. 27 oct. 2021 à 20:33, Simon Glass a écrit : > Hi François, > > On Wed, 27 Oct 2021 at 09:38, François Ozog > wrote: > > > > Hi Simon, > > > > On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 09:57, François Ozog > wrote: > >> > > >> > > >> > > >> > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > >> >> > >> >> Hi François, > >> >> > >> >> On Tue, 26 Oct 2021 at 08:31, François Ozog < > francois.o...@linaro.org> wrote: > >> >> > > >> >> > Hi Simon, > >> >> > > >> >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass > wrote: > >> >> >> > >> >> >> At present some of the ideas and techniques behind devicetree in > U-Boot > >> >> >> are assumed, implied or unsaid. Add some documentation to cover > how > >> >> >> devicetree is build, how it can be modified and the rules about > using > >> >> >> the various CONFIG_OF_... options. > >> >> >> > >> > >> [..] > >> > >> >> >> +Why not have two devicetrees? > >> >> >> +- > >> >> >> + > >> >> >> +Setting aside the argument for restricting U-Boot from having > its own nodes and > >> >> >> +properties, another idea proposed is to have two devicetrees, > one for the > >> >> >> +U-Boot-specific bits (here called `special`) and one for > everything else (here > >> >> >> +called `linux`). > >> >> >> + > >> >> >> +On the positive side, it might quieten the discussion alluded to > in the section > >> >> >> +above. But there are many negatives to consider and many open > questions to > >> >> >> +resolve. > >> >> >> + > >> >> >> +- **Bindings** - Presumably the special devicetree would have > its own bindings. > >> >> >> + It would not be necessary to put a `u-boot,` prefix on > anything. People coming > >> >> >> + across the devicetree source would wonder how it fits in with > the Linux > >> >> >> + devicetree. > >> >> >> + > >> >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > devicetree. This > >> >> >> + would need to be expanded to support two trees. Features which > need to access > >> >> >> + both (such as a device driver which reads the special > devicetree to get some > >> >> >> + configuration info) could become quite confusing to read and > write. > >> >> >> + > >> >> >> +- **Merging** - Can the two devicetree be merged if a platform > desires it? If > >> >> >> + so, how is this managed in tooling? Does it happen during the > build, in which > >> >> >> + case they are not really separate at all. Or does U-Boot merge > them at > >> >> >> + runtime, in which case this adds time and memory? > >> >> >> + > >> >> >> +- **Efficiency** - A second device tree adds more code and more > code paths. It > >> >> >> + requires that both be made available to the code in U-Boot, > e.g. via a > >> >> >> + separate pointer or argument or API. Overall the separation > would certainly > >> >> >> + not speed up U-Boot, nor decrease its size. > >> >> >> + > >> >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > pieces needed for > >> >> >> + U-Boot for a particular board. Would we use these same files > for the special > >> >> >> + devicetree? > >> >> >> + > >> >> >> +- **Complexity** - Two devicetrees complicates the build system > since it must > >> >> >> + build and package them both. Errors must be reported in such a > way that it > >> >> >> + is obvious which one is failing. > >> >> >> + > >> >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > driver model > >> >> >> + are currently placed in the nodes they relate to. How wou
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Tom Le mer. 27 oct. 2021 à 20:06, Tom Rini a écrit : > On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis > wrote: > > > > > > > From: François Ozog > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > > > > > Hi, > > > > > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > > > Hi all, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini > wrote: > > > > > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass > wrote: > > > > > > > > > > Hi François, > > > > > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > s...@chromium.org> > > > > > a écrit : > > > > > > > > > > >> > > > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > > > >> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > tr...@konsulko.com> > > > > > wrote: > > > > > > > > > > >> > > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > > > >> > > Hi Simon, > > > > > > > > > > >> > > > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > > > s...@chromium.org> wrote: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped > OF_PRIOR_STAGE and > > > > > OF_HOSTFILE so > > > > > > > > > > >> > > > there are only three ways to obtain a > devicetree: > > > > > > > > > > >> > > > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > devicetree > > > > > is built and > > > > > > > > > > >> > > > appended to U-Boot > > > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > > > devicetree is embedded in > > > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its > own > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree > > > > > is needed at all > > > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, > but > > > > > some don't. Some > > > > > > > > > > >> > > > don't even provide instructions on how to boot > on the > > > > > board. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > The problems with this approach are documented > at [1]. > > > > > > > > > > >> > > > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct > from > > > > > OF_SEPARATE. Any board > > > > > > > > > > >> > > > can obtain its devicetree at runtime, even it > is has a >
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Mark, On Wed, 27 Oct 2021 at 17:10, Mark Kettenis wrote: > > From: François Ozog > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > > > Hi all, > > > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini > wrote: > > > > > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > > > Hi François, > > > > > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > > > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass < > s...@chromium.org> > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini < > tr...@konsulko.com> > > > wrote: > > > > > > > > >> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng > wrote: > > > > > > > > >> > > Hi Simon, > > > > > > > > >> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > > > s...@chromium.org> wrote: > > > > > > > > >> > > > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE > and > > > OF_HOSTFILE so > > > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > > > >> > > > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the > devicetree > > > is built and > > > > > > > > >> > > > appended to U-Boot > > > > > > > > >> > > >- OF_EMBED - for development purposes, the > > > devicetree is embedded in > > > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > > > > >> > > > > > > > > > > > >> > > > The last one is currently set up so that no > devicetree > > > is needed at all > > > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > > > some don't. Some > > > > > > > > >> > > > don't even provide instructions on how to boot on > the > > > board. > > > > > > > > >> > > > > > > > > > > > >> > > > The problems with this approach are documented at > [1]. > > > > > > > > >> > > > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > > > OF_SEPARATE. Any board > > > > > > > > >> > > > can obtain its devicetree at runtime, even it is > has a > > > devicetree built > > > > > > > > >> > > > in U-Boot. This is because U-Boot may be a > second-stage > > > bootloader and its > > > > > > > > >> > > > caller may have a better idea about the hardware > > > available in the machine. > > > > > > > > >> > > > This is the case with a few QEMU boards, for > example. > > > > > > > > >> > > > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a > 'choice'. It > > > should be an > > > > > > > > >> > > > option, available with either OF_SEPARATE or > OF_EMBED. > > > > > >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, On Wed, 27 Oct 2021 at 16:13, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 09:57, François Ozog > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > >> > >> Hi François, > >> > >> On Tue, 26 Oct 2021 at 08:31, François Ozog > wrote: > >> > > >> > Hi Simon, > >> > > >> > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> >> > >> >> At present some of the ideas and techniques behind devicetree in > U-Boot > >> >> are assumed, implied or unsaid. Add some documentation to cover how > >> >> devicetree is build, how it can be modified and the rules about using > >> >> the various CONFIG_OF_... options. > >> >> > > [..] > > >> >> +Why not have two devicetrees? > >> >> +- > >> >> + > >> >> +Setting aside the argument for restricting U-Boot from having its > own nodes and > >> >> +properties, another idea proposed is to have two devicetrees, one > for the > >> >> +U-Boot-specific bits (here called `special`) and one for everything > else (here > >> >> +called `linux`). > >> >> + > >> >> +On the positive side, it might quieten the discussion alluded to in > the section > >> >> +above. But there are many negatives to consider and many open > questions to > >> >> +resolve. > >> >> + > >> >> +- **Bindings** - Presumably the special devicetree would have its > own bindings. > >> >> + It would not be necessary to put a `u-boot,` prefix on anything. > People coming > >> >> + across the devicetree source would wonder how it fits in with the > Linux > >> >> + devicetree. > >> >> + > >> >> +- **Access** - U-Boot has a nice `ofnode` API for accessing the > devicetree. This > >> >> + would need to be expanded to support two trees. Features which > need to access > >> >> + both (such as a device driver which reads the special devicetree > to get some > >> >> + configuration info) could become quite confusing to read and > write. > >> >> + > >> >> +- **Merging** - Can the two devicetree be merged if a platform > desires it? If > >> >> + so, how is this managed in tooling? Does it happen during the > build, in which > >> >> + case they are not really separate at all. Or does U-Boot merge > them at > >> >> + runtime, in which case this adds time and memory? > >> >> + > >> >> +- **Efficiency** - A second device tree adds more code and more > code paths. It > >> >> + requires that both be made available to the code in U-Boot, e.g. > via a > >> >> + separate pointer or argument or API. Overall the separation would > certainly > >> >> + not speed up U-Boot, nor decrease its size. > >> >> + > >> >> +- **Source code** - At present `u-boot.dtsi` files provide the > pieces needed for > >> >> + U-Boot for a particular board. Would we use these same files for > the special > >> >> + devicetree? > >> >> + > >> >> +- **Complexity** - Two devicetrees complicates the build system > since it must > >> >> + build and package them both. Errors must be reported in such a > way that it > >> >> + is obvious which one is failing. > >> >> + > >> >> +- **Referencing each other** - The `u-boot,dm-xxx` tags used by > driver model > >> >> + are currently placed in the nodes they relate to. How would these > tags > >> >> + reference a node that is in a separate devicetree? What extra > validation would > >> >> + be needed? > >> >> + > >> >> +- **Storage** - How would the two devicetrees be stored in the > image? At present > >> >> + we simply concatenate the U-Boot binary and the devicetree. We > could add the > >> >> + special devicetree before the Linux one, so two are concatenated, > but it is > >> >> + not pretty. We could use binman to support more complex > arrangements, but only > >> >> + some boards use this at present, so it would be a big change. > >> >> + > >> >> +- **API** - How would another project provide two devicetree files > to U-Boot at > >> >&
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Heinrich, On Wed, 27 Oct 2021 at 13:38, Heinrich Schuchardt < heinrich.schucha...@canonical.com> wrote: > > > On 10/24/21 01:25, Simon Glass wrote: > > > > The bootflow feature provide a built-in way for U-Boot to automatically > > boot an Operating System without custom scripting and other > customisation. > > This is called 'standard boot' since it provides a standard way for > > U-Boot to boot a distro, without scripting. > > > > It introduces the following concepts: > > > > - bootdev - a device which can hold a distro > > - bootmeth - a method to scan a bootdev to find bootflows (owned by > > U-Boot) > > - bootflow - a description of how to boot (owned by the distro) > > Please, describe why you are suggesting this change. > > Replacing a script by a devicetree chunk is just decreasing flexibility > and increasing complexity. Where is the benefit? > > I am missing a description here of where and how a boot flow shall be > defined. Describing some device-tree binding in patch 40/41 does not > replace describing the development and usage workflow. Who will provide > which bootflow information when? > > You still have an open discussion with Linaro about the source of > devicetrees. This discussion needs to be finalized before considering > this series. > > In my view bootflows cannot be defined in the devicetree because prior > firmware providing a devicetree is completely independent of any distro > and therefore cannot provide a distro specific bootflow. > Agreed if we talk about the DT passed to the OS. There are discussions in System Device Tree to represent partition booting orchestration information in a System Device Tree. This information may end-up being integrated in "a" device tree that will be used only by hypervisor as dynamic config. The same applies to secure world partitions: manifest are declared in "a" device tree that is consumed only by secure hypervisor (hafnium for the moment) as dynamic configuration, passed as a separate entity from a FIP section (I think it is TOS_CONFIG) https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html The other pattern is firmware component DT binding can be standardized separately from platform device tree. > > Best regards > > Heinrich > > > > > This series provides an implementation of these, enabled to scan for > > bootflows from MMC, USB and Ethernet. It supports the existing distro > > boot as well as the EFI loader flow (bootefi/bootmgr). It works > > similiarly to the existing script-based approach, but is native to > > U-Boot. > > > > With this we can boot on a Raspberry Pi 3 with just one command: > > > > bootflow scan -lb > > > > which means to scan, listing (-l) each bootflow and trying to boot each > > one (-b). The final patch shows this. > > > > With a standard way to identify boot devices, booting become easier. It > > also should be possible to support U-Boot scripts, for backwards > > compatibility only. > > > > This series relies on the PXE clean-up series, posted here: > > > > https://patchwork.ozlabs.org/project/uboot/list/?series=267078 > > > > For documentation, see the 'doc' patch. > > > > For version 2, a new naming scheme is used as above: > > > > - bootdev is used instead of bootdevice, because 'device' is > overused, > > is everywhere in U-Boot, can be confused with udevice > > - bootmeth - because 'method' is too vanilla, appears 1300 times in > > U-Boot > > > > Also in version 2, drivers are introduced for the boot methods, to make > > it more extensible. Booting a custom OS is simply a matter of creating a > > bootmeth for it and implementing the read_file() and boot() methods. > > > > The design is described in these two documents: > > > > > https://drive.google.com/file/d/1ggW0KJpUOR__vBkj3l61L2dav4ZkNC12/view?usp=sharing > > > > > https://drive.google.com/file/d/1kTrflO9vvGlKp-ZH_jlgb9TY3WYG6FF9/view?usp=sharing > > > > The series is available at u-boot-dm/bme-working > > > > Sample log on rpi_3_32b: > > > > U-Boot 2021.10-rc2-00043-gccd453aa918-dirty (Aug 28 2021 - 13:58:46 > -0600) > > > > DRAM: 992 MiB > > RPI 3 Model B (0xa22082) > > MMC: mmc@7e202000: 0, sdhci@7e30: 1 > > Loading Environment from FAT... Unable to read "uboot.env" from > mmc0:1... In:serial > > Out: vidconsole > > Err: vidconsole > > Net: No ethernet found. > > starting USB... > > Bus usb@7e98: USB DWC2 > > scanning bus usb@7e98 for devices... usb_kbd usb_kbd: Timeout poll > on interrupt endpoint > > Failed to get keyboard state from device 0c40:8000 > > 4 USB Device(s) found > > scanning usb for storage devices... 0 Storage Device(s) found > > Hit any key to stop autoboot: 0 > > Scanning for bootflows in all bootmethods > > Seq Type State UclassPart Name > Filename > > --- --- -- > > > Scanning bootmethod
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 00:07, François Ozog > wrote: > > > > Hi Simon > > > > Position unchanged on this series: adding fake dts for boards that > generate their device tree in the dts directory is not good. If you have > them in documentation the it is acceptable. > > I think we are going to have to disagree on this one. I actually used > the qemu one in testing/development recently. We have to have a way to > develop in-tree with U-Boot. It does not impinge on any of your use > cases, so far as I know. > I am not the only one in disagreement... You just saw Alex Bénée from Qemu saying the same thing. I understand the advanced debug/development scenario you mention. But locating the DT files in the dts directory is mis-leading the contributors to think that they need to compile the DT for the targeted platforms. For your advanced scenario, you can still have the dts in the documentation area, or whatever directory (except dts). compile it and supply to U-Boot. > > But trying to do any driver / core work for a board where you don't > have the devicetree is currently not possible. The devicetree is a > core component and being unable to modify it is simply not practical. > We are talking here about an option that can be enabled or disabled. > In my case I am able to disable it locally and do my development work. > BTW I've got the bloblist handoff working with a devicetree inside it, > for qemu_arm. I need to try it on a real board to figure out what the > difference is. > > That's great news and much needed for stabilizing the inbound ABI from prior loader to U-Boot. Let's create another thread to discuss this important topic. > Regards, > Simon > > > > > > > > > > > Cheers > > > > FF > > > > Le mar. 26 oct. 2021 à 02:24, Simon Glass a écrit : > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >>- OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >>- OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >>- OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented in another patch in this > >> series: "doc: Add documentation about devicetree usage" > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > >> > >> Note: If board maintainers are able to add their own patch to add the > >> files, some patches in this series can be dropped. > >> > >> It also provides a few qemu clean-ups discovered along the way. > >> > >> Note: This breaks the qemu-riscv64_spl test, which still needs > >> investigation. > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> - Merge RISC-V and ARM patches since they are similar > >> - Add new patches to clean up fdtdec_setup() and surrounds > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (th
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
On Wed, 27 Oct 2021 at 15:38, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we
> could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry
> on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> the
> > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history.
> We
> > > > > should sacrifice efficiency, expedience and expandability on the
> altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not
> saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is
> essential.
> > > > > So let's just assume that we need this everywhere, since we
> certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> > > > that to the DTs that are copied over from linux isn't imho. There
> are
> > > > various reasons for that. First of all syncing device trees is a
> huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync
> for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > >NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > >been promised now that there's validat
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Tom,
On Wed, 27 Oct 2021 at 14:59, Tom Rini wrote:
> On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > A bit late to the party, sorry!
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
>
> This re-sync is only a pain because:
> 1. Some platforms have been modifying the core dts files LIKE THEY ARE
>NOT SUPPOSED TO.
> 2. DTS files are getting closer to being the super stable API that has
>been promised now that there's validation tools.
>
> Some SoCs, like stm32 are doing an amazing job and keeping things in
> sync, every release. Others like NXP are violating rule #1.
With NXP commitment to SystemReady on some IMX8 boards, I think this is
changing,
at least for the SystemReady boards.
> Still
> others like some TI platforms get bit by #2 (I solved one of these, and
> need to cycle back to the one you and I talked about on IRC a while
> back, I bet it's another node name dash changed to underbar).
>
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> If you are passing the full device tree around, a few more
> nodes/properties aren't going to make the situation worse. If we're
> talking about a 60 kilobyte blob one more kilobyte isn't where we call
> the line, especially since if we wait another 6 months it'll be a 62
> kilobyte file coming in from Linux instead.
>
This is not about size but about firmware supply chain organization.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi, On Wed, 27 Oct 2021 at 14:48, Tom Rini wrote: > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote: > > Hi all, > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini wrote: > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > > > Hi François, > > > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.o...@linaro.org> wrote: > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > a écrit : > > > > > > >> > > > > > > >> Hi Tom, Bin,François, > > > > > > >> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > wrote: > > > > > > >> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > > > >> > > Hi Simon, > > > > > > >> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass < > s...@chromium.org> wrote: > > > > > > >> > > > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > > > >> > > > there are only three ways to obtain a devicetree: > > > > > > >> > > > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree > is built and > > > > > > >> > > > appended to U-Boot > > > > > > >> > > >- OF_EMBED - for development purposes, the > devicetree is embedded in > > > > > > >> > > > the ELF file (also used for EFI) > > > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > > > >> > > > > > > > > > >> > > > The last one is currently set up so that no devicetree > is needed at all > > > > > > >> > > > in the U-Boot tree. Most boards do provide one, but > some don't. Some > > > > > > >> > > > don't even provide instructions on how to boot on the > board. > > > > > > >> > > > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > > > >> > > > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > > > >> > > > caller may have a better idea about the hardware > available in the machine. > > > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > > > >> > > > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > >> > > > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > > > >> > > > (and placeholders) to make the build work. > > > > > > >> > > > > > > > > >> > > Adding device trees that are never used sounds like a > hack to me. > > > > > > >> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > > > >> > > command line parameters, and the device tree you put in > this series > > > > > > >> > > has various hardcoded values which normally do > not show up > > > > > > >> > > in hand-written dts files. > > > > > > >> > > > > >
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
On Tue, 26 Oct 2021 at 17:27, Simon Glass wrote: > Hi François, > > On Tue, 26 Oct 2021 at 08:31, François Ozog > wrote: > > > > Hi Simon, > > > > On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > >> > >> At present some of the ideas and techniques behind devicetree in U-Boot > >> are assumed, implied or unsaid. Add some documentation to cover how > >> devicetree is build, how it can be modified and the rules about using > >> the various CONFIG_OF_... options. > >> > >> Signed-off-by: Simon Glass > >> Reviewed-by: Marcel Ziswiler > >> --- > >> This patch attracted quite a bit of discussion here: > >> > >> > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > >> > >> I have not included the text suggested by François. While I agree that > >> it would be useful to have an introduction in this space, I do not agree > >> that we should have two devicetrees or that U-Boot should not have its > own > >> things in the devicetree, so it is not clear to me what we should > actually > >> write. > >> > >> The 'Devicetree Control in U-Boot' docs were recently merged and these > >> provide some base info, for now. > >> > >> Changes in v5: > >> - Bring into the OF_BOARD series > >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > >> - Refer to the 'control' DTB in the first paragraph > >> - Use QEMU instead of qemu > >> > >> Changes in v3: > >> - Clarify the 'bug' refered to at the top > >> - Reword 'This means that there' paragraph to explain U-Boot-specific > things > >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > >> > >> Changes in v2: > >> - Fix typos per Sean (thank you!) and a few others > >> - Add a 'Use of U-Boot /config node' section > >> - Drop mention of dm-verity since that actually uses the kernel cmdline > >> - Explain that OF_BOARD will still work after these changes (in > >> 'Once this bug is fixed...' paragraph) > >> - Expand a bit on the reason why the 'Current situation' is bad > >> - Clarify in a second place that Linux and U-Boot use the same > devicetree > >> in 'To be clear, while U-Boot...' > >> - Expand on why we should have rules for other projects in > >> 'Devicetree in another project' > >> - Add a comment as to why devicetree in U-Boot is not 'bad design' > >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover > >> points raised on v1 > >> - Add 'Why does U-Boot have its nodes and properties?' > >> - Add 'Why not have two devicetrees?' > >> > >> doc/develop/devicetree/dt_update.rst | 556 +++ > >> doc/develop/devicetree/index.rst | 1 + > >> 2 files changed, 557 insertions(+) > >> create mode 100644 doc/develop/devicetree/dt_update.rst > >> > >> diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > >> new file mode 100644 > >> index 000..3d4902e3592 > >> --- /dev/null > >> +++ b/doc/develop/devicetree/dt_update.rst > >> @@ -0,0 +1,556 @@ > >> +.. SPDX-License-Identifier: GPL-2.0+ > >> + > >> +Updating the devicetree > >> +=== > >> + > >> +U-Boot uses devicetree for runtime configuration and storing required > blobs or > >> +any other information it needs to operate. This is called the 'control' > >> +devicetree since it controls U-Boot. It is possible to update the > control > >> +devicetree separately from actually building U-Boot. This provides a > good degree > >> +of control and flexibility for firmware that uses U-Boot in > conjunction with > >> +other project. > >> + > >> +There are many reasons why it is useful to modify the devicetree after > building > >> +it: > >> + > >> +- Configuration can be changed, e.g. which UART to use > >> +- A serial number can be added > >> +- Public keys can be added to allow image verification > >> +- Console output can be changed (e.g. to select serial or vidconsole) > >> + > >> +This section describes how to work with devicetree to accomplish your > goals. > >> + > >> +See also :doc:`../devicetree/control` for a basic summary of the
Re: [PATCH v5 02/26] doc: Add documentation about devicetree usage
Hi Simon, On Tue, 26 Oct 2021 at 02:25, Simon Glass wrote: > At present some of the ideas and techniques behind devicetree in U-Boot > are assumed, implied or unsaid. Add some documentation to cover how > devicetree is build, how it can be modified and the rules about using > the various CONFIG_OF_... options. > > Signed-off-by: Simon Glass > Reviewed-by: Marcel Ziswiler > --- > This patch attracted quite a bit of discussion here: > > > https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ > > I have not included the text suggested by François. While I agree that > it would be useful to have an introduction in this space, I do not agree > that we should have two devicetrees or that U-Boot should not have its own > things in the devicetree, so it is not clear to me what we should actually > write. > > The 'Devicetree Control in U-Boot' docs were recently merged and these > provide some base info, for now. > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > doc/develop/devicetree/dt_update.rst | 556 +++ > doc/develop/devicetree/index.rst | 1 + > 2 files changed, 557 insertions(+) > create mode 100644 doc/develop/devicetree/dt_update.rst > > diff --git a/doc/develop/devicetree/dt_update.rst > b/doc/develop/devicetree/dt_update.rst > new file mode 100644 > index 000..3d4902e3592 > --- /dev/null > +++ b/doc/develop/devicetree/dt_update.rst > @@ -0,0 +1,556 @@ > +.. SPDX-License-Identifier: GPL-2.0+ > + > +Updating the devicetree > +=== > + > +U-Boot uses devicetree for runtime configuration and storing required > blobs or > +any other information it needs to operate. This is called the 'control' > +devicetree since it controls U-Boot. It is possible to update the control > +devicetree separately from actually building U-Boot. This provides a good > degree > +of control and flexibility for firmware that uses U-Boot in conjunction > with > +other project. > + > +There are many reasons why it is useful to modify the devicetree after > building > +it: > + > +- Configuration can be changed, e.g. which UART to use > +- A serial number can be added > +- Public keys can be added to allow image verification > +- Console output can be changed (e.g. to select serial or vidconsole) > + > +This section describes how to work with devicetree to accomplish your > goals. > + > +See also :doc:`../devicetree/control` for a basic summary of the available > +features. > + > + > +Devicetree source > +- > + > +Every board in U-Boot must include a devicetree sufficient to build and > boot > +that board on suitable hardware (or emulation). This is specified using > the > +`CONFIG DEFAULT_DEVICE_TREE` option. > + > + > +Current situation (October 2021) > +~~ > + > +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be > empty, > +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an > enormous > +amount of confusion and some wasted effort. This was not intended. > Support for > +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. > + > +Some of the problems created are: > + > +- It is not obvious that the devicetree is coming from another project > + > +- There is no way to see even a sample devicetree for these platform in > U-Boot, > + so it is hard to know what is going on, e.g. which devices are typically > + present > + > +- The other project may not provide a way to support U-Boot's > requirements for > + devicetree, such as the /config node. Note: On the U-Boot mailing > linst, this > + was only discovered after weeks of discussion and confusion > + > +- For QEMU
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Simon Position unchanged on this series: adding fake dts for boards that generate their device tree in the dts directory is not good. If you have them in documentation the it is acceptable. Cheers FF Le mar. 26 oct. 2021 à 02:24, Simon Glass a écrit : > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > there are only three ways to obtain a devicetree: > >- OF_SEPARATE - the normal way, where the devicetree is built and > appended to U-Boot >- OF_EMBED - for development purposes, the devicetree is embedded in > the ELF file (also used for EFI) >- OF_BOARD - the board figures it out on its own > > The last one is currently set up so that no devicetree is needed at all > in the U-Boot tree. Most boards do provide one, but some don't. Some > don't even provide instructions on how to boot on the board. > > The problems with this approach are documented in another patch in this > series: "doc: Add documentation about devicetree usage" > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > can obtain its devicetree at runtime, even it is has a devicetree built > in U-Boot. This is because U-Boot may be a second-stage bootloader and its > caller may have a better idea about the hardware available in the machine. > This is the case with a few QEMU boards, for example. > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > option, available with either OF_SEPARATE or OF_EMBED. > > This series makes this change, adding various missing devicetree files > (and placeholders) to make the build work. > > Note: If board maintainers are able to add their own patch to add the > files, some patches in this series can be dropped. > > It also provides a few qemu clean-ups discovered along the way. > > Note: This breaks the qemu-riscv64_spl test, which still needs > investigation. > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > Changes in v5: > - Bring into the OF_BOARD series > - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed > - Refer to the 'control' DTB in the first paragraph > - Use QEMU instead of qemu > - Merge RISC-V and ARM patches since they are similar > - Add new patches to clean up fdtdec_setup() and surrounds > > Changes in v3: > - Clarify the 'bug' refered to at the top > - Reword 'This means that there' paragraph to explain U-Boot-specific > things > - Move to doc/develop/devicetree now that OF_CONTROL is in the docs > > Changes in v2: > - Fix typos per Sean (thank you!) and a few others > - Add a 'Use of U-Boot /config node' section > - Drop mention of dm-verity since that actually uses the kernel cmdline > - Explain that OF_BOARD will still work after these changes (in > 'Once this bug is fixed...' paragraph) > - Expand a bit on the reason why the 'Current situation' is bad > - Clarify in a second place that Linux and U-Boot use the same devicetree > in 'To be clear, while U-Boot...' > - Expand on why we should have rules for other projects in > 'Devicetree in another project' > - Add a comment as to why devicetree in U-Boot is not 'bad design' > - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' > - Rewrite 'Devicetree generated on-the-fly in another project' to cover > points raised on v1 > - Add 'Why does U-Boot have its nodes and properties?' > - Add 'Why not have two devicetrees?' > > Ilias Apalodimas (1): > sandbox: Remove OF_HOSTFILE > > Simon Glass (25): > doc: Add documentation about devicetree usage > arm: qemu: Mention -nographic in the docs > arm: riscv: qemu: Explain how to extract the generated dt > arm: qemu: Add a devicetree file for qemu_arm > arm: qemu: Add a devicetree file for qemu_arm64 > riscv: qemu: Add devicetree files for qemu_riscv32/64 > arm: rpi: Add a devicetree file for rpi_4 > arm: vexpress: Add a devicetree file for juno > arm: xenguest_arm64: Add a fake devicetree file > arm: octeontx: Add a fake devicetree file > arm: xilinx_versal_virt: Add a devicetree file > arm: bcm7xxx: Add a devicetree file > arm: qemu-ppce500: Add a devicetree file > arm: highbank: Add a fake devicetree file > fdt: Make OF_BOARD a bool option > Drop CONFIG_BINMAN_STANDALONE_FDT > doc: Update info on devicetree update > fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() > fdt: Drop #ifdefs with MULTI_DTB_FIT > fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() > fdt: Drop #ifdef around board_fdt_blob_setup() > fdt: Use if() for fdtcontroladdr check > fdt: Drop OF_CONTROL check in fdtdec_setup() > fdt: Drop remaining preprocessor macros in fdtdec_setup() > fdt: Don't call board_fdt_blob_setup() without OF_BOARD > > Makefile |7 +- > arch/arm/dts/Makefile | 20 +- > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 + > arch/arm/dts/bcm7xxx.dts | 15 + >
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Le lun. 25 oct. 2021 à 09:05, Masami Hiramatsu
a écrit :
> Hi Francois,
>
> 2021年10月25日(月) 15:28 François Ozog :
> >
> >
> >
> > Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro <
> takahiro.aka...@linaro.org> a écrit :
> >>
> >> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
> >> > Hi Masami,
> >> >
> >> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
> >> > wrote:
> >> > >
> >> > > Hi Simon,
> >> > >
> >> > > 2021年10月15日(金) 9:40 Simon Glass :
> >> > > >
> >> > > > Hi Takahiro,
> >> > > >
> >> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro <
> takahiro.aka...@linaro.org> wrote:
> >> > > > >
> >> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature
> from DTB to
> >> > > > > .rodata"") failed to revert the removal of
> efi_get_public_key_data().
> >> > > > >
> >> > > > > Add back this function and move it under lib/efi_loader so that
> other
> >> > > > > platforms can utilize it. It is now declared as a weak function
> so that
> >> > > > > it can be replaced with a platform-specific implementation.
> >> > > > >
> >> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from
> DTB to
> >> > > > > .rodata"")
> >> > > > > Signed-off-by: AKASHI Takahiro
> >> > > > > ---
> >> > > > > lib/efi_loader/efi_capsule.c | 36
>
> >> > > > > 1 file changed, 36 insertions(+)
> >> > > > >
> >> > > > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> >> > > > > index b75e4bcba1a9..44f5da61a9be 100644
> >> > > > > --- a/lib/efi_loader/efi_capsule.c
> >> > > > > +++ b/lib/efi_loader/efi_capsule.c
> >> > > > > @@ -11,15 +11,20 @@
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > +#include
> >> > > > > +#include
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > > +#include
> >> > > > >
> >> > > > > #include
> >> > > > > #include
> >> > > > > #include
> >> > > > >
> >> > > > > +DECLARE_GLOBAL_DATA_PTR;
> >> > > > > +
> >> > > > > const efi_guid_t efi_guid_capsule_report =
> EFI_CAPSULE_REPORT_GUID;
> >> > > > > static const efi_guid_t
> efi_guid_firmware_management_capsule_id =
> >> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> >> > > > > @@ -251,6 +256,37 @@ out:
> >> > > > > }
> >> > > > >
> >> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> >> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
> *pkey_len)
> >> > > >
> >> > > > I don't think this should be weak. What other way is there of
> handling
> >> > > > this and why would it be platform-specific?
> >> > >
> >> > > I have a question about the current design of the capsule auth key.
> >> > > If the platform has its own key-storage, how can the platform use
> the
> >> > > platform specific storage? Does such platform load the key from the
> storage
> >> > > and generate the dtb node in the platform initialization code? (or
> >> > > device driver?)
> >> >
> >> > Are we talking about a public key (which I assume from the function
> >> > naming) or some secret key. What is an auth key?
> >>
> >> Surely, a public key (more strictly, x509 certificate under the current
> >> implementation)
> >>
> >> > As I understand it, the public key should be provided by the platform
> >> > in devicetree that U-Boot uses, by whatever prior stage has access to
> >> > the key.
> >>
> >> I still believe t
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Le lun. 25 oct. 2021 à 07:14, AKASHI Takahiro
a écrit :
> On Wed, Oct 20, 2021 at 07:39:37AM -0600, Simon Glass wrote:
> > Hi Masami,
> >
> > On Wed, 20 Oct 2021 at 02:18, Masami Hiramatsu
> > wrote:
> > >
> > > Hi Simon,
> > >
> > > 2021年10月15日(金) 9:40 Simon Glass :
> > > >
> > > > Hi Takahiro,
> > > >
> > > > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro <
> takahiro.aka...@linaro.org> wrote:
> > > > >
> > > > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from
> DTB to
> > > > > .rodata"") failed to revert the removal of
> efi_get_public_key_data().
> > > > >
> > > > > Add back this function and move it under lib/efi_loader so that
> other
> > > > > platforms can utilize it. It is now declared as a weak function so
> that
> > > > > it can be replaced with a platform-specific implementation.
> > > > >
> > > > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB
> to
> > > > > .rodata"")
> > > > > Signed-off-by: AKASHI Takahiro
> > > > > ---
> > > > > lib/efi_loader/efi_capsule.c | 36
>
> > > > > 1 file changed, 36 insertions(+)
> > > > >
> > > > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> > > > > index b75e4bcba1a9..44f5da61a9be 100644
> > > > > --- a/lib/efi_loader/efi_capsule.c
> > > > > +++ b/lib/efi_loader/efi_capsule.c
> > > > > @@ -11,15 +11,20 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > > +#include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > #include
> > > > > #include
> > > > > #include
> > > > >
> > > > > +DECLARE_GLOBAL_DATA_PTR;
> > > > > +
> > > > > const efi_guid_t efi_guid_capsule_report =
> EFI_CAPSULE_REPORT_GUID;
> > > > > static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > > > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > > > @@ -251,6 +256,37 @@ out:
> > > > > }
> > > > >
> > > > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t
> *pkey_len)
> > > >
> > > > I don't think this should be weak. What other way is there of
> handling
> > > > this and why would it be platform-specific?
> > >
> > > I have a question about the current design of the capsule auth key.
> > > If the platform has its own key-storage, how can the platform use the
> > > platform specific storage? Does such platform load the key from the
> storage
> > > and generate the dtb node in the platform initialization code? (or
> > > device driver?)
> >
> > Are we talking about a public key (which I assume from the function
> > naming) or some secret key. What is an auth key?
>
> Surely, a public key (more strictly, x509 certificate under the current
> implementation)
>
> > As I understand it, the public key should be provided by the platform
> > in devicetree that U-Boot uses, by whatever prior stage has access to
> > the key.
>
> I still believe that some platform provider may want to save the key
> in a *safer* storage, which should be at least read-only for non-authorized
> writers.
indeed. And U-Boot may not be entitled at all to check the capsule
signature. For example updating SCP firmware with a key that is in secure
world and will never leave this world.
But if this issue (__weak or not) is the only blocking factor
> for my entire patch series, I'm willing to drop __weak for now since
> someone with production system may change it in the future when he has
> a good reason for that :)
If that need be….
>
> -Takahiro Akashi
>
>
> > Regards,
> > Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v4 03/11] efi_loader: capsule: add back efi_get_public_key_data()
Le mer. 20 oct. 2021 à 10:18, Masami Hiramatsu
a écrit :
> Hi Simon,
>
> 2021年10月15日(金) 9:40 Simon Glass :
> >
> > Hi Takahiro,
> >
> > On Thu, 7 Oct 2021 at 00:25, AKASHI Takahiro
> wrote:
> > >
> > > The commit 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB
> to
> > > .rodata"") failed to revert the removal of efi_get_public_key_data().
> > >
> > > Add back this function and move it under lib/efi_loader so that other
> > > platforms can utilize it. It is now declared as a weak function so that
> > > it can be replaced with a platform-specific implementation.
> > >
> > > Fixes: 47a25e81d35c ("Revert "efi_capsule: Move signature from DTB to
> > > .rodata"")
> > > Signed-off-by: AKASHI Takahiro
> > > ---
> > > lib/efi_loader/efi_capsule.c | 36
> > > 1 file changed, 36 insertions(+)
> > >
> > > diff --git a/lib/efi_loader/efi_capsule.c
> b/lib/efi_loader/efi_capsule.c
> > > index b75e4bcba1a9..44f5da61a9be 100644
> > > --- a/lib/efi_loader/efi_capsule.c
> > > +++ b/lib/efi_loader/efi_capsule.c
> > > @@ -11,15 +11,20 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > +#include
> > > #include
> > > #include
> > > #include
> > > #include
> > > +#include
> > >
> > > #include
> > > #include
> > > #include
> > >
> > > +DECLARE_GLOBAL_DATA_PTR;
> > > +
> > > const efi_guid_t efi_guid_capsule_report = EFI_CAPSULE_REPORT_GUID;
> > > static const efi_guid_t efi_guid_firmware_management_capsule_id =
> > > EFI_FIRMWARE_MANAGEMENT_CAPSULE_ID_GUID;
> > > @@ -251,6 +256,37 @@ out:
> > > }
> > >
> > > #if defined(CONFIG_EFI_CAPSULE_AUTHENTICATE)
> > > +int __weak efi_get_public_key_data(void **pkey, efi_uintn_t *pkey_len)
> >
> > I don't think this should be weak. What other way is there of handling
> > this and why would it be platform-specific?
>
> I have a question about the current design of the capsule auth key.
> If the platform has its own key-storage, how can the platform use the
> platform specific storage? Does such platform load the key from the storage
> and generate the dtb node in the platform initialization code? (or
> device driver?)
it depends on what the capsule contains.
If the capsule contains SCP firmware or secure firmware or TAs, U-Boot may
not be even allowed to see the key.
If the capsule contains U-Boot itself it may be again outside scope of
U-Boot because that may be secure firmware that verifies the signature. We
may allow U-Boot to update itself but the final say is the secure firmware
that may prevent the boot.
If the capsule contains device firmware then it may depend on the device:
secure device U-Boot can do anything, otherwise then it is to be decided by
U-Boot.
>
> Thank you,
>
>
> >
> > > +{
> > > + const void *fdt_blob = gd->fdt_blob;
> > > + const void *blob;
> > > + const char *cnode_name = "capsule-key";
> > > + const char *snode_name = "signature";
> > > + int sig_node;
> > > + int len;
> > > +
> > > + sig_node = fdt_subnode_offset(fdt_blob, 0, snode_name);
> > > + if (sig_node < 0) {
> > > + log_err("Unable to get signature node offset\n");
> > > +
> > > + return -FDT_ERR_NOTFOUND;
> > > + }
> > > +
> > > + blob = fdt_getprop(fdt_blob, sig_node, cnode_name, );
> > > +
> > > + if (!blob || len < 0) {
> > > + log_err("Unable to get capsule-key value\n");
> > > + *pkey = NULL;
> > > + *pkey_len = 0;
> > > +
> > > + return -FDT_ERR_NOTFOUND;
> > > + }
> > > +
> > > + *pkey = (void *)blob;
> > > + *pkey_len = len;
> > > +
> > > + return 0;
> > > +}
> > >
> > > efi_status_t efi_capsule_authenticate(const void *capsule,
> efi_uintn_t capsule_size,
> > > void **image, efi_uintn_t
> *image_size)
> > > --
> > > 2.33.0
> > >
> >
> > Regards,
> > Simon
>
>
>
> --
> Masami Hiramatsu
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: please help, "Ram disk image is corrupt or invalid" (qemu virt machine, arm64)
Hi
If you use the second argument to indicate the location of the initrd then
Linux will use device tree information to get the size of the initrd. That
information is probably absent or incorrect.
The initrd= in your command line is thus useless as you task U-boot to load
it.
You may want to consider the Arm defined SystemReady boot flow to avoid
issues and benefit from secure boot flow and future extensions. In the
SystemReady boot flow , the Linux efi stub asks uboot to load the initrd
and do not need devicectree metadata to get any location or size (this is
to reinforce the use of device tree for hardware description as opposed to
hacking all information sharing between boot stages).
Cheers
FF
Le mer. 13 oct. 2021 à 07:44, Chan Kim a écrit :
>
>
> Hello all,
>
>
>
> I can boot linux kernel using this command line.
>
> ${QEMU_DIR}/qemu-system-aarch64 -M ${QMACHINE} -cpu cortex-a72 -kernel
> ${LINUX_DIR}/arch/arm64/boot/Image -initrd ${BUSYBOX_DIR}/initramfs.cpio.gz
> --append "root=/dev/ram init=/init nokaslr earlycon ip=dhcp" -m 2048M
> -nographic -netdev user,id=n1 -device e1000,netdev=n1
>
>
>
> After reading some docs and getting helps, I tried u-boot.
>
> After loading Image (for arm64) and dtb.dtb, I could see the kernel booting
> to the final stage of deploying initramfs but it failed because I didn't
> give the initramfs.cpio.gz address. (I used "booti 0x4020 - 0x4000)
>
>
>
> So I added initramfs.cpio.gz under /opt/tftp, and loaded kernel, initramfs,
> and dbt on memory and gave "booti 0x4020 0x4200 0x4000",
> addresses are kernel, initramfs and dtb).
>
> Below is the log. (please see the final error message below)
>
>
>
> ++ /home/ckim/QEMU/qemu/build/aarch64-softmmu/qemu-system-aarch64 -M virt
> -bios u-boot.bin -cpu cortex-a57 -bios u-boot.bin -nographic -drive
> if=pflash,format=raw,index=1,file=envstore.img -netdev
> user,id=net0,tftp=/opt/tftp -device e1000,netdev=net0
>
>
>
>
>
> U-Boot 2021.10-00455-g50c84208ad (Oct 13 2021 - 12:58:40 +0900)
>
>
>
> DRAM: 128 MiB
>
> Flash: 64 MiB
>
> MMC:
>
> Loading Environment from Flash... *** Warning - bad CRC, using default
> environment
>
>
>
> In:pl011@900
>
> Out: pl011@900
>
> Err: pl011@900
>
> Net: e1000: 52:54:00:12:34:56
>
>eth0: e1000#0
>
> Hit any key to stop autoboot: 0
>
> starting USB...
>
> No working controllers found
>
> USB is stopped. Please issue 'usb start' first.
>
> scanning bus for devices...
>
>
>
> Device 0: unknown device
>
>
>
> Device 0: unknown device
>
> starting USB...
>
> No working controllers found
>
> BOOTP broadcast 1
>
> BOOTP broadcast 2
>
> BOOTP broadcast 3
>
> DHCP client bound to address 10.0.2.15 (1004 ms)
>
> Using e1000#0 device
>
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
>
> Filename 'boot.scr.uimg'.
>
> Load address: 0x4020
>
> Loading: *
>
> TFTP error: 'File not found' (1)
>
> Not retrying...
>
> BOOTP broadcast 1
>
> BOOTP broadcast 2
>
> BOOTP broadcast 3
>
> DHCP client bound to address 10.0.2.15 (1001 ms)
>
> Using e1000#0 device
>
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
>
> Filename 'boot.scr.uimg'.
>
> Load address: 0x4040
>
> Loading: *
>
> TFTP error: 'File not found' (1)
>
> Not retrying...
>
> => tftp 0x4000 dtb.dtb
>
> Using e1000#0 device
>
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
>
> Filename 'dtb.dtb'.
>
> Load address: 0x4000
>
> Loading: #
>
> #
>
> 963.9 KiB/s
>
> done
>
> Bytes transferred = 1048576 (10 hex)
>
> => tftp 0x4020 Image
>
> Using e1000#0 device
>
> TFTP from server 10.0.2.2; our IP address is 10.0.2.15
>
> Filename 'Image'.
>
> Load address: 0x4020
>
> Loading: #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
> #
>
>
Re: License: embed u-boot binary in FPGA bitstream
Hi Did you get an answer I missed ? There’s active discussion on DTB lifecycle. >From the Xilinx boards I am aware of, there is a Xilinx primary boot loader that then loads u-boot SPL and then U-Boot proper. My understanding is that you can attach the hardware description DTB with the bitstream and pass it across to U-Boot proper. Your build system can take a base board DTS and add the FPGA devices to it to generate the DTB. I’ll ask an FPGA expert to comment. Cheers FF Le jeu. 14 oct. 2021 à 16:18, Andreas Oetken a écrit : > Dear U-Boot experts, > > If I embed a u-boot binary into a FPGA bitstream (block memory) are > there any license issues? I can't release the FPGA hardware description > files. So the only alternative I could think of would be another small > bootloader loading the u-boot binary from an external non-volatile > memory. > > Thank you, > Best Regards, > Andreas > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v3 7/7] doc: board: apple: Add Apple M1 documentation
Le jeu. 14 oct. 2021 à 22:44, Simon Glass a écrit : > Hi Mark, > > On Thu, 14 Oct 2021 at 14:09, Mark Kettenis > wrote: > > > > > From: Simon Glass > > > Date: Mon, 11 Oct 2021 11:01:20 -0600 > > > > > > Hi Mark, > > > > > > On Mon, 11 Oct 2021 at 10:40, Mark Kettenis > wrote: > > > > > > > > Provide preliminary instructions on how to get U-Boot to run on > > > > Apple Silicon Macs. > > > > > > > > > > Please can you add a change log to this patch? Patman will do it for > you. > > > > Sorry, I'm confused. The changelog is on the cover letter. This > > particular patch did not change at all... > > OK perhaps that is why I am confused too...it is better to have the > change log on each patch as well. > > Regards, > Simon hey guys , that’s really a cool thing ! > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le mer. 13 oct. 2021 à 20:06, Simon Glass a écrit : > Hi François, > > On Wed, 13 Oct 2021 at 11:35, François Ozog > wrote: > > > > Hi Simon > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : > >> > >> Hi Tom, Bin,François, > >> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > >> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > >> > > Hi Simon, > >> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > wrote: > >> > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > >> > > > there are only three ways to obtain a devicetree: > >> > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is built > and > >> > > > appended to U-Boot > >> > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > >> > > > the ELF file (also used for EFI) > >> > > >- OF_BOARD - the board figures it out on its own > >> > > > > >> > > > The last one is currently set up so that no devicetree is needed > at all > >> > > > in the U-Boot tree. Most boards do provide one, but some don't. > Some > >> > > > don't even provide instructions on how to boot on the board. > >> > > > > >> > > > The problems with this approach are documented at [1]. > >> > > > > >> > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. > Any board > >> > > > can obtain its devicetree at runtime, even it is has a devicetree > built > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > >> > > > caller may have a better idea about the hardware available in the > machine. > >> > > > This is the case with a few QEMU boards, for example. > >> > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be > an > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > >> > > > > >> > > > This series makes this change, adding various missing devicetree > files > >> > > > (and placeholders) to make the build work. > >> > > > >> > > Adding device trees that are never used sounds like a hack to me. > >> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on > >> > > command line parameters, and the device tree you put in this series > >> > > has various hardcoded values which normally do not show up > >> > > in hand-written dts files. > >> > > > >> > > I am not sure I understand the whole point of this. > >> > > >> > I am also confused and do not like the idea of adding device trees for > >> > platforms that are capable of and can / do have a device tree to give > us > >> > at run time. > >> > >> (I'll just reply to this one email, since the same points applies to > >> all replies I think) > >> > >> I have been thinking about this and discussing it with people for a > >> few months now. I've been signalling a change like this for over a > >> month now, on U-Boot contributor calls and in discussions with Linaro > >> people. I sent a patch (below) to try to explain things. I hope it is > >> not a surprise! > >> > >> The issue here is that we need a devicetree in-tree in U-Boot, to > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > >> Ilias' series and this one we can get ourselves on a stronger footing. > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > >> For more context: > >> > >> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > >> BTW I did suggest to QEMU ARM that they support a way of adding the > >> u-boot.dtsi but there was not much interest there (in fact the > >> maintainer would prefer there was no special support even for booting > >> Linux directly!) > > > > i understand their point of view and agree with it. > >> > >> But in any case it doesn't really help U-Boot. I > >> think
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le jeu. 14 oct. 2021 à 17:28, Tom Rini a écrit : > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.o...@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is > built and > > > > >> > > > appended to U-Boot > > > > >> > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is > needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > >> > > > caller may have a better idea about the hardware available > in the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a change like
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le jeu. 14 oct. 2021 à 18:24, Andre Przywara a écrit : > On Thu, 14 Oct 2021 09:17:52 -0600 > Simon Glass wrote: > > > Hi Tom, > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini wrote: > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote: > > > > Hi François, > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog < > francois.o...@linaro.org> wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a > écrit : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > wrote: > > > > >> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > > >> > > Hi Simon, > > > > >> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass > wrote: > > > > >> > > > > > > > >> > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and > OF_HOSTFILE so > > > > >> > > > there are only three ways to obtain a devicetree: > > > > >> > > > > > > > >> > > >- OF_SEPARATE - the normal way, where the devicetree is > built and > > > > >> > > > appended to U-Boot > > > > >> > > >- OF_EMBED - for development purposes, the devicetree is > embedded in > > > > >> > > > the ELF file (also used for EFI) > > > > >> > > >- OF_BOARD - the board figures it out on its own > > > > >> > > > > > > > >> > > > The last one is currently set up so that no devicetree is > needed at all > > > > >> > > > in the U-Boot tree. Most boards do provide one, but some > don't. Some > > > > >> > > > don't even provide instructions on how to boot on the board. > > > > >> > > > > > > > >> > > > The problems with this approach are documented at [1]. > > > > >> > > > > > > > >> > > > In practice, OF_BOARD is not really distinct from > OF_SEPARATE. Any board > > > > >> > > > can obtain its devicetree at runtime, even it is has a > devicetree built > > > > >> > > > in U-Boot. This is because U-Boot may be a second-stage > bootloader and its > > > > >> > > > caller may have a better idea about the hardware available > in the machine. > > > > >> > > > This is the case with a few QEMU boards, for example. > > > > >> > > > > > > > >> > > > So it makes no sense to have OF_BOARD as a 'choice'. It > should be an > > > > >> > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > >> > > > > > > > >> > > > This series makes this change, adding various missing > devicetree files > > > > >> > > > (and placeholders) to make the build work. > > > > >> > > > > > > >> > > Adding device trees that are never used sounds like a hack to > me. > > > > >> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly > based on > > > > >> > > command line parameters, and the device tree you put in this > series > > > > >> > > has various hardcoded values which normally do not > show up > > > > >> > > in hand-written dts files. > > > > >> > > > > > > >> > > I am not sure I understand the whole point of this. > > > > >> > > > > > >> > I am also confused and do not like the idea of adding device > trees for > > > > >> > platforms that are capable of and can / do have a device tree > to give us > > > > >> > at run time. > > > > >> > > > > >> (I'll just reply to this one email, since the same points applies > to > > > > >> all replies I think) > > > > >> > > > > >> I have been thinking about this and discussing it with people for > a > > > > >> few months now. I've been signalling a chang
Re: how to run u-boot on qemu arm64 virt machine?
Le jeu. 14 oct. 2021 à 05:06, Chan Kim a écrit : > > > I think my question has error. > > Is it possible to run it on SCP? I mean loading from SD card the kernel, > file system, dtb etc to the memory and calling kernel. > > è > > Is it possible to run it on SCP? I mean loading from SD card the kernel, > file system, dtb etc to the memory and waking the main processor to start > from kernel. > The role of the SCP is mainly to setup clock and power devices. It does have much space to do anything else. You can look at open source implementation of SCP, select a platform that has one and check if it has enough memory (you may try to run U-Boot SPL). You need to know which chip has reponsibility to setup dram controller. > Thank you. > > Chan Kim > > > > *From:* Chan Kim > *Sent:* Thursday, October 14, 2021 12:03 PM > *To:* 'François Ozog' > *Cc:* 'Tom Rini' ; 'u-boot@lists.denx.de' < > u-boot@lists.denx.de> > *Subject:* RE: how to run u-boot on qemu arm64 virt machine? > > > > > > Hi Francois, > > Thanks for the good information. I’ll look into that later. > > Can I ask you a basic question? > > When there are SCP, MCP and the main processor, in what processor does > u-boot program run? I understand it runs on the main processor. > > Is it possible to run it on SCP? I mean loading from SD card the kernel, > file system, dtb etc to the memory and calling kernel. > > Thank you! > > Chan Kim > > > > *From:* François Ozog > > *Sent:* Wednesday, October 13, 2021 6:29 PM > *To:* Chan Kim > *Cc:* Tom Rini ; u-boot@lists.denx.de > *Subject:* Re: how to run u-boot on qemu arm64 virt machine? > > > > Hi > > > > You can find work in progress here too: > > http://releases.linaro.org/components/ledge/rp-0.2/ledge-multi-armv8/ > > > > For aarch64 there are virt and sbsa-ref machines. Virt is essentially to > boot a VM while sbsa-ref is a reference platform that mimics all required > hardware, firmware for the secure world (TF-A, OP-TEE) and firmware for > normal world (U-Boot, EDK2). This technology (sbsa-ref) is really to > simulate a system for pre-silicon development while virt shall be used in > cloud native environments. > > > > We are working on something that we may end up calling bsa-ref (note the > absence of initial S standing for “server”). Sbsa-ref is about edk2 and > acpi, bsa-ref is about U-Boot and device tree. The directory points to this > work in progress. You can have a look at SystemReady in Arm to understand > and get details on bsa. > > > > In a future release of Qemu, one will be able to simulate a full platform > with its main processor (as of today) but also SCP (system control > processor) and MCP (management control processor). > > > > Cheers > > > > FF > > > > Le mer. 13 oct. 2021 à 07:03, Chan Kim a écrit : > > > > > That's a very old QEMU version. We use v6.1.0 currently and v4.2.0 > before > > that. > > > > -- > > Tom > > Thank you, Tom > > Yes, so I tried it now with v4.2.0 with "-nographic" option. (Without it I > still see qemu manager window.) > > Chan Kim > > > -- > > *François-Frédéric Ozog* | *Director Business Development* > > T: +33.67221.6485 > francois.o...@linaro.org | Skype: ffozog > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : > Hi Tom, Bin,François, > > On Tue, 12 Oct 2021 at 19:34, Tom Rini wrote: > > > > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > > Hi Simon, > > > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > > there are only three ways to obtain a devicetree: > > > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > > appended to U-Boot > > > >- OF_EMBED - for development purposes, the devicetree is embedded > in > > > > the ELF file (also used for EFI) > > > >- OF_BOARD - the board figures it out on its own > > > > > > > > The last one is currently set up so that no devicetree is needed at > all > > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > > don't even provide instructions on how to boot on the board. > > > > > > > > The problems with this approach are documented at [1]. > > > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > > can obtain its devicetree at runtime, even it is has a devicetree > built > > > > in U-Boot. This is because U-Boot may be a second-stage bootloader > and its > > > > caller may have a better idea about the hardware available in the > machine. > > > > This is the case with a few QEMU boards, for example. > > > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > > > This series makes this change, adding various missing devicetree > files > > > > (and placeholders) to make the build work. > > > > > > Adding device trees that are never used sounds like a hack to me. > > > > > > For QEMU, device tree is dynamically generated on the fly based on > > > command line parameters, and the device tree you put in this series > > > has various hardcoded values which normally do not show up > > > in hand-written dts files. > > > > > > I am not sure I understand the whole point of this. > > > > I am also confused and do not like the idea of adding device trees for > > platforms that are capable of and can / do have a device tree to give us > > at run time. > > (I'll just reply to this one email, since the same points applies to > all replies I think) > > I have been thinking about this and discussing it with people for a > few months now. I've been signalling a change like this for over a > month now, on U-Boot contributor calls and in discussions with Linaro > people. I sent a patch (below) to try to explain things. I hope it is > not a surprise! > > The issue here is that we need a devicetree in-tree in U-Boot, to > avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD, > BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between > Ilias' series and this one we can get ourselves on a stronger footing. > There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use. > For more context: > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > BTW I did suggest to QEMU ARM that they support a way of adding the > u-boot.dtsi but there was not much interest there (in fact the > maintainer would prefer there was no special support even for booting > Linux directly!) i understand their point of view and agree with it. > But in any case it doesn't really help U-Boot. I > think the path forward might be to run QEMU twice, once to get its > generated tree and once to give the 'merged' tree with the U-Boot > properties in it, if people want to use U-Boot features. > > I do strongly believe that OF_BOARD must be a run-time option, not a > build-time one. It creates all sorts of problems and obscurity which > have taken months to unpick. See the above patch for the rationale. > > To add to that rationale, OF_BOARD needs to be an option available to > any board. At some point in the future it may become a common way > things are done, e.g. TF-A calling U-Boot and providing a devicetree > to it. It doesn't make any sense to have people decide whether or not > to set OF_BOARD at build time, thus affecting how the image is put > together. We'll end up with different U-Boot build targets like > capricorn, capricorn_of_board and the like. It should be obvious where > that will lead. Instead, OF_BOARD needs to become a commonly used > option, perhaps enabled by most/all boards, so that this sort of build > explosion is not needed. If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built. > U-Boot needs to be flexible enough to > function correctly in whatever runtime environment in which it finds > itself. > > Also as binman is pressed into service more and more to build the > complex firmware images that
Re: [PATCH v3 3/3] RFC: doc: Add documentation about devicetree usage
Le mer. 13 oct. 2021 à 15:30, Tom Rini a écrit : > On Wed, Oct 13, 2021 at 03:12:02PM +0200, François Ozog wrote: > > Le mer. 13 oct. 2021 à 14:55, Tom Rini a écrit : > > > > > On Wed, Oct 13, 2021 at 10:15:02AM +0200, François Ozog wrote: > > > > Le sam. 18 sept. 2021 à 15:18, Tom Rini a > écrit : > > > > > > > > > On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote: > > > > > > Hi, > > > > > > > > > > > > On Fri, 10 Sept 2021 at 16:44, Tom Rini > wrote: > > > > > > > > > > > > > > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote: > > > > > > > > > Date: Fri, 10 Sep 2021 17:17:37 -0400 > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis > wrote: > > > > > > > > > > > Date: Fri, 10 Sep 2021 08:34:20 -0400 > > > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 10:38:17AM +0200, Heinrich > > > Schuchardt > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/9/21 10:10 PM, Simon Glass wrote: > > > > > > > > > > > > > At present some of the ideas and techniques behind > > > > > devicetree in U-Boot > > > > > > > > > > > > > are assumed, implied or unsaid. Add some > documentation > > > to > > > > > cover how > > > > > > > > > > > > > devicetree is build, how it can be modified and the > > > rules > > > > > about using > > > > > > > > > > > > > the various CONFIG_OF_... options. > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > > Reviewed-by: Marcel Ziswiler < > > > marcel.ziswi...@toradex.com> > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > > > - Fix typos linst suppled receive EFL > > > > > > > > > > > > > - Drop 'and' before 'self-defeating' > > > > > > > > > > > > > - Reword mention of control of QEMU's devicetree > > > generation > > > > > > > > > > > > > - Add mention of dropping CONFIG_OF_BOARD > > > > > > > > > > > > > - Clarify the 'Once this bug is fixed' paragraph a > bit > > > > > > > > > > > > > - Expand ways that CONFIG_OF_PRIOR_STAGE can > support > > > the > > > > > U-Boot devicetree > > > > > > > > > > > > > - Add a note at the top explaining that his patch > > > covers > > > > > 'now', not 'future' > > > > > > > > > > > > > - Add note 'Note: Some boards use a devicetree in > > > U-Boot > > > > > which does not match' > > > > > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > > > - Fix typos per Sean (thank you!) and a few others > > > > > > > > > > > > > - Add a 'Use of U-Boot /config node' section > > > > > > > > > > > > > - Drop mention of dm-verity since that actually > uses > > > the > > > > > kernel cmdline > > > > > > > > > > > > > - Explain that OF_BOARD will still work after these > > > > > changes (in > > > > > > > > > > > > >'Once this bug is fixed...' paragraph) > > > > > > > > > > > > > - Expand a bit on the reason why the 'Current > > > situation' > > > > > is bad > > > > > > > > > > > > > -
Re: [PATCH v3 3/3] RFC: doc: Add documentation about devicetree usage
Le mer. 13 oct. 2021 à 14:55, Tom Rini a écrit : > On Wed, Oct 13, 2021 at 10:15:02AM +0200, François Ozog wrote: > > Le sam. 18 sept. 2021 à 15:18, Tom Rini a écrit : > > > > > On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote: > > > > Hi, > > > > > > > > On Fri, 10 Sept 2021 at 16:44, Tom Rini wrote: > > > > > > > > > > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote: > > > > > > > Date: Fri, 10 Sep 2021 17:17:37 -0400 > > > > > > > From: Tom Rini > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis wrote: > > > > > > > > > Date: Fri, 10 Sep 2021 08:34:20 -0400 > > > > > > > > > From: Tom Rini > > > > > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 10:38:17AM +0200, Heinrich > Schuchardt > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 9/9/21 10:10 PM, Simon Glass wrote: > > > > > > > > > > > At present some of the ideas and techniques behind > > > devicetree in U-Boot > > > > > > > > > > > are assumed, implied or unsaid. Add some documentation > to > > > cover how > > > > > > > > > > > devicetree is build, how it can be modified and the > rules > > > about using > > > > > > > > > > > the various CONFIG_OF_... options. > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > Reviewed-by: Marcel Ziswiler < > marcel.ziswi...@toradex.com> > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > > > - Fix typos linst suppled receive EFL > > > > > > > > > > > - Drop 'and' before 'self-defeating' > > > > > > > > > > > - Reword mention of control of QEMU's devicetree > generation > > > > > > > > > > > - Add mention of dropping CONFIG_OF_BOARD > > > > > > > > > > > - Clarify the 'Once this bug is fixed' paragraph a bit > > > > > > > > > > > - Expand ways that CONFIG_OF_PRIOR_STAGE can support > the > > > U-Boot devicetree > > > > > > > > > > > - Add a note at the top explaining that his patch > covers > > > 'now', not 'future' > > > > > > > > > > > - Add note 'Note: Some boards use a devicetree in > U-Boot > > > which does not match' > > > > > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > > > - Fix typos per Sean (thank you!) and a few others > > > > > > > > > > > - Add a 'Use of U-Boot /config node' section > > > > > > > > > > > - Drop mention of dm-verity since that actually uses > the > > > kernel cmdline > > > > > > > > > > > - Explain that OF_BOARD will still work after these > > > changes (in > > > > > > > > > > >'Once this bug is fixed...' paragraph) > > > > > > > > > > > - Expand a bit on the reason why the 'Current > situation' > > > is bad > > > > > > > > > > > - Clarify in a second place that Linux and U-Boot use > the > > > same devicetree > > > > > > > > > > >in 'To be clear, while U-Boot...' > > > > > > > > > > > - Expand on why we should have rules for other > projects in > > > > > > > > > > >'Devicetree in another project' > > > > > > > > > > > - Add a comment as to why devicetree in U-Boot is not > 'bad > > > design' > > > > > > > > > > > - Reword 'in-tree U-Boot devicetree' to 'devicetree > source > > > in U-Boot' > > > > > > > > > > > - Rewrite 'Devicetree generated on-the-fly in another > > > project' to cover > > > > > > > > > > >points ra
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé a écrit : > Hi Simon, > > On 10/13/21 03:29, Bin Meng wrote: > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > >> > >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > >> there are only three ways to obtain a devicetree: > >> > >>- OF_SEPARATE - the normal way, where the devicetree is built and > >> appended to U-Boot > >>- OF_EMBED - for development purposes, the devicetree is embedded in > >> the ELF file (also used for EFI) > >>- OF_BOARD - the board figures it out on its own > >> > >> The last one is currently set up so that no devicetree is needed at all > >> in the U-Boot tree. Most boards do provide one, but some don't. Some > >> don't even provide instructions on how to boot on the board. > >> > >> The problems with this approach are documented at [1]. > >> > >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > >> can obtain its devicetree at runtime, even it is has a devicetree built > >> in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > >> caller may have a better idea about the hardware available in the > machine. > >> This is the case with a few QEMU boards, for example. > >> > >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an > >> option, available with either OF_SEPARATE or OF_EMBED. > >> > >> This series makes this change, adding various missing devicetree files > >> (and placeholders) to make the build work. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded values which normally do not show up > > in hand-written dts files. > > Besides, QEMU generates these dtb at runtime on purpose: it gives > emulated machines the freedom to evolve by adding new devices, > mapping/wiring peripherals differently. > > By adding static dtb this gives QEMU users false expectations the > machine hardware is stable, or force QEMU to have this interface > become a stable API. > > From QEMU perspective this seems counter-productive. > +1 > > Digging a bit I see this has already been discussed on qemu-devel@ > mailing list recently: > > > https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=n8rqm4voc...@mail.gmail.com/ > > > I am not sure I understand the whole point of this. > > > >> > >> It also provides a few qemu clean-ups discovered along the way. > >> > >> This series is based on Ilias' two series for OF_HOSTFILE and > >> OF_PRIOR_STAGE removal. > >> > >> It is available at u-boot-dm/ofb-working > >> > >> [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > >> > > > > Regards, > > Bin > > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt < heinrich.schucha...@canonical.com> a écrit : > > > On 10/13/21 03:01, Simon Glass wrote: > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > > - OF_SEPARATE - the normal way, where the devicetree is built and > >appended to U-Boot > > - OF_EMBED - for development purposes, the devicetree is embedded in > >the ELF file (also used for EFI) > > - OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > caller may have a better idea about the hardware available in the > machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > Why should we add dummy files with irrelevant content (see patch 06/16) > to make the build work? Why don't you fix the Makefile instead? > +1 > > Best regards > > Heinrich > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > Simon Glass (16): > >arm: qemu: Mention -nographic in the docs > >arm: qemu: Explain how to extract the generate devicetree > >riscv: qemu: Explain how to extract the generate devicetree > >arm: qemu: Add a devicetree file for qemu_arm > >arm: qemu: Add a devicetree file for qemu_arm64 > >riscv: qemu: Add devicetree files for qemu_riscv32/64 > >arm: rpi: Add a devicetree file for rpi_4 > >arm: vexpress: Add a devicetree file for juno > >arm: xenguest_arm64: Add a fake devicetree file > >arm: octeontx: Add a fake devicetree file > >arm: xilinx_versal_virt: Add a devicetree file > >arm: bcm7xxx: Add a devicetree file > >arm: qemu-ppce500: Add a devicetree file > >arm: highbank: Add a fake devicetree file > >fdt: Make OF_BOARD a bool option > >Drop CONFIG_BINMAN_STANDALONE_FDT > > > > Makefile |3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 + > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 + > > arch/arm/dts/qemu-arm64.dts| 381 + > > arch/arm/dts/xenguest-arm64.dts| 15 + > > arch/arm/dts/xilinx-versal-virt.dts| 307 > > arch/powerpc/dts/Makefile |1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 > > arch/riscv/dts/Makefile|2 +- > > arch/riscv/dts/qemu-virt.dts |8 - > > arch/riscv/dts/qemu-virt32.dts | 217 +++ > > arch/riscv/dts/qemu-virt64.dts | 217 +++ > > configs/bcm7260_defconfig |1 + > > configs/bcm7445_defconfig |1 + > > configs/highbank_defconfig |2 +- > > configs/octeontx2_95xx_defconfig |1 + > > configs/octeontx2_96xx_defconfig |1 + > > configs/octeontx_81xx_defconfig|1 + > > configs/octeontx_83xx_defconfig|1 + > > configs/qemu-ppce500_defconfig |2 + > > configs/qemu-riscv32_defconfig |1 + > > configs/qemu-riscv32_smode_defconfig |1 + > > configs/qemu-riscv32_spl_defconfig |4 +- > > configs/qemu-riscv64_defconfig |1 + > > configs/qemu-riscv64_smode_defconfig |1 + > > configs/qemu-riscv64_spl_defconfig |3 +- > > configs/qemu_arm64_defconfig |1 + > > configs/qemu_arm_defconfig |1 + > > configs/rpi_4_32b_defconfig|1 + > > configs/rpi_4_defconfig|1 + > > configs/rpi_arm64_defconfig|1 + > > configs/vexpress_aemv8a_juno_defconfig |1 + > > configs/xenguest_arm64_defconfig |1 + > >
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Le mer. 13 oct. 2021 à 14:41, Andre Przywara a écrit : > On Tue, 12 Oct 2021 19:01:04 -0600 > Simon Glass wrote: > > Hi, > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > there are only three ways to obtain a devicetree: > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > appended to U-Boot > >- OF_EMBED - for development purposes, the devicetree is embedded in > > the ELF file (also used for EFI) > >- OF_BOARD - the board figures it out on its own > > > > The last one is currently set up so that no devicetree is needed at all > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > don't even provide instructions on how to boot on the board. > > > > The problems with this approach are documented at [1]. > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board > > can obtain its devicetree at runtime, even it is has a devicetree built > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > caller may have a better idea about the hardware available in the > machine. > > This is the case with a few QEMU boards, for example. > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > option, available with either OF_SEPARATE or OF_EMBED. > > So I am possibly fine with that, but: > > > This series makes this change, adding various missing devicetree files > > (and placeholders) to make the build work. > > If we just need it to make the build work, we not just have pure stub DTs, > as you do for highbank, everywhere? > Adding *some* DT files for those platforms that actually do the right > thing seems like the wrong direction to me. > Providing DTs in the source repositories of the actual consumers is more > of a bad habit that dragged on since Linux started this around 10 years > ago (for practical reasons). For *some* platforms U-Boot is the firmware > component that is in the best situation to provide the DTB (because it's > more than a mere bootloader), but for other it's just not. And this is not > even looking at really dynamic platforms like QEMU, where providing some > kind of fixed DT is just not working. > > I don't get the argument that people would need to see the DT in the tree > to develop code. The DT spec and binding documentation (currently living > in the Linux kernel source tree) provide the specification to code > against, and the platform specific selection of drivers in Kconfig and > _defconfig select the drivers for the devices that people are expected to > see. Why does one need actual DT files in the tree? > > I totally agree on adding more documentation, possibly *pointing* to > example > DTs or giving commands on how to obtain the actual copy (-dumpdtb, > /sys/firmware/devicetree), but don't think that adding some .dts files for > platforms that don't need them is the right way. > > Cheers, > Andre. +1 > > > > > > It also provides a few qemu clean-ups discovered along the way. > > > > This series is based on Ilias' two series for OF_HOSTFILE and > > OF_PRIOR_STAGE removal. > > > > It is available at u-boot-dm/ofb-working > > > > [1] > > > https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ > > > > > > Simon Glass (16): > > arm: qemu: Mention -nographic in the docs > > arm: qemu: Explain how to extract the generate devicetree > > riscv: qemu: Explain how to extract the generate devicetree > > arm: qemu: Add a devicetree file for qemu_arm > > arm: qemu: Add a devicetree file for qemu_arm64 > > riscv: qemu: Add devicetree files for qemu_riscv32/64 > > arm: rpi: Add a devicetree file for rpi_4 > > arm: vexpress: Add a devicetree file for juno > > arm: xenguest_arm64: Add a fake devicetree file > > arm: octeontx: Add a fake devicetree file > > arm: xilinx_versal_virt: Add a devicetree file > > arm: bcm7xxx: Add a devicetree file > > arm: qemu-ppce500: Add a devicetree file > > arm: highbank: Add a fake devicetree file > > fdt: Make OF_BOARD a bool option > > Drop CONFIG_BINMAN_STANDALONE_FDT > > > > Makefile |3 +- > > arch/arm/dts/Makefile | 20 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 > > arch/arm/dts/bcm7xxx.dts | 15 + > > arch/arm/dts/highbank.dts | 14 + > > arch/arm/dts/juno-r2.dts | 1038 + > > arch/arm/dts/octeontx.dts | 14 + > > arch/arm/dts/qemu-arm.dts | 402 + > > arch/arm/dts/qemu-arm64.dts| 381 + > > arch/arm/dts/xenguest-arm64.dts| 15 + > > arch/arm/dts/xilinx-versal-virt.dts| 307 > > arch/powerpc/dts/Makefile |1 + > > arch/powerpc/dts/qemu-ppce500.dts | 264 > > arch/riscv/dts/Makefile|2 +- > > arch/riscv/dts/qemu-virt.dts |8 - > >
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Simon Le mer. 13 oct. 2021 à 03:35, Tom Rini a écrit : > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote: > > Hi Simon, > > > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass wrote: > > > > > > With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so > > > there are only three ways to obtain a devicetree: > > > > > >- OF_SEPARATE - the normal way, where the devicetree is built and > > > appended to U-Boot > > >- OF_EMBED - for development purposes, the devicetree is embedded in > > > the ELF file (also used for EFI) > > >- OF_BOARD - the board figures it out on its own > > > > > > The last one is currently set up so that no devicetree is needed at all > > > in the U-Boot tree. Most boards do provide one, but some don't. Some > > > don't even provide instructions on how to boot on the board. > > > > > > The problems with this approach are documented at [1]. > > > > > > In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any > board > > > can obtain its devicetree at runtime, even it is has a devicetree built > > > in U-Boot. This is because U-Boot may be a second-stage bootloader and > its > > > caller may have a better idea about the hardware available in the > machine. > > > This is the case with a few QEMU boards, for example. > > > > > > So it makes no sense to have OF_BOARD as a 'choice'. It should be an > > > option, available with either OF_SEPARATE or OF_EMBED. > > > > > > This series makes this change, adding various missing devicetree files > > > (and placeholders) to make the build work. > > > > Adding device trees that are never used sounds like a hack to me. > > > > For QEMU, device tree is dynamically generated on the fly based on > > command line parameters, and the device tree you put in this series > > has various hardcoded values which normally do not show up > > in hand-written dts files. > > > > I am not sure I understand the whole point of this. > > I am also confused and do not like the idea of adding device trees for > platforms that are capable of and can / do have a device tree to give us > at run time. > > -- > Tom +1 While the cleanup go get three options, including OF_BOARD is nice, the build solution you propose does not sound the right approach: U-Boot should be buildable without any DT. Getting the DT you produced as sample information can be useful and kept out of build path in documentation with ad-hoc warnings though as I explained in other mails of the series. OF_BOARD is a choice to say “I don’t override the legitimate DT with either OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for U-Boot maintainer of the platform). > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: how to run u-boot on qemu arm64 virt machine?
Hi You can find work in progress here too: http://releases.linaro.org/components/ledge/rp-0.2/ledge-multi-armv8/ For aarch64 there are virt and sbsa-ref machines. Virt is essentially to boot a VM while sbsa-ref is a reference platform that mimics all required hardware, firmware for the secure world (TF-A, OP-TEE) and firmware for normal world (U-Boot, EDK2). This technology (sbsa-ref) is really to simulate a system for pre-silicon development while virt shall be used in cloud native environments. We are working on something that we may end up calling bsa-ref (note the absence of initial S standing for “server”). Sbsa-ref is about edk2 and acpi, bsa-ref is about U-Boot and device tree. The directory points to this work in progress. You can have a look at SystemReady in Arm to understand and get details on bsa. In a future release of Qemu, one will be able to simulate a full platform with its main processor (as of today) but also SCP (system control processor) and MCP (management control processor). Cheers FF Le mer. 13 oct. 2021 à 07:03, Chan Kim a écrit : > > > > That's a very old QEMU version. We use v6.1.0 currently and v4.2.0 > before > > that. > > > > -- > > Tom > > Thank you, Tom > > Yes, so I tried it now with v4.2.0 with "-nographic" option. (Without it I > still see qemu manager window.) > > Chan Kim > > > > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v3 3/3] RFC: doc: Add documentation about devicetree usage
Le sam. 18 sept. 2021 à 15:18, Tom Rini a écrit : > On Sat, Sep 18, 2021 at 03:38:45AM -0600, Simon Glass wrote: > > Hi, > > > > On Fri, 10 Sept 2021 at 16:44, Tom Rini wrote: > > > > > > On Sat, Sep 11, 2021 at 12:09:40AM +0200, Mark Kettenis wrote: > > > > > Date: Fri, 10 Sep 2021 17:17:37 -0400 > > > > > From: Tom Rini > > > > > > > > > > On Fri, Sep 10, 2021 at 11:12:20PM +0200, Mark Kettenis wrote: > > > > > > > Date: Fri, 10 Sep 2021 08:34:20 -0400 > > > > > > > From: Tom Rini > > > > > > > > > > > > > > On Fri, Sep 10, 2021 at 10:38:17AM +0200, Heinrich Schuchardt > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 9/9/21 10:10 PM, Simon Glass wrote: > > > > > > > > > At present some of the ideas and techniques behind > devicetree in U-Boot > > > > > > > > > are assumed, implied or unsaid. Add some documentation to > cover how > > > > > > > > > devicetree is build, how it can be modified and the rules > about using > > > > > > > > > the various CONFIG_OF_... options. > > > > > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > Reviewed-by: Marcel Ziswiler > > > > > > > > > --- > > > > > > > > > > > > > > > > > > Changes in v3: > > > > > > > > > - Fix typos linst suppled receive EFL > > > > > > > > > - Drop 'and' before 'self-defeating' > > > > > > > > > - Reword mention of control of QEMU's devicetree generation > > > > > > > > > - Add mention of dropping CONFIG_OF_BOARD > > > > > > > > > - Clarify the 'Once this bug is fixed' paragraph a bit > > > > > > > > > - Expand ways that CONFIG_OF_PRIOR_STAGE can support the > U-Boot devicetree > > > > > > > > > - Add a note at the top explaining that his patch covers > 'now', not 'future' > > > > > > > > > - Add note 'Note: Some boards use a devicetree in U-Boot > which does not match' > > > > > > > > > > > > > > > > > > Changes in v2: > > > > > > > > > - Fix typos per Sean (thank you!) and a few others > > > > > > > > > - Add a 'Use of U-Boot /config node' section > > > > > > > > > - Drop mention of dm-verity since that actually uses the > kernel cmdline > > > > > > > > > - Explain that OF_BOARD will still work after these > changes (in > > > > > > > > >'Once this bug is fixed...' paragraph) > > > > > > > > > - Expand a bit on the reason why the 'Current situation' > is bad > > > > > > > > > - Clarify in a second place that Linux and U-Boot use the > same devicetree > > > > > > > > >in 'To be clear, while U-Boot...' > > > > > > > > > - Expand on why we should have rules for other projects in > > > > > > > > >'Devicetree in another project' > > > > > > > > > - Add a comment as to why devicetree in U-Boot is not 'bad > design' > > > > > > > > > - Reword 'in-tree U-Boot devicetree' to 'devicetree source > in U-Boot' > > > > > > > > > - Rewrite 'Devicetree generated on-the-fly in another > project' to cover > > > > > > > > >points raised on v1 > > > > > > > > > - Add 'Why does U-Boot have its nodes and properties?' > > > > > > > > > - Add 'Why not have two devicetrees?' > > > > > > > > > > > > > > > > > > doc/develop/index.rst | 1 + > > > > > > > > > doc/develop/package/devicetree.rst | 583 > + > > > > > > > > > doc/develop/package/index.rst | 1 + > > > > > > > > > 3 files changed, 585 insertions(+) > > > > > > > > > create mode 100644 doc/develop/package/devicetree.rst > > > > > > > > > > > > > > > > > > diff --git a/doc/develop/index.rst b/doc/develop/index.rst > > > > > > > > > index 83c929babda..d5ad8f9fe53 100644 > > > > > > > > > --- a/doc/develop/index.rst > > > > > > > > > +++ b/doc/develop/index.rst > > > > > > > > > @@ -36,6 +36,7 @@ Packaging > > > > > > > > > :maxdepth: 1 > > > > > > > > > > > > > > > > > > package/index > > > > > > > > > + package/devicetree > > > > > > > > > > > > > > > > > > Testing > > > > > > > > > --- > > > > > > > > > diff --git a/doc/develop/package/devicetree.rst > b/doc/develop/package/devicetree.rst > > > > > > > > > new file mode 100644 > > > > > > > > > index 000..b1bd310d906 > > > > > > > > > --- /dev/null > > > > > > > > > +++ b/doc/develop/package/devicetree.rst > > > > > > > > > @@ -0,0 +1,583 @@ > > > > > > > > > +.. SPDX-License-Identifier: GPL-2.0+ > > > > > > > > > + > > > > > > > > > +Updating the devicetree > > > > > > > > > +=== > > > > > > > > > + > > > > > > > > > +Note: This documentation describes how things are today, > mostly, with some > > > > > > > > > +mention of things that need to be fixed. It is not > intended to point the way to > > > > > > > > > +what might be done in the future. That should be the > subject of discussions on > > > > > > > > > +the mailing list. > > > > > > > > > + > > > > > > > > > +U-Boot uses devicetree for runtime configuration and > storing required blobs or > > > > > > > > > +any other information it needs to operate. It is possible > to update the > > > > > > > > > +devicetree separately from actually building
Re: [PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4
Hi Simon
This is making a clean environment go in the wrong direction. I have
witnessed that bus to mmio changed for instance, have seen patches to patch
live u-boot embedded DT because it does not do the work that Videocore
does.
The Videocore handles that properly so why adding this?
Si i would agree to have the file on the documentation directory not on the
dts with the same warning I mentioned earlier
Le mer. 13 oct. 2021 à 03:03, Simon Glass a écrit :
> Add this file, obtained from the Raspbian boot disk, so there is a
> reference devicetree in the U-Boot tree. The same one is used for
> 32- and 64-bit variants.
>
> Note that U-Boot does not normally need this at runtime, since
> CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> devicetree at runtime.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile|3 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> configs/rpi_4_32b_defconfig |1 +
> configs/rpi_4_defconfig |1 +
> configs/rpi_arm64_defconfig |1 +
> 5 files changed, 1963 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 52c586f3974..efc01a70bf2 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1062,7 +1062,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> - bcm2837-rpi-cm3-io3.dtb
> + bcm2837-rpi-cm3-io3.dtb \
> + bcm2711-rpi-4-b.dtb
>
> dtb-$(CONFIG_ARCH_BCM63158) += \
> bcm963158.dtb
> diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 000..425e9fb91c4
> --- /dev/null
> +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,1958 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for rpi_4
> +
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x 0x1000;
> +/ {
> + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> + model = "Raspberry Pi 4 Model B";
> + interrupt-parent = <0x01>;
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> +
> + aliases {
> + serial0 = "/soc/serial@7e215040";
> + serial1 = "/soc/serial@7e201000";
> + audio = "/soc/audio";
> + aux = "/soc/aux@7e215000";
> + sound = "/soc/sound";
> + soc = "/soc";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e10";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e20";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e34";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + i2c0 = "/soc/i2c@7e205000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + mmc = "/soc/mmc@7e30";
> + mmc1 = "/soc/mmcnr@7e30";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e98";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d58";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e00 0x00 0xfe00 0x180
> + 0x7c00 0x00 0xfc00 0x200
> + 0x4000 0x00 0xff80 0x80>;
> + dma-ranges = <0xc000 0x00 0x00 0x3c00>;
> + phandle = <0x30>;
> +
> + txp@7e004000 {
> + compatible = "brcm,bcm2835-txp";
> + reg = <0x7e004000 0x20>;
> + interrupts = <0x00 0x4b 0x04>;
> +
Re: [PATCH 10/16] arm: octeontx: Add a fake devicetree file
Hi Simon
It’s even in the title!
The idea of having a DT in dts for ALL boards is not properly rooted. You
may add some sample dts with warnings in the doc tree though.
Le mer. 13 oct. 2021 à 03:04, Simon Glass a écrit :
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> Unfortunately there are no build instructions in the U-Boot tree to enable
> a real file to be created.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile| 3 +++
> arch/arm/dts/octeontx.dts| 14 ++
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> 6 files changed, 21 insertions(+)
> create mode 100644 arch/arm/dts/octeontx.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f09a81eea8e..0fec648dd77 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1127,6 +1127,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>
> dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
>
> +dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
> +dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
> new file mode 100644
> index 000..60a15f5df23
> --- /dev/null
> +++ b/arch/arm/dts/octeontx.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for octeontx2 boards
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * I could not find any in-tree documentation at all so this is a dummy
> file.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/octeontx2_95xx_defconfig
> b/configs/octeontx2_95xx_defconfig
> index 6d8457f1d07..fac4c50aec4 100644
> --- a/configs/octeontx2_95xx_defconfig
> +++ b/configs/octeontx2_95xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX2_95XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx2_96xx_defconfig
> b/configs/octeontx2_96xx_defconfig
> index b72caef77d8..db883b5542c 100644
> --- a/configs/octeontx2_96xx_defconfig
> +++ b/configs/octeontx2_96xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX2_96XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_81xx_defconfig
> b/configs/octeontx_81xx_defconfig
> index 52678d59ff1..8309c29c091 100644
> --- a/configs/octeontx_81xx_defconfig
> +++ b/configs/octeontx_81xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX_81XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_83xx_defconfig
> b/configs/octeontx_83xx_defconfig
> index 3890c1e97d4..dae1d4880f8 100644
> --- a/configs/octeontx_83xx_defconfig
> +++ b/configs/octeontx_83xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x1
> CONFIG_TARGET_OCTEONTX_83XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e02800
> CONFIG_DEBUG_UART_CLOCK=2400
> CONFIG_DEBUG_UART=y
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
Le mer. 13 oct. 2021 à 03:02, Simon Glass a écrit : > QEMU currently generates a devicetree for use with U-Boot. Explain how to > obtain it. > > Signed-off-by: Simon Glass > --- > > doc/board/emulation/qemu-arm.rst | 12 > 1 file changed, 12 insertions(+) > > diff --git a/doc/board/emulation/qemu-arm.rst > b/doc/board/emulation/qemu-arm.rst > index 97b6ec64905..b458a398c69 100644 > --- a/doc/board/emulation/qemu-arm.rst > +++ b/doc/board/emulation/qemu-arm.rst > @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these > settings:: > CONFIG_DEBUG_UART_PL010=y > CONFIG_DEBUG_UART_BASE=0x900 > CONFIG_DEBUG_UART_CLOCK=0 > + > +Obtaining the QEMU devicetree > +- > + > +QEMU generates its own devicetree to pass to U-Boot and does this by > default. > +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree > version. this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ? > > + > +To obtain the devicetree that qemu generates, add `-machine > dumpdtb=dtb.dtb`, > +e.g.:: > + > +qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \ > + -bios u-boot.bin -machine dumpdtb=dtb.dtb > -- > 2.33.0.882.g93a45727a2-goog > > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
Hi Simon
The only place I could agree with this file presence is in the
documentation directory, not in dts. It creates a mental picture for the
reader an entirely bad mind scheme around Qemu and DT.
And even in a documentation directory I would place a bug warning: don’t
use this with any kernel , Qemu generates a DT dynamically based on cpu,
memory and devices specified at the command line.
I would also document how to get the DT that Qemu generates (and lkvm btw)
outside any firmware/os provided.
Cheers
FF
Le mer. 13 oct. 2021 à 03:03, Simon Glass a écrit :
> Add this file, generated from qemu, so there is a reference devicetree
> in the U-Boot tree.
>
> Signed-off-by: Simon Glass
> ---
>
> arch/arm/dts/Makefile| 2 +-
> arch/arm/dts/qemu-arm64.dts | 381 +++
> configs/qemu_arm64_defconfig | 1 +
> 3 files changed, 383 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/qemu-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index e2fc0cb65fc..52c586f3974 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
> imx8mm-cl-iot-gate.dtb
>
> dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
>
> -dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
> +dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
>
> targets += $(dtb-y)
>
> diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
> new file mode 100644
> index 000..7590e49cc84
> --- /dev/null
> +++ b/arch/arm/dts/qemu-arm64.dts
> @@ -0,0 +1,381 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for qemu_arm64
> +
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> + interrupt-parent = <0x8001>;
> + #size-cells = <0x02>;
> + #address-cells = <0x02>;
> + compatible = "linux,dummy-virt";
> +
> + psci {
> + migrate = <0xc405>;
> + cpu_on = <0xc403>;
> + cpu_off = <0x8402>;
> + cpu_suspend = <0xc401>;
> + method = "hvc";
> + compatible = "arm,psci-0.2\0arm,psci";
> + };
> +
> + memory@4000 {
> + reg = <0x00 0x4000 0x00 0x800>;
> + device_type = "memory";
> + };
> +
> + platform@c00 {
> + interrupt-parent = <0x8001>;
> + ranges = <0x00 0x00 0xc00 0x200>;
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + compatible = "qemu,platform\0simple-bus";
> + };
> +
> + fw-cfg@902 {
> + dma-coherent;
> + reg = <0x00 0x902 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + virtio_mmio@a00 {
> + dma-coherent;
> + interrupts = <0x00 0x10 0x01>;
> + reg = <0x00 0xa00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000200 {
> + dma-coherent;
> + interrupts = <0x00 0x11 0x01>;
> + reg = <0x00 0xa000200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000400 {
> + dma-coherent;
> + interrupts = <0x00 0x12 0x01>;
> + reg = <0x00 0xa000400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000600 {
> + dma-coherent;
> + interrupts = <0x00 0x13 0x01>;
> + reg = <0x00 0xa000600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000800 {
> + dma-coherent;
> + interrupts = <0x00 0x14 0x01>;
> + reg = <0x00 0xa000800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000a00 {
> + dma-coherent;
> + interrupts = <0x00 0x15 0x01>;
> + reg = <0x00 0xa000a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000c00 {
> + dma-coherent;
> + interrupts = <0x00 0x16 0x01>;
> + reg = <0x00 0xa000c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a000e00 {
> + dma-coherent;
> + interrupts = <0x00 0x17 0x01>;
> + reg = <0x00 0xa000e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001000 {
> + dma-coherent;
> + interrupts = <0x00 0x18 0x01>;
> + reg = <0x00 0xa001000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001200 {
> + dma-coherent;
> +
Re: Driver model at UEFI runtime
Le ven. 1 oct. 2021 à 00:00, Michael Walle a écrit : > > With SystemReady, DT from distros are ignored. > > Err? Is this really true, I know about some incompatible changes > to the device tree which prevents you from using usb (or even a > kernel panic) with the imx8mm and I know that on the ls1028a > flexspi wont work if the devicetree doesn't match the kernel. > I.e. if you have a device tree from kernel 5.14 you cannot > use it on 5.10. If you have one from 5.10 you cannot use it on > a later kernel. > >>> > >>> What you describe is the situation we want to avoid and that comes > >>> from years of tinkering. > >> > >> how is that tinkering? That means once you have a device tree, it is > >> set in stone. which isn't reality, sorry. > >> > >> Consider the ls1028a and the flexspi "bug". For the 5.10 kernel/dtb > >> there was a wrong clock connected to the flexspi device. There > >> wasn't > >> even a driver for the correct clock. > > > > The clock could have been described even though there was no Linux > > driver. > > DT is there to describe HW, not the capacity of a particular OS or > > boot firmware to deal with it. > > You're missing my point. It's not about what would be the perfect > scenario. But what actually happens in reality. And unfortunately, > it happens, so you have to deal with devicetree incompatibilies. > Just ignoring this and keeping just one devicetree in the firmware > is doomed to fail sooner or later. We have an example of firmware provided hardware description that works well (Ok: 99% of the time): ACPI. We also are 100% sure that the current situation is messy, hairy, buggy but familiar. > > > [..] > > >> Regarding the imx8mm usb error, apparently the node was renamed. If > >> you're > >> using older kernels with newer dtbs, the kernel oopes. If you're > >> using a > >> newer kernel with older dtbs, USB doesn't get probed. (Although I > >> was > >> told that there is a "fix" for this, that is, both node names are > >> tried.) > > > > I keep seeing those issues about node renames or compatible string > > changes. > > That's the tinkering I am talking about. > > There is no in-kernel ABI but Linus bang heads if anyone touches > > userland-kernel ABI inappropriately. > > > > As DT is mostly handled in-kernel, people treat DT as no-ABI. > > But it is part of firmware-kernel ABI. > > Until we properly organize this firmware-kernel ABI, the problem you > > describe and more will continue. > > Sure, but until you reaches that point (I predict it wont happen soon > or at all) you'll have to deal with per kernel devicetrees. Just > saying, we are just providing one devicetree supplied by the firmware > just doesn't work with the current situation. So IMHO if SystemReady is > really "it just works", then you have to consider this. And so far, > it seems all SystemReady certified boards just throw the u-boot > devicetree at linux and hope for the best. SystemReady is not meant to be all boards, starting now and mandatory. It is a selected of boards for which everyone in the value chain is willing to spend the energy to solve the problem as if we were living in a perfect world. > > > > Now the DT lifecycle before the firmware-kernel ABI also needs to be > > specified so that we properly handle hats, capes, SoMs, carrier > > boards... > > > >>> > >> > > > https://developer.arm.com/architectures/system-architectures/arm-systemready/ir > >>> lists a number of certified boards and the list is going to grow > >>> significantly. > >> > >> And the sl28 board will likely be there soon, too. > >> > >>> On those boards, you will be able to boot any kernel. > >> > >> Actually I don't think so, because you might hit the imx8mm bug, > >> too. > >> May > >> just be lucky by the devicetree/kernel combination. > >> > >>> The image I have in mind with OS provided DT is: > >>> as a French driver, my DT says that the steering wheel is on the > >> left > >>> hand side of the car. > >>> Shall I whine about the cars in England that do not comply to my > >> DT? > >>> or accept to use the car provided DT? > >>> The situation is comfortable for tinkerers, but not sustainable. > >> It is > >>> a matter of organization and not technology to solve the problems > >> you > >>> describe. > >> > >> Mh, I'm not sure I understand what you're trying to tell me. The > >> distribution also provides you the kernel, why shouldn't it provide > >> devicetree which exactly matches this kernel and was also tested > >> against. > > > > Because the kernel has no clue which hats, capes has been added for > > instance. > > And the same might be true for the firmware as pointed out before. > > > The kernel provided DTB works fine when the firmware builder and OS > > builders are the same. > > Ehh? It is just the other way around. The distro supplies the kernel > and thus it also have the corresponding devicetrees for this particular > kernel. The firmware can remain the same. Now Mark
Re: Driver model at UEFI runtime
On Thu, 30 Sept 2021 at 18:25, Michael Walle wrote: > Am 2021-09-30 17:47, schrieb François Ozog: > > On Thu, 30 Sept 2021 at 17:12, Michael Walle wrote: > > > >> [adding Vladimir, because he showed interest in this, too] > >> > >> Am 2021-09-30 15:56, schrieb François Ozog: > >>> On Thu, 30 Sept 2021 at 14:07, Michael Walle > >> wrote: > >>> > >>>> Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: > >>>>> Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle > >>>>> : > >>>>>> Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: > >>>>>>> On 9/30/21 8:23 AM, François Ozog wrote: > >>>>>> [..] > >>>>>>>> Is U-Boot's UEFI loader implementation supposed to be the > >>>>>>>> recommended > >>>>>>>> UEFI firmware on ARM and RISC-V on a production / > >>>> deployment > >>>>>>>> system? > >>>>>>>> > >>>>>>>> For Arm: yes, that is SystemReady spec. > >>>>>>> > >>>>>>> For RISC-V it is required by the RISC-V platform > >> specification. > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, > >>>> or > >>>>>>>> do > >>>>>>>> we > >>>>>>>> expect to load grub.efi which chain-loads a kernel without > >>>>>>>> CONFIG_EFI_STUB? > >>>>>>>> > >>>>>>>> all paths should be possible , and the shim.efi is to be > >>>> supported > >>>>>>>> too. > >>>>>>>> With UEFI, I always see that UEFI is kept down to OS for > >>>> SecureBoot. > >>>>>>>> In > >>>>>>>> other words I don’t see grub.efi booting a non > >>>> config_efi_stub. > >>>>>>>> > >>>>>>>> What do distributions normally do? > >>>>>>>> > >>>>>>>> At least Red Hat made it clear at multiple Linaro Connect > >> that > >>>> they > >>>>>>>> want > >>>>>>>> standards, and SystemReady is one that makes the life of > >>>> embedded > >>>>>>>> distros easy. > >>>>>>>> Distros boot shim.efi, grub.efi, Linux.efi to benefit from > >> UEFi > >>>>>>>> SecureBoot. > >>>>>>> > >>>>>>> For Fedora see > >>>>>>> > >>>> > >>> > >> > > https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description > >>>>>>> > >>>>>>> SUSE started the UEFI implementation to boot on all > >>>> architectures in > >>>>>>> the > >>>>>>> same way. The current ARM and RISC-V images uses UEFI. > >>>>>>> > >>>>>>> Debian and Ubuntu install for booting via GRUB if the > >> installer > >>>> is > >>>>>>> invoked via UEFI. A fallback solution using the legacy Linux > >>>> entry > >>>>>>> point > >>>>>>> exists. > >>>>>>> > >>>>>>> For BSD the only way to boot on ARM is via UEFI. > >>>>>>> > >>>>>>>> > >>>>>>>> What's our > >>>>>>>> position when compared to EDK II? > >>>>>>> > >>>>>>> U-Boot implements only a subset of UEFI defined in the EBBR > >>>>>>> specification. > >>>>>>> > >>>>>>> For servers you need a larger scope which is offered by EDK > >> II. > >>>> This > >>>>>>> is > >>>>>>> required both by the RISC-V platform specification as well as > >>>> the ARM > >>>>>>> SystemReady ServerReady profile. > >>>>>>> > >>>>>>> The number of boards supported by upstream EDK II is very low. > >>>> But > >
Re: Driver model at UEFI runtime
On Thu, 30 Sept 2021 at 17:12, Michael Walle wrote: > [adding Vladimir, because he showed interest in this, too] > > Am 2021-09-30 15:56, schrieb François Ozog: > > On Thu, 30 Sept 2021 at 14:07, Michael Walle wrote: > > > >> Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: > >>> Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle > >>> : > >>>> Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: > >>>>> On 9/30/21 8:23 AM, François Ozog wrote: > >>>> [..] > >>>>>> Is U-Boot's UEFI loader implementation supposed to be the > >>>>>> recommended > >>>>>> UEFI firmware on ARM and RISC-V on a production / > >> deployment > >>>>>> system? > >>>>>> > >>>>>> For Arm: yes, that is SystemReady spec. > >>>>> > >>>>> For RISC-V it is required by the RISC-V platform specification. > >>>>> > >>>>>> > >>>>>> > >>>>>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, > >> or > >>>>>> do > >>>>>> we > >>>>>> expect to load grub.efi which chain-loads a kernel without > >>>>>> CONFIG_EFI_STUB? > >>>>>> > >>>>>> all paths should be possible , and the shim.efi is to be > >> supported > >>>>>> too. > >>>>>> With UEFI, I always see that UEFI is kept down to OS for > >> SecureBoot. > >>>>>> In > >>>>>> other words I don’t see grub.efi booting a non > >> config_efi_stub. > >>>>>> > >>>>>> What do distributions normally do? > >>>>>> > >>>>>> At least Red Hat made it clear at multiple Linaro Connect that > >> they > >>>>>> want > >>>>>> standards, and SystemReady is one that makes the life of > >> embedded > >>>>>> distros easy. > >>>>>> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi > >>>>>> SecureBoot. > >>>>> > >>>>> For Fedora see > >>>>> > >> > > https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description > >>>>> > >>>>> SUSE started the UEFI implementation to boot on all > >> architectures in > >>>>> the > >>>>> same way. The current ARM and RISC-V images uses UEFI. > >>>>> > >>>>> Debian and Ubuntu install for booting via GRUB if the installer > >> is > >>>>> invoked via UEFI. A fallback solution using the legacy Linux > >> entry > >>>>> point > >>>>> exists. > >>>>> > >>>>> For BSD the only way to boot on ARM is via UEFI. > >>>>> > >>>>>> > >>>>>> What's our > >>>>>> position when compared to EDK II? > >>>>> > >>>>> U-Boot implements only a subset of UEFI defined in the EBBR > >>>>> specification. > >>>>> > >>>>> For servers you need a larger scope which is offered by EDK II. > >> This > >>>>> is > >>>>> required both by the RISC-V platform specification as well as > >> the ARM > >>>>> SystemReady ServerReady profile. > >>>>> > >>>>> The number of boards supported by upstream EDK II is very low. > >> But > >>>>> proprietary firmware based on EDK II exists. > >>>>> > >>>>>> > >>>>>> the typical distro boot flow is not the most efficient and > >> drags > >>>>>> concept > >>>>>> dating where the Microsoft certs had to be part of the picture. > >> A > >>>>>> direct > >>>>>> U-Boot Linux.efi is my preferred; avoids yet another OS in the > >> boot > >>>>>> path > >>>>>> (grub), avoids convoluted platform cert management (shim) and > >> just > >>>>> > >>>>> This is why U-Boot supports UEFI boot options specifying both a > >>>>> binary > >>>>> as well as an initial RAM disk. > >>>> > >>>
Re: Driver model at UEFI runtime
On Thu, 30 Sept 2021 at 14:07, Michael Walle wrote: > Am 2021-09-30 12:50, schrieb Heinrich Schuchardt: > > Am 30. September 2021 11:53:47 MESZ schrieb Michael Walle > > : > >> Am 2021-09-30 08:56, schrieb Heinrich Schuchardt: > >>> On 9/30/21 8:23 AM, François Ozog wrote: > >> [..] > >>>> Is U-Boot's UEFI loader implementation supposed to be the > >>>> recommended > >>>> UEFI firmware on ARM and RISC-V on a production / deployment > >>>> system? > >>>> > >>>> For Arm: yes, that is SystemReady spec. > >>> > >>> For RISC-V it is required by the RISC-V platform specification. > >>> > >>>> > >>>> > >>>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or > >>>> do > >>>> we > >>>> expect to load grub.efi which chain-loads a kernel without > >>>> CONFIG_EFI_STUB? > >>>> > >>>> all paths should be possible , and the shim.efi is to be supported > >>>> too. > >>>> With UEFI, I always see that UEFI is kept down to OS for SecureBoot. > >>>> In > >>>> other words I don’t see grub.efi booting a non config_efi_stub. > >>>> > >>>> What do distributions normally do? > >>>> > >>>> At least Red Hat made it clear at multiple Linaro Connect that they > >>>> want > >>>> standards, and SystemReady is one that makes the life of embedded > >>>> distros easy. > >>>> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi > >>>> SecureBoot. > >>> > >>> For Fedora see > >>> > https://fedoraproject.org/wiki/Changes/uEFIforARMv7#Detailed_Description > >>> > >>> SUSE started the UEFI implementation to boot on all architectures in > >>> the > >>> same way. The current ARM and RISC-V images uses UEFI. > >>> > >>> Debian and Ubuntu install for booting via GRUB if the installer is > >>> invoked via UEFI. A fallback solution using the legacy Linux entry > >>> point > >>> exists. > >>> > >>> For BSD the only way to boot on ARM is via UEFI. > >>> > >>>> > >>>> What's our > >>>> position when compared to EDK II? > >>> > >>> U-Boot implements only a subset of UEFI defined in the EBBR > >>> specification. > >>> > >>> For servers you need a larger scope which is offered by EDK II. This > >>> is > >>> required both by the RISC-V platform specification as well as the ARM > >>> SystemReady ServerReady profile. > >>> > >>> The number of boards supported by upstream EDK II is very low. But > >>> proprietary firmware based on EDK II exists. > >>> > >>>> > >>>> the typical distro boot flow is not the most efficient and drags > >>>> concept > >>>> dating where the Microsoft certs had to be part of the picture. A > >>>> direct > >>>> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot > >>>> path > >>>> (grub), avoids convoluted platform cert management (shim) and just > >>> > >>> This is why U-Boot supports UEFI boot options specifying both a > >>> binary > >>> as well as an initial RAM disk. > >> > >> I might be late to this, but where does the devicetree come from? As > >> far > >> as I understand it right now, for most (all) the SytemReady IR > >> certified > >> boards, the compiled-in one from u-boot is passed to linux. This won't > >> work > >> in the long run, because the devicetrees keep getting incompatible > >> changes. > >> So while it work for one kernel version it might not work on the next > >> version. > > > > It would make sense to add the fdt devicepath to the bootoption like > > we did it for the initrd. > > I haven't followed the much of the recent development, are there any > commits/files I can look at? > > And I'm not just talking about the use case where the EFI stub of linux > is booted directy, but also when there is grub in between. > > The distribution would supply a bunch of devicetrees along with > the kernel (and initrd). Possibly also different versions of these. > In grub you would choose
Re: Driver model at UEFI runtime
Le jeu. 30 sept. 2021 à 08:38, Bin Meng a écrit : > On Thu, Sep 30, 2021 at 2:23 PM François Ozog > wrote: > >> >> >> Le jeu. 30 sept. 2021 à 07:12, Bin Meng a écrit : >> >>> Hi Heinrich, >>> >>> On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt >>> wrote: >>> > >>> > Hello Simon, >>> > >>> > The EBBR specification requires that the UEFI SystemReset() runtime >>> > service is available to the operating system. >>> > >>> > Up to now this has been implemented by overriding function >>> > efi_reset_system() which is marked as __efi_runtime. >>> > >>> > Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM >>> > and the System Reset Extension for SBI on RISC-V. This has kept the >>> > number of implementations low. The only exceptions are: >>> > >>> > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c >>> > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs >>> > * arch/sandbox/cpu/start.c >>> > >>> > Bin has suggested in >>> > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to >>> use >>> > reset drivers based on the driver model. >>> > >>> > Currently after ExitBootServices() the driver model does not exist >>> anymore. >>> > >>> > When evaluating Bin's suggestion one has to keep in mind that after >>> > invoking ExitBootServices() most operating systems call >>> > SetVirtualAddressMap(). Due to the change of the address map all >>> > pointers used by U-Boot afterwards must be updated to match the new >>> > memory map. >>> > >>> >>> Yeah, this was discussed 3 years ago: >>> >>> https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken >>> >>> > The impression that Ilias and I have is that keeping the driver model >>> > alive after SetVirtualAddressMap() would incur: >>> > >>> > * a high development effort >>> > * a significant code size increase >>> > * an enlarged attack surface >>> > >>> > For RISC-V it has been clarified in the platform specification that the >>> > SBI must implement the system reset extension. For ARMv8 using TF-A and >>> > PSCI is what ARM suggests. >>> > >>> > So for these architectures we do not expect a growth in the number of >>> > drivers needed. >>> > >>> > Ilias and my favorite would be keeping the design as is. >>> > >>> > What is your view on this? >>> >>> Is U-Boot's UEFI loader implementation supposed to be the recommended >>> UEFI firmware on ARM and RISC-V on a production / deployment system? >> >> For Arm: yes, that is SystemReady spec. >> > > How about EDK II? Is EDK II supposed to be used in the server environment > where UEFI + ACPI is the way to go? > Arm server boot is defined in SystemReady-SR. > Does any board that ships EDK II with UEFI + DTB? > there are boards with EDK II with DTB (Socionext Synquacer has a boot menu to select between ACPI and DT). > Can we safely assume that U-Boot's UEFI loader is the reference > implementation for UEFI + DTB on Arm? > yes: that is SystemReady-IR that Arm, Linaro and SoC vendors have made a reality in the past year and a half. The key benefit is non brickable with anti rollback protection you get of all firmware through the UEFI capsule. The UEFi capsule is complemented by an Arm architecture capsule through FFA interface. You will have a number os SystemReady sessions at the forthcoming Arm Dev Summit. You will also see VMWare supporting SystemReady-ES, and I am hopeful that Andrei@VMware will also support SystemReady-IR. > > >> >>> Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we >>> expect to load grub.efi which chain-loads a kernel without >>> CONFIG_EFI_STUB? >> >> all paths should be possible , and the shim.efi is to be supported too. >> With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In >> other words I don’t see grub.efi booting a non config_efi_stub. >> >>> What do distributions normally do? >> >> At least Red Hat made it clear at multiple Linaro Connect that they want >> standards, and SystemReady is one that makes the life of embedded distros >> easy. >> Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi >> SecureBoot. >> >>> What's our >>> position when compared to EDK II? >> >> the typical distro boot flow is not the most efficient and drags concept >> dating where the Microsoft certs had to be part of the picture. A direct >> U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path >> (grub), avoids convoluted platform cert management (shim) and just enhance >> security and boot time. Note: Since kernel 5.10, initrd can be measured >> (with TPM) when loaded by efi-stub. >> > > Regards, > Bin > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: Driver model at UEFI runtime
Le jeu. 30 sept. 2021 à 07:12, Bin Meng a écrit : > Hi Heinrich, > > On Thu, Sep 9, 2021 at 7:16 PM Heinrich Schuchardt > wrote: > > > > Hello Simon, > > > > The EBBR specification requires that the UEFI SystemReset() runtime > > service is available to the operating system. > > > > Up to now this has been implemented by overriding function > > efi_reset_system() which is marked as __efi_runtime. > > > > Both ARM and RISC-V support generic interfaces for reset. PSCI for ARM > > and the System Reset Extension for SBI on RISC-V. This has kept the > > number of implementations low. The only exceptions are: > > > > * arch/arm/cpu/armv8/fsl-layerscape/cpu.c > > * arch/arm/mach-bcm283x/reset.c for the Raspberry PIs > > * arch/sandbox/cpu/start.c > > > > Bin has suggested in > > https://lists.denx.de/pipermail/u-boot/2021-September/459865.html to use > > reset drivers based on the driver model. > > > > Currently after ExitBootServices() the driver model does not exist > anymore. > > > > When evaluating Bin's suggestion one has to keep in mind that after > > invoking ExitBootServices() most operating systems call > > SetVirtualAddressMap(). Due to the change of the address map all > > pointers used by U-Boot afterwards must be updated to match the new > > memory map. > > > > Yeah, this was discussed 3 years ago: > > https://u-boot.denx.narkive.com/mA8xIbLk/efi-loader-runtime-services-implementation-broken > > > The impression that Ilias and I have is that keeping the driver model > > alive after SetVirtualAddressMap() would incur: > > > > * a high development effort > > * a significant code size increase > > * an enlarged attack surface > > > > For RISC-V it has been clarified in the platform specification that the > > SBI must implement the system reset extension. For ARMv8 using TF-A and > > PSCI is what ARM suggests. > > > > So for these architectures we do not expect a growth in the number of > > drivers needed. > > > > Ilias and my favorite would be keeping the design as is. > > > > What is your view on this? > > Is U-Boot's UEFI loader implementation supposed to be the recommended > UEFI firmware on ARM and RISC-V on a production / deployment system? For Arm: yes, that is SystemReady spec. > > Do we expect bootefi to boot a kernel with CONFIG_EFI_STUB, or do we > expect to load grub.efi which chain-loads a kernel without > CONFIG_EFI_STUB? all paths should be possible , and the shim.efi is to be supported too. With UEFI, I always see that UEFI is kept down to OS for SecureBoot. In other words I don’t see grub.efi booting a non config_efi_stub. > What do distributions normally do? At least Red Hat made it clear at multiple Linaro Connect that they want standards, and SystemReady is one that makes the life of embedded distros easy. Distros boot shim.efi, grub.efi, Linux.efi to benefit from UEFi SecureBoot. > What's our > position when compared to EDK II? the typical distro boot flow is not the most efficient and drags concept dating where the Microsoft certs had to be part of the picture. A direct U-Boot Linux.efi is my preferred; avoids yet another OS in the boot path (grub), avoids convoluted platform cert management (shim) and just enhance security and boot time. Note: Since kernel 5.10, initrd can be measured (with TPM) when loaded by efi-stub. > > > Regards, > Bin > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
