On 10/28/21 7:59 PM, Tom Rini wrote:
On Thu, Oct 28, 2021 at 06:50:02PM +0100, Peter Robinson wrote:
On Thu, Oct 28, 2021 at 6:47 PM Tom Rini <tr...@konsulko.com> wrote:
On Thu, Oct 28, 2021 at 06:37:42PM +0100, Peter Robinson wrote:
On Wed, Oct 27, 2021 at 3:11 PM Simon Glass <s...@chromium.org> wrote:
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?
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?
Is this question from the board PoV, the developer of U-Boot or the
distro trying to boot?
If you mean from a boot flow PoV for UEFI to find the HW that contains
the OS to boot I thought that was handled elsewhere in the series.
What I mean is that today looking at Pi we have:
#define BOOT_TARGET_DEVICES(func) \
BOOT_TARGET_MMC(func) \
BOOT_TARGET_USB(func) \
BOOT_TARGET_PXE(func) \
BOOT_TARGET_DHCP(func)
As the board maintainer set that as the list of places to start looking
for the next payload (say the GRUB EFI binary). Simon's series replaces
that with I think he said "bootflow scan -b". And then the above env
portion is replaced with, well, what's documented in patch #40 if you
don't just want to rely on device probe order.
Because we need to have _something_ that says where to look for what,
yes? Or should that be replaced entirely with efi vars and
BootOrder/BootXXX and "bootefi bootmgr $fdt_addr_r" ?
UEFI variables must be supported for booting via UEFI. But if no valid
image can be found via the UEFI variables you have to scan the EFI
system partition for the file EFI/BOOT/BOOT<arch>.EFI and run it. This
requires to scan all block devices for the ESP.
Furthermore not all distributions use UEFI by default on all systems.
Best regards
Heinrich
