Modules for carrier boards [Was: Re: Question about extension board used in U-boot]

[François Ozog]

Le lun. 20 sept. 2021 à 13:32, Daniel Thompson <daniel.thompson at linaro.org>
a écrit :

> On Sat, Sep 18, 2021 at 08:49:48AM +0200, François Ozog wrote:
> > 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.
>
> What you're describing sounds exactly like Raspberry Pi HATs work:
> https://github.com/raspberrypi/hats/blob/master/devicetree-guide.md
>
> Similarly Beagleboard capes use rely on I2C EEPROMs for make them
> discoverable, although I don't think all have to have a built-in
> overlay (IIRC because they joined the party too early).
>
I believe this would be a great SystemReady addition: define details of the
DT lifecycle and probably adopt one of the two models. Or worst case define
a consolidated one.
I hope this is also adoptable by  96boards…

>
> In other words there's plenty of prior art here and, as new hardware
> standards come out, it should be much easier for them to find this prior
> art. However I'm near certain mistakes will still be made...
>
>
> > 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.
>
> Sub-optimal or not[1] the u-boot extension board code still looks like it
> would be a good starting point even for boards with non-discoverable
> extensions (96Boards CE 1.0 for example).
>
> If implementing on a board with non-discoverable extensions then I would
> consider implementing "extension scan" to report non-discoverable modules
> (e.g. from an internal list) and proposing patches to that "extension
> apply all" would not enable non-discoverable boards (so that non-
> discoverable boards would have to be enabled by injecting a "extension
> apply <id>" into the boot scripts).
>
> Of course, I may have overlooked a better existing mechanism in u-boot
> but that's what I would start with until I was corrected by
> maintainers ;-) .
>
>
> Daniel.
>
>
> [1] And also extremely off-topic for Paul since his (a) boards are
>     discoverable and (b) the extension framework can't fire up early
>     enough for TPM extensions ;-) .
>
>
>
> > 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.
> > >
> > >
> > > 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 at linaro.org | Skype: ffozog
> > _______________________________________________
> > boot-architecture mailing list
> > boot-architecture at lists.linaro.org
> > https://lists.linaro.org/mailman/listinfo/boot-architecture
>
-- 
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog at linaro.org | Skype: ffozog