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=-10.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 ACC47C433F5 for ; Mon, 20 Sep 2021 11:32:47 +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 CE7576101C for ; Mon, 20 Sep 2021 11:32:46 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org CE7576101C 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 7441482A01; Mon, 20 Sep 2021 13:32:44 +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=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (2048-bit key; unprotected) header.d=linaro.org header.i=@linaro.org header.b="ULUyde5b"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 8539D82A15; Mon, 20 Sep 2021 13:32:42 +0200 (CEST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 806B5829F9 for ; Mon, 20 Sep 2021 13:32:38 +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=daniel.thompson@linaro.org Received: by mail-wr1-x42f.google.com with SMTP id u15so28691120wru.6 for ; Mon, 20 Sep 2021 04:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=py+xWWyzBL6hoQIyvRHDw7wGM5P717WtcT66g804Ojs=; b=ULUyde5bBytN4HUi4s+Bp8Ld4NGY6R5MFAPKD9lImzR80E0qc0LvUFrgACmX0vhRxW anq+qysn482XOtYPryFSCJqLnBNvIGlSQ9UcvE2XDerMVXHaUq+8WsO8XfkbL4DYl051 2sTgVI7lUQWJ9/iU4Oc1dyIb3M2QxUKVMqx0lXPeb1/zh7pBje/V0f4QAKiAhFmksfjm 5CzqRLThzf4ia7R7/52p7F4PJF5aBLwACYVJwZZ8cVM8NqQeCWMIw14noyite+vYKIx7 ac5EZWoN3nmPJz/sQar7hVKKxl8eGUYmz8FTKfjcHxf53k97E3FoMpxp9KdvnvM64YcZ lSRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=py+xWWyzBL6hoQIyvRHDw7wGM5P717WtcT66g804Ojs=; b=tjM51ernuojBhA/ppVFOsX+b08nJwVDZ3K98eQrEbFXwGqcfOZodeXMFz6e5pRveo3 6QwLDpKalx14vq7JZdJfASLMNbW4BYzpKLJwwd5QH01NWpjktBB3BxLYDm1eTZfxS4+q MAujieb9aCDQNhyyT4z31quGSy5obBhG7oTWS0P6hsu3CaP9eQqSDxSHekSnLkU2J//k 2rXOCKb3Za7y7RGFPA1dBkNbuiC5LA8XZb/ITWDVmRvvR8eW41Lw89ksGa8i6dcOokcz BepGCdhDFxG7TBuXxRwuhqej4ICVaWCnAzBg2ot3zG7LaKPdIrqfNfKBM5rc5+/Q6c1B 3T/Q== X-Gm-Message-State: AOAM532wNPE0RKVERUtTrW583A0CV05X93cPe8HJ3I3FArpm/pQkjNY8 kXcnU7OFh6ZhIU8GHD+KvgzwlA== X-Google-Smtp-Source: ABdhPJzyPwt8Emne4SaX1l2G6JCZirqt2Jm/VLPXLClCMU0duYVxtxn3kaGKpmADNEsB81LgDPRuJg== X-Received: by 2002:a5d:4579:: with SMTP id a25mr27951761wrc.222.1632137557882; Mon, 20 Sep 2021 04:32:37 -0700 (PDT) Received: from maple.lan (cpc141216-aztw34-2-0-cust174.18-1.cable.virginm.net. [80.7.220.175]) by smtp.gmail.com with ESMTPSA id h18sm15403604wrb.33.2021.09.20.04.32.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 20 Sep 2021 04:32:37 -0700 (PDT) Date: Mon, 20 Sep 2021 12:32:30 +0100 From: Daniel Thompson To: =?utf-8?B?RnJhbsOnb2lz?= Ozog Cc: "Ying-Chun Liu (PaulLiu)" , u-boot , Bill Mills , Boot Architecture Mailman List Subject: Modules for carrier boards [Was: Re: Question about extension board used in U-boot] Message-ID: <20210920113230.6rxkst4tuy3rj55f@maple.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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 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). 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 " 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) > 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@linaro.org | Skype: ffozog > _______________________________________________ > boot-architecture mailing list > boot-architecture@lists.linaro.org > https://lists.linaro.org/mailman/listinfo/boot-architecture