On 27.04.18 08:24, Udit Kumar wrote: > Hi > There is bit of discussion on linux-efi too , to handle DT update > > I guess some members of this forum are active there too. > > https://www.spinics.net/lists/linux-efi/msg13700.html > > To summaries > 1/ Ownership of DTB > IMO should be firmware and we should retain this > ownership in EBBR as well, Any objections/thoughts ?
I fully agree. On top of that we need to make clear that backward and forward compatibility are not optional. For that I think we may need to actually give people workable solutions to create device trees that are compatible with multiple levels of kernel support. The main areas I'm aware of that keep breaking are: * fine grained interrupt controller support * clock support * power domain support * pinctrl support Every time a device tree changes in any of the above, that usually ends up in backwards incompatibility. My idea to solve that would be to basically create a device tree that has self-contained overlays that only trigger when certain feature strings are available. That way the base device tree could for example contain fixed clocks, but an overlay can get applied when the clock driver is enabled in the kernel configuration. That overlay would then enable the kernel to drive clocks. Further down, we could even extend dtc with annotations that indicate "this property should only be exposed when feature string X is available" to not force people to write overlays inside the device tree. > > Update > 1/ Updating whole device tree from OS > [Capsule update can be used ] I think the device tree should be part of firmware. If you need to update it, update your firmware (or a firmware specific method, not specified by EBBR). > 2/ Just modifying the device tree DTBO Yes, dtbo support in the boot chain definitely makes sense. > My preferred way to handle DTBO in firmware will be > https://source.android.com/devices/architecture/dto/multiple > See picture Runtime DTO implementation for multiple DTs > > To store this information in partition, options we have > 1/ Run time variables You mean EFI variables? We could certainly have a driver in firmware that reads certain EFI variables to apply dtbos from. > 2/ Some driver in Linux writing to DTBO partition What is a DTBO partition? > 3/ Some other way ?? In a lot of cases I think we will end up with enumerable extensions to systems that will want to have a dtbo applied by their respective driver. As outlined in the notes from last week, that driver could expose availability of such an extension to the OS (grub) which could then apply an OS provided dtbo. > I am not sure, if distro are updating device tree which is default shipped > with board ?? I would prefer they didn't :). Right now we leave people little chance, because device trees keep changing incompatibly. If we get rid of that problem, there will be very little incentive by distros to ship device trees. Alex _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
