Hi folks,
Weekly EBBR meeting starts in about 1/2 hour. Dial in details below. Once again the agenda is very short, but I'll open it up to other topics after action item review. I think there was some interest in talking about DT overlay handling.
Notes are being captured in the following Google doc. I would greatly appreciate help with taking meeting minutes.
https://docs.google.com/document/d/1RdlFp5SIrvjcVOGoGEFVYDsqTqFBJHugbBMV5MuX...
Agenda: 1) Action item review 2) Any other business
Cheers, g.
Time: Every Thursday at 16:30-17:30 BST (8:30 PDT, 23:30 CST) Join by Phone +44 2033215213,, 4664465#
---
Join online meeting https://meet.lync.com/armh/grant.likely/YBY93TIK
Trouble Joining? Try Skype Web App https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1
Join by Phone +44 2033215213,, 4664465#
Find a local number https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33 Conference ID: 4664465 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
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.
Regards Udit
Hi Udit,
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
On 04/23/2018 01:55 AM, Alexander Graf wrote:
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
Hi Alex
I don’t know much about beagle and cape-manager . But looks there is dedicated driver handling these. IMO, all the overlays should be applied by boot-loader however kernel can write to agreed location, it could be runtime variable, some partition
boot-architecture@lists.linaro.org
-
Alexander Graf -
Grant Likely -
Udit Kumar -
William Mills