Question about extension board used in U-boot

[Heinrich Schuchardt]

On 9/18/21 8:54 AM, François Ozog wrote:
> Le sam. 18 sept. 2021 à 08:49, François Ozog <francois.ozog at 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) <paulliu at 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.ozog at linaro.org | Skype: ffozog
>>
>> --
> François-Frédéric Ozog | *Director Business Development*
> T: +33.67221.6485
> francois.ozog at linaro.org | Skype: ffozog
> _______________________________________________
> boot-architecture mailing list
> boot-architecture at lists.linaro.org
> https://lists.linaro.org/mailman/listinfo/boot-architecture
>