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

Simon Glass sjg at chromium.org
Thu Jan 20 20:56:52 CET 2022


Hi Mark,

On Thu, 20 Jan 2022 at 11:56, Mark Kettenis <mark.kettenis at xs4all.nl> wrote:
>
> > Date: Thu, 20 Jan 2022 13:30:47 -0500
> > From: Tom Rini <trini at konsulko.com>
> >
> > 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.
>
> Something like that.  I remember a lot of issues when boards were
> switched over to DM_MMC and the boot order changed.  I believe this
> ended up beging solved by having aliases in the device tree.

The bootdevs use the same aliases so the ordering should remain the
same in that sense.

Regards,
Simon


More information about the U-Boot mailing list