On 04/23/2018 01:55 AM, Alexander Graf wrote:
Hi Udit,
Am 23.04.2018 um 07:15 schrieb Udit Kumar udit.kumar@nxp.com:
Hi Alex,
I was reading your notes for DT management
Alex: Have logic in firmware that can enumerate "Hat"s and create EFI object for them. These objects could then be backed by DTBOs - either by grabbing them from the device (EEPROM) or by a stored blob in firmware. >Grub for example could then also be taught about these objects and DTBO support, so an OS could store its own overlays. EDK2 has the hat logic support today and already does create objects.
I am not sure, where you want to store DTBO in EEPROM or on some other partition/media. If this is EEPROM then I hope firmware is stored on this as well. Then we shouldn't expose EEPROM to OS.
There are hats that provide device tree overlays as part of their self description, such as the beagle ones. That‘s what I was referring to.
Of course the actual hat driver again can override or self define a dtbo as well.
Alex
I am not sure what is meant as an "EFI Object". Is this a driver module? Is it a string that causes an existing driver in the platform to be called with some data?
I was expecting the DTBO support to be some list of DTBO files with an optional conditional prefix.
capeid:367?wizbang_cape.dtbo;capeid:768?cadcam_cape.dtbo
For platforms that understand what a "cape" is they have a driver that registers the capeid prefix, parses the rest of the the string up to the conditional delimiter (? in this example syntax) and then returns true or false if that condition is met.
Even in this scheme there are lost of questions: * All all entries in one big list in a single EFI variable or can they be recorded in multiple variables? * Are the lists per BOOT### setting or per platform or both? * Should this data be in a file rather than vars?
How does this compare to what you are suggesting Alex?
Thanks, Bill