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 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 wrote: > > > > > > > > > From: Michael Walle > > > > > 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. -- Tom