Le lun. 20 sept. 2021 à 13:32, Daniel Thompson <daniel.thomp...@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) < > 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. > > > > > > > > > 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.o...@linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture@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.o...@linaro.org | Skype: ffozog _______________________________________________ boot-architecture mailing list boot-architecture@lists.linaro.org https://lists.linaro.org/mailman/listinfo/boot-architecture
