On 9/18/21 8:54 AM, François Ozog wrote:
Le sam. 18 sept. 2021 à 08:49, François Ozog <francois.o...@linaro.org> a
écrit :
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.
i just forgot to state that the mode is well known: SPD for DIMMs.
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) <paul...@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.
You could implement the weak function board_fdt_blob_setup() to detect
your addon boards and extend the devicetree.
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
Measured boot is provided in U-Boot v2021.10-rc4 based on TPMv2. Just
enable CONFIG_EFI_TCG2_PROTOCOL.
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?
U-Boot has a fdt command which you could use to apply overlays. Or
implement function board_fdt_blob_setup().
Best regards
Heinrich
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.o...@linaro.org | Skype: ffozog
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.o...@linaro.org | Skype: ffozog
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
_______________________________________________
boot-architecture mailing list
boot-architecture@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/boot-architecture
