search

ARM-software / ebbr

Embedded Base Boot Requirements Specification
Creative Commons Attribution Share Alike 4.0 International
113 stars 36 forks source link

Storage location of device tree files #58

Closed xypron closed 3 years ago

xypron commented 3 years ago

For binaries the UEFI specifies a default path for the storage of boot images to run if these are not specified by BootXXXX variables.

For flattened device trees (*.dtb) such a directory is not defined. U-Boot searches the EFI partition paths \, \dtb, \dtb\current for a filename specified in the U-Boot configuration (CONFIG_DEFAULT_DEVICE_TREE) by default.

When using boot options BootXXXX or BootNext it is not specified how to declare the related device tree file. A solution might be to use variables FdtXXXX and FdtNext to define the device paths of the FDT matching the boot option.

daniel-thompson commented 3 years ago

Currently EBBR contains the following text (which I now realize to be rather vague): "Compliant systems are required to provide one, but not both, of the following tables"

IIRC part of the intent of that language was to require the firmware (rather than the OS) to provide the device tree (or ACPI table). If my recollection is correct then:

  1. We need to figure out of we stand by that approach and tighten the language if required
  2. (if we stand by it) FdtXXXXX/FdtNext may simply not be on scope for EBBR
  3. FdtXXXXX/FdtNext may still be very useful for u-boot regardless! Perhaps an EBBR compliant system would require defaults such that the FDT were loaded from a firmware owned partition rather than an OS boot partition but that implementation specific defined and variables are not prohibited.

PS I think the "if we stand by it" should perhaps be discussed/reviewed at next meeting since as we step towards EFI secure boot then we wouldn't want an implementation to implement FdtXXXXX variables and leave the FDT unsigned. It could be that we need to bring this into scope partially or wholey simply ensure it isn't a vector to bypass secure boot ;-).

wmamills commented 3 years ago

DTE evolution call is working on this problem.

POR is Firmware always provides DTB but OS boot manager could override if it wants and can ask firmware to provide extra fixups via a new UEFI protocol (available only as boot time service).

Currents status slides: https://docs.google.com/presentation/d/1Hq7-42EfM4xC_1N1HMO20vXVKSpkA_S-LosSYp4l9Ik/edit?usp=sharing

glikely commented 3 years ago

Closing as out of scope for EBBR

glikely commented 3 years ago

I should elaborate; at the 15 Feb 2021 biweekly meeting this issue was discussed. There is still activity on how to store DTBs, or how to provide an updated DTB, but this issue doesn't really address those topics and so has been closed.