From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Tue, 6 Oct 2020 17:32:27 +0200 Subject: Fit images and EFI_LOAD_FILE2_PROTOCOL In-Reply-To: References: <951b8fca-da6b-c4bb-8e5a-fc96646f7f07@gmx.de> <1b8fc3ff-ac50-6f70-db61-30f67dd69151@arm.com> <9B772910-62A9-4770-AE55-77460D1F369F@gmx.de> <70e79c8d-ad3f-f08b-1527-1d3cfb87fde9@arm.com> <2cb94bde-7e44-3fe7-dcdc-509b64b6fe4b@gmx.de> <53b34131-ab59-a16a-68c2-51d532d5272a@arm.com> <6dd4f4c2-5c01-bac5-e924-e6d13b540662@gmx.de> <91be0932-372a-7ee3-5ae4-297cc89c039a@arm.com> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, 6 Oct 2020 at 17:08, Fran?ois Ozog wrote: > > > On Tue, 6 Oct 2020 at 16:46, Ard Biesheuvel wrote: > >> >> >> On Tue, 6 Oct 2020 at 16:22, Fran?ois Ozog >> wrote: >> >>> Ard, there is a question for you in the below thread ;-) >>> >>> On Tue, 6 Oct 2020 at 15:02, Grant Likely 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 at linaro.org | Skype: ffozog >>> >>> > > -- > Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group* > T: +33.67221.6485 > francois.ozog at linaro.org | Skype: ffozog > > -- Fran?ois-Fr?d?ric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog at linaro.org | Skype: ffozog