Hi Tom, On Thu, 20 Jan 2022 at 18:08, Tom Rini <tr...@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 <tr...@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 <tr...@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 <tr...@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.kette...@xs4all.nl> wrote: > > > > > > > > > > > > > > > > > > > From: Michael Walle <mich...@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. Regards, Simon
