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 8E5E1C433EF for ; Mon, 20 Sep 2021 15:38:40 +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 D06BC61159 for ; Mon, 20 Sep 2021 15:38:39 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org D06BC61159 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 D75A683259; Mon, 20 Sep 2021 17:38:36 +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="py4QUEP0"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 2ADD483231; Mon, 20 Sep 2021 17:38:34 +0200 (CEST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 23A3482D5B for ; Mon, 20 Sep 2021 17:38:28 +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-x82a.google.com with SMTP id x9so3376345qtv.0 for ; Mon, 20 Sep 2021 08:38:28 -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=cdPu29FmoBRyhwGXxmxbtCBXIJLw96kFlRDOq4fzyEQ=; b=py4QUEP0KsV8wdj+uCKogkSRC4xXkIPrrRSw6gSJrI2E0SDrZcWtwYNf52Q3K+NV1w Ja0XjrPpCKPUiX86Ogiayru+aokdff99rKvXZwJvxXAsmUAO3XyRfnuwnFiCOhTO7Yhn Ish7Xp/llBDlyHI3s5Bl/KQuvcfNQ2FkcWyBg= 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=cdPu29FmoBRyhwGXxmxbtCBXIJLw96kFlRDOq4fzyEQ=; b=od+TFOjg5wWsPk9QgBi4JN3wEO4CC3juz9fC0zjBDo7dlvEnlQ9aSId3SQRHRJkDTa lQSTrP9/3OjVJ/32FO95hcbVnTRCxtTzG2BStoB9tgGUtiUX+x/kxWNgIT1xocp8q82t MC1wtM56E1Gk0Wq9ntrV22zSFJlAONcKXhzQCryT2FjYN/c0q4UqPsuZyrQT+igd7din rENU4YbPo2CTaZQd2CCOv84SDe7xgF6qazX+FQeYnTddyCaXLlS1q36wVvmF5mCgUu6q 7l+/YYEPUcja2mBzkc1/cCBsFGYrwiNDAMVWA9srh4I6Y815Qi72O2qBB/T8d95Z03qn wWFQ== X-Gm-Message-State: AOAM531rfM/SZACtFkS/OL7sH0lQSxLoZV5p2mgvqa7Qx4Kg0xBPxgPR KhE+S6GCuB2JFiQYrj1Ipq/s2w== X-Google-Smtp-Source: ABdhPJzlpxz7xOh6hM58QScGJqAoGGJiFweiEVLyDyLiDQJma+SmJGh/pTt9+jQYUB5bKluxeE91Vw== X-Received: by 2002:ac8:7050:: with SMTP id y16mr23803378qtm.44.1632152306901; Mon, 20 Sep 2021 08:38:26 -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 j184sm11807686qkd.74.2021.09.20.08.38.25 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Mon, 20 Sep 2021 08:38:26 -0700 (PDT) Date: Mon, 20 Sep 2021 11:38:24 -0400 From: Tom Rini To: Mark Kettenis Cc: Simon Glass , moizimtiaz1@gmail.com, u-boot@lists.denx.de, moiz.imtiaz@skyelectric.com, jehannazkhan@skyelectric.com Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting Message-ID: <20210920153824.GA8579@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> <20210917172605.GA8971@bill-the-cat> <5614693cd736c804@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="36+Jv5wzUORg1Ut4" Content-Disposition: inline In-Reply-To: <5614693cd736c804@bloch.sibelius.xs4all.nl> 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 --36+Jv5wzUORg1Ut4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2021 at 01:15:07PM +0200, Mark Kettenis wrote: > > From: Simon Glass > > Date: Sat, 18 Sep 2021 03:27:48 -0600 > >=20 > > 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 mention= ed 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 th= ere isn't any > > > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-b= oot. I tried to > > > > > > > > add the dtb and other dts dtsi > > > > > > > > files > > > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF= _SEPARATE and > > > > > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot = the 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= supported by > > > > > > > > RPI4? > > > > > > > > > > > > > > The issue with the rpi4 is that the addresses of devices move= around > > > > > > > based on the version of the Raspberry Pi firmware you're usin= g. And > > > > > > > possibly on the amount of memory on the board as well. So U-= Boot > > > > > > > pretty much has to use the device tree passed by the firmware= since > > > > > > > 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 t= he idea > > > > > > > of having all U-Boot configuration information in a single de= vice 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 device= tree. > > > > > > > > > > As long as that configuration is optional, yes, maybe. > > > > > > > > > > > It seems that rpi is actually OK in this regard. If you think a= bout > > > > > > it, it would be pretty hopeless if first-stage firmware assumed= that > > > > > > 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 t= o 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 t= o 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. >=20 > I still think that if there is some sort of prior stage firmware, > there typically is no need for SPL. And if there is, DRAM is probably > set up already and there are no space constraints so using the full DT > isn't an issue. This isn't strictly true. You can look at the TI Keystone 3 platforms where there's both R5 and A72 cores and it's still an intentional software design to use SPL at the A72 stage. I think this is explained in the U-Boot docs, but if not I think it has been on the mailing list, perhaps? But that's just an FYI really. > > > 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. >=20 > And this is I think the root of the controversy. IMHO, U-Boot should > have no "hard" devicetree requirements other than the requirement that > the device tree provides a complete enough description of the hardware > using standardized DT bindings. >=20 > That doesn't mean you can't have something like a /config node with > U-Boot specific options. I'd say that would be a great way for prior > stage firmware to control U-Boot behaviour. >=20 > But what it does mean is that none of those options can be a "hard" > requirement in the sense that in order to have a functioning U-Boot on > a platform you absolutely have to have U-Boot specific nodes and/or > properties in your DT. >=20 > I guess what I'm saying/asking is, why can't we have some sort of > middle ground here? >=20 > If there is no prior-stage firmware to speak of and U-Boot is entirely > responsible for bootstrapping a board (the typical scenario where you > need SPL/TPL) I don't see a problem with having a control DT that > specifies everything. >=20 > If there is prior-stage firmware, and U-Boot proper is the canonical > payload for that firmware on a board, adding U-Boot specific stuff to > the DT should be no issue. There are some obvious issues here in > keeping DT bindings in synch between the prior-stage firmware and > U-Boot in that case, so standardizing/upstreaming the U-Boot DT > bindings would be helpful in this scenario. >=20 > If U-Boot is just one of many choices for the payload having U-Boot > specific stuff in the DT may not make sense. In that scenario you'd > just get reasonable default behaviour (and potentially no verified > boot). But it should be possible to change the default behaviour > using the U-Boot environment variables in cases where it makes sense. I concur. And I would just note that everyone using DT is supposed to be using the same bindings, so the in-sync part shouldn't be a big issue. --=20 Tom --36+Jv5wzUORg1Ut4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFIqvAACgkQFHw5/5Y0 tyxmvgwAmaLLeEP5OuoktSY9P11Q6k9ye74fuI+EGBr5DWVvGMFTF3sEabnZB0NK qVaCz6VEdIR2oet9UdTtCoC6Gp3q4XihOuzXZdtfjdlLSedael2uwvSZCzBrNjqB t5ETD76AQDTh631euh2R1WY3TsNBnpt0eSW5OB2lrBsfRAfMAVD52fcLuxi3BQiO QIKsLh9xOlT/t7/+D1Kmq/8XzmI1aAsKSH7yu86UaxNUCzApTnUByU4Oaj0vftPq 8wkdFwvo0H1Djy8A6jn7KcStkmR1LPCTnPWSt+xP5mVOUurgNYnytDSoDg7MyRZA kBvH9ITXjohy/UHDyjtq/Y7i0GSnwqZdvuLONUUp3fYFD+twB6zKRVSrXUaN+uVX 00J2koDIcklOcRTHLgNzzSp5Ia6wRdeHHb0UgqALjkImac4VoaP6OCMU8AsJrvJE jj77AM6/swLbO2na1kVE0WGZl7MOq4HAJVJeLzQZGEIVWvis2HPSYA2XrLvtaATQ HpTOzvWj =4mWj -----END PGP SIGNATURE----- --36+Jv5wzUORg1Ut4--