On Tue, 6 Oct 2020 at 17:08, François Ozog francois.ozog@linaro.org wrote:
On Tue, 6 Oct 2020 at 16:46, Ard Biesheuvel ardb@kernel.org wrote:
On Tue, 6 Oct 2020 at 16:22, François Ozog francois.ozog@linaro.org wrote:
Ard, there is a question for you in the below thread ;-)
On Tue, 6 Oct 2020 at 15:02, Grant Likely grant.likely@arm.com wrote:
On 06/10/2020 13:52, Heinrich Schuchardt wrote:
On 06.10.20 14:43, Grant Likely wrote:
Current U-Boot by default uses the same DT image for both U-Boot internal setup and to provide to the OS. This should be split so that the U-Boot internal version has what U-Boot needs without needs to
track
mainline Linux DTB schema.
I've been looking into a generic config for adding a separate OS-dtb
to
U-Boot that is not used internally and is only passed to the OS. That would solve the problem you're seeing above.
What would be the advantage of building said second device-tree into U-Boot instead of loading it from a (possibly signed) file?
I would see that as an implementation detail, but from the OS point of view EBBR requires the firmware to provide a DTB to the OS without the OS having any involvement in providing it. The easiest solution is to embed the OS dtb into U-Boot, but it could be loaded and verified from a file as well.
To strongly state that the DT is a hardware description entity, disconnected from open source projects consuming it, I would still build the DT for the Booted Payload in the context of devicetree.org and append it to either FIP or U-Boot. From a hierarchical perspective FIP would make more sense (I was told by the LinuxBoot guys that the ACPI tables are tied to PEI so that they can use them while replacing EDK2. I am not sure my understanding is correct: Ard ?)
For TF-A, I would think having the same DT lifecycle regardless BL33
(U-Boot, LinuxBoot, Xen...) is a nice objective. hence the FIP proposal. In this context, U-Boot, LinuxBoot and Xen can have their own DTB for their operations. I am just considering the DT for the Booted Payload. Other firmware frameworks (U-Boot SPL, coreboot) may have different flows.
No that is a lie. In EDK2 based firmwares, there are DXE protocols used for publishing and manipulating ACPI tables, and for exposing them via the config table array when the boot finally occurs.
Are the ACPI tables "static" blobs that are integrated into the firmware
image with some late fixups in the DXE phase or are they entirely built programmatically during the DXE phase? In the case they are static base blobs in the firmware image, are they used (to access hardware, not manipulated) in all phases (SEC, PEI, DXE) ?
I should also point out (for anyone that hadn't noticed) that the Linuxboot guys have a highly skewed and opinionated view of UEFI boot, which seems mostly based on bad experiences with IBV provided, OEM mangled builds for proprietary code bases of which it is unknown how much they are based on EDK2 (or UEFI for that matter). The IBVs used to claim that they carried their own complete implementations of the PI and UEFI and specifications, but everybody knows that is a lie, especially for firmwares built for ARM machines.
as I consider that PEI and TF-A are at the same layer I am inclined to
promote this.
TF-A is secure firmware, PEI is non-secure firmware, so I suppose it depends on how you defined your layers. Although in the x86 context, PEI executes when the SMM execution context has not split off yet, so it s closer to a secure world firmware than it is on ARM (same applies to DXE before EndOfDxe, but the boundary line is not as clear in this case)
I was biased by the x86 model here...
Should the DTB cause problems, the one embedded in the FIT would be
replacing the platform base one (I assume this is your "loaded and verified from a file" comment).
g.
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog
-- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog