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.5 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 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 A907DC432BE for ; Fri, 27 Aug 2021 03:57:41 +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 09B5960F45 for ; Fri, 27 Aug 2021 03:57:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 09B5960F45 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 383A28322F; Fri, 27 Aug 2021 05:57:38 +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="AV7Wd8ka"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id DF00383246; Fri, 27 Aug 2021 05:57:36 +0200 (CEST) Received: from mail-wm1-x32a.google.com (mail-wm1-x32a.google.com [IPv6:2a00:1450:4864:20::32a]) (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 235AC8322E for ; Fri, 27 Aug 2021 05:57:32 +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-wm1-x32a.google.com with SMTP id f9-20020a05600c1549b029025b0f5d8c6cso8229562wmg.4 for ; Thu, 26 Aug 2021 20:57:32 -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; bh=VklwHLS1wPcuCZ0rzrKpI3xrUzngqvDzAV+6K+BPW1I=; b=AV7Wd8kaJ9vrUxTnq0e/VRXpu8ROrTJMNIEWwOGLz0AX0hAgxwqt5j56FzEsszja6L g038h4K7fNqrgamyNEPF78gUWiaNtEMXcDUW2k6Fftn53tci0eSx93ciGfwfC9yFCFbz nPuEFebaSiEvTyKh02gu7tkb74VdlOBledcUI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VklwHLS1wPcuCZ0rzrKpI3xrUzngqvDzAV+6K+BPW1I=; b=r39lJVSHXmbi+VLxnPv03bUoGsZSNQS9zSUlDRLNnTK+h9q3gdaBgifMHaAmS2euQQ J5GoeVFKsrNIdo4J6HfOCnf1S7eYBsggPf0vBmKmXd7m+etUE28jiO2zACmZzT1sek9N I1tl7z32uCRDNvdorM5hlK77M+AALNxf+jVZDWx6t4GH+QZWLmJ4tF8rpp8sHddbtJJ7 OckdszOo+SMCQ/IPYfuB3qcnvu8ybRcusVB70SWJT5adM+tWXcafZkLFSIS1YQ6mnEwy 6YOE+r5Cyz+SZraoOrh/QPYQVDsgH6uRzxF/1+wSLbowJv5ppA/856zW8lVG9ncLl1ci 2P+Q== X-Gm-Message-State: AOAM530MM0y/mKP3WYXnhilz9/peZetalKhQvZL3lKeUcAQRDDtd13tA Dgze5U57SUXhUUoAXZwxJ0STTKaMli8zLoTsEH+wjg== X-Google-Smtp-Source: ABdhPJwm73TofmtmqHU8LZYPlVUjYxKwaoB2TEkOGQSWgt3R2NfILQZd0yB4pJs7wl/0f2eX5Ep+jbYUPvmqh67Ajgo= X-Received: by 2002:a1c:9a0e:: with SMTP id c14mr15021609wme.119.1630036651334; Thu, 26 Aug 2021 20:57:31 -0700 (PDT) MIME-Version: 1.0 References: <344db9d3-38fc-2ef4-beaf-cc3b40f613fa@gmx.de> <56141d633da54721@bloch.sibelius.xs4all.nl> In-Reply-To: <56141d633da54721@bloch.sibelius.xs4all.nl> From: Simon Glass Date: Thu, 26 Aug 2021 21:57:19 -0600 Message-ID: Subject: Re: Usage of device-tree for blobs To: Mark Kettenis Cc: Heinrich Schuchardt , Ilias Apalodimas , U-Boot Mailing List Content-Type: text/plain; charset="UTF-8" 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 Mark, On Thu, 26 Aug 2021 at 14:18, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 26 Aug 2021 13:54:49 -0600 > > > > Hi Heinrich, > > > > > > On Thu, 26 Aug 2021 at 01:10, Heinrich Schuchardt wrote: > > > > > > On 8/26/21 5:15 AM, Simon Glass wrote: > > > > Hi Heinrich, > > > > > > > > On Wed, 25 Aug 2021 at 02:05, Heinrich Schuchardt wrote: > > > >> > > > >> Hello Simon, > > > >> > > > >> some boards like qemu-riscv64_defconfig do not use any device-tree at > > > >> build time. A device-tree is only supplied at runtime by the prior boot > > > >> stage (CONFIG_OF_PRIOR_STAGE=y). > > > >> > > > >> In doc/develop/devicetree/intro.rst you suggest to put binary blobs into > > > >> the device-tree. > > > >> > > > >> Could you, please, update the documentation to explain how adding blobs > > > >> to the device-tree works in the different scenarios depending on the > > > >> values of: > > > >> > > > >> CONFIG_OF_EMBED > > > >> CONFIG_OF_SEPARATE > > > >> CONFIG_OF_BOARD > > > >> CONFIG_OF_HOSTFILE > > > >> CONFIG_OF_PRIOR_STAGE > > > >> > > > >> It would be especially important to understand how one can develop a > > > >> board independent feature which works for all of these settings. > > > > > > > > OK I will take a crack at this tomorrow. > > > > > > > > But I think there is a disconnect here, since the only options that > > > > matter within U-Boot are OF_SEPARATE and OF_HOSTFILE, which both use a > > > > u-boot.dtb file. There is nothing tricky here. > > > > > > The following boards use OF_PRIO_STAGE: > > > > > > * QEMU > > > * bcm7260_defconfig > > > * bcm7445_defconfig > > > * ae350_rv32_defconfig > > > * ae350_rv32_spl_defconfig > > > * ae350_rv64_defconfig > > > * ae350_rv64_spl_defconfig > > > > Most of these seem OK as they have an in-tree DT. But the arm and > > riscv qemus and the bcm builds do not: > > > > bcm7260_defconfig > > bcm7445_defconfig > > configs/qemu_arm64_defconfig > > configs/qemu_arm_defconfig > > configs/qemu-ppce500_defconfig > > configs/qemu-riscv32_defconfig > > configs/qemu-riscv32_smode_defconfig > > configs/qemu-riscv64_defconfig > > configs/qemu-riscv64_smode_defconfig > > > > I think we are going to have to ban this. We are not really testing > > the build at all, and it presumably depends on the version of qemu > > that is used. It's OK to provide the DT to U-Boot as one flow, but not > > to completely drop it from the tree. > > So you want to have a DT in the U-Boot tree that is completely unused? Why would I want it to be unused? It is used by the U-Boot build, at least. Does this all work because the qemu support has been in there for ages and never changes? Otherwise I wonder about version compatibility. > > > Where is the qemu source code that creates these DTs? > > For ARM the code is in: > > https://github.com/qemu/qemu/blob/master/hw/arm/virt.c Gosh that's 3k LOC that I didn't even imagine existed! Thank you for the pointer. I don't see any mention in there about U-Boot. Are you sure that it is passed to U-Boot, or is it just passed to Linux? If U-Boot uses it, someone should make a note of that in the file. > > > > > The OF_BOARD business is for when the board does special things. > > > > Presumably signing will do special things too. We cannot really know > > > > what those things are because the board as 'opted out' of the standard > > > > options. > > > > > > > >> > > > >> Please, describe CONFIG_OF_PRIOR_STAGE in > > > >> doc/develop/devicetree/control.rst. > > > > > > > > So I'm not allowed to delete that option? :-) > > > > > > No. > > > > > > > It seems to me to be > > > > extremely sparse on documentation. We need an explanation of what it > > > > means and what effect it has on the build system, U-Boot and some > > > > discussion of how qemu works. It seems to have been added as part of > > > > an unrelated broadcom commit. The tags were incorrect so I doubt > > > > anyone noticed it. Since then it has apparently proved useful > > > > elsewhere, but no one has added more docs. > > > > > > > > So perhaps you can help me with my doc by explaining how > > > > OF_PRIOR_STAGE works in qmeu, why the DT in U-Boot cannot be used, and > > > > which project actually hosts the DT that qemu provides? Armed with > > > > that information, I might be able to make sense of it all. > > > > > > The DT provided by QEMU is not hosted anywhere. It is generated on the > > > fly by QEMU in dependence of the command line arguments that are used > > > for calling QEMU. The project is hosted at > > > > > > https://github.com/qemu/qemu. > > > > 404 on that. Do you have a link to the code that actually generates the DT? > > > > > > > > On RISC-V the address of the device-tree of the prior bootstage is > > > provided in register t0. > > > > > > On ARM platforms QEMU places the device-tree at 0x40000000. > > > > > > QEMU is not the only platform where the prior boot stage supplies the > > > device-tree which is to be used for booting the operating system. Any > > > platform using TF-A or OpenSBI can be setup in this way. > > > > > > Generally it would be preferable that the prior boot stage provides the > > > device-tree. But unfortunately Linux is not always backwards compatible. > > > > > > Don't expect the device-tree of the prior stage to contain any U-Boot > > > specific quirks. > > > > This is my concern. I think every board in U-Boot needs at least a > > basic DT, even if only a skeleton, so we have places to put things. > > Any packaging at all needs a binman node, for example. U-Boot also has > > its own options for certain things. > > Most of the options are for SPL though, and these platforms don't have > that as there is other firmware that does the low-level bringup. And > these platforms typically don't need packaging. I believe QEMU just > needs the ELF binary, and that's also the case for how we boot the > Apple M1 using m1n1. You mean that you load u-boot (the ELF file) with no DT? > > I suppose we could have a DT for these platforms that doesn't describe > the hardware and just does the config stuff. But then you'll be No, I'd like a basic DT that describes the hardware and has a node for each of the enabled drivres. > juggling two DTs and have to make sure that the real one is passed on > to the kernel booted by U-Boot. But I think your idea of having > everything configured in a single DT is flawed. Perhaps the real issue here is that OF_PRIOR_STAGE is a build-time option. Perhaps it should be a run-time option, selected by the prior stage. If not provided, U-Bot uses its own DT? What is the flaw? Do you want to use overlays? I don't think it is unreasonable for U-Boot to have a DT in its own project. It has a defconfig, an environment and all the drivers. > > > Also, where does the environment come from on these boards? Having the > > env in one tree and the DT in another must make things very > > interesting. > > What environment do you mean? The U-Boot variables are defined in the > config files, not in the DT. The U-Boot environment. Eg. here: https://www.denx.de/wiki/DULG/UBootEnvVariables Regards, Simon