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

[Simon Glass]

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 it doesn't really matter how the general list is sorted, but
> > sorting by the speed of the interface sounds.. strange.
>
> From a security standpoint "removable" vs. "non-removable" is what
> really matters.  You don't really want someone to plug a usb key or
> SD card into your device and accidentally boot from it.

Yes, this should be easy enough to set up. From what I've seen so far,
people tend to put the MMC devices next to each other in priority,
with USB and network later.

But I still think having a sane default makes sense rather than making
every board do this explicitly.

>
> Also, changing the default boot order for an already supported device
> is probably going to cause problems.  Something to keep in mind when
> devices get converted to the new mechanism.

Well conversion is a different thing. We should be able to make sure
the order is the same as before, perhaps with a runtime check, e.g.
adding an env variable which provides the expected order.

Regards,
Simon