Hi Heinrich,
On Wed, 27 Oct 2021 at 05:38, Heinrich Schuchardt heinrich.schuchardt@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 -lbwhich 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.
[..]