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,URIBL_BLOCKED,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 B534DC433EF for ; Fri, 17 Sep 2021 17:43:05 +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 E2EFF60E05 for ; Fri, 17 Sep 2021 17:43:04 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E2EFF60E05 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 77BFD83202; Fri, 17 Sep 2021 19:43:01 +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="WLSEaeRH"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id E769E83208; Fri, 17 Sep 2021 19:42:58 +0200 (CEST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 8DD5D82D52 for ; Fri, 17 Sep 2021 19:42:54 +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-x82d.google.com with SMTP id j13so4593006qtq.6 for ; Fri, 17 Sep 2021 10:42:54 -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=iutEMcyB+lwIY+aqVzHTz+F7t9S2ej/hfkSsmz5xOPY=; b=WLSEaeRHhIPveK0IScRl1F3c6f1GymSTkuxkMRycA7mz90+7Y/tb4ZxBpmd0TJfOPF 09nDQIHAQCkCroSdNJmMLoy+yeRFsTi/UTY08zlJnfgAo+pfbj41OyqMwcJjj11Sk8VZ 3bQumLpvEq4oRoDRgBzORf3kO9zC1c5C4rGd8= 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=iutEMcyB+lwIY+aqVzHTz+F7t9S2ej/hfkSsmz5xOPY=; b=cVCGJGAAuZEIBRXM2fpQB6rh5z5LbTo8e/s14IfZNpg0kPfJ013qY6NmjVsGnIEaWa +reM+HsNlK+T8bXYqAKgdaFrHR6yV37lwKV1gFqv9PuMKy1ek40wfx3spkV1wZMtTyPG g6vqn0DZxU+/HcwSEBfy2KFLNN4dfoaNmqzP8jNBwxW8DY91F9S7Cs5BtNd1GZDZIF+o tL6x1khlAB5Xkx7CQ9GbDZH89Ug9FtNKzDr064OlxO4stWNWPyAIf0U0rOOgZVHqK8le AgRZdgU5QBfoljyJqOCXDzEdQs7rb7bcFvxVnVaIMF1uKhTg4EcLaJ8JXEbwGUfaCOGA rVQA== X-Gm-Message-State: AOAM531I0zoKvggeOL4t6CIS5DPsfXLaveNf47nn9yIoyVNnQj1FHtN2 ozFhJQStKijqRbAEJo5R2argaA== X-Google-Smtp-Source: ABdhPJz347BPCFNN/WkF17fNQy595vfr9y1wSoirySETkegaRNBz/1F11zZTlsUqXYUVe9t0cTifcw== X-Received: by 2002:ac8:7c56:: with SMTP id o22mr11496691qtv.366.1631900573257; Fri, 17 Sep 2021 10:42:53 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-e4f8-f572-7f11-97be.res6.spectrum.com. [2603:6081:7b01:cbda:e4f8:f572:7f11:97be]) by smtp.gmail.com with ESMTPSA id u189sm5260982qkh.14.2021.09.17.10.42.52 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Sep 2021 10:42:52 -0700 (PDT) Date: Fri, 17 Sep 2021 13:42:50 -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: <20210917174250.GB8971@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> <20210915133547.GV12964@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="LyciRD1jyfeSSjG0" 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 --LyciRD1jyfeSSjG0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 17, 2021 at 10:21:15AM -0600, Simon Glass wrote: > Hi Tom, >=20 > 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 mentioned in > > > > > > "doc/uImage.FIT/beaglebone_vboot.txt". > > > > > > > > > > > > >I wonder if rpi is not using the devicetree compiled with U-Bo= ot, but > > > > > > instead one provided by the earlier-stage firmware? > > > > > > > > > > > > Not sure, but seems like this is the case. I checked and there = isn't any > > > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot.= I tried to > > > > > > add the dtb and other dts dtsi > > > > > > files > > > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEP= ARATE 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 an= y device > > > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not sup= ported by > > > > > > RPI4? > > > > > > > > > > The issue with the rpi4 is that the addresses of devices move aro= und > > > > > 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-Boot > > > > > pretty much has to use the device tree passed by the firmware sin= ce > > > > > 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 i= dea > > > > > of having all U-Boot configuration information in a single device= 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 devicetree. > > > > > > As long as that configuration is optional, yes, maybe. > > > > Lets be a little careful. We don't want to have two ways to provide 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 about > > > > 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 to run > > > U-Boot. > > > > And keep in mind that one of those long stated goals is that the device > > tree for a platform lives physically on the platform and doesn't require > > being replaced entirely at run-time with a new/different device tree. > > > > > 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 apply 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 could > > > > 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 kernel. > > 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-recent > > piece of hardware. > > > > > In practice, the device tree provided by the firmware will have more > > > 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 does= n'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_LOADER > > > 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 device > > 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 "what > > should U-Boot require of the DT?" problem. I'm thinking that might be > > the right answer, in some cases. >=20 > 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 Tom --LyciRD1jyfeSSjG0 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFE05YACgkQFHw5/5Y0 tyxG4gv/X+F8j24bMF5m08DJT+1eRh+MXFmE759Hzvxzduxo8AON4BjrKIsHoKnn M8dhWZsETLT3z6WN1awZL6IaWYuJYrK751+sy4OQCY5U+C/xBEghupIHe5G2knIO DAlqbnDF53krZZM8w8GXsRR1JwF78Zdxm/Ob34Tj9kvDHsJPCdFvb9TBwCUg/6bm SKRGjLKUbiO4HcJ6T4JptoAsBMSoJsbd9ReBeAuQ2exlHCYZvNwLSLiccqkl1ZB0 YO7cZJX2/x0qenMKM+EAXoQuepqaaVcLV3AVUCFGl0ck3We9yUwckgdnZ5Lh8Lcl 0T2jKYsBkhomKYN6HcjpLi8gwryVDPXeMi/24m7EYHqd9Eoby/1/TReppVGaekOe eY6j92b+N8c2yPPAI8D8xFckV8NE2UB3FKVzVQ45c8mOZkNEdmVnzZPwHGcwGbeh LSE339u6WoA+XMercwytZaNtKqhHkHiQU5TfwtcJCtu9K3CkFnvMeJ1qvFyd0S3H 38xOnTap =pBb2 -----END PGP SIGNATURE----- --LyciRD1jyfeSSjG0--