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=-12.2 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,USER_AGENT_SANE_1 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 5EA84C433EF for ; Mon, 20 Sep 2021 15:28:06 +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 55B6561077 for ; Mon, 20 Sep 2021 15:28:05 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 55B6561077 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com 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 3CC0680EC5; Mon, 20 Sep 2021 17:28:02 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="OEc4I0vb"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id D385B80C68; Mon, 20 Sep 2021 17:28:00 +0200 (CEST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 90E5A80C68 for ; Mon, 20 Sep 2021 17:27:56 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qt1-x832.google.com with SMTP id d11so15913090qtw.3 for ; Mon, 20 Sep 2021 08:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=J/3HKmfADSjn9VAm8jdpL8ZFUs5dFjuKpsDkBPhjZIY=; b=OEc4I0vbxRvHWsnQI1BSV7qD/HZGix9bH1DM3xWJrC1+jV3n0ziSkGgxiT+uLNi8mp TXQwaB8JDbqCPyIE55cRMY+A1vLvvm/47RwHBSXa088sAWl8hTSTMsKu1rnFt0fV5fhK GvKK/GAD2VC+SZtTwcRlR82iFMsPLsBkgaTgE= 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:in-reply-to:user-agent; bh=J/3HKmfADSjn9VAm8jdpL8ZFUs5dFjuKpsDkBPhjZIY=; b=fIvv98ZCNgLwUScoiz8Ej68JYT2s+MGkV0Sb1iE7zmg5264kSuQHV14WLikBbee3mw Ta5AS8Y7fT43PeovDZl5ifAAspo8yZdiPuiaN//PCV1+SWT6JfrT8Tephov1IPMuBdhE kMuCW/uz9lcD7U64WFXsZWnzD9LF7K0EDfC3enNLNd4jxlrodAZKM2NGzqZ6cKJrimEJ AKXbqti/3AdQW1JEkiNjpBZBD+lDfe1p2Y0UVLo9Pf9cdAd+J4hTkji0j0lG1cxwifqX VH++vKuojM0fP2Zs8g5QM7vmgPrnrqdr7D4tgydameWoqynycFwLErkvZ0CZUq0E2cwL R3/g== X-Gm-Message-State: AOAM532FaDgqNGDiBeY0nbTXmYwBU/OBZFBcM9R0FiEQqJyJo3OFOTn2 x/bmzswF2+Szfnqhjwp47r96RA== X-Google-Smtp-Source: ABdhPJwNgJD5WhGkkz/jqgOhCOb/qX6GB85kMTenHmRiUUJr1kYEKefJtda2Evr9t49+csNKiOjddw== X-Received: by 2002:ac8:724c:: with SMTP id l12mr23332180qtp.131.1632151675276; Mon, 20 Sep 2021 08:27:55 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-09be-67ba-cce9-f7cd.res6.spectrum.com. [2603:6081:7b01:cbda:9be:67ba:cce9:f7cd]) by smtp.gmail.com with ESMTPSA id o15sm749403qkk.129.2021.09.20.08.27.54 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Sep 2021 08:27:54 -0700 (PDT) Date: Mon, 20 Sep 2021 11:27:52 -0400 From: Tom Rini To: Simon Glass Cc: Mark Kettenis , Moiz Imtiaz , U-Boot Mailing List , Moiz Imtiaz Khan , Jehannaz Khan Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting Message-ID: <20210920152752.GY8579@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> <20210917172605.GA8971@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="65fUfJaAyj3QT6Mb" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.9.4 (2018-02-28) 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 --65fUfJaAyj3QT6Mb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2021 at 03:27:48AM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Fri, 17 Sept 2021 at 11:26, Tom Rini wrote: > > > > On Fri, Sep 17, 2021 at 10:19:18AM -0600, Simon Glass wrote: > > > Hi Mark, > > > > > > On Wed, 15 Sept 2021 at 05:52, Mark Kettenis wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Wed, 15 Sep 2021 04:13:24 -0600 > > > > > > > > Hi Simon, > > > > > > > > > Hi Mark, > > > > > > > > > > On Sat, 11 Sept 2021 at 13:18, Mark Kettenis wrote: > > > > > > > > > > > > > From: Moiz Imtiaz > > > > > > > Date: Sat, 11 Sep 2021 23:19:05 +0500 > > > > > > > > > > > > > > Hi Simon, > > > > > > > > > > > > > > Thanks for the reply. I already followed the steps mentioned= in > > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > > > > > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-= Boot, but > > > > > > > instead one provided by the earlier-stage firmware? > > > > > > > > > > > > > > Not sure, but seems like this is the case. I checked and ther= e isn't any > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boo= t. I tried to > > > > > > > add the dtb and other dts dtsi > > > > > > > files > > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_S= EPARATE and > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot th= e U-Boot and > > > > > > > it would just give a blank screen*. I wonder why there isn't = any device > > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not s= upported by > > > > > > > RPI4? > > > > > > > > > > > > The issue with the rpi4 is that the addresses of devices move a= round > > > > > > based on the version of the Raspberry Pi firmware you're using.= And > > > > > > possibly on the amount of memory on the board as well. So U-Bo= ot > > > > > > pretty much has to use the device tree passed by the firmware s= ince > > > > > > the device tree in the U-Boot tree would be wrong for many > > > > > > combinations of firmware and hardware. > > > > > > > > > > > > Simon, this sort of thing is exactly the reason why I think the= idea > > > > > > of having all U-Boot configuration information in a single devi= ce tree > > > > > > with the hardware description doesn't work everywhere. > > > > > > > > > > >From my reading of this thread, it rather reinforces the need to > > > > > provide a way to give U-Boot the config it needs, in the devicetr= ee. > > > > > > > > As long as that configuration is optional, yes, maybe. > > > > > > > > > It seems that rpi is actually OK in this regard. If you think abo= ut > > > > > it, it would be pretty hopeless if first-stage firmware assumed t= hat > > > > > it could provide a devicetree to whatever is next. > > > > > > > > Not hopeless. If that device tree provides a hardware description > > > > that is complete enough to boot Linux, it should be good enough to = run > > > > U-Boot. > > > > > > Not in general. I hope I have covered this in enormous detail in the > > > devicetree patch. But if you don't need verified boot, SPL or some > > > other feature that needs config, then perhaps you will get away with > > > it. > > > > Wait, why does SPL _need_ it? If something provides us with a device > > tree, we don't need u-boot,dm-spl as that's used to filter nodes in to a > > smaller DT to use. >=20 > Yes, although if the filtering is not done I am not sure what SPL > would do. In fact we don't have a way to provide two DTs (SPL, U-Boot > proper) from a prior boot stage at present. The need to filter the DT down for SPL tends to be because we don't otherwise have enough initialized memory to retrieve / work with / etc the DT. That can't be true if some other stage is handing us something. > > Dealing with u-boot,dm-pre-reloc could be trickier, > > but means whatever loaded us needs to have enabled any early clocks we > > need. But even then, it's just going to be output related? And some > > "was already configured" path could be used. >=20 > My point is that ignoring U-Boot's devicetree requirements doesn't > work in general. It may work in specific cases. It cannot work for > verified boot of course. I'm trying to not belabor the point here, since you've said you'll post some bindings for review, but it's not _our_ device tree. That breaks the whole blasted point of having "a" device tree, rather than everyone having their own device tree. So figuring out a good path forward for verified boot is something that'll require a little more thinking quite possibly and explaining how you do it on something again modern and potentially hardware-assisted. --=20 Tom --65fUfJaAyj3QT6Mb Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFIqHgACgkQFHw5/5Y0 tyxBlQwAr2ZkueiHfseO0QfWW5Uttdtjefvhz13CIp3dca7/NJqdvhfWJa03shcO W4o0+mN0q3+MuSVYcqsR2gc/4gnTXOSD1mXZCcKF0yxuP0UtZ1OWd78HCv1zI+yk ePfsNHEL3b8P71gEuLoTYRtwbz0wllxNfdqTc0wC3Y0Ug9+Thwp+mwmNFknPX6oW AIW6bLSwi2EKLJnaUPUE2qVMU+kd1Myt0YImsYGdxo70hk3F/zt1p+cpqkxowp0g m0ngV2OtRJnF3SrJUkeFH3hp+gMvHvY1atuEwMsUybbkes/9sYlS7XSNk3BHIOut EUWg2Lrl0B+L05zBVi/eqqKs/y1fZieqaA6xX3eTVDR1NDl+WWTLJHSODB1vXYAT 6357R6PUwCIPT04onR3m5OePz0CXsDd8SoetTedneDaJ6KkRKES+q0Z9lQJIKVvn iRaGQfIVHve04X5hmBtsNLflCPA2UVGY6m8b5Vl4o3iSiRMViz7wyRBgpHGfDZJE eEiddHVn =/+4y -----END PGP SIGNATURE----- --65fUfJaAyj3QT6Mb--