Hi Peter, On Fri, 31 Mar 2023 at 21:40, Peter Robinson <pbrobin...@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
