Hi Heinrich, On Wed, 27 Oct 2021 at 05: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?
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. > > > > [..]