Hi Tom, On Fri, 21 Jan 2022 at 08:05, Tom Rini <tr...@konsulko.com> wrote: > > On Thu, Jan 20, 2022 at 08:12:41PM -0700, Simon Glass wrote: > > 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: > > I still owe comments on the concept, but I want to make sure we don't > end up in another case where we ad-hoc something for device tree and > keep building off of it without it being made official.
Yes, the bootstd node itself is currently ad-hoc, as are the bootdev devices and bootmeth. Of course all of these are optional and don't appear in .dts files for now, but we should still add bindings for them. Regards, Simon
