Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration

From: Peter Robinson <pbrobinson@gmail.com>
To: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>, u-boot@lists.denx.de
Subject: Re: [v4 0/7] Fix Rockchip RK3399 bootstd migration
Date: Mon, 27 Mar 2023 18:50:41 +0100	[thread overview]
Message-ID: <CALeDE9MatNvJiAbDxf=C1iJQeKTrgH7O8=jcL1M4K_=7iEzOEg@mail.gmail.com> (raw)
In-Reply-To: <CAPnjgZ2orGwgNovk6McoStw3fx7vEOyBBaEcjo-c=Kbff5QMAw@mail.gmail.com>

On Mon, Mar 27, 2023 at 5:02 AM Simon Glass <sjg@chromium.org> wrote:
>
> Hi Tom,
>
> On Sat, 25 Mar 2023 at 09:58, Tom Rini <trini@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
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.

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@gmail.com>

Now I get to go and work out all of the rest of the mess!

Regards,
Peter