On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote: > Hi trying to reply to all at the same time! > > On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote: > > > Hi Tom, > > > > > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <tr...@konsulko.com> wrote: > > > > > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote: > > > > > Hi Simon, > > > > > > > > > > A bit late to the party, sorry! > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > I really want to see what the binary case looks like since we > > > > > > > could > > > > then > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we > > > > > > > could > > > > > > > then also do a rpi_arm32_defconfig too. > > > > > > > > > > > > > > I want to see less device trees in U-Boot sources, if they can > > > > > > > come > > > > > > > functionally correct from the hardware/our caller. > > > > > > > > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also > > > > don't > > > > > > > use the device tree from build time at run time, ignoring the > > > > > > > device > > > > > > > tree provided to us at run time by the caller. > > > > > > > > > > > > Firstly I should say that I find building firmware very messy and > > > > > > confusing these days. Lots of things to build and it's hard to find > > > > > > the instructions. It doesn't have to be that way, but if we carry on > > > > > > as we are, it will continue to be messy and in five years you will > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My > > > > > > objective here is to simplify things, bringing some consistency to > > > > > > the > > > > > > different components. Binman was one effort there. I feel that > > > > > > putting > > > > > > at least the U-Boot house in order, in my role as devicetree > > > > > > maintainer (and as author of devicetree support in U-Boot back in > > > > > > 2011), is the next step. > > > > > > > > > > > > If we set things up correctly and agree on the bindings, devicetree > > > > > > can be the unifying configuration mechanism through the whole of > > > > > > firmware (except for very early bits) and into the OS, this will set > > > > > > us up very well to deal with the complexity that is coming. > > > > > > > > > > > > Anyway, here are the mental steps that I've gone through over the > > > > > > past > > > > > > two months: > > > > > > > > > > > > Step 1: At present, some people think U-Boot is not even allowed to > > > > > > have its own nodes/properties in the DT. It is an abuse of the > > > > > > devicetree standard, like the /chosen node but with less history. We > > > > > > should sacrifice efficiency, expedience and expandability on the > > > > > > altar > > > > > > of 'devicetree is a hardware description'. How do we get over that > > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree > > > > > > for its own purposes, as well as for booting the OS. I am not saying > > > > > > it always has to have those properties, but with existing features > > > > > > like verified boot, SPL as well as complex firmware images where > > > > > > U-Boot needs to be able to find things in the image, it is > > > > > > essential. > > > > > > So let's just assume that we need this everywhere, since we > > > > > > certainly > > > > > > need it in at least some places. > > > > > > > > > > > > (stop reading here if you disagree, because nothing below will make > > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have > > > > > > OF_CONTROL :-) > > > > > > > > > > Having U-Boot keep it's *internal* config state in DTs is fine. > > > > > Adding > > > > > that to the DTs that are copied over from linux isn't imho. There are > > > > > various reasons for that. First of all syncing device trees is a huge > > > > pain > > > > > and that's probably one of the main reasons our DTs are out of sync > > > > > for a > > > > > large number of boards. > > > > > > > > This re-sync is only a pain because: > > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE > > > > NOT SUPPOSED TO. > > > > 2. DTS files are getting closer to being the super stable API that has > > > > been promised now that there's validation tools. > > Agree on both, but still this is the reality we have to deal with right now > > > > > > > > > Some SoCs, like stm32 are doing an amazing job and keeping things in > > > > sync, every release. Others like NXP are violating rule #1. > > > > > > With NXP commitment to SystemReady on some IMX8 boards, I think this is > > > changing, > > > at least for the SystemReady boards. > > > > I'd really like to see some progress (as would the other non-NXP folks > > working on NXP SoCs) in that regard. > > > > > > Still > > > > others like some TI platforms get bit by #2 (I solved one of these, and > > > > need to cycle back to the one you and I talked about on IRC a while > > > > back, I bet it's another node name dash changed to underbar). > > > > > > > > > The point is this was fine in 2011 were we had SPL only, but the > > > > > reality > > > > > today is completely different. There's previous stage boot loaders > > > > > (and > > > > > enough cases were vendors prefer those over SPL). If that bootloader > > > > needs > > > > > to use it's own device tree for whatever reason, imposing > > > > > restrictions > > > > on > > > > > it wrt to the device tree it has to include, and require them to have > > > > > knowledge of U-Boot and it's internal config mechanism makes no sense > > > > > not > > > > > to mention it doesn't scale at all. > > > > > > > > If you are passing the full device tree around, a few more > > > > nodes/properties aren't going to make the situation worse. If we're > > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call > > > > the line, especially since if we wait another 6 months it'll be a 62 > > > > kilobyte file coming in from Linux instead. > > > > > > This is not about size but about firmware supply chain organization. > > > > That's great since it means we just need the bindings reviewed then > > everyone can pass whatever everyone else needs. > > > > Size here is not my concern. If the bindings u-boot expects gets > upstreamed I am obviously fine with the previous stage bootloader passing > them over. What I strongly disagree, is *demand* the previous stage boot > loader have knowledge about them if they are not in upstream.
I also agree that bindings MUST be upstreamed for there to be a reasonable expectation that any other project (or human creating a dts) be adding them, either statically or any sort of run-time modification (think memory information, this gets fixed up at run-time often still). And it may end up being zero "u-boot,FOO" bindings where this is the case. Or it may end up being related to secure / verified boot stuff only. -- Tom
signature.asc
Description: PGP signature