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=-8.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING, SPF_HELO_NONE,SPF_PASS,UNPARSEABLE_RELAY,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 401B2C433EF for ; Sat, 11 Sep 2021 21:30:14 +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 13C91611BF for ; Sat, 11 Sep 2021 21:30:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 13C91611BF Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xs4all.nl 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 6E1A2837E7; Sat, 11 Sep 2021 23:30:09 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Received: by phobos.denx.de (Postfix, from userid 109) id 2A43A837E8; Sat, 11 Sep 2021 23:30:07 +0200 (CEST) Received: from sibelius.xs4all.nl (sibelius.xs4all.nl [83.163.83.176]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id 9AD62837E5 for ; Sat, 11 Sep 2021 23:30:02 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=fail (p=none dis=none) header.from=xs4all.nl Authentication-Results: phobos.denx.de; spf=fail smtp.mailfrom=mark.kettenis@xs4all.nl Received: from localhost (bloch.sibelius.xs4all.nl [local]) by bloch.sibelius.xs4all.nl (OpenSMTPD) with ESMTPA id d28b18a0; Sat, 11 Sep 2021 23:30:00 +0200 (CEST) Date: Sat, 11 Sep 2021 23:30:00 +0200 (CEST) From: Mark Kettenis To: Tom Rini Cc: moizimtiaz1@gmail.com, sjg@chromium.org, u-boot@lists.denx.de, moiz.imtiaz@skyelectric.com, jehannazkhan@skyelectric.com In-Reply-To: <20210911210545.GX12964@bill-the-cat> (message from Tom Rini on Sat, 11 Sep 2021 17:05:45 -0400) Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting References: <561452b36639d218@bloch.sibelius.xs4all.nl> <20210911210545.GX12964@bill-the-cat> Message-ID: <561452f953d600b5@bloch.sibelius.xs4all.nl> 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 > Date: Sat, 11 Sep 2021 17:05:45 -0400 > From: Tom Rini > > On Sat, Sep 11, 2021 at 09:18:46PM +0200, 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 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 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. > > In this case, doesn't the Pi firmware pass along apply overlays and > construct the device tree it's going to pass along, so in this case you > would want to make an "overlay" for the Pi firmware to apply and pass > along to U-Boot, that includes the required information? yes, that might work. The overlay can be specified in the config.txt file. I think truly verified boot is impossible on the Pi though, as u-boot and the overlay file will need to be stored on the uSD card of the Pi. But that applies to the scenario where the public key is stored in the device tree embedded in u-boot itself as well.