Hi Rob > > The Android way of handling overlays is very much rooted in how the Android > ecosystem works. >
Yes, idea is if we can leverage something from this. > 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. On part of requirement, IMO, we should define how device-tree update will be handled. The EBBR document should mention, -how kernel will provide overlays. - where and how those will be stored - and how those will be applied Defined EBBR may/may not work for Android. But I guess this is not primary goal of EBBR. > 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. Yes > >> 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
