From: Simon Glass sjg@chromium.org Date: Thu, 20 Jan 2022 20:12:41 -0700
Hi Tom,
On Thu, 20 Jan 2022 at 18:08, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 20, 2022 at 05:59:53PM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 20 Jan 2022 at 16:23, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 20, 2022 at 01:47:41PM -0700, Simon Glass wrote:
Hi Tom,
On Thu, 20 Jan 2022 at 13:08, Tom Rini trini@konsulko.com wrote:
On Thu, Jan 20, 2022 at 12:56:55PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 20 Jan 2022 at 11:30, Tom Rini trini@konsulko.com wrote: > > > > On Thu, Jan 20, 2022 at 11:16:35AM -0700, Simon Glass wrote: > > > Hi Mark, > > > > > > On Thu, 20 Jan 2022 at 03:29, Mark Kettenis mark.kettenis@xs4all.nl wrote: > > > > > > > > > From: Michael Walle michael@walle.cc > > > > > Date: Thu, 20 Jan 2022 09:35:44 +0100 > > > > > > > > > > > The bootdevs have a natural priority, based on the assumed speed of > > > > > > the device, so the board would only need to intervene (with an env var > > > > > > or a devicetree property) when that is wrong. > > > > > > > > > > Does this make sense in general? The default boot order for a > > > > > board should depend on what is available on board (or on the > > > > > carrier board) and what is pluggable. I doubt there can be a sane > > > > > default, so almost all boards will have to define its own > > > > > boot order anyway. > > > > > > Please can you be more specific about what you the problem is here? If > > > the board does not have a device then it will not exist in driver > > > model (or will not probe) and it won't have a bootdev (or it won't > > > probe). That seems to be equivalent to me. > > > > So, I'm not sure how much of a problem it is, since the board can still > > define the default probe order via environment. But pick any random SoC > > with more than 1 SD/MMC set of lines on the chip. Youboard may put the > > first as SD slot and second as eMMC and Myboard may do the opposite and > > both are going to probe in the same order since it's the same chip. > > > > That's what I think Mark is getting at with it not really making sense > > to just rely on probe order as what to try. > > Doesn't the 'non-removable' flag describe this feature of the hardware? > > If you don't want to rely on the normal ordering, you can set the > boot_targets variable. I'd just like to avoid that being required for > 'normal' boards and situations.
I think setting things via the environment to have correct defaults is a must. I mean, yes, OK, if there's some device tree binding that we can use that describes this, sure, that's choice A. But choice B would probably be environment strings. Probe and hope is choice C, or more like last resort, imho.
Well the boot_targets var is implemented in this series.
The question is whether we force platforms to define it, or have a way to handle things gracefully by default.
I think we need to force it to be defined until / unless there's some agreed on standard to provide that information at run time.
Well we can do that with a cut-down distro header with some macros, I suppose?
Sorry? I mean, when I said standard above, and since you had mentioned from the device tree before (I thought..) I mean get some property defined and accepted and use that for first best path. Then keep using
I think this discussion is a bit beyond the scope of this series. You are talking about the policy for the bootdev selection. So far, implemented in this series, we have, in order of preference:
- boot_targets env var
- bootdev-order device tree property (which you are referring to here)
- priority order (as announced by each bootdev, i.e. it can depend on
removable flags, etc.)
- alias order (using device tree)
- simple sequence order (position in device tree, or order in which
devices were bound)
I think that is enough to be getting on with. My point above was that if we want to define the boot_targets env var in a header file as now, we could.
boot_targets and make sure it's documented (and in help, etc) that boards should define that in their default environment for a preferred fallback default boot order. The final fall back of "probe and guess" might need an off switch for securing systems, I'm not sure.
Yes we need to be careful about that. But for now my intent is to make it possible to migrate from the scripts. Once we have the basics in place we can expand it and I suspect people will find it a lot easier to work with.
Also see BOOTFLOWF_FIXED for example, which isn't implemented, but is intended to allow devices to be filtered based on whether they are internal to the device or not.
I think what is important here is that when a board gets converted to the new mechanism, the order remains the same as before. With the approach taken by Simon that will take some effort. That's why I thought that keeping the existing macros but redefining them to just produce the boot_targets environment variable instead of the complicated script we have now would be a good idea.
Regarding encoding the boot order in the device tree, I must say that the proposed bindings look a bit strange to me with the use of compatible strings for things that are essentially user-settable options. I also don't entirely see why boot device selection should be u-boot-specific. There actually is a precedent here set by Open Firmware. In Open Firmware you select the boot order by setting the "boot-device" variable that appears as a property of the /options node in the device tree. This variable is a list of boot devices very similar to the boot_targets variable that U-Boot has. The items in this list are separated by spaces (like boot_targets) and the are in principle full device tree paths specifying devices. But aliases (as defined in the /aliases node) can be used as well.