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.7 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 64FAAC433EF for ; Wed, 15 Sep 2021 11:52: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 A4C1361268 for ; Wed, 15 Sep 2021 11:52:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A4C1361268 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 2117482BD6; Wed, 15 Sep 2021 13:51:59 +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 D83EF82C2B; Wed, 15 Sep 2021 13:51:56 +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 506B982BC4 for ; Wed, 15 Sep 2021 13:51:53 +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 907c8857; Wed, 15 Sep 2021 13:51:51 +0200 (CEST) Date: Wed, 15 Sep 2021 13:51:51 +0200 (CEST) From: Mark Kettenis To: Simon Glass Cc: moizimtiaz1@gmail.com, u-boot@lists.denx.de, trini@konsulko.com, moiz.imtiaz@skyelectric.com, jehannazkhan@skyelectric.com In-Reply-To: (message from Simon Glass on Wed, 15 Sep 2021 04:13:24 -0600) Subject: Re: Problem with U-boot | Configuration Signature not being checked while booting References: <561452b36639d218@bloch.sibelius.xs4all.nl> Message-ID: <56145f817ba7aedc@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 > 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-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. > > >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. > 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 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. > 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 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 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_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?