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 1BF4EC433F5 for ; Wed, 15 Sep 2021 13:36:02 +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 454D160F26 for ; Wed, 15 Sep 2021 13:36:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 454D160F26 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 6B1BA82C47; Wed, 15 Sep 2021 15:35:58 +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="iVEBLuOO"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 0F6F582C7D; Wed, 15 Sep 2021 15:35:56 +0200 (CEST) Received: from mail-qv1-xf32.google.com (mail-qv1-xf32.google.com [IPv6:2607:f8b0:4864:20::f32]) (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 2571182C2B for ; Wed, 15 Sep 2021 15:35:52 +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-xf32.google.com with SMTP id di6so1879670qvb.1 for ; Wed, 15 Sep 2021 06:35:52 -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=N8q5dwvApR7PZKgB1IUuHOWA2Tl+5KnBfn9UJzIBiIw=; b=iVEBLuOOwTgZFoBgpab1hzx5zvWd5BWOprQA807JmwwiiO1FbgkZtMUY7X/Z/jBzME uAngUsM9uMzgbVfV4YcSsVsF3w4oUFZgA8R/v2en5k4ecu5pAyIzZRHOHdnyASPhQ5+J zOxesoyCYgtR7kkOdyzpsVyoE5LLSZTKfL1aE= 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=N8q5dwvApR7PZKgB1IUuHOWA2Tl+5KnBfn9UJzIBiIw=; b=luGyxxdvKnl0fz6z1nBrhjmyhmRWVRu2E3FKmqFDT39/aN4Y2iFReqlmODdXv6G8Pn o8dFcyjJw+IxgJeAJl9U8aG7ct+/7EM1f78CaeA74xKkgeO7+0b+wd+2Ai9L7mxIH4Ix cfh9GCJhbCS06AhiGUy5taB9NIKSnIjJ4xcvjJ60ESGNH+J9uE6J+NS2drpQE9LyWKrv rSMvBuvLo79HIQzyuiPYT/E3knMN3FULfBexiUnw1HxMKVkRdB0vMKA42CmuAyGmbJlQ H3CMAhiwSQeC8zfIkeFcWznq6ITjUWw0Y9eIP1pnn+xE4RVBB94vbj+iSRb10MA5bpe7 oJpQ== X-Gm-Message-State: AOAM530xTk0GbnVTVxpfiffXV9tY59h0e0QRzhFiUTVE16ykGCraeFU7 VJA6HkvmaUSwFK2HwebTXniZCg== X-Google-Smtp-Source: ABdhPJxPVvXkWPxEoZASVtSeHK4NcVlGXhOxC2cz5wfpy+9NsezUEQM2EDeToySwF2s/+AZbm/++yg== X-Received: by 2002:a05:6214:1e1:: with SMTP id c1mr10888443qvu.42.1631712950742; Wed, 15 Sep 2021 06:35:50 -0700 (PDT) Received: from bill-the-cat (2603-6081-7b01-cbda-682c-a086-e3f8-65b4.res6.spectrum.com. [2603:6081:7b01:cbda:682c:a086:e3f8:65b4]) by smtp.gmail.com with ESMTPSA id p123sm10248087qke.94.2021.09.15.06.35.49 (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 15 Sep 2021 06:35:49 -0700 (PDT) Date: Wed, 15 Sep 2021 09:35:47 -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: <20210915133547.GV12964@bill-the-cat> References: <561452b36639d218@bloch.sibelius.xs4all.nl> <56145f817ba7aedc@bloch.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FhQ5AB9L6omD9jPF" Content-Disposition: inline In-Reply-To: <56145f817ba7aedc@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 --FhQ5AB9L6omD9jPF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 >=20 > Hi Simon, >=20 > > Hi Mark, > >=20 > > 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 there isn'= t any > > > > dtb or dts for rpi4 (bcm2711-rpi-4-b) in arc/arm/dts in u-boot. I t= ried to > > > > add the dtb and other dts dtsi > > > > files > > > > from the raspberry pi Linux and compile them with CONFIG_OF_SEPARAT= E and > > > > CONFIG_OF_EMBED (one at a time) *but it couldn't even boot the U-Bo= ot and > > > > it would just give a blank screen*. I wonder why there isn't any de= vice > > > > tree in the U-boot repo for RPI4. Is U-boot control FDT not support= ed 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 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 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 the idea > > > of having all U-Boot configuration information in a single device tree > > > with the hardware description doesn't work everywhere. > >=20 > > >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. >=20 > 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. >=20 > 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. >=20 > 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 ;). >=20 > > If UEFI is used, the devicetree would have no effect, since it doesn't > > support devicetree. >=20 > 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. >=20 > > So perhaps the only remaining issue is with qemu on ARM / Risc-V? >=20 > 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 Tom --FhQ5AB9L6omD9jPF Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmFB9q0ACgkQFHw5/5Y0 tyzz4Qv/f9qrMJojrsWXaZVVt5ItnSad6JKNFfsU7WxoL6oH5MdzpeCVElpPU8T2 Gs22aNbrN38YfaLx/HeKmo5RTr58UkXcG7OkfQ6F0Znnq4R63Y4wxidjXZPZVHm9 qptY6Pv7koi6y1dfQyPvEfIMTc0GIOGRAWMbX56YXRvXoR7lFGI1tl9G4gotiLn7 TF85CZgZSuDDhkAofEPSytqOFGhAl50ATWX0ndEAxpbfR25Mg990bPc25lWH3GKt HOjP9o6aoJ8ugcO2oizw5JAstKoUz80ybpSyBICAG8ahXERrYD8o1XiXoIuoqAbC 7PfjdBYYj/TI/BfPbNj9oW3GKzh1WCmK/KzSZ9u5R4OAZTGUdP1ihxYm6wv3XxjP EIJCpr8tAPP8yQ0s3UrdLkOv9EJW5jhsiXoPqThomm+k3iexTAMicvw1T1xsvcqz nyNxMKSprElz5tJ9kpUmSFSOYJ3b0mUNkxxjgcRfIHBRyHkz6zT7r9zYzKVYKdh7 EdpTjKgH =KiUy -----END PGP SIGNATURE----- --FhQ5AB9L6omD9jPF--