[v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Peter,

On Tue, 28 Mar 2023 at 06:50, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg at chromium.org> wrote:
> >
> > Hi Tom,
> >
> > On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > Hey all,
> > >
> > > I took a look at Simon's v3 series to fix the rk3399 bootstd migration,
> > > and it changed too much for everything else. I took about half of that
> > > series and then reworked a few things. Now only rk3399 platforms change
> > > at all and aside from bootcmd changes, the only thing is they now
> > > disable true/test/sysboot/showvar/false/exit commands as those were
> > > being pulled in from distro and now we don't set that flag. I think the
> > > way I changed how we enable BOOTSTD_DEFAULTS should make it easier to
> > > perform more SoC migrations.
> >
> > Thanks for digging into this. I haven't seen any comments on the rpi
> > conversion, so perhaps people could test that?
>
> I was planning on looking at that once 2023.04 was out but TBH I have
> wasted so much time over the last few cycles dealing with regressions
> through a bunch of these series that I now have so little time for
> enhancements I now shy away. I know a lot of these series should
> improve things in the future but they don't feel like when there's
> unnecessary changes for things that are clearly untested.
>
> There's also a lot of change for changes sake, for example the
> rockchips ATF binaries needed is called bl31.elf by the default output
> of the ATF build process, for others it's bl31.bin, binman for what
> ever reason has changed that to be atf-bl31, now I have to change the
> entire build process to be able to work out what is what on a board by
> board basis to be able to set the required variable to be able to
> specify the ATF where  previously it "just worked (tm)"..... I suppose

For this point, you could use the BL31 environment variable, which
would allow the old file to be used. That is in the instructions for
some boards.

Also, the change to atf-bl31 is because no particular filename is
provided as a default, so we end up using the entry type. I suppose
the problem is that there are two names in common use (bl31.bin and
bl31.elf) and if we use the wrong one it won't boot. That is an
unfortunate result of how things work with ATF. But in any case this
is a decision for the SoC maintainer, who can provide a default
filename if desired, in the binman description for that SoC.

> there is some perceived goal and improvement here but with both my
> "U-Boot device maintainer" and "distro maintainer" hats on, both of
> which I do in my own spare time, I currently fail to see it and I end
> up.

Basically the benefit is that U-Boot is not full of loads of strange
shell / Python scripts for each SoC type, it is possible (at least in
principle) to figure out how to build an image without scanning the
web for vendor-specific instructions, tools which are needed to build
images are registered (binman tool -l) and can be fetched. Overall,
having a data-driven approach to firmware packaging is vastly superior
to a code-based approach, particularly as firmware fragments more and
more. You can find more here [1]

>
> All that said, thank you Tom for picking up the pieces for something
> which should have been actually working when it landed.
>
> Tested-by: Peter Robinson <pbrobinson at gmail.com>
>
> Now I get to go and work out all of the rest of the mess!

Yes, thank you Tom.

Thank you also Peter for your comments. I suspect a lot of people feel
the same way.

>From my perspective, these migrations can be exhausting, particularly
when drawn out over a long period of time. Removing SPL_FIT_GENERATOR
started almost 3 years ago[2]. People continued adding new boards to
it even until recently.

It is also often difficult to predict how things will turn out, even
for people with many years of experience in software development. So
we sometimes make wrong turns.

I would love to see more attention from SoC maintainers, to sit down
with a coffee once a month and take a hard look at the state of the
code they look after, what migrations are outstanding, etc.

The firmware world is changing rapidly. We need to be able to keep on
top of the increasing complexity with new tools and techniques.
Perhaps it will settle down at some point, but for now it is quite a
daunting task and we all need to pitch in.

Regards,
Simon

[1] https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation
[2] https://patchwork.ozlabs.org/project/uboot/patch/20200613205717.v2.42.I2428dcb9b077364f9517f2c291db63b6bac1e992@changeid/