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. -- Tom
signature.asc
Description: PGP signature
