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=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 5EE98C433EF for ; Fri, 17 Sep 2021 16:22:12 +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 E126C611C4 for ; Fri, 17 Sep 2021 16:22:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org E126C611C4 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=chromium.org 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 55A9A832BF; Fri, 17 Sep 2021 18:22:05 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org 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=chromium.org header.i=@chromium.org header.b="HkX7q+dY"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 80D4E83202; Fri, 17 Sep 2021 18:21:59 +0200 (CEST) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 2EAD1832F4 for ; Fri, 17 Sep 2021 18:21:52 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=chromium.org Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=sjg@google.com Received: by mail-oi1-x231.google.com with SMTP id w206so3023185oiw.4 for ; Fri, 17 Sep 2021 09:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FuQ0MlLZSsA72quW+WeuDkRkqvwB/LhE6b+70T0tdbQ=; b=HkX7q+dY7La493a3oDcLCMksgYJBGFV2ZOdnk3nOm7F2Y2GtmFlSmGtte+mtGeIYhd zF4MC19HOkY1MwDaqDusRRcB10iGJ/jP6X6Lz0sJgQSww2qcx9mf4IRWZ+MD00KYhnM+ ylqyeiZToiKYf9XCUagDdCMWj1QcisvkxOfO4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FuQ0MlLZSsA72quW+WeuDkRkqvwB/LhE6b+70T0tdbQ=; b=5YDTNNOZF6bIkfKiJKKFekNM8OAco2kvTG+tMER4kvEuwM1ergytGat5rTlXvhIj/g 2FYEmR8hp0AR1z3uDd6+SZhKXcWFwCLMpHydHdYl3unl/3sJsZxWwMWtpmgQYYzLZkeY jU+wKn7qI+ICm7hwSj9FruzfGxa/Z7FQ3yyKjs99RvMxXqpLcroiZ6fjecSeVl031d3s Uix6jolt4Y6HkO6I8gaDLuLdbf0dHe7Ljtl++3/ES5c+u/mQt0uOYfxHZ01qI5aSacNh BejTBXlNwg5CdchnM1PLM6r+JCJ/jX0BEavD581HdWn2WnOl5WYT52h6Odd0ySa87TD9 yCdw== X-Gm-Message-State: AOAM530vSYecmAckuC+xMMECE2g45TEmX1F/dhEomItkAQn/26C1BP3A FNYJwD92qLw3dGn10JUbRFPEB+rc79cQd3aXuZeUYQ== X-Google-Smtp-Source: ABdhPJzOcvu6TZpUzUHm+eOf2VCJp1GvDG42ZfHOxVCY77DuITBoX9MpcNAtXa7bdOolu0hy0nD7Y4KAQAO0d36kBeM= X-Received: by 2002:aca:a984:: with SMTP id s126mr4559000oie.150.1631895709969; Fri, 17 Sep 2021 09:21:49 -0700 (PDT) MIME-Version: 1.0 References: <561452b36639d218@bloch.sibelius.xs4all.nl> In-Reply-To: From: Simon Glass Date: Fri, 17 Sep 2021 10:21:38 -0600 Message-ID: Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting To: =?UTF-8?Q?Fran=C3=A7ois_Ozog?= Cc: Jehannaz Khan , Mark Kettenis , Moiz Imtiaz , Moiz Imtiaz Khan , Tom Rini , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 Hi Fran=C3=A7ois, On Wed, 15 Sept 2021 at 04:26, Fran=C3=A7ois Ozog wrote: > > > > Le mer. 15 sept. 2021 =C3=A0 12:13, Simon Glass a =C3= =A9crit : >> >> Hi Mark, >> >> On Sat, 11 Sept 2021 at 13:18, Mark Kettenis w= rote: >> > >> > > 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, b= ut >> > > 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 tr= ied 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-Boo= t and >> > > it would just give a blank screen*. I wonder why there isn't any dev= ice >> > > tree in the U-boot repo for RPI4. Is U-boot control FDT not supporte= d 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. >> >> 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. >> >> 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. For example, if >> U-Boot evolves to support more devices, they could not be supported. >> If UEFI is used, the devicetree would have no effect, since it doesn't >> support devicetree. > > Please use EDK2 when you refer to it and not by the interface it implemen= ts. And even if we read =E2=80=9CIf EDK2 is used=E2=80=9D this is false as = Socionext has a platform that can select ACPI or DT for its EDK2 implementa= tion. OK I will try to remember to use 'EDK2' to describe a UEFI implementation. Since all the other UEFI implementations are closed-source(?) I suppose it is the only one that is relevant here. Not that EDK2 actually supports very many boards, so far as I can tell from the source tree. I recall people complaining about libfdt being needed in EDK2 (I assume, perhaps it was some other UEFI?) Are you saying that EDK2 can use devicetree for its configuration? If not, thenI think you misunderstood my point. > TF-A has fat less drivers than U-Boot. There is no problem in having a = =E2=80=9Cverified=E2=80=9D platform DT stored in BL33_CONFIG part of a FIP,= verified by TFa and handed over by U-Boot to OS. > That can be the same thing in RPI4 case or FPGA boards. >> OK. I think you are saying that we can use TF-A on rpi and have it provide a suitable devicetree for U-Boot. That's fine. However it happens is fine. It just needs to support the features U-Boot supports, not provide a partial devicetree forcing U-Boot to put its config elsewhere. >> >> >> So perhaps the only remaining issue is with qemu on ARM / Risc-V? Regards, Simon