[v4 0/7] Fix Rockchip RK3399 bootstd migration

[Simon Glass]

Hi Peter,

On Fri, 31 Mar 2023 at 21:40, Peter Robinson <pbrobinson at gmail.com> wrote:
>
> Hi Simon,
>
> > > > > > > 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.
>
> Can you do a patch to fix this regression please and then specify the
> correct pieces in the binman section then?

Yes I think this should be fixed.

We don't have any Rockchip maintainers / contributors on this thread.
Would you like to start a new one, or add them to this thread?

>
> > > 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.
> >
> > Sorry, I don't agree with that at all. We store configuration
> > information in devicetree in firmware as this seems to be best format
> > for it, particularly with the growing number of firmware components
> > that need to share this information at runtime. The layout of firmware
> > is an important part of the system. We are still figuring out the
> > flows though. Also I have not attempted to upstream the binman
> > binding. I am very open to ideas on how best to do that.
>
> Rob what's your thoughts on the binman firmware build pieces being in
> device tree and the process on upstreaming the bindings?

It might be easier for Rob to comment on an actual proposal, which I
have not done. It is on my radar though.

Regards,
Simon


>
> Regards,
> 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