On Fri, Apr 27, 2018 at 2:47 AM, Alexander Graf <[email protected]> wrote: > > > 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
Do you have an example of that? The only thing I can think of is people switching interrupts from the GIC to an always-on, low-power mode custom interrupt controller. > * clock support Are there cases other than going from fixed, fake clocks to a real clock controller node. I'm inclined to stop allowing people to do that. A better way this could be done is just provide a clock controller driver with a bunch of fixed clocks. Then the switch from the dumb driver to the real driver is just a kernel change. > * power domain support Example? > * pinctrl support This would be the firmware initially does all the pin setup, then you move it to DT and drop the setup from the firmware? Otherwise I don't understand the problem in this case. We'd start with no pinctrl and then add it to the DT. Why wouldn't the kernel just ignore it? > Every time a device tree changes in any of the above, that usually ends > up in backwards incompatibility. TBC, you're talking about new dtb with old kernels. We've mainly cared about old dtbs and new kernels. So first we should agree the former is important too. I do, because simply you wouldn't want a BIOS update to make your PC stop booting your already installed OS. I'd like to solve this with policy and good practice before we try to apply technical solutions on top of a mess. > 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. The number of combinations that would create makes me run away. Then we're going to combine that with all the other ways people want to use overlays. > 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. How would that work with clocks where you are changing: clocks = <&fake_fixed_clk>; to: clocks = <&soc_clock_ctrlr 123>; > >> >> 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 The Android way of handling overlays is very much rooted in how the Android ecosystem works. We should probably have wider discussion and decision on to what extent does EBBR address/care about/work with Android? On the one hand, I don't think Android requires anything that's specifically incompatible with EBBR if some wants to follow EBBR and use Android. OTOH, we can't define any requirements for Android in EBBR. Google will define things to the extent they want and vendors will follow that only to the extent they have to. >> 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? The Android way. Everything can be solved with another partition. :) Rob _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
