Hi,
Following the EFI capsule revert, here* is a contribution to
understand the context in which we designed the patch set. (everyone
is a commenter, please be mindful).
The presentation explores booting, with more details for the Arm
context, pre and post U-Boot. On Arm, pre-U-Boot is shaped after
Firmware Framework-A and other interfaces. There is a similar approach
in RISC-V with OpenSBI.
There is nothing to agree on: many elements of the presentation are
specifications for the Arm ecosystem. The purpose is to reach common
understanding of those for rest of the journey.
Careful reading is required because as we all know very well the
topic, we may skip over stuff and miss key elements that may have
changed since you last checked. So I'll attract your attention on:
Slide 9: there can be multiple device trees in a Trusted Firmware FIP
(nothing to agree on...)
Slide 11: roles and responsibilities of firmware go far beyond booting
and OTA. CoreBoot and SPL will have to take those into account in the
future.
Slide 17: there is a new boot flow based on "give-me-my-initrd" UEFI protocol
Slide 24: when the firmware is stored on Secure Storage which is a
common case for products, U-Boot/Linux have absolutely no means to
perform the update (see notes for details).
Slide 28: there are plenty of keys needed, the U-Boot and U-Boot
updater can be different; as well as all firmware components.
I acknowledge that the presentation is hard to read without enough
speaker notes or myself talking to it. Let's say that I prefer to keep
the ball rolling before we can actually program a call: could you send
me in private message your preferred day of the week and best time
(with TZ) for such a thing?
Cordially,
--
François-Frédéric Ozog
*) https://docs.google.com/presentation/d/1AHTf9xMNqPXbiDLkBpoKt45UTjV8s34Jdtm…
Hi Paul
Too posting because I think we also need to address this at a higher level.
i think we discussed this topic quite a while back. I may be wrong but it
may be Bill Mills who proposed to have an eeprom on the extensions that the
carrier board can use to detect and fetch proper overlay. Another way would
be that the contract between the extension board and the carrier board
includes an i2c accessible storage to fetch an overlay that would identify
the board and give all details. Bottom line, a software only solution seems
not entirely satisfying.
In that suboptimal case, U-Boot shall be able to assemble a DT for itself
and another for OS (may be same in some cases) through scripting. And in
this case, come your questions below
.
Le sam. 18 sept. 2021 à 01:21, Ying-Chun Liu (PaulLiu) <paulliu(a)debian.org>
a écrit :
> Hi all,
>
>
> I have some questions about how to implement extension board usage.
> My case is on imx8mm-cl-iot-gate. It can add three different types of
> extension boards.
> One of the extension boards is SPI extension which have 3 empty slots.
> And you can add
> some small boards onto it. One of them is a "TPM2" module.
>
>
> My first question is if I want to use tpm2 in U-boot for measured boot.
> How to implement this right? Currently I just modify the dts used by
> U-boot to let it drive
> the extension board. And let it drive the TPM. But it is not good for
> upstreaming because
> when other types of extension boards installed then it is not working.
> Where to implement this? What is the best practice of this?
> The second question is about extension manager.
> I have read the extension.rst. I think I'll implement this anyway
> because then
> I can have a command to query what type of extension boards I have.
> And if the extension board is the 3 slots one. I can then detect which
> slot is the TPM.
> I'll implement this anyway because the "extension" command is convenient
> for users.
> But it seems to me that it only solves the problem for Linux kernel.
> It can apply a DTB Overlay to Linux DTB to let Linux knows we have that
> extension board.
> But it is too late for U-boot itself, right?
>
>
> The third question is I'm also dong SystemReady IR certificate. That means
> the dtb for Linux is directly provided by U-boot. We use U-boot dtb
> directly to Linux
> kernel. In this case, how to modify that dts dynamically to feed to the
> Linux kernel by
> the extension manager?
> What is the best practice if I want to use U-boot dts for Linux in
> implementation?
>
>
> Thanks a lot.
>
>
> Yours,
> Paul
>
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
All,
Today is the first day of the Linux Plumbers Conference.
I suspect we will not have quorum.
However since I did not cancel before now, I will be on the bridge.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
Hi,
this mail just to inform you that there is a plan to support native
building of PE/COFF for aarch64 and in particular to support SBAT for
shim.efi.
It is seen possible to deliver this by the end of October (this is just an
early estimate).
Cordially
FF
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog(a)linaro.org | Skype: ffozog
All,
Monday Sept 6 is a US Holiday so I am canceling the call this week.
Thanks,
Bill
--
Bill Mills
Principal Technical Consultant, Linaro
+1-240-643-0836
TZ: US Eastern
Work Schedule: Tues/Wed/Thur
