Hi Tom Le jeu. 28 oct. 2021 à 20:27, Tom Rini <tr...@konsulko.com> a écrit :
> On Thu, Oct 28, 2021 at 08:17:50PM +0200, François Ozog wrote: > > Hi Tom, > > > > Le jeu. 28 oct. 2021 à 19:59, Tom Rini <tr...@konsulko.com> a écrit : > > > > > 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? > > > > Shouldn’t we describe the user point of view ? > > No, because to extend the x86 metaphor we're talking about the defaults > here, not what the user has configured later on. The user has and > continues to be able to configure the system afterwards, if desired. > Sorry , missed this “detail”… > > -- > Tom > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
