[PATCH v2 41/41] RFC: Switch rpi over to use bootstd

[Tom Rini]

On Thu, Oct 28, 2021 at 11:16:31AM -0600, Simon Glass wrote:
> Hi Tom,
> 
> On Thu, 28 Oct 2021 at 10:43, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Sat, Oct 23, 2021 at 05:26:35PM -0600, Simon Glass wrote:
> >
> > > Switch this over, for testing purposes.
> > >
> > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > [snip]
> > >  #define CONFIG_EXTRA_ENV_SETTINGS \
> > >       "dhcpuboot=usb start; dhcp u-boot.uimg; bootm\0" \
> > > +     "boot_targets=mmc0 mmc1 usb0 pxe dhcp\0" \
> >
> > So, based on this patch I went "oh, so we can still easily control the
> > device order, per board and also for users to tweak".  Then I looked for
> > where boot_targets was used, saw it wasn't and looked over the
> > documentation patch previous to this.   That's not looking easier to
> > configure than what we have now either.
> 
> Yes, I did originally implement the boot_targets env var, then decided
> it should be in the device tree instead, since you can do:
> 
> bootstd {
>    compatible = "u-boot,boot-std";
>    bootdev-order = "mmc2", "mmc1";
> };
> 
> (with nothing else in the devicetree)
> 
> I made this change since it seems that boot_targets is always set in
> the env and should not be touched by the distro. If that is not
> correct I can bring the code back...

Aside from what I said to the cover letter, I think all of the device
tree stuff is taking it the wrong direction.  The environment is
something that can easily be manipulated in a persistent and well
understood manner by a number of tools, and is done so today.  Defining
the boot order to start with in a device tree fragment is going to be
annoying for all of the platforms where the device tree comes from
somewhere else.  But it's going to suck even more for users to
manipulate (now that we've installed, we don't want to probe the whole
world normally, just check where it's installed).

I'm not seeing this as a better step forward at all right now, sorry.

> BTW the MAC address was just for my testing.

Hoped so, thanks :)

-- 
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/20211028/db39602f/attachment.sig>