On 05/03/2018 12:13 PM, Daniel Thompson wrote:
On Wed, May 02, 2018 at 05:39:02PM -0400, Tom Rini wrote:
On Wed, May 02, 2018 at 05:12:03AM +0000, Chang, Abner (HPS SW/FW Technologist)
wrote:
-----Original Message-----
From: Udit Kumar [mailto:[email protected]]
Sent: Wednesday, May 02, 2018 12:26 PM
To: Chang, Abner (HPS SW/FW Technologist) <[email protected]>;
Alexander Graf <[email protected]>; William Mills <[email protected]>
Cc: [email protected]; [email protected]; Rod Dorris
<[email protected]>; [email protected]
Subject: RE: DT handling, [Ref Linux-Efi]
We probably don't need to provide a genetic DT driver in UEFI U-Boot,
instead, we will have to mention how SoC/platform vendors publish
DTB/DTBO in EBBR spec.
For example,
The EFI_CONFIGURATION_TABLE in EFI System table could be used to
publish the pointer to DTB and DTBO. Declare two GUIDs in EBBR, one
for DTB another for DTBO. OS boot loader is responsible to merge
DTB/DTBO according DTB/DTBO discovered in EFI Configuration Table. To
read DT from EFI variable into memory, memory map to DT in EEPROM or
other mechanisms is platform implementation. No matter which approach,
DT producer has to create configuration table in EFI system table
follow the data structure defined in EBBR.
Another way instead of using GUID in configuration table is to publish
DTB/DTBO in EFI device path, this way is more UEFI oriented IMO.
However, we have to defined corresponding device path node in UEFI
spec for DT. Similar to using system configuration table. DT producer
has to install EFI device path for either DTB or DTBO. Then OS boot
loaders locate those EFI device paths of DTB and DTBO and merge it.
We are adding a requirement on OS boot loaders to merge it.
IMO, merging should be done by firmware itself.
In case, we want to host multiple distribution at same time, then this is likely
to go with OS boot loaders
That is fine to merge DT by firmware, we still can standardize how
UBoot merges DT in EBBR. For example, SoC and other platform UBoot
drivers produce their DT or DTO in their own drivers. UBoot provides a
centralized EFI DT driver to collect DT/DTO from either EFI system
configuration table or EFI device path. Then this centralized EFI DT
driver produces the pointer to point to final DT in EFI system
configuration table. OS boot loader cab just check EFI system
configuration table to retrieve DT, something like this.
I think I need to step in here to clarify something. U-Boot drivers
don't produce a DT and while it's possible, it's generally[1] not done,
that U-Boot uses _the_ device tree that we pass along to the next stage
(we've likely filtered things out for space and added a few specific
things of our own).
IMHO, what EBBR should cover is saying that firmware may apply overlays
because we know there's N valid use cases of taking a base and fixing it
up in both big and small ways. Then firmware will pass along to the
next stage (EFI application such as GRUB or *BSD loader or a Linux
Kernel or ...).
Which bits of this discussion target level 0 and which target a later
level 1?
Personally I'm not sure there is enough prior art w.r.t. device tree
overlay for anything much related to overlays to target level 0.
In fact if we take the view that EBBR defines a contract between the
system firmware and the OS then arguably DT update is also out of scope
unless we are defining runtime services by which the OS can update the
DT. Again not something I think is ready for level 0.
Well, things like hat devices that give boot loaders hints on what OS
provided overlays would be useful to load are basically part of the
contract.
But I agree that it can easily be an EBBR Level 1 topic.
Alex
_______________________________________________
boot-architecture mailing list
[email protected]
https://lists.linaro.org/mailman/listinfo/boot-architecture
