Hi Tom, On Thu, 28 Oct 2021 at 11:52, Tom Rini <[email protected]> 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 <[email protected]> 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 something able to deal with memory allocatoin automatically. Perhaps we should use malloc() more, or use LMB more proactively. Even for custom flows, creating a bootmethod will have advantages, I think. The other thing is that this allows further innovation. For verified boot, it makes it possible to sensibly deal with A/B;recovery, whereas at present that is all just scripting, certainly not handled by distro boot. > > > 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. Yes and perhaps the growth can be reduced, too. Regards, Simon
