> Am 03.05.2018 um 16:31 schrieb Daniel Thompson <[email protected]>: > >> On Thu, May 03, 2018 at 09:02:40AM -0500, Rob Herring wrote: >> On Thu, May 3, 2018 at 5:13 AM, Daniel Thompson >> <[email protected]> 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. >> >> 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.
That is already part of the existing UEFI interfaces. The DT is passed as table and any UEFI application can override that table. Alex > > >> 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. > _______________________________________________ > Arm.ebbr-discuss mailing list > [email protected] _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
