[PATCH v8 00/13] bootstd: Convert rockchip and add various fixes and tweaks

[Tom Rini]

On Sat, Apr 08, 2023 at 07:53:10AM +1200, Simon Glass wrote:
> Hi Tom,
> 
> On Sat, 8 Apr 2023 at 07:39, Tom Rini <trini at konsulko.com> wrote:
> >
> > On Fri, Apr 07, 2023 at 10:36:38PM +1200, Simon Glass wrote:
> >
> > > This series converts rockchip boards over to use standard boot. It also
> > > fixes various problems which have come up recently, showing differences
> > > between the current implementation and the distroboot scripts.
> > >
> > > This should get us closer to being able to turn down the scripts.
> >
> > Alright, so I grabbed a few parts of this series to investigate the
> > points I'm trying to grasp better, and I think this is going the wrong
> > track. We should start off by dropping "default y" from BOOTSTD, and
> > then start adding "default y if" for SoCs as we convert them. The end
> > goal should be that we get to the point where we can "default y if ARM
> > || RISCV || X86" or perhaps "default y !(PPC || M68K || ...)" as it's
> > just a few architectures that haven't ended up being converted. But
> > today, there's too much churn on platforms that aren't making any use of
> > this. And I don't think this is going to be functionally worse than all
> > of the places we "imply DISTRO_DEFAULTS" today, as functionally we can
> > replace that with "imply BOOTSTD" as they get migrated.
> 
> That would really be a backward step. I'm not sure what to say at this
> point. I've put a lot of effort in trying to get this over the line,
> but the only way we get feedback is when it is applied.

Having bootstd enabled and not functional (because boot_targets aren't
set) isn't helping the migration happen. And the hard part of the
migration isn't knowing it's possible, or enabling 1-2 options, it's
testing it and also it really just being 1-2 options.

> What churn are you seeing? Do you mean:
> 
> disable BOOTSTD for boards with custom commands? You asked for that patch
> disabling BOOTSTD_DEFAULTS? You asked for that patch
> enable BOOTSTD_DEFAULTS by default? We can drop it if you like

We need all 3 of those patches because without the 3rd you don't get a
good experience when you do enable bootstd for a platform. The problem
is that unless you have distro_bootcmd today you're getting between 63kB
(a lot of mediatek platforms) and 5k (silk, as a semi-random example) of
growth because bootstd is on and now is the default bootcmd, when before
they had nothing. And probably had board docs saying "now do ... to
boot". And that's largely setting aside the *_r5_* platforms that I know
are just doing something else, and could disable it.

We want to convert everyone doing distro_bootcmd over to this, that's
good. The problem is we don't have a symbol today that means "we want
distro_bootcmd" and also isn't overloaded (DISTRO_DEFAULTS is overloaded
in this sense).

The wrong direction part of this series is that for platforms that
aren't in the middle of converting we're increasing their size between
somewhat and very very much, and we haven't tested that it'll work. And
yes, there's some automatic guessing logic, which hasn't been tested on
these platforms either, so we don't actually know if going from no
bootcmd (and so drops to prompt) to attempts to autoboot something is an
improvement.

-- 
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/20230407/230c3822/attachment.sig>