On 04/23/2018 01:55 AM, Alexander Graf wrote:
> Hi Udit,
> 
>> Am 23.04.2018 um 07:15 schrieb Udit Kumar <[email protected]>:
>>
>> 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

_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture

Reply via email to