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. > > > > 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. > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we > > > > have binman definitions, etc. So we need a way to overlay those things > > > > into the DT. We already support this for in-tree DTs, so IMO this is > > > > easy. Just require every board to have an in-tree DT. It helps with > > > > discoverability and documentation, anyway. That is this series. > > > > > > Again, the board might decide for it's own reason to provide it's own > > DT. > > > IMHO U-Boot must be able to cope with that and asking DTs to be included > > in > > > U-Boot source is not the right way to do that, not to mention cases were > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB > > from > > > it's flash). > > > > > > > (I think most of us are at the beginning of step 2, unsure about it > > > > and worried about step 3) > > > > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular > > > > flow only, or boards that sometimes use a flow) which need the DT to > > > > come from a prior stage. How to handle that? IMO that is only going to > > > > grow as every man and his dog get into the write-a-bootloader > > > > business. > > > > > > And that's exactly why we have to come up with something that scales, > > without > > > having to add a bunch of unusable DTs in U-Boot. > > > > Both of these are solved by having our bindings reviewed and upstreamed > > and then what we need included in the authoritative dts files. > > > There shall be authoritative System Device Trees as vendors are working on. > Those System Device Trees cover all aspects of a board, not just the > Cortex-A part that U-Boot cares about. > Out of those system device trees, a tool (lopper) is going to carve out the > "authoritative dts for the cortex-A". > Essentially, that carve out will correspond to what would come out of Linux. s/Linux/software/ > This scheme will not be generalized, just adopted by vendors on some > boards. > DT for those board become part of the OS ABI (meaning, the driver > developper is constrained). OK? And is going to pick and choose which valid bindings to implement? Or is it going to provide half a node for Linux? No? I assume no. So it will also provide whatever bindings we've upstreamed and say need to be passed. -- Tom
signature.asc
Description: PGP signature