Hi Simon Le sam. 4 déc. 2021 à 18:35, Simon Glass <[email protected]> a écrit :
> Hi François, > > On Sat, 4 Dec 2021 at 09:55, François Ozog <[email protected]> > wrote: > > > > Hi Simon > > > > Le sam. 4 déc. 2021 à 16:21, Simon Glass <[email protected]> a écrit : > >> > >> Hi Tom, > >> > >> On Sat, 4 Dec 2021 at 06:52, Tom Rini <[email protected]> wrote: > >> > > >> > On Fri, Dec 03, 2021 at 06:01:56PM -0700, Simon Glass wrote: > >> > > >> > [huge snip] > >> > > > There's things that need to be cleaned up because we have some > small > >> > > > number of platforms that went off and did their own thing. But > largely > >> > > > yes, things make sense to me. We have: > >> > > > - We embedded the device tree that will configure U-Boot, because > there > >> > > > is no way for the hardware to have provided us one. > >> > > > - We do not embed the device tree that will configure U-Boot, > because > >> > > > there is already one present in memory for us to use. > >> > > > > >> > > > Then we have the developer option of: > >> > > > - We embedded the device tree that will configure U-Boot, because > we're > >> > > > developing something. > >> > > > >> > > Yes, agreed those are the cases. To me this needs to be a run-time > choice. > >> > > >> > But it's not possible. That's the problem we keep going around and > >> > around about. People keep raising real life examples where you cannot > >> > make a run time choice between "device tree we're passed at run time" > >> > and "device tree we're compiled with". > >> > >> I haven't seen one. The most extreme case is QEMU and it works fine. I > >> even added a test with it. What am I missing? > >> > >> > > >> > And it's not helpful. It is ALWAYS the case that we know that we want > >> > to override the run time device tree with our own, because it's a > >> > developer developing things or it's a user / production case where we > >> > must use the provided tree. NOT doing that is what leads to madness > >> > like we see for example on Pi where if we don't use the passed tree we > >> > still need to copy X/Y/Z out of it. > >> > >> Aren't you talking about the distro DT there, rather than the the one > >> on the boot disk? That is my reading of that patch. If we need to do > >> that sort of thing, it doesn't matter where the the cointrol DT comes > >> from. You are still going to have to do that sort of thing. > >> > >> It is not ALWAYS the case. I've shown you how easy it is to disable > >> OF_BOARD and still boot / iterate. > >> > >> > > >> > > > > Are you looking to have an empty DT in u-boot.bin? Perhaps we > should > >> > > > > provide a way to do that? But what is driving that desire? > >> > > > > >> > > > I'm looking for ways to convince you that we do not need to > include a > >> > > > device tree in the binary. There's a growing set of devices > where the > >> > > > device tree exists with the device. If it's missing, that's a > huge > >> > > > fatal error we can't do all that much about. If we need to do > something > >> > > > to that device tree for U-Boot, yes, fine, we should make it > straight > >> > > > forward for the developer to do that. But that's not the common > case! > >> > > > >> > > Well we could add another Kconfig which tells U-Boot not to include > a > >> > > devicetree in u-boot.bin, if that would resolve this? > >> > > > >> > > I just want to make sure that we always build the devicetrees and > that > >> > > it is easy for a knowledgeable dev to switch over to use them, > without > >> > > spelunking through dozens of other projects to discover the secret > DT > >> > > that no one will tell us about. > >> > > >> > Should we demand better documentation for boards? Yes. But it's > still > >> > a valid case to have zero device trees for a given platform in-tree. > >> > Xen is an example of this. QEMU is an example of this. Platforms > need > >> > to work without adding special tweaks for us. Maybe that means some > >> > features can't be tested in QEMU-as-virtual-platform and only in > >> > QEMU-faithfully-emulating-specific-physical-platforms. > >> > >> You mention QEMU (for ARM and RISC-V) and now XEN. They are a special > >> case, I think. How about we create a special Kconfig for that case? We > >> need to make some progress here. > >> > >> > > >> > > > I guess another part of the problem is that historically almost > all > >> > > > platforms were in the first case I list above, no run time > provided > >> > > > device tree, so we took the kernel one and added our bindings to > it. > >> > > > Now we're being bit by the growing number of platforms that are > the > >> > > > second case, and how do we get our properties in there, and which > ones > >> > > > even make sense to do that for. > >> > > > >> > > I think upstreaming the bindings is the solution there. I've made a > >> > > start, but we need to make progress with this series and all the > other > >> > > things in flight. I think a lot of people want U-Boot to not have a > >> > > devicetree source files in it for ARMv8 platforms. I am strongly > >> > > opposed to that. I've laid out my reasons very clearly in the past. > I > >> > > think this is a good summary: > >> > > > >> > > https://lists.gnu.org/archive/html/qemu-devel/2021-10/msg03480.html > >> > > >> > Yes, there are some ARMv8 platforms we will have to have the source > >> > files to, in tree, because they won't come to us at run time. But > >> > others we won't for practical reasons, namely that we can't statically > >> > provide something that exists dynamically without massive duplication > of > >> > code or just taking things from that passed to us tree. > >> > >> So let's require that the static ones have the Linux DT in our tree > >> for now. The dynamic ones are just QEMU for ARM and Xen, I think. If > >> that's it then I can agree a special case for them, so long as we sort > >> out the docs for Xen. > >> > >> > > >> > > I believe I have been consistent in this although with all the > >> > > discussion I'm really not sure anymore. > >> > > >> > Yes, everyone has been consistent in these discussions. > >> > >> I'd like to think more people accept that U-Boot is allowed its own > >> properties than did at the start. > > > > there is no question that U-Boot can have its properties specified in > Device Tree. > > I am pretty sure you were on the other side of that fence at some > point. I know quite a few others that still are. > > > What we may not agree in is how those properties make it to U-Boot. > > Yes but that is just the next step along in my progression in that > email ('why can't we just...' to 'this is how U-Boot works'). From > memory there are 3 more steps. > > >> > >> > >> > >> > > >> > > The problem is that various people have various views about how > U-Boot > >> > > should work with devicetree. I strongly believe that until we have > >> > > bindings upstream, a central repo for DTs with easy downloading for > >> > > builds, automated validation, among other things, we must maintain > the > >> > > devicetree in U-Boot. Just from the POV of energy expended, I do not > >> > > want to be arguing with the Linaro folks about what U-Boot is > allowed > >> > > to do every month for the next two years. I'd rather set out the > stall > >> > > now and then deal with the problems it causes from that perspective. > >> > > >> > The problems of the last going on 12 years won't be solved instantly. > >> > The conflict as I see it is that you're insisting that all platforms > >> > must have statically usable device trees, and I (and I believe others) > >> > are saying that's unreasonable in cases where the trees are dynamic at > >> > heart, lets just ensure we have good enough documentation for them, > >> > which we don't today. > >> > > >> > To be clear and pick an example, I don't want Pi dts files in U-Boot, > >> > but, OK, it's an easy enough case to sync them up and so long as we > >> > aren't yet at the "now we pick at run time between compiled in or > passed > >> > to us dtb", I can accept them in tree, but not in the resulting binary > >> > for OF_CONTROL=y. But as the Xen folks have also noted, there's no > >> > reasonable tree to include there. It does need to be better > documented > >> > how to fire it up however, in our sources. > >> > >> I'm OK with us copying in the Linux devicetree and using that. But > >> OF_BOARD must be a run-time option and able to be disabled. The > >> devicetree must be built, so it is actually real. We can have a > >> separate OF_OMIT or something like that to omit the devicetree from > >> the output image, perhaps. > >> > >> All of the other things need to wait until we make progress with > >> devicetree bindings, validation, > >> > >> How can we make progress on this? We have different goals, as I have > >> explained, so we are not going to agree on everything. > > > > A V7 with empty device trees (except with comments to explain why they > are empty and how to force one for dev purposes) for platforms that provide > U-Boot with DT (RPI, Qemu, xen…) seem a good base unless someone can > propose a better way forward. If we build consensus on the feature aspect > of the patch set I will be able to dedicate some time on the documentation > part as I thought it was useless to check those until we agree on the > functional part. > > That's the status quo, so it doesn't resolve any of my concerns, > sorry. I suggest: > You make progress on various front that can get consensus in a number of your patches, so it it not status quo. > > - Check in all the DTs we can get (e.g. from Linux), and build them doesn’t change anytime. RPI4 DT in the kernel is not be used anyways. > > - Use an empty one if we cannot find it, and ask the maintainer to add > docs and deal with it > - For QEMU arm and QEMU RISC-V (i.e. the 'virt' case), use a base one > that works with the base QEMU config > > We then have the follow-ons that Tom and I have discussed, e.g. the > Kconfig option that Mark mentioned. > > That will clear up all the confusion and provide a baseline for how DT > is dealt with in U-Boot. > > We should then continue on the path towards upstreaming bindings, > syncing DT with Linux, validation, removing them from U-Boot if we can > automatically download them all from somewhere, etc. > > The thing is, I think people are more aligned on the eventual goal > than on this series. I’d interested to know that. Should we ask +1, -1, -2 for the patches? > My concern is that without this series, it will > continue to be crazy-town and no one will be able to find anything > without manual effort. For those of us who deal with more than one > platform, this is an important point. > > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 [email protected] | Skype: ffozog
