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

[Peter Robinson <pbrobinson@gmail.com>]

On Wed, Mar 29, 2023 at 3:54 PM Tom Rini <trini@konsulko.com> wrote:
>
> On Mon, Mar 27, 2023 at 06:50:41PM +0100, Peter Robinson wrote:
> > 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.
>
> I too am unhappy with how some of these have gone. The _intent_ here is
> that getting the current "boot generic distro" framework is complex /
> error prone, and we can do better. Unfortunately the first set of
> platforms to switch to this are Rockchip and I think there was overlap
> there with platforms that got broken at the end of the v2023.01 cycle to
> fix other platforms, and then those sets of platforms flipped early in
> v2023.04 and took until -rc2? to get resolved.  Which was less than
> ideal.
>
> > 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.
>
> I wish I knew where to talk to with ATF / TF-A to get some agreed upon
> naming scheme going as one of the things that is very frustrating is
> getting the names and combinations of everything else that's required
> Just Right for every chip. And feedback that things aren't working is
> appreciated, since we do need to make things easier.

In all of the various make_fit_atf.py the various vendors specified
them, this is the case for the rockchip one [1]. This is the case for
the Allwinner boards [2] but the rockchip ports have missed this so it
also should be fixed for GA.

A side point is that binman should not be storing firmware build
specifics in the device tree which is a means of describing the
hardware, This really needs to be fixed as it really isn't the right
place for that sort of things. I suspect a file in arch/arm/mach-<SOC>
is likely a better location, or if it's board specific in the board/
sub directory.

Peter

[1] https://source.denx.de/u-boot/u-boot/-/blob/v2023.01/arch/arm/mach-rockchip/make_fit_atf.py#L227
[2] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/dts/sunxi-u-boot.dtsi#L64