Hi Tom, On Thu, 28 Oct 2021 at 10:27, Tom Rini <tr...@konsulko.com> 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
