From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C40E7C433FE for ; Mon, 20 Sep 2021 15:59:54 +0000 (UTC) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 27F6A610FB for ; Mon, 20 Sep 2021 15:59:54 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 27F6A610FB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.denx.de Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 53D9A82A15; Mon, 20 Sep 2021 17:59:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="UD6rI205"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8CE5F82C47; Mon, 20 Sep 2021 17:59:50 +0200 (CEST) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id E9C33807FE for ; Mon, 20 Sep 2021 17:59:45 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=francois.ozog@linaro.org Received: by mail-ed1-x52e.google.com with SMTP id v24so63282579eda.3 for ; Mon, 20 Sep 2021 08:59:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dUD2wONLvYFwiCNUpm38Wvnf9IJo62wO0YzzMNEUAMw=; b=UD6rI205PCJDM2HATkXFXpl08vMFO0CI0bcoUx1nJUpi2hrCakyIK1QoMbxApOOtZk Q8jptBRcmjI9nNOKjmgN9uuPLdMSevV1bjwwAR6nAnwOPuRBn8CUTtdB+XNNbVTAdgCx JMBZdohpqHwDs7lWPykwl8kDqwjwOoK39nu+vaPyNjJP4//Bz6JNs7TdY3vPm6wg1JNd Rv84s/Vvvi8vkdJR8zphjm1MalMyI8eOz2c2jhX0Q6L3q/JCsw0fYAtTqrazAZzZxp70 qb6SzybiOpUpfJzB1S+zYvNT46poY//Fqm0OhC4DtYQnoGzlU3NT3fB0Nf+WHSADmy0y PjrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dUD2wONLvYFwiCNUpm38Wvnf9IJo62wO0YzzMNEUAMw=; b=wfp7DLK+y9QKNWSUTOfdEjPJwAdGr/sj8Pb/kCXDrVpIWsQkPMJdQLzJbPmyKeCRL/ ve27WD7JxvgBSANnlptp2vrzD146q3h3KXTPiynF3BG3fsVrIWAFXiygs8F0E5KOkaHW DM1I8a4Yk4nhlST4vj/ybY5TTVVxUFTmsNFV90iXSJ8jQO7u6Q0VXKDC5JhaKFJ/wMJE /FXEGcjj4FLP31Skuu1m55Yka/g18QhGIZvcobBFkoDgbz7NiGAWYIYHUBLyg/YDw/Zt KpnZSdSgLhXT8CLLIiRdyjBFm/Yw6Lk2INAqR7GEy2ELu3qJaHkfuoFPmbPuTMZ5MxiL Akbw== X-Gm-Message-State: AOAM531ZT9eOC2soyKZ6Zmuhf7RmQQgfWC1Ir5BtN7q3ku2bSLqKQ65G sdQxgQeCO3Tt2VjbnhinkOeLfuR3IA80gER0IFnxUw== X-Google-Smtp-Source: ABdhPJymEAdbC/qalMM/3wzMuUROQpWKuxkEdYnoBcSUuvYttFImnCdXMmfPOD0cFSSPhyGc+SKL2StEdWj1DJxDTVs= X-Received: by 2002:a17:906:3383:: with SMTP id v3mr30360164eja.213.1632153531891; Mon, 20 Sep 2021 08:58:51 -0700 (PDT) MIME-Version: 1.0 References: <20210920113230.6rxkst4tuy3rj55f@maple.lan> In-Reply-To: <20210920113230.6rxkst4tuy3rj55f@maple.lan> From: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Date: Mon, 20 Sep 2021 17:58:41 +0200 Message-ID: Subject: Re: Modules for carrier boards [Was: Re: Question about extension board used in U-boot] To: Daniel Thompson Cc: Bill Mills , Boot Architecture Mailman List , "Ying-Chun Liu (PaulLiu)" , u-boot Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.34 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.2 at phobos.denx.de X-Virus-Status: Clean Le lun. 20 sept. 2021 =C3=A0 13:32, Daniel Thompson a =C3=A9crit : > On Sat, Sep 18, 2021 at 08:49:48AM +0200, Fran=C3=A7ois 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=E2=80=A6 > > 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 itse= lf > > and another for OS (may be same in some cases) through scripting. And i= n > > 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 " 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 =C3=A0 01:21, Ying-Chun Liu (PaulLiu) < > paulliu@debian.org> > > a =C3=A9crit : > > > > > 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 boo= t. > > > 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 whic= h > > > 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 th= at > > > 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 t= he > > > 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=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* > > T: +33.67221.6485 > > francois.ozog@linaro.org | Skype: ffozog > > _______________________________________________ > > boot-architecture mailing list > > boot-architecture@lists.linaro.org > > https://lists.linaro.org/mailman/listinfo/boot-architecture > --=20 Fran=C3=A7ois-Fr=C3=A9d=C3=A9ric Ozog | *Director Business Development* T: +33.67221.6485 francois.ozog@linaro.org | Skype: ffozog