On Thu, May 03, 2018 at 09:02:40AM -0500, Rob Herring wrote:
On Thu, May 3, 2018 at 5:13 AM, Daniel Thompson daniel.thompson@linaro.org 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:udit.kumar@nxp.com] Sent: Wednesday, May 02, 2018 12:26 PM To: Chang, Abner (HPS SW/FW Technologist) abner.chang@hpe.com; Alexander Graf agraf@suse.de; William Mills wmills@ti.com Cc: boot-architecture@lists.linaro.org; nd@arm.com; Rod Dorris rod.dorris@nxp.com; arm.ebbr-discuss@arm.com 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.
By "DT update" here, did you mean replacing the base DT or still talking about overlays?
Just replacement, the idea being the *minimum* useful thing that a platform can provide is the capacity to grab, hack (including applying overlays ahead of time) and replace the DT... and even that may not be in scope for level 0 since it may not require a firmware/OS interface.
The contract is not just what the firmware provides to the OS, but how the OS interacts with and configures the firmware. A user telling the firmware what overlays to apply would be within that scope IMO.
Agree to an extent.
It really depends if the user instructs the firmware via an OS facing interface (think capsule update) or a firmware provided unstandardized interface (think secure boot key provisioning).
I think both approaches were contemplated in the conversation above (although I've lost track of who to credit with what).
But yes, I also agree probably not a level 0 thing.
Perhaps I should have been smart enough not to reply on that basis... but your mail had a question mark in it (and Alex G's did not).
Daniel.