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

[Tom Rini]

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.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220120/a66377f2/attachment.sig>