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 6820AC433EF for ; Sat, 18 Sep 2021 13:24:21 +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 A22FF6128A for ; Sat, 18 Sep 2021 13:24:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A22FF6128A 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 C7CE08322E; Sat, 18 Sep 2021 15:24:17 +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="WMY7piYP"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 7F4B88322E; Sat, 18 Sep 2021 15:24:15 +0200 (CEST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 14D49829FC for ; Sat, 18 Sep 2021 15:24:11 +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-qv1-xf2c.google.com with SMTP id cf2so8214764qvb.10 for ; Sat, 18 Sep 2021 06:24:11 -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=rXnpTL9YCJifv0zK4u7q7dndjh3o3S2cj0NNyR+8R54=; b=WMY7piYPAs0BOMMkAGAbR3CROK3t43+4gqjHRhTXq2FavsVD0bIKh1O6kA/1R60asq ox8Y/f+fDxYvkMTKCk1vLoWLSNGmcjfyQoRuPHAJxEoPm70a5EDJHK0vXom1cGuiEIDL zMgSPHCimv89ooAKXqzPPCHQVZ9iR3L/VvECQ= 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=rXnpTL9YCJifv0zK4u7q7dndjh3o3S2cj0NNyR+8R54=; b=V84I+FmyLbYsTt7j7+RnhZ+sdyMB5TlbXCgt8DQ1ualSgoEn+cAwMzR+sdarmH1v5q yS1rdUXKqGMLYFPRVcKDCeOst9DW5lxr/coinoWsG0i8IproKqTRufuS2AgfJKV04vXq 27Jrcb0t4OT7gKuMZJvzdahi9ehE9WuvUfuhr3FEupoNTa0YYdCyt6ABn2LCEu6rxqqz 55wqSKs3Mj9pNlMehnOe/IXe6o06NPsWYIt/ITAET+hayhO1/TgF1+KedNUx2r6VhX+q jfyzfBiIXBx2JBnU2EbkJswXKWeBt8OvP2FeEIgsI6gG+lV8EAJvwMtLYleSAtcqzfS2 wo7w== X-Gm-Message-State: AOAM531QrdM9Y+PwA895putcRv1Qwhhz+SHaEMgcnE0rMgY+j98iedrL n4HuhfmyVqFwnqtAfYs3gYPkfg== X-Google-Smtp-Source: ABdhPJxkQ5AnhoYP9+sAIh8e2P93LPPQfXsxLtOLS3hEPJNJeaQ9Ad7eE9Lsiam+yPQwzuV/1lEvXg== X-Received: by 2002:a0c:d412:: with SMTP id t18mr16626434qvh.53.1631971449751; Sat, 18 Sep 2021 06:24:09 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-11d5-faa7-99fc-5b2d.res6.spectrum.com. [2603:6081:7b01:cbda:11d5:faa7:99fc:5b2d]) by smtp.gmail.com with ESMTPSA id t5sm1183329qkj.61.2021.09.18.06.24.08 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Sat, 18 Sep 2021 06:24:09 -0700 (PDT) Date: Sat, 18 Sep 2021 09:24:07 -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: <20210918132407.GN8579@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> <20210915133547.GV12964@bill-the-cat> <20210917174250.GB8971@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="SEFvVLxbW/dEDtN8" 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 --SEFvVLxbW/dEDtN8 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2021 at 03:27:40AM -0600, Simon Glass wrote: > Hi Tom, >=20 > On Fri, 17 Sept 2021 at 11:42, Tom Rini wrote: > > > > On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote: > > > Hi Tom, > > > > > > On Wed, 15 Sept 2021 at 07:35, Tom Rini wrote: > > > > > > > > On Wed, Sep 15, 2021 at 01:51:51PM +0200, 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. > > > > > > > > Lets be a little careful. We don't want to have two ways to provid= e the > > > > information for a given feature. But some configuration properties= are > > > > certainly optional. > > > > > > > > > > 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. > > > > > > > > And keep in mind that one of those long stated goals is that the de= vice > > > > tree for a platform lives physically on the platform and doesn't re= quire > > > > being replaced entirely at run-time with a new/different device tre= e. > > > > > > > > > And yes, the Raspberry Pi has a nice way to load overlays to do > > > > > additional hardware configuration and support add-on hardware that > > > > > connects to the GPIO header on the Pi. Replicating all this in U= -Boot > > > > > would make very little sense. > > > > > > > > Note that in U-Boot we do have functionality to figure out and appl= y DT > > > > overlays for a platform, and it's generic enough that platforms can > > > > plugin their logic to detect what overlays are appropriate. This is > > > > under CMD_EXTENSION. It's not appropriate for Pi as they did all of > > > > this in their in-house firmware instead of using U-Boot. > > > > > > > > > > For example, if U-Boot evolves to support more devices, they co= uld > > > > > > not be supported. > > > > > > > > > > Unless the device in question has a mechanism to load device tree > > > > > overlays like the Pi, this would require a firmware update. > > > > > > > > In that CMD_EXTENSION is about updating the tree for the next stage= , and > > > > not ourself, yes. But this is also the same problem that OSes have= that > > > > lead to overlays, at least in part. But also why it's so hard to > > > > support a static device tree on hardware, and have an evolving kern= el. > > > > I'm not sure there's many / any good examples of wholly static and = also > > > > feature complete device trees and OSes today, on a recent / semi-re= cent > > > > piece of hardware. > > > > > > > > > In practice, the device tree provided by the firmware will have m= ore > > > > > stuff than U-Boot will ever need though. Unless you're advocating > > > > > that U-Boot evolves into a full-fledged OS ;). > > > > > > > > > > > If UEFI is used, the devicetree would have no effect, since it = doesn't > > > > > > support devicetree. > > > > > > > > > > That is not true. UEFI supports device trees just fine. All the > > > > > arm64 and riscv64 boards supported by U-Boot that include EFI_LOA= DER > > > > > support use device trees. The idea that UEFI implies ACPI is a > > > > > misconception. > > > > > > > > > > > So perhaps the only remaining issue is with qemu on ARM / Risc-= V? > > > > > > > > > > Maybe somebody can add device tree overlay support to QEMU? > > > > > > > > Having gone through this thread, I wonder if U-Boot generating a de= vice > > > > tree overlay (and also the keeping the source of it, before > > > > preprocessing if we can) isn't part of the solution here. Heinrich= had > > > > suggested in another thread, and Simon had strongly disagreed with > > > > overlays being how we perhaps solve some portions of the overall "w= hat > > > > should U-Boot require of the DT?" problem. I'm thinking that might= be > > > > the right answer, in some cases. > > > > > > Note that my objection here is adding runtime to U-Boot. If the prior > > > stage wants to arrange things that way, it seems OK to me. In > > > particular for QEMU arm, we could add a -dtsi arg to provide a U-Boot > > > tree to merge with what it generates. > > > > Right. I am talking about U-Boot applying an overlay to a provided by > > prior stage device tree. In the above example of Pi, the prior stage > > has an option already to apply an overlay before-hand, yes. But that's > > not going to be the case for all platforms. >=20 > There is no need for the prior stage to apply an overlay though. It > just needs to provide the correct devicetree with the U-Boot > properties. Well, it depends on what upstream is and how it handles things. The case where U-Boot is optional in the boot chain, like Pi, is perhaps more common than we would like to admit, and at least Pi, and possibly other cases also have a mechanism for applying overlays to the generated device tree, in order to pass it to the kernel (or, U-Boot). I'd almost say that if for no reason other than to make examples for vboot, and other things too, available on Pi (as nearly everyone has one in/on their desk), it's important to do so. It's the most common reference platform. > I'm going to send a binding for the config node upstream and see what hap= pens. OK, please make sure to CC me, thanks! --=20 Tom --SEFvVLxbW/dEDtN8 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFF6HcACgkQFHw5/5Y0 tyxf6gv+NClu7pop2kPbNE0z8TIX4TZ3iABVi/MRSf42lTBgkhZsQDVnKxs8sbXv 8F6Yl2WGdWjwj74/JDhIxZejbjVPtzurLI/EbRgSoyonU0GcLq2leUz7HOYRoLU5 CkdzXb6BiQUR7kaY39AYmWXk3P7aT7GwlyAQU6d19aT8AFdDLR4Cs4zgV3WyaaXa T59sDXqwtzlz/ydrJK6Kc4Zp9IUITyijSnjWVCBQA+iLJspAlj52LHe4NCx603/z nzS9rtO7wlG9cIhnf2gK6yYHTCoQzE/C/LRkSXU9be3e2BXsigUc8gk0Xa6YZp47 G8V15XcPJ40uTaR/FZoL7I/+K6yTr+IfVVsfEm4LdFNQKqu3VpZN/XrGa2X+BHlF bQcqSCCnLCKT2L1n/NK7KvGyFFuR8J0QKxSY3kUDoyFnyYHhusxGsG9jnleGVblP dZ7qaoj2YefrkmCuDoN+vDwUH4NXJgWPvUl7WBTtqdvjagzpSii0FWVayrH9Eg+c Tilpy8E8 =3UtE -----END PGP SIGNATURE----- --SEFvVLxbW/dEDtN8--