From patchwork Thu Dec 2 15:58:54 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Simon Glass X-Patchwork-Id: 1562821 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=chromium.org header.i=@chromium.org header.a=rsa-sha256 header.s=google header.b=jjIF9drr; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de (client-ip=85.214.62.61; helo=phobos.denx.de; envelope-from=u-boot-bounces@lists.denx.de; receiver=) Received: from phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4J4gf30QQcz9s1l for ; Fri, 3 Dec 2021 03:00:26 +1100 (AEDT) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 60CCB83633; Thu, 2 Dec 2021 17:00:22 +0100 (CET) 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="jjIF9drr"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id 145FE8350D; Thu, 2 Dec 2021 17:00:14 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: from mail-ot1-x32c.google.com (mail-ot1-x32c.google.com [IPv6:2607:f8b0:4864:20::32c]) (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 10322834CB for ; Thu, 2 Dec 2021 17:00:05 +0100 (CET) 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@chromium.org Received: by mail-ot1-x32c.google.com with SMTP id h19-20020a9d3e53000000b0056547b797b2so237022otg.4 for ; Thu, 02 Dec 2021 08:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=zF2wqKYaFhefeTGlZhhBByFErPS0M7nInxlfMu4Og7E=; b=jjIF9drrv1HZJH4muIyXJnWACxI03m5gNZxcQU+1FWtS4j2+lJfqIS2B7cfkhK3hXH gY+fEyLcgV8tiQkL9BClpZihRVhJOZv3PQiPF5SKyoe6jYG2IAjEFOCzfemThtQHp005 oRUDvLR6qvv3BR/COG0Cipe9XIcR81dTdHUrM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=zF2wqKYaFhefeTGlZhhBByFErPS0M7nInxlfMu4Og7E=; b=nnlYpTTW3k2pwGBAiyG9yNsciAfzO7ud0XQSeSknva3BrbCxc3S6MZv6jETF6wV8Fc rTbqUA615zxaLL57Zm2m9kwqoOOCZrZki77Mmq5odv7QGTU+mNRafTISlNCY5UZ1Soun yX2qcDWj4OB/60JC/2a3uKhHaCe2HpjAAWtZ3ZoO0IK0oYgQMIA9bHjm3FLNfIJjuUuA wIGUM8UsjceRtmbhn0f6MWi6ba+P38d6BUw3mCw4zpxhtyJWxX6gLZ+XI00ckBOxSjq3 O9656A/I0cOUCO54ppYXbJ2JE1EajxiPeoNBH+4S8MifxQ7WhXAD8IUkdQUpGIB/oQsf tUfg== X-Gm-Message-State: AOAM530ZKNiQ4Vc2R/DXeR8C6GldEUuww7+SK/YV4ct8+72fyEMZIr2V etQFeZzaifLMdmB/grxBAPkzqyrJwcTAKw== X-Google-Smtp-Source: ABdhPJz1jLO4zXiBPdaqhaazojRGYMclI9sZwnidBH1KxZ4OzIWK0BRnPNs5FEB6Nof+k599Fkij2Q== X-Received: by 2002:a9d:734d:: with SMTP id l13mr11963700otk.292.1638460803155; Thu, 02 Dec 2021 08:00:03 -0800 (PST) Received: from kiwi.bld.corp.google.com (c-67-190-101-114.hsd1.co.comcast.net. [67.190.101.114]) by smtp.gmail.com with ESMTPSA id r22sm103459oij.36.2021.12.02.08.00.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Dec 2021 08:00:02 -0800 (PST) From: Simon Glass To: U-Boot Mailing List Cc: Mark Kettenis , Sean Anderson , Ilias Apalodimas , Tom Rini , =?utf-8?q?Fran=C3=A7ois_Ozog?= , Heinrich Schuchardt , Simon Glass , Aaron Williams , Albert Aribaud , Alexander Graf , Anastasiia Lukianenko , Andre Przywara , Bin Meng , Jerry Van Baren , Linus Walleij , Matthias Brugger , Michal Simek , Oleksandr Andrushchenko , Peter Maydell , Stephen Warren , Stephen Warren , Thomas Fitzsimmons , Tuomas Tynkkynen Subject: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option Date: Thu, 2 Dec 2021 08:58:54 -0700 Message-Id: <20211202155919.2429190-1-sjg@chromium.org> X-Mailer: git-send-email 2.34.0.rc2.393.gf8c9666880-goog MIME-Version: 1.0 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.38 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 With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage" In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example. So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED. This series makes this change, adding various missing devicetree files (and placeholders) to make the build work. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. The qemu-riscv64_spl problem is fixed. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/ Changes in v6: - Fix description of OF_BOARD so it refers just to the current state - Explain that the 'two devicetrees' refers to two *control* devicetrees - Expand the commit message based on comments - Expand the commit message based on comments Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD Makefile | 3 +- arch/arm/dts/Makefile | 20 +- arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++ arch/arm/dts/bcm7xxx.dts | 15 + arch/arm/dts/highbank.dts | 14 + arch/arm/dts/juno-r2.dts | 1038 +++++++++++++ arch/arm/dts/octeontx.dts | 14 + arch/arm/dts/qemu-arm.dts | 402 +++++ arch/arm/dts/qemu-arm64.dts | 381 +++++ arch/arm/dts/xenguest-arm64.dts | 15 + arch/arm/dts/xilinx-versal-virt.dts | 307 ++++ arch/powerpc/dts/Makefile | 1 + arch/powerpc/dts/qemu-ppce500.dts | 264 ++++ arch/riscv/dts/Makefile | 2 +- arch/riscv/dts/qemu-virt.dts | 8 - arch/riscv/dts/qemu-virt32.dts | 217 +++ arch/riscv/dts/qemu-virt64.dts | 217 +++ configs/bcm7260_defconfig | 1 + configs/bcm7445_defconfig | 1 + configs/highbank_defconfig | 2 +- configs/octeontx2_95xx_defconfig | 1 + configs/octeontx2_96xx_defconfig | 1 + configs/octeontx_81xx_defconfig | 1 + configs/octeontx_83xx_defconfig | 1 + configs/qemu-ppce500_defconfig | 2 + configs/qemu-riscv32_defconfig | 1 + configs/qemu-riscv32_smode_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 4 +- configs/qemu-riscv64_defconfig | 1 + configs/qemu-riscv64_smode_defconfig | 1 + configs/qemu-riscv64_spl_defconfig | 3 +- configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + configs/rpi_4_32b_defconfig | 1 + configs/rpi_4_defconfig | 1 + configs/rpi_arm64_defconfig | 1 + configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 2 +- configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 497 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 30 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 117 +- tools/binman/binman.rst | 20 - 49 files changed, 5538 insertions(+), 124 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst Tested-by: Heinrich Schuchardt Reviewed-by: Ilias Apalodimas