[PATCH v3 31/31] RFC: Switch rpi over to use bootstd

[Simon Glass]

Hi Mark,

On Fri, 21 Jan 2022 at 02:36, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > From: Simon Glass <sjg at chromium.org>
> > Date: Thu, 20 Jan 2022 20:12:41 -0700
> >
> > Hi Tom,
> >
> > On Thu, 20 Jan 2022 at 18:08, Tom Rini <trini at 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 at 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 at 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 at 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 at xs4all.nl> wrote:
> > > > > > > > > > >
> > > > > > > > > > > > From: Michael Walle <michael at 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.

Your comment above is why I suggested keeping some macros but just
produced that one env var from them.

>
> 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.

Which compatible strings are you referring to?

There is a "bootdev-order" property which sounds like "boot-device",
except that it is a string list, not a space-separated string.

Regards,
Simon