On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote:
On Wed, Oct 27, 2021 at 3:11 PM Simon Glass sjg@chromium.org wrote:
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?
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?