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