Le lun. 21 juin 2021 à 12:32, Alexander Graf <ag...@csgraf.de> a écrit :
> > On 20.05.21 18:42, Simon Glass wrote: > > Hi, > > > > Re Jeremy's comment: > >> Using DT to pass platform info at this level is sort of crazy on an ACPI > >> machine which won't have native DTs. Meaning there is an additional > >> level of unnecessary indirection that needs to be converted back into a > >> format which can be utilized by AML and other parts of the ACPI stack. > > U-Boot has to generate part of the ACPI tables programmatically, using > info > > from the DT to do so. In other words, U-Boot supports DT but must also > > support generating AML, etc. I don't see a particular problem with that. > > > > I don't think it makes any sense to use ACPI tables to pass data between > > boot phases, but if that is being proposed, I'd like to understand the > > reason. I also wonder why people are using UEFI on rpi, but that's a > > different topic. > > > Reading the conversation, I believe the main confusion is about what > "use DT to pass data" means. > > There are fundamentally two ways to think of this: > > 1) Take a standard Linux device tree as input. Use exactly that to pass > data between stages. Go through the LKML to define pre-Linux bindings. > Implement a full DT parser to enumerate hardware. > > 2) Use DT purely as opaque data transfer mechanism and reuse simple > parts (directories, compatible strings, etc) but leave out the > complicated ones (recursive #address-cells, interrupt-map, etc). Use it > to pass data privately between components. Be self-consistent, > self-documenting and self-backwards-compatible. > > > Which one of them do you mean Simon? I'd be super happy to see option 2. > DT as a data container is so much nicer than opaque binary blobs. At the > same time, I can see how people feel like option 1 would tie them into > an ecosystem dependency they don't want to be in. thanks for making that crisply. Option 2 is addressing nicely backward and forward compatibility. > > > Thanks, > > Alex > > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
