Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom, On Thu, 28 Oct 2021 at 16:50, Tom Rini wrote: > > On Thu, Oct 28, 2021 at 04:22:11PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 28 Oct 2021 at 13:19, Tom Rini wrote: > > > > > > On Thu, Oct 28, 2021 at 12:48:50PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > > > > > > > > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > > > I'm going to break my feedback down in to a few threads, to > > > > > > > > > hopefully > > > > > > > > > not confuse things too much. My first comment is that > > > > > > > > > rpi_arm64 grows > > > > > > > > > in size by 17 kilobytes, with the whole series (pxe, env, > > > > > > > > > this) applied. > > > > > > > > > And while there's a few small changes in the pxe cleanup I'm > > > > > > > > > going to > > > > > > > > > re-investigate on their own, it's really just this series, > > > > > > > > > right here, > > > > > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > > > > > environment scripting, with C. It's not even the earlier > > > > > > > > > parts of the > > > > > > > > > series to clean up / prepare, it starts at "bootstd: Add the > > > > > > > > > bootstd > > > > > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > > > > > commands are disabled or simplified, e.g. to only support > > > > > > > > 'bootflow > > > > > > > > scan -b'. At the moment it enables all dev features. > > > > > > > > > > > > > > OK, for the next go-round yes, please show what a typical > > > > > > > enablement > > > > > > > would look like on Pi, for example. > > > > > > > > > > > > OK. Do understand that conceiving of this and implementing it is > > > > > > quite > > > > > > a bit of effort. At some point I just send things out, to get > > > > > > feedback > > > > > > and to think some more. Apart from anything else, there is a risk of > > > > > > going into the weeds or never finishing it. > > > > > > > > > > > > > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment > > > > > > > > goes > > > > > > > > drops by 3.5KB. > > > > > > > > > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is > > > > > > > not a > > > > > > > win. > > > > > > > > > > > > Certainly not on size! On testing, debug, visibility and control of > > > > > > the boot process, there are wins. > > > > > > > > > > I'm not sure if there's wins on those grounds either, and certainly > > > > > not > > > > > enough to justify what this adds. > > > > > > > > > > > > > We should compare this with the EFI support which is about > > > > > > > > 90KB, as I recall. > > > > > > > > > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > > > > > replacing the generic distro boot macros, so that's what the size > > > > > > > comparison is to. At the end of the day, and looking towards > > > > > > > non-legacy > > > > > > > uses, a big common use case is "Find the EFI app to run". > > > > > > > > > > > > I just mean that EFI has been accepted as part of U-Boot and adds > > > > > >
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Thu, Oct 28, 2021 at 04:22:11PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 28 Oct 2021 at 13:19, Tom Rini wrote: > > > > On Thu, Oct 28, 2021 at 12:48:50PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > > > > > > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > > > I'm going to break my feedback down in to a few threads, to > > > > > > > > hopefully > > > > > > > > not confuse things too much. My first comment is that > > > > > > > > rpi_arm64 grows > > > > > > > > in size by 17 kilobytes, with the whole series (pxe, env, this) > > > > > > > > applied. > > > > > > > > And while there's a few small changes in the pxe cleanup I'm > > > > > > > > going to > > > > > > > > re-investigate on their own, it's really just this series, > > > > > > > > right here, > > > > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > > > > environment scripting, with C. It's not even the earlier parts > > > > > > > > of the > > > > > > > > series to clean up / prepare, it starts at "bootstd: Add the > > > > > > > > bootstd > > > > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > > > > commands are disabled or simplified, e.g. to only support > > > > > > > 'bootflow > > > > > > > scan -b'. At the moment it enables all dev features. > > > > > > > > > > > > OK, for the next go-round yes, please show what a typical enablement > > > > > > would look like on Pi, for example. > > > > > > > > > > OK. Do understand that conceiving of this and implementing it is quite > > > > > a bit of effort. At some point I just send things out, to get feedback > > > > > and to think some more. Apart from anything else, there is a risk of > > > > > going into the weeds or never finishing it. > > > > > > > > > > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment > > > > > > > goes > > > > > > > drops by 3.5KB. > > > > > > > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not > > > > > > a > > > > > > win. > > > > > > > > > > Certainly not on size! On testing, debug, visibility and control of > > > > > the boot process, there are wins. > > > > > > > > I'm not sure if there's wins on those grounds either, and certainly not > > > > enough to justify what this adds. > > > > > > > > > > > We should compare this with the EFI support which is about 90KB, > > > > > > > as I recall. > > > > > > > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > > > > replacing the generic distro boot macros, so that's what the size > > > > > > comparison is to. At the end of the day, and looking towards > > > > > > non-legacy > > > > > > uses, a big common use case is "Find the EFI app to run". > > > > > > > > > > I just mean that EFI has been accepted as part of U-Boot and adds > > > > > 90KB. > > > > > > > > OK? I still don't see the relevance here. > > > > > > > > > > > If we continue down the path of making this feature use U-Boot > > > > > > > functions directly, instead the command line, I suspect we can > > > > > > > save > > > > > > > quite a bit more, since there is a lot of overhead with these > > > > > > >
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom, On Thu, 28 Oct 2021 at 13:19, Tom Rini wrote: > > On Thu, Oct 28, 2021 at 12:48:50PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > > > > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > > > > > > > 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. > > > > > > > > > > > > > > I'm going to break my feedback down in to a few threads, to > > > > > > > hopefully > > > > > > > not confuse things too much. My first comment is that rpi_arm64 > > > > > > > grows > > > > > > > in size by 17 kilobytes, with the whole series (pxe, env, this) > > > > > > > applied. > > > > > > > And while there's a few small changes in the pxe cleanup I'm > > > > > > > going to > > > > > > > re-investigate on their own, it's really just this series, right > > > > > > > here, > > > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > > > environment scripting, with C. It's not even the earlier parts > > > > > > > of the > > > > > > > series to clean up / prepare, it starts at "bootstd: Add the > > > > > > > bootstd > > > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > > > commands are disabled or simplified, e.g. to only support 'bootflow > > > > > > scan -b'. At the moment it enables all dev features. > > > > > > > > > > OK, for the next go-round yes, please show what a typical enablement > > > > > would look like on Pi, for example. > > > > > > > > OK. Do understand that conceiving of this and implementing it is quite > > > > a bit of effort. At some point I just send things out, to get feedback > > > > and to think some more. Apart from anything else, there is a risk of > > > > going into the weeds or never finishing it. > > > > > > > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment goes > > > > > > drops by 3.5KB. > > > > > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not a > > > > > win. > > > > > > > > Certainly not on size! On testing, debug, visibility and control of > > > > the boot process, there are wins. > > > > > > I'm not sure if there's wins on those grounds either, and certainly not > > > enough to justify what this adds. > > > > > > > > > We should compare this with the EFI support which is about 90KB, as > > > > > > I recall. > > > > > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > > > replacing the generic distro boot macros, so that's what the size > > > > > comparison is to. At the end of the day, and looking towards > > > > > non-legacy > > > > > uses, a big common use case is "Find the EFI app to run". > > > > > > > > I just mean that EFI has been accepted as part of U-Boot and adds 90KB. > > > > > > OK? I still don't see the relevance here. > > > > > > > > > If we continue down the path of making this feature use U-Boot > > > > > > functions directly, instead the command line, I suspect we can save > > > > > > quite a bit more, since there is a lot of overhead with these > > > > > > commands. At present it is impossible to boot without CONFIG_CMDLINE > > > > > > enabled, for example. > > > > > > > > > > Yes, this should be using the API and not the command interface. > > > > > > > > Right, but that's not something I am taking on right now. The PXE > > > > refactoring gives an idea of what is needed. I did that work mainly > > > > because
Re: [PATCH v2 00/41] Initial implementation of standard boot
> Date: Thu, 28 Oct 2021 13:47:21 -0400 > From: Tom Rini > > 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? Before we had "bootefi bootmgr", this was done using "setenv boot_targets ...", where you would specify a list of devices to try and boot from. This is effectively a command line version of the menu that most x86 BIOS (and UEFI) implementations offer to specify the order of devices to boot from. We document this in the OpenBSD/arm64 installtion instructions and it wouldn't surprise me of some of the Linux distro's do this as well. This still works fine, unless you set the UEFI variables that "bootefi bootmgr" looks at. But I fear Simon's patch series breaks this. I didn't try the patch series yet though, so I might be mistaken. When "bootefi bootmgr" is used, the device/OS to boot is specified by the Boot and BootOrder UEFI variables. I believe these can be set from the U-Boot command line, but doing so in the right way isn't trivial. The way this is supposed to work I think is that the OS installer defines an appropriate Boot variable and adds it to tje BootOrder variable. But that pretty much relies on on the ability to set those variables at OS runtime using EFI runtime services. And as was pointed out that doesn't really work for most U-Boot targets. To be honest, I don't really understand how "bootefi bootmgr" is used in the real world right now. There is a lot of good work done in this area in U-Boot. But I get the feeling that too much of it is driven by meeting requirements of specs and that there is too little thought put into the practicalities of actually booting a general purpose OS (e.g. a mainstrain Linux distro) on a board with U-Boot support.
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Thu, Oct 28, 2021 at 12:48:50PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > > > > > 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. > > > > > > > > > > > > I'm going to break my feedback down in to a few threads, to > > > > > > hopefully > > > > > > not confuse things too much. My first comment is that rpi_arm64 > > > > > > grows > > > > > > in size by 17 kilobytes, with the whole series (pxe, env, this) > > > > > > applied. > > > > > > And while there's a few small changes in the pxe cleanup I'm going > > > > > > to > > > > > > re-investigate on their own, it's really just this series, right > > > > > > here, > > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > > environment scripting, with C. It's not even the earlier parts of > > > > > > the > > > > > > series to clean up / prepare, it starts at "bootstd: Add the bootstd > > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > > commands are disabled or simplified, e.g. to only support 'bootflow > > > > > scan -b'. At the moment it enables all dev features. > > > > > > > > OK, for the next go-round yes, please show what a typical enablement > > > > would look like on Pi, for example. > > > > > > OK. Do understand that conceiving of this and implementing it is quite > > > a bit of effort. At some point I just send things out, to get feedback > > > and to think some more. Apart from anything else, there is a risk of > > > going into the weeds or never finishing it. > > > > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment goes > > > > > drops by 3.5KB. > > > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not a > > > > win. > > > > > > Certainly not on size! On testing, debug, visibility and control of > > > the boot process, there are wins. > > > > I'm not sure if there's wins on those grounds either, and certainly not > > enough to justify what this adds. > > > > > > > We should compare this with the EFI support which is about 90KB, as I > > > > > recall. > > > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > > replacing the generic distro boot macros, so that's what the size > > > > comparison is to. At the end of the day, and looking towards non-legacy > > > > uses, a big common use case is "Find the EFI app to run". > > > > > > I just mean that EFI has been accepted as part of U-Boot and adds 90KB. > > > > OK? I still don't see the relevance here. > > > > > > > If we continue down the path of making this feature use U-Boot > > > > > functions directly, instead the command line, I suspect we can save > > > > > quite a bit more, since there is a lot of overhead with these > > > > > commands. At present it is impossible to boot without CONFIG_CMDLINE > > > > > enabled, for example. > > > > > > > > Yes, this should be using the API and not the command interface. > > > > > > Right, but that's not something I am taking on right now. The PXE > > > refactoring gives an idea of what is needed. I did that work mainly > > > because I don't like adding to code that desperately needs > > > refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but > > > that might take a year. > > > > Well, maybe this particular part of things get set aside for now, and > > the generic distro boot framework just needs to be moved to the env > > update you
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom, On Thu, 28 Oct 2021 at 12:36, Tom Rini wrote: > > On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > > > 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. > > > > > > > > > > I'm going to break my feedback down in to a few threads, to hopefully > > > > > not confuse things too much. My first comment is that rpi_arm64 grows > > > > > in size by 17 kilobytes, with the whole series (pxe, env, this) > > > > > applied. > > > > > And while there's a few small changes in the pxe cleanup I'm going to > > > > > re-investigate on their own, it's really just this series, right here, > > > > > adding tons of code. To replace an admittedly complex bit of > > > > > environment scripting, with C. It's not even the earlier parts of the > > > > > series to clean up / prepare, it starts at "bootstd: Add the bootstd > > > > > uclass and core implementation" and keeps going from there. > > > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > > commands are disabled or simplified, e.g. to only support 'bootflow > > > > scan -b'. At the moment it enables all dev features. > > > > > > OK, for the next go-round yes, please show what a typical enablement > > > would look like on Pi, for example. > > > > OK. Do understand that conceiving of this and implementing it is quite > > a bit of effort. At some point I just send things out, to get feedback > > and to think some more. Apart from anything else, there is a risk of > > going into the weeds or never finishing it. > > > > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment goes > > > > drops by 3.5KB. > > > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not a > > > win. > > > > Certainly not on size! On testing, debug, visibility and control of > > the boot process, there are wins. > > I'm not sure if there's wins on those grounds either, and certainly not > enough to justify what this adds. > > > > > We should compare this with the EFI support which is about 90KB, as I > > > > recall. > > > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > > replacing the generic distro boot macros, so that's what the size > > > comparison is to. At the end of the day, and looking towards non-legacy > > > uses, a big common use case is "Find the EFI app to run". > > > > I just mean that EFI has been accepted as part of U-Boot and adds 90KB. > > OK? I still don't see the relevance here. > > > > > If we continue down the path of making this feature use U-Boot > > > > functions directly, instead the command line, I suspect we can save > > > > quite a bit more, since there is a lot of overhead with these > > > > commands. At present it is impossible to boot without CONFIG_CMDLINE > > > > enabled, for example. > > > > > > Yes, this should be using the API and not the command interface. > > > > Right, but that's not something I am taking on right now. The PXE > > refactoring gives an idea of what is needed. I did that work mainly > > because I don't like adding to code that desperately needs > > refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but > > that might take a year. > > Well, maybe this particular part of things get set aside for now, and > the generic distro boot framework just needs to be moved to the env > update you did. > > > > > In any case, I think this feature is filling a gap in U-Boot since at > > > > present everything about boot is ad-hoc. This gives us a base to build > > > > on. Nothing is for free. > > > > > > I disagree. At present, booting is either intentionally per-board, or > > > it's using the generic distro boot framework. That framework is what to > > >
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Thu, Oct 28, 2021 at 12:13:56PM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > > > 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. > > > > > > > > I'm going to break my feedback down in to a few threads, to hopefully > > > > not confuse things too much. My first comment is that rpi_arm64 grows > > > > in size by 17 kilobytes, with the whole series (pxe, env, this) applied. > > > > And while there's a few small changes in the pxe cleanup I'm going to > > > > re-investigate on their own, it's really just this series, right here, > > > > adding tons of code. To replace an admittedly complex bit of > > > > environment scripting, with C. It's not even the earlier parts of the > > > > series to clean up / prepare, it starts at "bootstd: Add the bootstd > > > > uclass and core implementation" and keeps going from there. > > > > > > Yes it does add a lot of code, although it is a lot less if the > > > commands are disabled or simplified, e.g. to only support 'bootflow > > > scan -b'. At the moment it enables all dev features. > > > > OK, for the next go-round yes, please show what a typical enablement > > would look like on Pi, for example. > > OK. Do understand that conceiving of this and implementing it is quite > a bit of effort. At some point I just send things out, to get feedback > and to think some more. Apart from anything else, there is a risk of > going into the weeds or never finishing it. > > > > > > It does save a small amount of data. E.g. rpi_3_32b environment goes > > > drops by 3.5KB. > > > > So we're replacing 3.5KB of scripts with 17KB of code. That is not a > > win. > > Certainly not on size! On testing, debug, visibility and control of > the boot process, there are wins. I'm not sure if there's wins on those grounds either, and certainly not enough to justify what this adds. > > > We should compare this with the EFI support which is about 90KB, as I > > > recall. > > > > No, we shouldn't. This isn't about replacing EFI, this is about > > replacing the generic distro boot macros, so that's what the size > > comparison is to. At the end of the day, and looking towards non-legacy > > uses, a big common use case is "Find the EFI app to run". > > I just mean that EFI has been accepted as part of U-Boot and adds 90KB. OK? I still don't see the relevance here. > > > If we continue down the path of making this feature use U-Boot > > > functions directly, instead the command line, I suspect we can save > > > quite a bit more, since there is a lot of overhead with these > > > commands. At present it is impossible to boot without CONFIG_CMDLINE > > > enabled, for example. > > > > Yes, this should be using the API and not the command interface. > > Right, but that's not something I am taking on right now. The PXE > refactoring gives an idea of what is needed. I did that work mainly > because I don't like adding to code that desperately needs > refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but > that might take a year. Well, maybe this particular part of things get set aside for now, and the generic distro boot framework just needs to be moved to the env update you did. > > > In any case, I think this feature is filling a gap in U-Boot since at > > > present everything about boot is ad-hoc. This gives us a base to build > > > on. Nothing is for free. > > > > I disagree. At present, booting is either intentionally per-board, or > > it's using the generic distro boot framework. That framework is what to > > further build on or perhaps make more readily simplified (for example, > > making it just be "scan around for EFI" or just be "scan around of > > extlinux.conf"). > > Well if the Universal Bootloader is only going to exist to boot EFI, > then we should rename it :-) > > I am not sure that
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
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. -- Tom signature.asc Description: PGP signature
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 v2 00/41] Initial implementation of standard boot
Hi Tom, On Thu, 28 Oct 2021 at 11:52, Tom Rini wrote: > > On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > > > 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. > > > > > > I'm going to break my feedback down in to a few threads, to hopefully > > > not confuse things too much. My first comment is that rpi_arm64 grows > > > in size by 17 kilobytes, with the whole series (pxe, env, this) applied. > > > And while there's a few small changes in the pxe cleanup I'm going to > > > re-investigate on their own, it's really just this series, right here, > > > adding tons of code. To replace an admittedly complex bit of > > > environment scripting, with C. It's not even the earlier parts of the > > > series to clean up / prepare, it starts at "bootstd: Add the bootstd > > > uclass and core implementation" and keeps going from there. > > > > Yes it does add a lot of code, although it is a lot less if the > > commands are disabled or simplified, e.g. to only support 'bootflow > > scan -b'. At the moment it enables all dev features. > > OK, for the next go-round yes, please show what a typical enablement > would look like on Pi, for example. OK. Do understand that conceiving of this and implementing it is quite a bit of effort. At some point I just send things out, to get feedback and to think some more. Apart from anything else, there is a risk of going into the weeds or never finishing it. > > > It does save a small amount of data. E.g. rpi_3_32b environment goes > > drops by 3.5KB. > > So we're replacing 3.5KB of scripts with 17KB of code. That is not a > win. Certainly not on size! On testing, debug, visibility and control of the boot process, there are wins. > > > We should compare this with the EFI support which is about 90KB, as I > > recall. > > No, we shouldn't. This isn't about replacing EFI, this is about > replacing the generic distro boot macros, so that's what the size > comparison is to. At the end of the day, and looking towards non-legacy > uses, a big common use case is "Find the EFI app to run". I just mean that EFI has been accepted as part of U-Boot and adds 90KB. > > > If we continue down the path of making this feature use U-Boot > > functions directly, instead the command line, I suspect we can save > > quite a bit more, since there is a lot of overhead with these > > commands. At present it is impossible to boot without CONFIG_CMDLINE > > enabled, for example. > > Yes, this should be using the API and not the command interface. Right, but that's not something I am taking on right now. The PXE refactoring gives an idea of what is needed. I did that work mainly because I don't like adding to code that desperately needs refactoring. We need to do the same for dhcp, EFI and bootm/zboot, but that might take a year. > > > In any case, I think this feature is filling a gap in U-Boot since at > > present everything about boot is ad-hoc. This gives us a base to build > > on. Nothing is for free. > > I disagree. At present, booting is either intentionally per-board, or > it's using the generic distro boot framework. That framework is what to > further build on or perhaps make more readily simplified (for example, > making it just be "scan around for EFI" or just be "scan around of > extlinux.conf"). Well if the Universal Bootloader is only going to exist to boot EFI, then we should rename it :-) I am not sure that anyone wants something intentionally per-board, it's just that everything about the boot in U-Boot is really low-level (bootm, fixed addresses, etc.) We need the layer on top that can deal with these silly details. For example, yes there is a Chrome OS boot script in chromebook_coral, but it is the same on all devices. I would rather just enable that bootmethod so that if Chrome OS is present it will boot. Re the memory side, i don't like the vars that define the kernel address, FDT address, etc. It seems to me that most/all are unnecessary, if there is
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Thu, Oct 28, 2021 at 08:09:35PM +0200, Heinrich Schuchardt wrote: > On 10/28/21 7:59 PM, Tom Rini wrote: > > 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? Or should that be replaced entirely with efi vars and > > BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ? > > > > UEFI variables must be supported for booting via UEFI. But if no valid > image can be found via the UEFI variables you have to scan the EFI > system partition for the file EFI/BOOT/BOOT.EFI and run it. This > requires to scan all block devices for the ESP. > > Furthermore not all distributions use UEFI by default on all systems. Assume a UEFI distribution for the moment. What should the default boot command look like, these
Re: [PATCH v2 00/41] Initial implementation of standard boot
On 10/28/21 7:59 PM, Tom Rini wrote: 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? Or should that be replaced entirely with efi vars and BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ? UEFI variables must be supported for booting via UEFI. But if no valid image can be found via the UEFI variables you have to scan the EFI system partition for the file EFI/BOOT/BOOT.EFI and run it. This requires to scan all block devices for the ESP. Furthermore not all distributions use UEFI by default on all systems. Best regards Heinrich
Re: [PATCH v2 00/41] Initial implementation of standard boot
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? Or should that be replaced entirely with efi vars and BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Thu, Oct 28, 2021 at 11:29:35AM -0600, Simon Glass wrote: > Hi Tom, > > On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > > > 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. > > > > I'm going to break my feedback down in to a few threads, to hopefully > > not confuse things too much. My first comment is that rpi_arm64 grows > > in size by 17 kilobytes, with the whole series (pxe, env, this) applied. > > And while there's a few small changes in the pxe cleanup I'm going to > > re-investigate on their own, it's really just this series, right here, > > adding tons of code. To replace an admittedly complex bit of > > environment scripting, with C. It's not even the earlier parts of the > > series to clean up / prepare, it starts at "bootstd: Add the bootstd > > uclass and core implementation" and keeps going from there. > > Yes it does add a lot of code, although it is a lot less if the > commands are disabled or simplified, e.g. to only support 'bootflow > scan -b'. At the moment it enables all dev features. OK, for the next go-round yes, please show what a typical enablement would look like on Pi, for example. > It does save a small amount of data. E.g. rpi_3_32b environment goes > drops by 3.5KB. So we're replacing 3.5KB of scripts with 17KB of code. That is not a win. > We should compare this with the EFI support which is about 90KB, as I recall. No, we shouldn't. This isn't about replacing EFI, this is about replacing the generic distro boot macros, so that's what the size comparison is to. At the end of the day, and looking towards non-legacy uses, a big common use case is "Find the EFI app to run". > If we continue down the path of making this feature use U-Boot > functions directly, instead the command line, I suspect we can save > quite a bit more, since there is a lot of overhead with these > commands. At present it is impossible to boot without CONFIG_CMDLINE > enabled, for example. Yes, this should be using the API and not the command interface. > In any case, I think this feature is filling a gap in U-Boot since at > present everything about boot is ad-hoc. This gives us a base to build > on. Nothing is for free. I disagree. At present, booting is either intentionally per-board, or it's using the generic distro boot framework. That framework is what to further build on or perhaps make more readily simplified (for example, making it just be "scan around for EFI" or just be "scan around of extlinux.conf"). > Anyway, I can look at what the minimum size is with the above points > and send that info through. I looked at the PXE stuff, and I think the minimal growth there ends up being reasonable, fwiw. It comes down to adding sanity checks in places where the code wasn't always sanity checking, as you reduced duplication. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/41] Initial implementation of standard boot
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.
Re: [PATCH v2 00/41] Initial implementation of standard boot
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? -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/41] Initial implementation of standard boot
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. I do actually like a bunch of the ideas in here, random scripts in distro_boot were a big step forward for straight forward booting a decade or so when everything prior was random board specific boot.scr and uImage but things have evolved into booting via UEFI which is very standard across the general purpose compute devices style industries and clearing up the random behind the scenes hush scripting is definitely long overdue but I don't feel there needs to be another layer of unnecessary indirection here. > - Move all this stuff out of the environment so we can move to a > text-based environment that doesn't rely on ad-hoc CONFIG options >(this unblocks the 7-year-old CONFIG migration) > - Add proper tests to cover this important functionality (the scripts > have no tests) >(this makes development much easier and faster) > - Provide a path to booting more 'directly' without needing the CLI > (which adds size / security risk) > > This initial series is not the end of the matter. I expect various > other people will contribute to cover their use cases and additional > features, but at least now we have good basis for this development and > innovation. > > [..] > > Regards, > Simon
Re: [PATCH v2 00/41] Initial implementation of standard boot
Hi Tom, On Thu, 28 Oct 2021 at 10:27, Tom Rini wrote: > > On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > > > 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. > > I'm going to break my feedback down in to a few threads, to hopefully > not confuse things too much. My first comment is that rpi_arm64 grows > in size by 17 kilobytes, with the whole series (pxe, env, this) applied. > And while there's a few small changes in the pxe cleanup I'm going to > re-investigate on their own, it's really just this series, right here, > adding tons of code. To replace an admittedly complex bit of > environment scripting, with C. It's not even the earlier parts of the > series to clean up / prepare, it starts at "bootstd: Add the bootstd > uclass and core implementation" and keeps going from there. Yes it does add a lot of code, although it is a lot less if the commands are disabled or simplified, e.g. to only support 'bootflow scan -b'. At the moment it enables all dev features. It does save a small amount of data. E.g. rpi_3_32b environment goes drops by 3.5KB. We should compare this with the EFI support which is about 90KB, as I recall. If we continue down the path of making this feature use U-Boot functions directly, instead the command line, I suspect we can save quite a bit more, since there is a lot of overhead with these commands. At present it is impossible to boot without CONFIG_CMDLINE enabled, for example. In any case, I think this feature is filling a gap in U-Boot since at present everything about boot is ad-hoc. This gives us a base to build on. Nothing is for free. Anyway, I can look at what the minimum size is with the above points and send that info through. Regards, Simon
Re: [PATCH v2 00/41] Initial implementation of standard boot
On Sat, Oct 23, 2021 at 05:25:54PM -0600, 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) > > 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. I'm going to break my feedback down in to a few threads, to hopefully not confuse things too much. My first comment is that rpi_arm64 grows in size by 17 kilobytes, with the whole series (pxe, env, this) applied. And while there's a few small changes in the pxe cleanup I'm going to re-investigate on their own, it's really just this series, right here, adding tons of code. To replace an admittedly complex bit of environment scripting, with C. It's not even the earlier parts of the series to clean up / prepare, it starts at "bootstd: Add the bootstd uclass and core implementation" and keeps going from there. -- Tom signature.asc Description: PGP signature
Re: [PATCH v2 00/41] Initial implementation of standard boot
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? See previous email in thread. Continuing here on a few of your other points... > > 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? We already have this with distro boot, so nothing really changes there. Think of this as a generalised 'standard boot' implementation, which can support distro boot and anything else we need in the future. There is nothing required in the devicetree for normal operation. > > You still have an open discussion with Linaro about the source of > devicetrees. This discussion needs to be finalized before considering > this series. Why is that? They don't seem to be at all related to me. > > 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. See previous post, they are not defined in the devicetree. Can you suggest how I can change the language to make that clear? Regards, Simon > > > > > 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. > > > > [..]
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 v2 00/41] Initial implementation of standard boot
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) - Move all this stuff out of the environment so we can move to a text-based environment that doesn't rely on ad-hoc CONFIG options (this unblocks the 7-year-old CONFIG migration) - Add proper tests to cover this important functionality (the scripts have no tests) (this makes development much easier and faster) - Provide a path to booting more 'directly' without needing the CLI (which adds size / security risk) This initial series is not the end of the matter. I expect various other people will contribute to cover their use cases and additional features, but at least now we have good basis for this development and innovation. [..] Regards, Simon
Re: [PATCH v2 00/41] Initial implementation of standard boot
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. 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 'mmc@7e202000.bootmethod': 0 efi-loader loaded mmc 1 mmc@7e202000.bootmethod.p efi/boot/bootarm.efi ** Booting bootflow 'mmc@7e202000.bootmethod.part_1' Scanning disk m...@7e202000.blk... ** Unrecognized filesystem type ** Card did not respond to voltage select! : -110 Scanning disk sd...@7e30.blk... Disk sd...@7e30.blk not ready Found 4 disks No EFI system partition Booting /efi\boot Waiting for Ethernet connection... done. Fedora (5.11.12-300.fc34.armv7hl) 34 (Workstation Edition) UEFI Firmware Settings Use the ▲ and ▼ keys to change the selection. Press 'e' to edit the selected item, or 'c' for a command prompt. Press Escape to return to the previous menu. The selected entry will be started automatically in 0s. Changes in v2: - Free the memory buffer, to avoid running out of memory - Unmap the file - Reorder struct sandbox_mmc_priv Simon Glass (41): lib: Add a way to find the postiion of a trailing number Makefile: Allow LTO to be disabled for a build test/py: Allow passing input to a program sandbox: Support unmapping a file sandbox: mmc: Support a backing file mmc: Allow for children
Re: [PATCH v2 00/41] Initial implementation of standard boot
+u-boot-board-maintain...@lists.denx.de +u-boot-custodi...@lists.denx.de On Sat, 23 Oct 2021 at 17:26, 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) > > 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 'mmc@7e202000.bootmethod': > 0 efi-loader loaded mmc 1 mmc@7e202000.bootmethod.p > efi/boot/bootarm.efi > ** Booting bootflow 'mmc@7e202000.bootmethod.part_1' > Scanning disk m...@7e202000.blk... > ** Unrecognized filesystem type ** > Card did not respond to voltage select! : -110 > Scanning disk sd...@7e30.blk... > Disk sd...@7e30.blk not ready > Found 4 disks > No EFI system partition > Booting /efi\boot > Waiting for Ethernet connection... done. > > Fedora (5.11.12-300.fc34.armv7hl) 34 (Workstation Edition) > UEFI Firmware Settings > > Use the ▲ and ▼ keys to change the selection. > Press 'e' to edit the selected item, or 'c' for a command prompt. Press > Escape to return to the previous menu. >The selected entry will be started automatically in 0s. > > Changes in v2: > - Free the memory buffer, to avoid running out of memory > - Unmap the file > - Reorder struct sandbox_mmc_priv > > Simon Glass (41): > lib: Add a way to find the postiion of a trailing number > Makefile: Allow LTO to be disabled for a build > test/py: Allow passing input to a program > sandbox: Support unmapping a file > sandbox: mmc: Support a backing file > mmc: Allow for children other than the block device > mbr: Correct verification check > disk: part_dos: Fix a NULL pointer error > common: Allow a smaller console-recording pre-reloc > dm: core: Add tests for stringlist functions > dm: core: Fix handling of uclass pre_unbind method > dm: core: Fix up string-function documentation > dm: core: Add a way to obtain a string list > dm: core: Allow finding children / uclasses by partial name > dm: core: Add a way to count the devices in a uclass > sandbox: Enable HEXDUMP for sandbox_flattree > test/py:
[PATCH v2 00/41] Initial implementation of standard boot
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) 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 'mmc@7e202000.bootmethod': 0 efi-loader loaded mmc 1 mmc@7e202000.bootmethod.p efi/boot/bootarm.efi ** Booting bootflow 'mmc@7e202000.bootmethod.part_1' Scanning disk m...@7e202000.blk... ** Unrecognized filesystem type ** Card did not respond to voltage select! : -110 Scanning disk sd...@7e30.blk... Disk sd...@7e30.blk not ready Found 4 disks No EFI system partition Booting /efi\boot Waiting for Ethernet connection... done. Fedora (5.11.12-300.fc34.armv7hl) 34 (Workstation Edition) UEFI Firmware Settings Use the ▲ and ▼ keys to change the selection. Press 'e' to edit the selected item, or 'c' for a command prompt. Press Escape to return to the previous menu. The selected entry will be started automatically in 0s. Changes in v2: - Free the memory buffer, to avoid running out of memory - Unmap the file - Reorder struct sandbox_mmc_priv Simon Glass (41): lib: Add a way to find the postiion of a trailing number Makefile: Allow LTO to be disabled for a build test/py: Allow passing input to a program sandbox: Support unmapping a file sandbox: mmc: Support a backing file mmc: Allow for children other than the block device mbr: Correct verification check disk: part_dos: Fix a NULL pointer error common: Allow a smaller console-recording pre-reloc dm: core: Add tests for stringlist functions dm: core: Fix handling of uclass pre_unbind method dm: core: Fix up string-function documentation dm: core: Add a way to obtain a string list dm: core: Allow finding children / uclasses by partial name dm: core: Add a way to count the devices in a uclass sandbox: Enable HEXDUMP for sandbox_flattree test/py: Relax the naming rules for unit tests test/py: Raise a ValueError if a command fails bootstd: Add the concept of a bootflow bootstd: Add the bootstd uclass and core implementation bootstd: Add the bootdev uclass bootstd: Add the bootmeth uclass and helpers bootstd: Add support for bootflows bootstd: Add a bootdev command bootstd:
