On Wed, Mar 29, 2023 at 3:54 PM Tom Rini <tr...@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 <s...@chromium.org> wrote: > > > > > > Hi Tom, > > > > > > On Sat, 25 Mar 2023 at 09:58, Tom Rini <tr...@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
