[PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
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-...@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|
[PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Also explain how to merge it to produce a devicetree with the U-Boot features included. Signed-off-by: Simon Glass --- (no changes since v5) Changes in v5: - Merge RISC-V and ARM patches since they are similar doc/board/emulation/qemu-arm.rst | 3 ++ doc/board/emulation/qemu-riscv.rst | 3 ++ doc/develop/devicetree/dt_qemu.rst | 48 ++ doc/develop/devicetree/index.rst | 1 + 4 files changed, 55 insertions(+) create mode 100644 doc/develop/devicetree/dt_qemu.rst diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 8bd7b60cdb4..ff64ec08c3e 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality: Additionally, a number of optional peripherals can be added to the PCI bus. +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. + Building U-Boot --- Set the CROSS_COMPILE environment variable as usual, and run: diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..3409fff8117 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass configuration information to guest software. It implements RISC-V privileged + +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. architecture spec v1.10. Building U-Boot diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst new file mode 100644 index 000..1392a2cae97 --- /dev/null +++ b/doc/develop/devicetree/dt_qemu.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Devicetree in QEMU +== + +For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on the +fly by QEMU. It is intended for use in Linux but can be used by U-Boot also, +so long as any nodes/properties needed by U-Boot are merged in. + +When `CONFIG_OF_BOARD` is enabled + + +Obtaining the QEMU devicetree +- + +Where QEMU generates its own devicetree to pass to U-Boot tou can use +`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`, +e.g.:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb + + +Merging in U-Boot nodes/properties +-- + +Various U-Boot features require nodes and properties in the U-Boot devicetree +and at present QEMU is unaware of these. To use these you must manually merge +in the appropriate pieces. + +One way to do this is with dtc. This command runs dtc on each .dtb file in turn, +to produce a text file. It drops the duplicate header on the qemu one. Then it +joins them up and runs them through dtc to compile the output:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb +cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb + +You can then run qemu with the merged devicetree, e.g.:: + +qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb + +Note that there seems to be a bug in some versions of qemu where the output of +dumpdtb does not quite match what is provided to U-Boot. diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst index b5b33dfea0f..fc2fb41b1bb 100644 --- a/doc/develop/devicetree/index.rst +++ b/doc/develop/devicetree/index.rst @@ -12,3 +12,4 @@ build-time and runtime configuration. intro control dt_update + dt_qemu -- 2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 02/25] arm: qemu: Mention -nographic in the docs
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass --- (no changes since v1) doc/board/emulation/qemu-arm.rst | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 584ef0a7e15..8bd7b60cdb4 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -41,14 +41,15 @@ The minimal QEMU command line to get U-Boot up and running is: - For ARM:: -qemu-system-arm -machine virt -bios u-boot.bin +qemu-system-arm -machine virt -nographic -bios u-boot.bin - For AArch64:: -qemu-system-aarch64 -machine virt -cpu cortex-a57 -bios u-boot.bin +qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 -bios u-boot.bin Note that for some odd reason qemu-system-aarch64 needs to be explicitly -told to use a 64-bit CPU or it will boot in 32-bit mode. +told to use a 64-bit CPU or it will boot in 32-bit mode. The -nographic argument +ensures that output appears on the terminal. Use Ctrl-A X to quit. Additional persistent U-boot environment support can be added as follows: -- 2.34.0.rc2.393.gf8c9666880-goog
Re: [PATCH] drivers: core: lists: fix for loop index type
On Sat, 6 Nov 2021 at 09:11, wrote: > > From: Alexander Preißner > > * fixes the bug in function bind_drivers_pass that for > CONFIG_CC_OPTIMIZE_FOR_SIZE=n and no entries in the driver_info list, > i.e. n_ents == 0, the processor steps into the first loop iteration > despite the loop condition being false. > * the Xilinx Zynq-7000 device would eventually hang due to an attempted > access to an invalid memory address > * the bug is fixed by changing the type of idx from uint to int > > Board: zynq-zybo > Target: ARM > Compiler: arm-none-eabi-gcc 9.2.1 > > Signed-off-by: Alexander Preissner > --- > drivers/core/lists.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/core/lists.c b/drivers/core/lists.c > index 5d4f2ea0e3..d2e9dc5719 100644 > --- a/drivers/core/lists.c > +++ b/drivers/core/lists.c > @@ -58,7 +58,7 @@ static int bind_drivers_pass(struct udevice *parent, bool > pre_reloc_only) > const int n_ents = ll_entry_count(struct driver_info, driver_info); > bool missing_parent = false; > int result = 0; > - uint idx; > + int idx; > > /* > * Do one iteration through the driver_info records. For of-platdata, > -- > 2.25.1 > Acked-by: Simon Glass Tested on sandbox: Tested-by: Simon Glass
Re: [PATCH] mtd: sf: Set SF parameters as env variables
On 10/7/21 8:40 AM, Pratyush Yadav wrote: On 23/09/21 10:00PM, Marek Vasut wrote: On 9/23/21 8:53 PM, Pratyush Yadav wrote: > On 14/09/21 05:28AM, Marek Vasut wrote: > > Set the SF page size, erase block size and total size as an environment > > variable after "sf probe". This lets us discern boards with multiple > > distinct SPI flash options and also e.g. set mtdparts accordingly. > > I don't quite follow the rationale for making these environment > variables. Wouldn't you be better off finding this info out via mtd or > sf command? I need to use that info in a script, that's why these env vars. Ok. Honestly, it doesn't feel quite right to me. I haven't played with U-Boot's shell too much but is there no way to assign variables from command outputs? For example, can we do something like `foo=$(cat a.txt)`? If that is possible, maybe add some new subcommands to "sf" that return this information? There is not. IMO the current solution (exporting to environment variables in an ad-hoc manner) is rather ugly, but fixing it is difficult :) --Sean
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Ilias, On Thu, 2 Dec 2021 at 10:04, Ilias Apalodimas wrote: > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > Hi Simon > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > 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-...@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 > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > not in favor of this new version either. > > > If you make a version without « fake DTs » as you name them, there are > > > good > > > advances in the documentation and other areas that would be better in > > > mainline…. > > > If I am the only one thinking this way and the patch can be accepted, I > > > would love there is a warning in capital letters at the top of the DTS > > > fake > > > files that explains the intent of this fake DT, the possible outcomes of > > > not using the one provided by the platform and the right way of dealing > > > with DTs for the platform. > > > > This is the part that I too am still unhappy about. I do not want > > reference or fake or whatever device trees in the U-Boot source tree. > > We should be able to _remove_ the ones we have, that are not required, > > with doc/board/...rst explaining how to get / view one. Not adding > > more. > > So this is a key point for me and the reason I completely disagree > with this approach. This proposal is working in the *exact* opposite > direction and we'll never be able to get rid of device trees from > U-Boot, even if at some point they move out of the kernel to a > 'common' repo'. I'll just repeat what I've been saying since v1. > Personally I'd be way happier if we could figure out were the specific > U-Boot config nodes are needed and when are they needed. Based on > what we figure out we could, pick up the device tree from a previous > state bootloader and fix it up with our special nodes before we start > using it, using internal DTS files (compiled to .dtbos or similar) > that indeed belong in the u-boot tree. Eh? If the device tree files are actually common then there should be a single source. If U-Boot has a copy then it should be identical. The special node thing makes no sense for U-Boot. We just need to upstream our bindings and I am working on that. Are the device tree files moving out of Linux? Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit > : > > > > > > > > > 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-...@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 > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is > initialized in the pre-relocation phase this means that the device > tree nodes
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > > > From: Ilias Apalodimas > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > with this approach. This proposal is working in the *exact* opposite > > > > direction and we'll never be able to get rid of device trees from > > > > U-Boot, even if at some point they move out of the kernel to a > > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > > Personally I'd be way happier if we could figure out were the specific > > > > U-Boot config nodes are needed and when are they needed. Based on > > > > what we figure out we could, pick up the device tree
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: François Ozog > Date: Thu, 2 Dec 2021 19:32:17 +0100 > > On Thu, 2 Dec 2021 at 19:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > écrit : > > > > > > > > > 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-...@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 > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there > are good > > > > advances in the documentation and other areas that would be better > in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > would love there is a warning in capital letters at the top of the > DTS fake > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > not using the one provided by the platform and the right way of > dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source > tree. > > > We should be able to _remove_ the ones we have, that are not > required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > wrote: > > > > > > > > > From: Ilias Apalodimas > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > Hi Simon > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > écrit : > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > list.so I am > > > > > > > not in favor of this new version either. > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > there are good > > > > > > > advances in the documentation and other areas that would be > > > > > > > better in > > > > > > > mainline…. > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > accepted, I > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > the DTS fake > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > outcomes of > > > > > > > not using the one provided by the platform and the right way of > > > > > > > dealing > > > > > > > with DTs for the platform. > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > tree. > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > required, > > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > > more. > > > > > > > > > > So this is a key point for me and the reason I completely disagree > > > > > with this approach. This proposal is working in the *exact* opposite > > > > > direction and we'll never be able to get rid of device trees from > > > > > U-Boot, even if at some point they move
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:44, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:29, Simon Glass wrote: >> >> Hi François, >> >> On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: >> > >> > Hi Simon >> > >> > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> >> >> Hi Tom, >> >> >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> >> > >> >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> >> > > Hi, Simon! >> >> > > >> >> > > Sorry for being late to the party >> >> > > >> >> > > On 02.12.21 17:59, Simon Glass wrote: >> >> > > > Add an empty file to prevent build errors when building with >> >> > > > CONFIG_OF_SEPARATE enabled. >> >> > > > >> >> > > > The build instructions in U-Boot do not provide enough detail to >> >> > > > build a >> >> > > > useful devicetree, unfortunately. >> >> > > Xen guest doesn't use any built-in device trees as the guest's device >> >> > > tree is provided >> >> > > by the Xen hypervisor itself and is generated at the virtual machine >> >> > > creation time: it is >> >> > > populated with memory size, number of CPUs etc. based on [1]. >> >> > > So, even if we provide some device tree here it must not be used by >> >> > > U-boot at >> >> > > the end of the day. Thus, it might be a reasonable solution to >> >> > > provide an empty device >> >> > > tree as you do, but put a comment that it is not used. >> >> > >> >> > So another example of why this series is taking things in the wrong >> >> > direction. >> >> >> >> Why? >> > >> > I only had that comment in mind: "there is none so deaf as he who will not >> > hear." >> >> Hey, stop the pile-on. It's not useful. >> >> I've guided U-Boot's use of devicetree for 10 years successfully. The >> current state is a mess and I just to straighten it out. >> > I admire your talent and knowledge. > I know you are 99,99% of the time correct and spot on for your comments in > many meetings we were attending. > When you questioned a number of points I made, I first tried to understand > what I got wrong because you said it. > And you were right ;-) > For this topic, I made every effort to come to your position, but > definitively can't. Thank you. I think this will come together in a few years when devicetree is sorted out in U-Boot and Binman is more widely used. For this series, if and when it is applied, I predict: - it will not cause any confusion - it will aid development - it will help with discoverability, pressuring people to explain how to build for their systems - it will be a good basis for future work (we have a long list) - everyone will wonder what the fuss was about Here is the commit that introduced OF_PRIOR_STAGE. It attracted no such push-back. commit 894c3ad27fa940beb7fdc07d01dcfe81c03d0481 Author: Thomas Fitzsimmons Date: Fri Jun 8 17:59:45 2018 -0400 board: arm: Add support for Broadcom BCM7445 Add support for loading U-Boot on the Broadcom 7445 SoC. This port assumes Broadcom's BOLT bootloader is acting as the second stage bootloader, and U-Boot is acting as the third stage bootloader, loaded as an ELF program by BOLT. Signed-off-by: Thomas Fitzsimmons Cc: Stefan Roese Cc: Tom Rini Cc: Florian Fainelli Regards, Simon
Re: [PATCH 12/17] binman: Update the section documentation
Expand this to explain subclassing better and also to tidy up formatting for rST. Fix a few pylint warnings to avoid dropping the score. Signed-off-by: Simon Glass --- tools/binman/entries.rst | 149 +++--- tools/binman/etype/section.py | 148 +++-- 2 files changed, 242 insertions(+), 55 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 09/17] binman: Drop the filename property in entry_Section
This is not used and does nothing. Drop it. Add a tweak to avoid reducing the pylint score. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 14/17] binman: Use normal entries in cbfs
This currently uses _cbfs_entries[] to store entries. Since the entries are in fact valid etypes, we may as well use the same name as entry_Section uses, which is _entries. This allows reusing more of the code there (in a future patch). Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 16 1 file changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 15/17] binman: cbfs: Refactor the init process
Update the constructor to work in the recommended way, where the node properties are read in a separate function. This makes it more similar to entry_Section. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 13/17] binman: Move cbfs.ObtainContents() down a bit
It is easier to understand this file if reading the entries comes before obtaining the contents, since that is the order in which Binman proceeds. Move the function down a bit. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 16/17] binman: cfbs: Refactor ObtainContents() for consistency
Update this to use the same arguments as entry_Section uses. Signed-off-by: Simon Glass --- tools/binman/etype/cbfs.py | 40 ++ 1 file changed, 23 insertions(+), 17 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Ilias Apalodimas > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > > > écrit : > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > there are good > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > accepted, I > > > > > > > > would love there is a warning in capital letters at the top of > > > > > > > > the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > outcomes of > > > > > > > > not using the one provided by the platform and the right way of > > > > > > > > dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > > > reference or fake or whatever device trees in the U-Boot source > > > > > > > tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > > > > > > > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > > > > > > adding > > > > > > >
Re: Please pull u-boot-net/master
On Thu, Dec 02, 2021 at 10:22:52AM +0200, Ramon Fried wrote: > Hi Tom, > The below contains two fixes from Marek for designware and mdio. > > The following changes since commit 4a14bfffd42f968ed9d72a780a8d44a9053c5b95: > > Merge https://source.denx.de/u-boot/custodians/u-boot-marvell > (2021-11-30 08:59:22 -0500) > > are available in the Git repository at: > > https://source.denx.de/u-boot/custodians/u-boot-net.git/ > > for you to fetch changes up to 3fbd17aadf792735846a5f2052b3f68f7075201f: > > net: dwc_eth_qos: Enable clock in probe (2021-12-02 08:35:44 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: Question/issues about i.MX6 DDR configuration
Hi Michael, On Thu, Dec 2, 2021 at 5:36 PM Michael Nazzareno Trimarchi wrote: > The bootrom loads the dcd using some logic and you write the register > in sequence. > You don't respect the ddr initialization or this delay on MMDC > according to 44.4.2. > Is that not necessary? I don't see in 44.4.2 where it mentions the requirement of delay between register writes. The part that Francesco quoted: "A Precharge All command must be issued prior to the MRW command to ensure robust DDR initialization. This command is required to be issued to both chip selects if two chip selects are utilized in the system." Does not apply to mx6sabresd as it only has one chip select. Regards, Fabio Estevam
Re: [PATCH 02/17] dtoc: Add support for reading 64-bit ints
Add functions to read a 64-bit integer property from the devicetree. Signed-off-by: Simon Glass --- tools/dtoc/fdt_util.py | 35 tools/dtoc/test/dtoc_test_simple.dts | 1 + tools/dtoc/test_dtoc.py | 2 ++ tools/dtoc/test_fdt.py | 21 ++--- 4 files changed, 56 insertions(+), 3 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH] drivers: core: lists: fix for loop index type
On Sat, 6 Nov 2021 at 09:11, wrote: > > From: Alexander Preißner > > * fixes the bug in function bind_drivers_pass that for > CONFIG_CC_OPTIMIZE_FOR_SIZE=n and no entries in the driver_info list, > i.e. n_ents == 0, the processor steps into the first loop iteration > despite the loop condition being false. > * the Xilinx Zynq-7000 device would eventually hang due to an attempted > access to an invalid memory address > * the bug is fixed by changing the type of idx from uint to int > > Board: zynq-zybo > Target: ARM > Compiler: arm-none-eabi-gcc 9.2.1 > > Signed-off-by: Alexander Preissner > --- > drivers/core/lists.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > Applied to u-boot-dm/next, thanks!
Re: [PATCH 05/17] binman: Add a way to obtain the version
Add a -V option which shows the version number of binman. For now this just uses a local 'version' file. Once the tool is packaged in some way we can figure out an approach that suits. Signed-off-by: Simon Glass --- tools/binman/cmdline.py | 29 + tools/binman/ftest.py | 20 tools/binman/state.py | 18 ++ 3 files changed, 67 insertions(+) Applied to u-boot-dm/next, thanks!
Re: [PATCH 04/17] binman: Tidy up style in cmdline
Update this file to improve the pylint score a little. The remaining item is: Function name "ParseArgs" doesn't conform to snake_case naming style which needs some binman-wide renaming. Signed-off-by: Simon Glass --- scripts/pylint.base | 2 +- tools/binman/cmdline.py | 45 - 2 files changed, 28 insertions(+), 19 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 1/1] sandbox: replace putchar(ch) by fputc(ch, stdout)
On Sat, 20 Nov 2021 at 05:28, Heinrich Schuchardt wrote: > > When compiled with -Og for better debugability u-boot ends up in a stack > overflow using > > gcc (Ubuntu 11.2.0-7ubuntu2) 11.2.0 > GNU Binutils for Ubuntu 2.37 > > putchar(ch) is defined as a macro which ends up calling U-Boot's putc() > implementation instead of the glibc one, which calls os_putc() ... > > Let's use fputc(ch, stdout) instead as fputc() does not exist in U-Boot. > > Signed-off-by: Heinrich Schuchardt > --- > arch/sandbox/cpu/os.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass Applied to u-boot-dm/next, thanks!
Re: [PATCH 01/17] dtoc: Bring in the libfdt module automatically
Use the same technique as with binman to load this module from the U-Boot tree if available. This allows running tests without having to specify the PYTHONPATH variable. Signed-off-by: Simon Glass --- tools/dtoc/test_fdt.py | 6 ++ 1 file changed, 6 insertions(+) Applied to u-boot-dm/next, thanks!
Re: Question/issues about i.MX6 DDR configuration
Hi Francesco, On Thu, Dec 2, 2021 at 1:14 PM Francesco Dolcini wrote: > > Hello Fabio, Tim and all, > in the last few weeks I have been debugging some sporadic i.MX6 board > boot failures (2020.07 U-Boot, if that matters) and we have some loose > indication that they could be RAM related. The effect is that SPL is not > able to load U-Boot from the eMMC to DDR and dqs|write_level calibration > is failing. > > We do write the memory configuration in a pretty simple way, SPL is just > iterating thought a list of register address/value, in a very similar > way to what was done using the DCD table. Today most of the boards > however use a more programmatic approach as introduced by Tim in 2014 [1]. > > Contrary to that, however, Fabio moved away from this new approach to > just raw registers writing for the sabre board [2][3]. > > I'm a little bit puzzled at the moment, according to the iMX6 reference > manual[4], 44.4.2 MMDC initialization, a specific sequence is required > to be followed and this is implemented by the `mx6_dram_cfg()`[5] > function, but according to what Fabio wrote the raw initialization of > registers was just more reliable for mx6sabresd. Fabio, what was the > reason? The reason is that I wanted to keep the DDR initialization 100% the same in U-Boot mainline versus NXP U-Boot for mx6sabresd board. The mx6_ddr_sysinfo approach is more elegant, for sure. It is just that I wanted to keep 100% in sync with the initialization done by the NXP hardware team. Regards, Fabio Estevam
Re: Question/issues about i.MX6 DDR configuration
Hi Fabio On Thu, Dec 2, 2021 at 9:14 PM Fabio Estevam wrote: > > Hi Francesco, > > On Thu, Dec 2, 2021 at 1:14 PM Francesco Dolcini > wrote: > > > > Hello Fabio, Tim and all, > > in the last few weeks I have been debugging some sporadic i.MX6 board > > boot failures (2020.07 U-Boot, if that matters) and we have some loose > > indication that they could be RAM related. The effect is that SPL is not > > able to load U-Boot from the eMMC to DDR and dqs|write_level calibration > > is failing. > > > > We do write the memory configuration in a pretty simple way, SPL is just > > iterating thought a list of register address/value, in a very similar > > way to what was done using the DCD table. Today most of the boards > > however use a more programmatic approach as introduced by Tim in 2014 [1]. > > > > Contrary to that, however, Fabio moved away from this new approach to > > just raw registers writing for the sabre board [2][3]. > > > > I'm a little bit puzzled at the moment, according to the iMX6 reference > > manual[4], 44.4.2 MMDC initialization, a specific sequence is required > > to be followed and this is implemented by the `mx6_dram_cfg()`[5] > > function, but according to what Fabio wrote the raw initialization of > > registers was just more reliable for mx6sabresd. Fabio, what was the > > reason? > > The reason is that I wanted to keep the DDR initialization 100% the > same in U-Boot > mainline versus NXP U-Boot for mx6sabresd board. > > The mx6_ddr_sysinfo approach is more elegant, for sure. > The bootrom loads the dcd using some logic and you write the register in sequence. You don't respect the ddr initialization or this delay on MMDC according to 44.4.2. Is that not necessary? Michael > It is just that I wanted to keep 100% in sync with the initialization > done by the NXP hardware team. > > Regards, > > Fabio Estevam
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 14:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > > Hi Mark, > > > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > > > Hi Mark, > > > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > > wrote: > > > > > > > > > > > From: Simon Glass > > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > > > Hi Mark, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > > wrote: > > > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name > > > > > > > > > > them, there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the > > > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 15:53, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > > Hi Simon,Tom > > > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > > Hi Tom, > > > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > > wrote: > > > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > a écrit : > > > > > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > list.so I am > > > > > > > > > > not in favor of this new version either. > > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > there are good > > > > > > > > > > advances in the documentation and other areas that would be > > > better in > > > > > > > > > > mainline…. > > > > > > > > > > If I am the only one thinking this way and the patch can be > > > accepted, I > > > > > > > > > > would love there is a warning in capital letters at the top > > > of the DTS fake > > > > > > > > > > files that explains the intent of this fake DT, the possible > > > outcomes of > > > > > > > > > > not using the one provided by the platform and the right way > > > of dealing > > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > want > > > > > > > > > reference or fake or whatever device trees in the U-Boot > > > source tree. > > > > > > > > > We should be able to _remove_ the ones we have, that are not > > >
[PATCH v3] xilinx: Kconfig: add XILINX_OF_BOARD_DTB_ADDR default value for microblaze
The xilinx board_fdt_blob_setup() implementation makes use of XILINX_OF_BOARD_DTB_ADDR, but no default value is currently defined for microblaze. Add one so that microblaze could also work with CONFIG_OF_SEPARATE. Signed-off-by: Ovidiu Panait --- board/xilinx/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/board/xilinx/Kconfig b/board/xilinx/Kconfig index 64507b5d84..1788066173 100644 --- a/board/xilinx/Kconfig +++ b/board/xilinx/Kconfig @@ -43,6 +43,7 @@ endif config XILINX_OF_BOARD_DTB_ADDR hex "Default DTB pickup address" default 0x1000 if ARCH_VERSAL + default 0x8000 if MICROBLAZE default 0x10 if ARCH_ZYNQ || ARCH_ZYNQMP depends on OF_BOARD || OF_SEPARATE help -- 2.25.1
Re: [PATCH 07/17] binman: Correct comments for ReadChildData()
The comment here is incomplete. Fix it. Signed-off-by: Simon Glass --- tools/binman/entry.py | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 03/17] dtoc: Add support for reading fixed-length bytes properties
Add functions to read a sequence of bytes from the devicetree. Signed-off-by: Simon Glass --- scripts/pylint.base| 4 ++-- tools/dtoc/fdt_util.py | 20 tools/dtoc/test_fdt.py | 17 + 3 files changed, 39 insertions(+), 2 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 10/17] binman: Allow overriding BuildSectionData()
This method is currently marked private. However it is useful to be able to subclass it, since much of the entry_Section code can be reused. Rename it. Also document one confusing part of this code, so people can understand how to add a test for this case. Fix up a few pylint warnings to avoid regressing the score. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 16 tools/binman/ftest.py | 2 +- 2 files changed, 13 insertions(+), 5 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 11/17] binman: Allow control of which entries to read
The ObtainContents() and GetEntryContents() methods in this file read every single entry in the section. This is the common case. However when one of the entries has had its data updated (e.g. with 'binman replace') we don't want to read it again from the file. Allow the entry to be skipped, for this purpose. This is currently done in the CBFS implementation, so adding it here will allow that to use more of the entry_Section code. Signed-off-by: Simon Glass --- tools/binman/etype/section.py | 13 +++-- 1 file changed, 7 insertions(+), 6 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 06/17] binman: Correct init of entry in Entry class
This should not have an underscore. Drop it so that derived classes can rely on it being set correctly. Signed-off-by: Simon Glass --- tools/binman/entry.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH 08/17] binman: Drop the underscore in _ReadEntries()
This function can be overridden so should not have an underscore. Drop it. Signed-off-by: Simon Glass --- tools/binman/etype/blob_phase.py | 2 +- tools/binman/etype/cbfs.py | 4 ++-- tools/binman/etype/files.py | 2 +- tools/binman/etype/section.py| 8 4 files changed, 8 insertions(+), 8 deletions(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon,Tom Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > Hi Tom, > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > wrote: > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > a écrit : > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > list.so I am > > > > > > > > not in favor of this new version either. > > > > > > > > If you make a version without « fake DTs » as you name them, > there are good > > > > > > > > advances in the documentation and other areas that would be > better in > > > > > > > > mainline…. > > > > > > > > If I am the only one thinking this way and the patch can be > accepted, I > > > > > > > > would love there is a warning in capital letters at the top > of the DTS fake > > > > > > > > files that explains the intent of this fake DT, the possible > outcomes of > > > > > > > > not using the one provided by the platform and the right way > of dealing > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > want > > > > > > > reference or fake or whatever device trees in the U-Boot > source tree. > > > > > > > We should be able to _remove_ the ones we have, that are not > required, > > > > > > > with doc/board/...rst explaining how to get / view one. Not > adding > > > > > > > more. > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > wish > > > > > > it had not come to this. > > > > > > > > > > > > However we are only talking about 10 boards, three of which > don't even > > > > > > have a devicetree anywhere I can find. > > > > > > > > > > > > I think on balance this is a substantial clean-up. I am happy to > add > > > > > > whatever caveats and documentation people want to clarify what is
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:12:16PM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 11:34, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > > > reference or fake or whatever device trees in the
Re: [PATCH 17/17] binman: Rename testCbfsNoCOntents()
Use a lower-case O as was intended. Signed-off-by: Simon Glass --- tools/binman/ftest.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied to u-boot-dm/next, thanks!
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 12:24:24PM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 12:22, Mark Kettenis wrote: > > > > > From: Simon Glass > > > Date: Thu, 2 Dec 2021 11:53:53 -0700 > > > > > > Hi Mark, > > > > > > On Thu, 2 Dec 2021 at 11:47, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > > > > > > > > > Hi Mark, > > > > > > > > > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis > > > > > wrote: > > > > > > > > > > > > > From: Ilias Apalodimas > > > > > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > > > > > > > > a écrit : > > > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > > > > > > > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > > > > > > > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > > > > > > > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > > > > > > > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > > > > > > > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > > > > > > > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > > > > > > > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > > > > > > > want > > > > > > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:36:59PM +0100, François Ozog wrote: > Hi Simon,Tom > > Le jeu. 2 déc. 2021 à 19:34, Tom Rini a écrit : > > > On Thu, Dec 02, 2021 at 11:17:38AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > > > > Hi Tom, > > > > > > > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > > > > Hi Tom, > > > > > > > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini > > wrote: > > > > > > > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass > > a écrit : > > > > > > > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing > > list.so I am > > > > > > > > > not in favor of this new version either. > > > > > > > > > If you make a version without « fake DTs » as you name them, > > there are good > > > > > > > > > advances in the documentation and other areas that would be > > better in > > > > > > > > > mainline…. > > > > > > > > > If I am the only one thinking this way and the patch can be > > accepted, I > > > > > > > > > would love there is a warning in capital letters at the top > > of the DTS fake > > > > > > > > > files that explains the intent of this fake DT, the possible > > outcomes of > > > > > > > > > not using the one provided by the platform and the right way > > of dealing > > > > > > > > > with DTs for the platform. > > > > > > > > > > > > > > > > This is the part that I too am still unhappy about. I do not > > want > > > > > > > > reference or fake or whatever device trees in the U-Boot > > source tree. > > > > > > > > We should be able to _remove_ the ones we have, that are not > > required, > > > > > > > > with doc/board/...rst explaining how to get / view one. Not > > adding > > > > > > > > more. > > > > > > > > > > > > > > I understand you don't like it and that others don't as well. I > > wish > > > > > > > it had not come to this. > > > > > > > > > > >
[PATCH v6 19/25] fdt: Drop #ifdefs with MULTI_DTB_FIT
Refactor the code to drop the #ifdefs for this feature.
Signed-off-by: Simon Glass
---
(no changes since v1)
dts/Kconfig | 1 -
include/asm-generic/global_data.h | 8
lib/fdtdec.c | 31 +++
3 files changed, 19 insertions(+), 21 deletions(-)
diff --git a/dts/Kconfig b/dts/Kconfig
index 6ebbac2a649..5dcc79d5192 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -177,7 +177,6 @@ endchoice
config MULTI_DTB_FIT_UNCOMPRESS_SZ
hex "Size of memory reserved to uncompress the DTBs"
- depends on (MULTI_DTB_FIT_GZIP || MULTI_DTB_FIT_LZO)
default 0x8000
help
This is the size of this area where the DTBs are uncompressed.
diff --git a/include/asm-generic/global_data.h
b/include/asm-generic/global_data.h
index 16fd305a65c..99daa20c765 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -512,6 +512,14 @@ static_assert(sizeof(struct global_data) == GD_SIZE);
#define gd_acpi_ctx() NULL
#endif
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
+#define gd_multi_dtb_fit() gd->multi_dtb_fit
+#define gd_set_multi_dtb_fit(_dtb) gd->multi_dtb_fit = _dtb
+#else
+#define gd_multi_dtb_fit() NULL
+#define gd_set_multi_dtb_fit(_dtb)
+#endif
+
/**
* enum gd_flags - global data flags
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index e0ce2532f95..4967ab87075 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1146,11 +1146,10 @@ int fdtdec_setup_mem_size_base_lowest(void)
return 0;
}
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
- CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO)
static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
{
+#if CONFIG_IS_ENABLED(MULTI_DTB_FIT_GZIP) ||\
+ CONFIG_IS_ENABLED(MULTI_DTB_FIT_LZO)
size_t sz_out = CONFIG_VAL(MULTI_DTB_FIT_UNCOMPRESS_SZ);
bool gzip = 0, lzo = 0;
ulong sz_in = sz_src;
@@ -1175,11 +1174,11 @@ static int uncompress_blob(const void *src, ulong
sz_src, void **dstp)
return -ENOMEM;
}
} else {
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA)
+# if CONFIG_IS_ENABLED(MULTI_DTB_FIT_USER_DEFINED_AREA)
dst = (void *)CONFIG_VAL(MULTI_DTB_FIT_USER_DEF_ADDR);
-# else
+# else
return -ENOTSUPP;
-# endif
+# endif
}
if (CONFIG_IS_ENABLED(GZIP) && gzip)
@@ -1197,16 +1196,12 @@ static int uncompress_blob(const void *src, ulong
sz_src, void **dstp)
return -EBADMSG;
}
*dstp = dst;
- return 0;
-}
-# else
-static int uncompress_blob(const void *src, ulong sz_src, void **dstp)
-{
+#else
+ *dstp = (void *)src;
*dstp = (void *)src;
+#endif
return 0;
}
-# endif
-#endif
#if defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/*
@@ -1606,7 +1601,6 @@ __weak int fdtdec_board_setup(const void *fdt_blob)
*/
static void setup_multi_dtb_fit(void)
{
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
void *blob;
/*
@@ -1624,10 +1618,9 @@ static void setup_multi_dtb_fit(void)
*/
blob = locate_dtb_in_fit(gd->fdt_blob);
if (blob) {
- gd->multi_dtb_fit = gd->fdt_blob;
+ gd_set_multi_dtb_fit(gd->fdt_blob);
gd->fdt_blob = blob;
}
-#endif /* # MULTI_DTB_FIT */
}
int fdtdec_setup(void)
@@ -1664,7 +1657,6 @@ int fdtdec_setup(void)
return ret;
}
-#if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
int fdtdec_resetup(int *rescan)
{
void *fdt_blob;
@@ -1675,8 +1667,8 @@ int fdtdec_resetup(int *rescan)
* FIT image stillpresent there. Save the time and space
* required to uncompress it again.
*/
- if (gd->multi_dtb_fit) {
- fdt_blob = locate_dtb_in_fit(gd->multi_dtb_fit);
+ if (gd_multi_dtb_fit()) {
+ fdt_blob = locate_dtb_in_fit(gd_multi_dtb_fit());
if (fdt_blob == gd->fdt_blob) {
/*
@@ -1700,7 +1692,6 @@ int fdtdec_resetup(int *rescan)
*rescan = 0;
return 0;
}
-#endif
int fdtdec_decode_ram_size(const void *blob, const char *area, int board_id,
phys_addr_t *basep, phys_size_t *sizep,
--
2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 20/25] fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup()
Move this to the header file to clean up the C code.
Signed-off-by: Simon Glass
---
(no changes since v1)
include/fdtdec.h | 14 ++
lib/fdtdec.c | 6 +-
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 6c7ab887b20..68786111a44 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -111,6 +111,20 @@ struct fdt_pci_addr {
extern u8 __dtb_dt_begin[];/* embedded device tree blob */
extern u8 __dtb_dt_spl_begin[];/* embedded device tree blob for
SPL/TPL */
+/* Get a pointer to the embedded devicetree, if there is one, else NULL */
+static inline u8 *dtb_dt_embedded(void)
+{
+#ifdef CONFIG_OF_EMBED
+# ifdef CONFIG_SPL_BUILD
+ return __dtb_dt_spl_begin;
+# else
+ return __dtb_dt_begin;
+# endif
+#else
+ return NULL;
+#endif
+}
+
/**
* Compute the size of a resource.
*
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 4967ab87075..fbdc92c0813 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1629,11 +1629,7 @@ int fdtdec_setup(void)
#if CONFIG_IS_ENABLED(OF_CONTROL)
# ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
-# ifdef CONFIG_SPL_BUILD
- gd->fdt_blob = __dtb_dt_spl_begin;
-# else
- gd->fdt_blob = __dtb_dt_begin;
-# endif
+ gd->fdt_blob = dtb_dt_embedded();
# elif defined(CONFIG_OF_BOARD) || defined(CONFIG_OF_SEPARATE)
/* Allow the board to override the fdt address. */
gd->fdt_blob = board_fdt_blob_setup();
--
2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 25/25] fdt: Don't call board_fdt_blob_setup() without OF_BOARD
At present this override function is called even when OF_BOARD Is not
enabled. This makes it impossible to disable this feature and in fact
makes the OF_BOARD option useless.
Reinstate its intended purpose, so that it is possible to switch between
the appended devicetree and one provided by the board's custom function.
Signed-off-by: Simon Glass
---
(no changes since v5)
Changes in v5:
- Add new patches to clean up fdtdec_setup() and surrounds
include/fdtdec.h | 7 +--
lib/fdtdec.c | 21 -
2 files changed, 17 insertions(+), 11 deletions(-)
diff --git a/include/fdtdec.h b/include/fdtdec.h
index 68786111a44..68a36f10583 100644
--- a/include/fdtdec.h
+++ b/include/fdtdec.h
@@ -1170,10 +1170,13 @@ int fdtdec_resetup(int *rescan);
/**
* Board-specific FDT initialization. Returns the address to a device tree
blob.
- * Called when CONFIG_OF_BOARD is defined, or if CONFIG_OF_SEPARATE is defined
- * and the board implements it.
+ *
+ * Called when CONFIG_OF_BOARD is defined.
+ *
+ * The existing devicetree is available at gd->fdt_blob
*
* @err internal error code if we fail to setup a DTB
+ * @returns new devicetree blob pointer
*/
void *board_fdt_blob_setup(int *err);
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index a7f62123a94..31a509bc221 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1203,15 +1203,15 @@ static int uncompress_blob(const void *src, ulong
sz_src, void **dstp)
return 0;
}
-/*
- * For CONFIG_OF_SEPARATE, the board may optionally implement this to
- * provide and/or fixup the fdt.
+/**
+ * fdt_find_separate() - Find a devicetree at the end of the image
+ *
+ * @return pointer to FDT blob
*/
-__weak void *board_fdt_blob_setup(int *err)
+static void *fdt_find_separate(void)
{
void *fdt_blob = NULL;
- *err = 0;
#ifdef CONFIG_SPL_BUILD
/* FDT is at end of BSS unless it is in a different memory region */
if (IS_ENABLED(CONFIG_SPL_SEPARATE_BSS))
@@ -1626,13 +1626,16 @@ int fdtdec_setup(void)
int ret;
/* The devicetree is typically appended to U-Boot */
- if (IS_ENABLED(CONFIG_OF_SEPARATE) || IS_ENABLED(CONFIG_OF_BOARD)) {
- /* Allow the board to override the fdt address. */
+ if (IS_ENABLED(CONFIG_OF_SEPARATE))
+ gd->fdt_blob = fdt_find_separate();
+ else /* embed dtb in ELF file for testing / development */
+ gd->fdt_blob = dtb_dt_embedded();
+
+ /* Allow the board to override the fdt address. */
+ if (IS_ENABLED(CONFIG_OF_BOARD)) {
gd->fdt_blob = board_fdt_blob_setup();
if (ret)
return ret;
- } else { /* embed dtb in ELF file for testing / development */
- gd->fdt_blob = dtb_dt_embedded();
}
if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
--
2.34.0.rc2.393.gf8c9666880-goog
Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
On 12/2/21 16:58, Simon Glass wrote: QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Also explain how to merge it to produce a devicetree with the U-Boot features included. Information like the number of CPUs and the memory must be accurate in the devicetree and match the call parameter of QEMU. This worked without this series and must work afterwards. How do you achieve this? Best regards Heinrich Signed-off-by: Simon Glass --- (no changes since v5) Changes in v5: - Merge RISC-V and ARM patches since they are similar doc/board/emulation/qemu-arm.rst | 3 ++ doc/board/emulation/qemu-riscv.rst | 3 ++ doc/develop/devicetree/dt_qemu.rst | 48 ++ doc/develop/devicetree/index.rst | 1 + 4 files changed, 55 insertions(+) create mode 100644 doc/develop/devicetree/dt_qemu.rst diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 8bd7b60cdb4..ff64ec08c3e 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality: Additionally, a number of optional peripherals can be added to the PCI bus. +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. + Building U-Boot --- Set the CROSS_COMPILE environment variable as usual, and run: diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..3409fff8117 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass configuration information to guest software. It implements RISC-V privileged + +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. architecture spec v1.10. Building U-Boot diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst new file mode 100644 index 000..1392a2cae97 --- /dev/null +++ b/doc/develop/devicetree/dt_qemu.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Devicetree in QEMU +== + +For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on the +fly by QEMU. It is intended for use in Linux but can be used by U-Boot also, +so long as any nodes/properties needed by U-Boot are merged in. + +When `CONFIG_OF_BOARD` is enabled + + +Obtaining the QEMU devicetree +- + +Where QEMU generates its own devicetree to pass to U-Boot tou can use +`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`, +e.g.:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb + + +Merging in U-Boot nodes/properties +-- + +Various U-Boot features require nodes and properties in the U-Boot devicetree +and at present QEMU is unaware of these. To use these you must manually merge +in the appropriate pieces. + +One way to do this is with dtc. This command runs dtc on each .dtb file in turn, +to produce a text file. It drops the duplicate header on the qemu one. Then it +joins them up and runs them through dtc to compile the output:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb +cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb + +You can then run qemu with the merged devicetree, e.g.:: + +qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb + +Note that there seems to be a bug in some versions of qemu where the output of +dumpdtb does not quite match what is provided to U-Boot. diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst index b5b33dfea0f..fc2fb41b1bb 100644 --- a/doc/develop/devicetree/index.rst +++ b/doc/develop/devicetree/index.rst @@ -12,3 +12,4 @@ build-time and runtime configuration. intro control dt_update + dt_qemu
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 16:40, Simon Glass wrote: > The word 'fake' applies to only three of the boards (highbank, bcm7xxx > and octeontx), where I could not even figure out where to get a > devicetree. One might think this would be a significant problem! Isn't highbank https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts ? -- PMM
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Mark, On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > From: Ilias Apalodimas > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > 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-...@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 > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > So this is a key point for me and the reason I completely disagree > > with this approach. This proposal is working in the *exact* opposite > > direction and we'll never be able to get rid of device trees from > > U-Boot, even if at some point they move out of the kernel to a > > 'common' repo'. I'll just repeat what I've been saying since v1. > > Personally I'd be way happier if we could figure out were the specific > > U-Boot config nodes are needed and when are they needed. Based on > > what we figure out we could, pick up the device tree from a previous > > state bootloader and fix it up with our special nodes before we start > > using it, using internal DTS files (compiled to .dtbos or similar) > > that indeed belong in the u-boot tree. > > I don't think it makes sense to put stuff in the DT that is specific > for U-Boot only to pull it out moments later. Maybe it does make some > sense to do this to pass information between TPL/SPL and U-Boot > proper. But otherwise you can just use global variables... > > Now I just ran into an issue on Apple M1 that may have some relevance > here. I'm adding support for power domains and the serial port > requires certain power domains to be on. Since the serial port is >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
> From: Simon Glass > Date: Thu, 2 Dec 2021 11:21:22 -0700 > > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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-...@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 > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > >
[PATCH 08/15] rtc: pcf2127: remove U-Boot specific compatible string
Now that all in-tree boards have been converted to the compatible
strings from Linux, delete the support for the ad-hoc "pcf2127-rtc" one.
Cc: Simon Glass
Signed-off-by: Vladimir Oltean
---
drivers/rtc/pcf2127.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index 291ef0329a3e..2f3fafb4968f 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -120,7 +120,6 @@ static const struct rtc_ops pcf2127_rtc_ops = {
};
static const struct udevice_id pcf2127_rtc_ids[] = {
- { .compatible = "pcf2127-rtc" },
{ .compatible = "nxp,pcf2127" },
{ .compatible = "nxp,pcf2129" },
{ .compatible = "nxp,pca2129" },
--
2.25.1
[PATCH 15/15] arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports
As explained in the previous patch "arm: dts: ls1028a-rdb: sync Ethernet
device tree nodes with Linux", the commit below broke traffic through
switch ports where the SERDES protocol requires in-band autoneg: SGMII,
QSGMII, USXGMII (with 2500Base-X, in-band autoneg isn't supported).
The LS1028A-QDS boards are not yet ready for syncing their device trees
with Linux, since Ethernet is missing there (but has been submitted):
https://lore.kernel.org/lkml/2022223457.10599-11-leoyang...@nxp.com/
When agreement is reached for the Ethernet support in Linux, there will
be a sync for these boards as well. For now, just enable in-band autoneg
to fix the breakage.
Fixes: e3789a726269 ("net: dsa: felix: configure the in-band autoneg property
based on OF node info")
Cc: Ramon Fried
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 1 +
arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 1 +
arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4
arch/arm/dts/fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4
6 files changed, 18 insertions(+)
diff --git a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
index f4c557e69e6e..f208a02721e3 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi
@@ -15,6 +15,7 @@
_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@02}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
index 7d197c31814a..0a0926473541 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi
@@ -14,6 +14,7 @@
_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
index 992092ec7838..94b5e765aedb 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801-LBRW.dtsi
@@ -44,24 +44,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@1c}>;
};
_felix_port2 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1e}>;
};
_felix_port3 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
index a905d77a9a71..bd46adfd2928 100644
--- a/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds--sch-24801.dtsi
@@ -29,24 +29,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1c}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1d}>;
};
_felix_port2 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1e}>;
};
_felix_port3 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "sgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@40/phy@1f}>;
};
diff --git a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
index 62e818f099ca..5909e7635a1a 100644
--- a/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi
@@ -29,24 +29,28 @@
_felix_port0 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@00}>;
};
_felix_port1 {
status = "okay";
+ managed = "in-band-status";
phy-mode = "usxgmii";
phy-handle = <&{/soc/i2c@200/fpga@66/mux-mdio@54/mdio@50/phy@01}>;
};
_felix_port2 {
[PATCH 11/15] arm: dts: ls1028a-rdb: disable DSPI nodes
There is no SPI peripheral on the LS1028A-RDB, therefore no reason to
enable these nodes in the U-Boot device tree (and Linux does not enable
them either).
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb.dts | 12
1 file changed, 12 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 7c2a865de168..5a3f404d0040 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -24,18 +24,6 @@
};
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
{
status = "okay";
};
--
2.25.1
[PATCH 14/15] arm: dts: ls1028a-rdb: sync device tree with Linux
Allow device trees to be reused between Linux and U-Boot.
The source for these device trees is today's linux-next plus these
changes that have been made so that the sources can be shared. These
other patches are currently in flight:
https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb.dts | 160 ---
1 file changed, 147 insertions(+), 13 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 9b69c2848331..09c38ecaf95c 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -1,20 +1,28 @@
-// SPDX-License-Identifier: GPL-2.0+ OR X11
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
/*
- * NXP ls1028ARDB device tree source
+ * Device Tree file for NXP LS1028A RDB Board.
*
- * Copyright 2019 NXP
+ * Copyright 2018-2021 NXP
+ *
+ * Harninder Rai
*
*/
/dts-v1/;
-
#include "fsl-ls1028a.dtsi"
#include "fsl-ls1028a-rdb-u-boot.dtsi"
/ {
- model = "NXP Layerscape 1028a RDB Board";
+ model = "LS1028A RDB Board";
compatible = "fsl,ls1028a-rdb", "fsl,ls1028a";
+
aliases {
+ crypto =
+ serial0 =
+ serial1 =
+ mmc0 =
+ mmc1 =
+ rtc1 = _alarm0;
spi0 =
ethernet0 = _port0;
ethernet1 = _port2;
@@ -23,6 +31,83 @@
ethernet4 = _felix_port2;
ethernet5 = _felix_port3;
};
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x0 0x8000 0x1 0x000>;
+ };
+
+ sys_mclk: clock-mclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <2500>;
+ };
+
+ reg_1p8v: regulator-1p8v {
+ compatible = "regulator-fixed";
+ regulator-name = "1P8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-always-on;
+ };
+
+ sb_3v3: regulator-sb3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3_vbus";
+ regulator-min-microvolt = <330>;
+ regulator-max-microvolt = <330>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Speaker", "Speaker Ext",
+ "Line", "Line In Jack";
+ simple-audio-card,routing =
+ "MIC_IN", "Microphone Jack",
+ "Microphone Jack", "Mic Bias",
+ "LINE_IN", "Line In Jack",
+ "Headphone Jack", "HP_OUT",
+ "Speaker Ext", "LINE_OUT";
+
+ simple-audio-card,cpu {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <>;
+ frame-master;
+ bitclock-master;
+ system-clock-frequency = <2500>;
+ };
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
+};
+
+ {
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <500>;
+ };
};
{
@@ -68,45 +153,85 @@
};
{
+ sd-uhs-sdr104;
+ sd-uhs-sdr50;
+ sd-uhs-sdr25;
+ sd-uhs-sdr12;
status = "okay";
};
{
- status = "okay";
mmc-hs200-1_8v;
+ mmc-hs400-1_8v;
+ bus-width = <8>;
+ status = "okay";
};
{
status = "okay";
mt35xu02g0: flash@0 {
+ compatible = "jedec,spi-nor";
#address-cells = <1>;
#size-cells = <1>;
- compatible = "jedec,spi-nor";
spi-max-frequency = <5000>;
+ /* The following setting enables 1-1-8 (CMD-ADDR-DATA) mode */
+ spi-rx-bus-width = <8>; /* 8 SPI Rx lines */
+ spi-tx-bus-width = <1>; /* 1 SPI Tx line */
reg = <0>;
- spi-rx-bus-width = <8>;
- spi-tx-bus-width = <1>;
};
};
{
status = "okay";
-i2c-mux@77 {
-
- compatible = "nxp,pca9547";
+ i2c-mux@77 {
+
[PATCH 12/15] arm: dts: ls1028a-rdb: disable I2C buses 1 through 7
There is no I2C peripheral on these buses on the reference design board,
and the Linux device tree does not enable them either.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb.dts | 28
1 file changed, 28 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 5a3f404d0040..c346ad9b881c 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -112,34 +112,6 @@
};
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
_felix {
status = "okay";
};
--
2.25.1
[PATCH 13/15] arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi
Reuse the scheme implemented by the Kontron SL28 boards in commit
d08011d7f9b4 ("arm: dts: ls1028a: disable the PCIe controller by
default") and move the 'status = "okay"' lines for the PCIe controllers
inside a separate U-Boot dtsi for the LS1028A-RDB board. This way, the
existing Linux device tree can simply be dropped in.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi | 14 ++
arch/arm/dts/fsl-ls1028a-rdb.dts | 9 +
2 files changed, 15 insertions(+), 8 deletions(-)
create mode 100644 arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
diff --git a/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
b/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
new file mode 100644
index ..34aa87f1ab93
--- /dev/null
+++ b/arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+
+/*
+ * u-boot will enable the device in the linux device tree in place. Because
+ * we are using the linux device tree, we have to enable the PCI controller
+ * ourselves.
+ */
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index c346ad9b881c..9b69c2848331 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -9,6 +9,7 @@
/dts-v1/;
#include "fsl-ls1028a.dtsi"
+#include "fsl-ls1028a-rdb-u-boot.dtsi"
/ {
model = "NXP Layerscape 1028a RDB Board";
@@ -153,14 +154,6 @@
status = "okay";
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
{
status = "okay";
};
--
2.25.1
Re: [PATCH] pci: When disabling pref MEM set all base bits
On 12/2/21 00:12, Pali Rohár wrote:
On Tuesday 30 November 2021 07:10:37 Stefan Roese wrote:
On 11/25/21 11:34, Pali Rohár wrote:
It is common to set all base address bits to one and all limit address bits
to zero for disabling address forwarding. Forwarding is disabled when base
address is higher than limit address, so this change should not have any
effect.
Signed-off-by: Pali Rohár
---
drivers/pci/pci_auto.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pci/pci_auto.c b/drivers/pci/pci_auto.c
index 6e5ed194f247..c0acf331398d 100644
--- a/drivers/pci/pci_auto.c
+++ b/drivers/pci/pci_auto.c
@@ -243,7 +243,7 @@ void dm_pciauto_prescan_setup_bridge(struct udevice *dev,
int sub_bus)
cmdstat |= PCI_COMMAND_MEMORY;
} else {
/* We don't support prefetchable memory for now, so disable */
- dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0x1000 |
+ dm_pci_write_config16(dev, PCI_PREF_MEMORY_BASE, 0xfff0 |
prefechable_64);
Again, does it make sense to add / use a macro for this 0xfff0 above?
This is again setting all range bits in this register to ones. So
(~0 & PCI_PREF_RANGE_MASK) or (0x & PCI_PREF_RANGE_MASK).
Again, no real issue IMHO - was just checking. Perhaps someone else has
more thoughts on this.
Thanks,
Stefan
Other than this:
Reviewed-by: Stefan Roese
Thanks,
Stefan
dm_pci_write_config16(dev, PCI_PREF_MEMORY_LIMIT, 0x0 |
prefechable_64);
And then 0x0 here can be expressed similarly via that macro by:
(0x0 & PCI_PREF_RANGE_MASK)
It is verbose, but would follow style if want to use macros for values.
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Viele Grüße,
Stefan Roese
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH v6 01/25] doc: Add documentation about devicetree usage
At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass Reviewed-by: Marcel Ziswiler --- This patch attracted quite a bit of discussion here: https://patchwork.ozlabs.org/project/uboot/patch/20210909201033.755713-4-...@chromium.org/ I have not included the text suggested by François. While I agree that it would be useful to have an introduction in this space, I do not agree that we should have two devicetrees or that U-Boot should not have its own things in the devicetree, so it is not clear to me what we should actually write. The 'Devicetree Control in U-Boot' docs were recently merged and these provide some base info, for now. 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 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 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?' doc/develop/devicetree/dt_update.rst | 555 +++ doc/develop/devicetree/index.rst | 1 + 2 files changed, 556 insertions(+) create mode 100644 doc/develop/devicetree/dt_update.rst diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst new file mode 100644 index 000..a1429d6e21a --- /dev/null +++ b/doc/develop/devicetree/dt_update.rst @@ -0,0 +1,555 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +=== + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. This is called the 'control' +devicetree since it controls U-Boot. It is possible to update the control +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (October 2021) +~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous +amount of confusion and some wasted effort. This was not intended. Support for +an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. + +Some of the problems created are: + +- It is not obvious that the devicetree is coming from another project + +- There is no way to see even a sample devicetree for these platform in U-Boot, + so it is hard to know what is going on, e.g. which devices are typically + present + +- The other project may not provide a way to support U-Boot's requirements for + devicetree, such as the /config node. Note: On the U-Boot mailing linst, this + was only discovered after weeks of discussion and confusion + +- For QEMU specifically, consulting two QEMU source files is required, for which + there are no references in U-Boot documentation. The code is generating a + devicetree,
[PATCH v6 06/25] riscv: qemu: Add devicetree files for qemu_riscv32/64
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass
---
(no changes since v1)
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/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
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
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@1010 {
+ dma-coherent;
+ reg = <0x00 0x1010 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@2000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x2000 0x00 0x200
+ 0x00 0x2200 0x00 0x200>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@1000";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x00 0x8000 0x00 0x800>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@1000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x1000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x>;
+ offset = <0x00>;
+ regmap = <0x04>;
+
[PATCH v6 04/25] arm: qemu: Add a devicetree file for qemu_arm
Add this file, generated from QEMU, so there is a reference devicetree
in the U-Boot tree. So long as OF_BOARD is enabled, it is overridden at
runtime by the QEMU version. However, with this change it becomes
possible to run with the U-Boot devicetree, if desired, including any
local modifications, for development and testing/CI purposes.
The exact source of the devicetree is shown at boot (with a later patch)
to avoid any confusion as to what is going on.
This allows a binman node to be added to the devicetree, so that a
firmware image can be built.
This was generated from QEMU emulator version 6.1.50
Note that this dtb is only guaranteed to work if the same QEMU version
is used, with vanilla command arguments, as documented in
doc/board/emulation/qemu-arm.rts
However in practice this devicetree is suitable for basic use at least
from QEMU 2.5 and devicetree is a stable, backwards-compatible API.
Signed-off-by: Simon Glass
---
Changes in v6:
- Expand the commit message based on comments
arch/arm/dts/Makefile | 2 +
arch/arm/dts/qemu-arm.dts | 402 +
configs/qemu_arm_defconfig | 1 +
3 files changed, 405 insertions(+)
create mode 100644 arch/arm/dts/qemu-arm.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 7f622fedbda..eaad3b679cc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1162,6 +1162,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) +=
imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts
new file mode 100644
index 000..fed558ced98
--- /dev/null
+++ b/arch/arm/dts/qemu-arm.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0x8405>;
+ cpu_on = <0x8403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0x8401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+
[PATCH v6 05/25] arm: qemu: Add a devicetree file for qemu_arm64
Add this file, generated from QEMU, so there is a reference devicetree
in the U-Boot tree. So long as OF_BOARD is enabled, it is overridden at
runtime by the QEMU version. However, with this change it becomes
possible to run with the U-Boot devicetree, if desired, including any
local modifications, for development and testing/CI purposes.
The exact source of the devicetree is shown at boot (with a later patch)
to avoid any confusion as to what is going on.
This allows a binman node to be added to the devicetree, so that a
firmware image can be built.
This was generated from QEMU emulator version 6.1.50
Note that this dtb is only guaranteed to work if the same QEMU version
is used, with vanilla command arguments, as documented in
doc/board/emulation/qemu-arm.rts
However in practice this devicetree is suitable for basic use at least
from QEMU 2.5 and devicetree is a stable, backwards-compatible API.
Signed-off-by: Simon Glass
---
Changes in v6:
- Expand the commit message based on comments
arch/arm/dts/Makefile| 2 +-
arch/arm/dts/qemu-arm64.dts | 381 +++
configs/qemu_arm64_defconfig | 1 +
3 files changed, 383 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/qemu-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index eaad3b679cc..2d92b2f940d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1162,7 +1162,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) +=
imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
-dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
new file mode 100644
index 000..7590e49cc84
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm64
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0xc405>;
+ cpu_on = <0xc403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0xc401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Simon Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > 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-...@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 You haven’t addressed any concerns expressed on the mailing list.so I am not in favor of this new version either. If you make a version without « fake DTs » as you name them, there are good advances in the documentation and other areas that would be better in mainline…. If I am the only one thinking this way and the patch can be accepted, I would love there is a warning in capital letters at the top of the DTS fake files that explains the intent of this fake DT, the possible outcomes of not using the one provided by the platform and the right way of dealing with DTs for the platform. > > 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:
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi, Simon!
Sorry for being late to the party
On 02.12.21 17:59, Simon Glass wrote:
> Add an empty file to prevent build errors when building with
> CONFIG_OF_SEPARATE enabled.
>
> The build instructions in U-Boot do not provide enough detail to build a
> useful devicetree, unfortunately.
Xen guest doesn't use any built-in device trees as the guest's device tree is
provided
by the Xen hypervisor itself and is generated at the virtual machine creation
time: it is
populated with memory size, number of CPUs etc. based on [1].
So, even if we provide some device tree here it must not be used by U-boot at
the end of the day. Thus, it might be a reasonable solution to provide an empty
device
tree as you do, but put a comment that it is not used.
Thank you,
Oleksandr
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile| 2 ++
> arch/arm/dts/xenguest-arm64.dts | 15 +++
> configs/xenguest_arm64_defconfig | 2 +-
> 3 files changed, 18 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index d53bae2c350..f6345988c8c 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
> mt8516-pumpkin.dtb \
> mt8518-ap1-emmc.dtb
>
> +dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
> new file mode 100644
> index 000..52d3b062248
> --- /dev/null
> +++ b/arch/arm/dts/xenguest-arm64.dts
> @@ -0,0 +1,15 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for xenguest_arm64
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * Build instructions at xenguest_arm64.rst are inadequate for obtaining a
> real
> + * devicetree.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/xenguest_arm64_defconfig
> b/configs/xenguest_arm64_defconfig
> index 8d9d9133a2e..edce34346d3 100644
> --- a/configs/xenguest_arm64_defconfig
> +++ b/configs/xenguest_arm64_defconfig
> @@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
> CONFIG_TARGET_XENGUEST_ARM64=y
> CONFIG_SYS_TEXT_BASE=0x4008
> CONFIG_SYS_MALLOC_LEN=0x200
> -CONFIG_SYS_MALLOC_F_LEN=0x2000
> +CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
> CONFIG_IDENT_STRING=" xenguest"
> CONFIG_SYS_LOAD_ADDR=0x4000
> CONFIG_BOOTDELAY=10
[1] https://xenbits.xen.org/docs/unstable/man/xl.cfg.5.html
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. So another example of why this series is taking things in the wrong direction. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > Hi Tom, > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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-...@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 > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > I understand you don't like it and that others don't as well. I wish > > > it had not come to this. > > > > > > However we are only talking about 10 boards, three of which don't even > > > have a devicetree anywhere I can find. > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > whatever caveats and documentation people want to clarify what is > > > going on here. I'm happy to look at future options where the > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > within U-Boot for development purposes. > > > > > > I'll also note that the bootstd series shows the devicetree source: > > > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > > > But for now, I still feel this is the best path forward. > > > > I'm not sure how to proceed here. The reviews are rather strongly > > against the "include a device tree that won't be used". The use case of > >
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
On Thu, Dec 02, 2021 at 11:05:16AM -0700, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > > > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > > > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > > > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide an > > > empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. I agree with everything except "a basic DT in the tree". It's not used. If you're going to do something with it, the instructions on where the DT comes from will get you there. If the instructions are something like "Well, it's actually horribly complex and depends on what you're doing Xen on and ...", then that's even more of an argument for not having "a basic DT" that will be misleading as well. -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Simon On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: > Hi Tom, > > On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: > > > > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: > > > Hi, Simon! > > > > > > Sorry for being late to the party > > > > > > On 02.12.21 17:59, Simon Glass wrote: > > > > Add an empty file to prevent build errors when building with > > > > CONFIG_OF_SEPARATE enabled. > > > > > > > > The build instructions in U-Boot do not provide enough detail to > build a > > > > useful devicetree, unfortunately. > > > Xen guest doesn't use any built-in device trees as the guest's device > tree is provided > > > by the Xen hypervisor itself and is generated at the virtual machine > creation time: it is > > > populated with memory size, number of CPUs etc. based on [1]. > > > So, even if we provide some device tree here it must not be used by > U-boot at > > > the end of the day. Thus, it might be a reasonable solution to provide > an empty device > > > tree as you do, but put a comment that it is not used. > > > > So another example of why this series is taking things in the wrong > > direction. > > Why? I only had that comment in mind: "there is none so deaf as he who will not hear." > At least we might figure out where to get the DT and how to run > Xen with U-Boot. I don't see any down-side to having a basic DT in the > tree along with instructions on how to run Xen. > If an EMPTY device is what is required to pass current build constraints, so be it, and let's correct that in a later patch. And EMPTY is not basic. > Regards, > Simon > -- François-Frédéric Ozog | *Director Business Development* T: +33.67221.6485 francois.o...@linaro.org | Skype: ffozog
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Hi Mark, On Thu, 2 Dec 2021 at 10:34, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Thu, 2 Dec 2021 08:59:01 -0700 > > > > Add this file, obtained from the Raspbian boot disk, so there is a > > reference devicetree in the U-Boot tree. The same one is used for > > 32- and 64-bit variants. > > > > Note that U-Boot does not normally need this at runtime, since > > CONFIG_OF_BOARD is enabled. The previous firmware stage provides a > > devicetree at runtime. > > > > Signed-off-by: Simon Glass > > --- > > > > (no changes since v1) > > > > arch/arm/dts/Makefile|3 +- > > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++ > > configs/rpi_4_32b_defconfig |1 + > > configs/rpi_4_defconfig |1 + > > configs/rpi_arm64_defconfig |1 + > > 5 files changed, 1963 insertions(+), 1 deletion(-) > > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts > > > > diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile > > index 2d92b2f940d..9cddab37207 100644 > > --- a/arch/arm/dts/Makefile > > +++ b/arch/arm/dts/Makefile > > @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \ > > bcm2837-rpi-3-a-plus.dtb \ > > bcm2837-rpi-3-b.dtb \ > > bcm2837-rpi-3-b-plus.dtb \ > > - bcm2837-rpi-cm3-io3.dtb > > + bcm2837-rpi-cm3-io3.dtb \ > > + bcm2711-rpi-4-b.dtb > > > > dtb-$(CONFIG_ARCH_BCM63158) += \ > > bcm963158.dtb > > diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts > > b/arch/arm/dts/bcm2711-rpi-4-b.dts > > new file mode 100644 > > index 000..425e9fb91c4 > > --- /dev/null > > +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts > > @@ -0,0 +1,1958 @@ > > +// SPDX-License-Identifier: GPL-2.0+ OR MIT > > +/* > > + * Sample device tree for rpi_4 > > + > > + * Copyright 2021 Google LLC > > + */ > > This is of course an utter lie. This wasn't written from scratch by a > Google employee. > > The original copyright and license for the dtb files you > "disassembled" applies. You don't specify exactly where you obtained > the file from, but it probably came from here: > > https://github.com/raspberrypi/firmware > > And the README.md for that repo states that: > > "The dtbs, overlays and associated README are built from Linux >kernel sources, released under the GPL (see boot/COPYING.linux)" > > They're probably talking about their own fork of the Linux kernel > sources here as there are still differences between their device trees > and the the device trees in the official Linux tree. But if you > insist on having a device tree in the U-Boot tree, that's where you > should look. IANAL and didn't consider this point. I got this from the boot disk (using fdtdump) and it does not include a copyright message. I'll change this in the next version. Regards, Simon
[PATCH 00/15] Sync NXP LS1028A-RDB device trees between U-Boot and Linux
The changes were intended to be minimal, but unfortunately I discovered some other stuff as well: - we need to make some changes to the compatible strings of RTC devices and I2C muxes. This has ramifications to other NXP boards which were also updated. - I broke Ethernet on LS1028A boards through a patch that is currently in Ramon's tree. Therefore this patch set is a bit larger than would be otherwise expected. The Linux device tree changes have just been posted by me here and are currently in flight, but they are rather small so I don't expect too much pushback on them: https://lore.kernel.org/linux-arm-kernel/20211202141528.2450169-5-vladimir.olt...@nxp.com/T/#m6f63c92e75fa79a01144b2c2c6dc4776e7971395 Cc: Heiko Schocher Cc: Simon Glass Cc: Ramon Fried Vladimir Oltean (15): i2c: muxes: pca954x: add PCA9847 variant rtc: pcf2127: sync with Linux compatible strings arm: dts: ls1028a-qds: use Linux compatible string for RTC arm: ls1088a-qds: use Linux compatible string for RTC arm: ls1088a-rdb: use Linux compatible string for RTC arm: lx2160a-qds: use Linux compatible string for RTC arm: dts: lx2160a-rdb: use Linux compatible string for RTC rtc: pcf2127: remove U-Boot specific compatible string arm: dts: ls1028a-rdb: sort nodes alphabetically arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux arm: dts: ls1028a-rdb: disable DSPI nodes arm: dts: ls1028a-rdb: disable I2C buses 1 through 7 arm: dts: ls1028a-rdb: enable PCIe controllers from U-Boot dtsi arm: dts: ls1028a-rdb: sync device tree with Linux arm: dts: ls1028a-qds: declare in-band autoneg for Ethernet ports .../dts/fsl-ls1028a-qds-1xxx-sch-30842.dtsi | 1 + .../dts/fsl-ls1028a-qds-8xxx-sch-24801.dtsi | 1 + .../fsl-ls1028a-qds--sch-24801-LBRW.dtsi | 4 + .../dts/fsl-ls1028a-qds--sch-24801.dtsi | 4 + .../fsl-ls1028a-qds-x3xx-sch-30841-LBRW.dtsi | 4 + .../fsl-ls1028a-qds-x5xx-sch-28021-LBRW.dtsi | 4 + arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi | 14 + arch/arm/dts/fsl-ls1028a-rdb.dts | 295 -- arch/arm/dts/fsl-ls1088a-qds.dtsi | 2 +- arch/arm/dts/fsl-ls1088a-rdb.dts | 2 +- arch/arm/dts/fsl-lx2160a-qds.dtsi | 2 +- arch/arm/dts/fsl-lx2160a-rdb.dts | 2 +- drivers/i2c/muxes/pca954x.c | 9 +- drivers/rtc/pcf2127.c | 4 +- 15 files changed, 241 insertions(+), 109 deletions(-) create mode 100644 arch/arm/dts/fsl-ls1028a-rdb-u-boot.dtsi -- 2.25.1
[PATCH 05/15] arm: ls1088a-rdb: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LS1088A-RDB to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1088a-rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1088a-rdb.dts b/arch/arm/dts/fsl-ls1088a-rdb.dts
index de92bf22e203..5cdd59815234 100644
--- a/arch/arm/dts/fsl-ls1088a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1088a-rdb.dts
@@ -135,7 +135,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH 06/15] arm: lx2160a-qds: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LX2160A-QDS to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-lx2160a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-lx2160a-qds.dtsi
b/arch/arm/dts/fsl-lx2160a-qds.dtsi
index 288607c0347b..69e11cca2da1 100644
--- a/arch/arm/dts/fsl-lx2160a-qds.dtsi
+++ b/arch/arm/dts/fsl-lx2160a-qds.dtsi
@@ -250,7 +250,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH 10/15] arm: dts: ls1028a-rdb: sync Ethernet device tree nodes with Linux
In a bit of a blunder, the blamed commit made the mscc_felix switch
driver look at the 'managed = "in-band-status"' device tree property,
forgetting that the U-Boot device tree had not been updated to include
that property, whereas the Linux one does.
The switch is therefore described in the device tree as not requiring
in-band autoneg, but the PHY driver for VSC8514 (drivers/net/phy/mscc.c)
still enables that feature. This results in a mismatch => no traffic.
This patch is a copy-paste of the Ethernet device tree nodes from Linux,
which resolves that issue. The device tree update also renames the
Ethernet PHY labels.
Fixes: e3789a726269 ("net: dsa: felix: configure the in-band autoneg property
based on OF node info")
Cc: Ramon Fried
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb.dts | 32 ++--
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 4af409fd4758..7c2a865de168 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -45,33 +45,33 @@
};
_mdio_pf3 {
- status = "okay";
- rdb_phy0: phy@2 {
- reg = <2>;
+ sgmii_phy0: ethernet-phy@2 {
+ reg = <0x2>;
};
- /* VSC8514 QSGMII PHY */
- sw_phy0: phy@10 {
+ /* VSC8514 QSGMII quad PHY */
+ qsgmii_phy0: ethernet-phy@10 {
reg = <0x10>;
};
- sw_phy1: phy@11 {
+ qsgmii_phy1: ethernet-phy@11 {
reg = <0x11>;
};
- sw_phy2: phy@12 {
+ qsgmii_phy2: ethernet-phy@12 {
reg = <0x12>;
};
- sw_phy3: phy@13 {
+ qsgmii_phy3: ethernet-phy@13 {
reg = <0x13>;
};
};
_port0 {
- status = "okay";
+ phy-handle = <_phy0>;
phy-mode = "sgmii";
- phy-handle = <_phy0>;
+ managed = "in-band-status";
+ status = "okay";
};
_port2 {
@@ -158,28 +158,32 @@
_felix_port0 {
label = "swp0";
- phy-handle = <_phy0>;
+ managed = "in-band-status";
+ phy-handle = <_phy0>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port1 {
label = "swp1";
- phy-handle = <_phy1>;
+ managed = "in-band-status";
+ phy-handle = <_phy1>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port2 {
label = "swp2";
- phy-handle = <_phy2>;
+ managed = "in-band-status";
+ phy-handle = <_phy2>;
phy-mode = "qsgmii";
status = "okay";
};
_felix_port3 {
label = "swp3";
- phy-handle = <_phy3>;
+ managed = "in-band-status";
+ phy-handle = <_phy3>;
phy-mode = "qsgmii";
status = "okay";
};
--
2.25.1
[PATCH 07/15] arm: dts: lx2160a-rdb: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LX2160A-RDB to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-lx2160a-rdb.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-lx2160a-rdb.dts b/arch/arm/dts/fsl-lx2160a-rdb.dts
index 5fbdd907017c..8ca4afa7eaea 100644
--- a/arch/arm/dts/fsl-lx2160a-rdb.dts
+++ b/arch/arm/dts/fsl-lx2160a-rdb.dts
@@ -117,7 +117,7 @@
status = "okay";
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH 09/15] arm: dts: ls1028a-rdb: sort nodes alphabetically
The nodes in the NXP LS1028A-RDB device tree are out of order, regroup
them alphabetically to have a simple delta when the Linux device tree is
brought in.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-rdb.dts | 110 +++
1 file changed, 55 insertions(+), 55 deletions(-)
diff --git a/arch/arm/dts/fsl-ls1028a-rdb.dts b/arch/arm/dts/fsl-ls1028a-rdb.dts
index 537ebbc697cb..4af409fd4758 100644
--- a/arch/arm/dts/fsl-ls1028a-rdb.dts
+++ b/arch/arm/dts/fsl-ls1028a-rdb.dts
@@ -36,6 +36,48 @@
status = "okay";
};
+ {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+};
+
+_mdio_pf3 {
+ status = "okay";
+ rdb_phy0: phy@2 {
+ reg = <2>;
+ };
+
+ /* VSC8514 QSGMII PHY */
+ sw_phy0: phy@10 {
+ reg = <0x10>;
+ };
+
+ sw_phy1: phy@11 {
+ reg = <0x11>;
+ };
+
+ sw_phy2: phy@12 {
+ reg = <0x12>;
+ };
+
+ sw_phy3: phy@13 {
+ reg = <0x13>;
+ };
+};
+
+_port0 {
+ status = "okay";
+ phy-mode = "sgmii";
+ phy-handle = <_phy0>;
+};
+
+_port2 {
+ status = "okay";
+};
+
{
status = "okay";
};
@@ -110,44 +152,6 @@
status = "okay";
};
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
- {
- status = "okay";
-};
-
-_port0 {
- status = "okay";
- phy-mode = "sgmii";
- phy-handle = <_phy0>;
-};
-
-_port2 {
- status = "okay";
-};
-
_felix {
status = "okay";
};
@@ -185,26 +189,22 @@
status = "okay";
};
-_mdio_pf3 {
+ {
status = "okay";
- rdb_phy0: phy@2 {
- reg = <2>;
- };
+};
- /* VSC8514 QSGMII PHY */
- sw_phy0: phy@10 {
- reg = <0x10>;
- };
+ {
+ status = "okay";
+};
- sw_phy1: phy@11 {
- reg = <0x11>;
- };
+ {
+ status = "okay";
+};
- sw_phy2: phy@12 {
- reg = <0x12>;
- };
+ {
+ status = "okay";
+};
- sw_phy3: phy@13 {
- reg = <0x13>;
- };
+ {
+ status = "okay";
};
--
2.25.1
[PATCH v6 15/25] fdt: Make OF_BOARD a bool option
This should not be a separate option from OF_SEPARATE. It is a run-time option to override the devicetree, even if present. Move the option out of the choice. Disable BINMAN_FDT for a few boards which don't actually use it. Signed-off-by: Simon Glass --- (no changes since v1) configs/qemu-ppce500_defconfig | 1 + configs/qemu-riscv32_spl_defconfig | 2 ++ configs/qemu-riscv64_spl_defconfig | 1 + dts/Kconfig| 11 ++- 4 files changed, 10 insertions(+), 5 deletions(-) diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig index ae4cd8b9618..81d12d5f3c1 100644 --- a/configs/qemu-ppce500_defconfig +++ b/configs/qemu-ppce500_defconfig @@ -56,4 +56,5 @@ CONFIG_VIRTIO_PCI=y CONFIG_VIRTIO_NET=y CONFIG_VIRTIO_BLK=y CONFIG_ADDR_MAP=y +# CONFIG_BINMAN_FDT is not set CONFIG_PANIC_HANG=y diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig index c4422969c61..8889b028c6b 100644 --- a/configs/qemu-riscv32_spl_defconfig +++ b/configs/qemu-riscv32_spl_defconfig @@ -6,6 +6,7 @@ CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32" CONFIG_SPL=y CONFIG_TARGET_QEMU_VIRT=y CONFIG_RISCV_SMODE=y +# CONFIG_OF_BOARD_FIXUP is not set CONFIG_DISTRO_DEFAULTS=y CONFIG_SYS_LOAD_ADDR=0x8020 CONFIG_FIT=y @@ -18,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig index e02ca3a1465..8f875949ec0 100644 --- a/configs/qemu-riscv64_spl_defconfig +++ b/configs/qemu-riscv64_spl_defconfig @@ -19,3 +19,4 @@ CONFIG_OF_BOARD=y CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM_MTD=y CONFIG_SYSRESET_SBI=y +# CONFIG_BINMAN_FDT is not set diff --git a/dts/Kconfig b/dts/Kconfig index b7c4a2fec03..9994ab13dcb 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -97,11 +97,9 @@ config OF_LIVE choice prompt "Provider of DTB for DT control" depends on OF_CONTROL - default OF_BOARD if SANDBOX config OF_SEPARATE bool "Separate DTB for DT control" - depends on !SANDBOX help If this option is enabled, the device tree will be built and placed as a separate u-boot.dtb file alongside the U-Boot image. @@ -114,14 +112,17 @@ config OF_EMBED and development only and is not recommended for production devices. Boards in the mainline U-Boot tree should not use it. +endchoice + config OF_BOARD bool "Provided by the board (e.g a previous loader) at runtime" + default y if SANDBOX help If this option is enabled, the device tree will be provided by - the board at runtime if the board supports it, instead of being - bundled with the image. + the board at runtime if the board supports it. The device tree bundled + with the image (if any) will be overridden / ignored. -endchoice + A device tree file must be provided in the tree. config DEFAULT_DEVICE_TREE string "Default Device Tree for DT control" -- 2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 17/25] doc: Update info on devicetree update
Since OF_BOARD has been corrected to be a run-time option, we can drop the historical info from this documentation. Signed-off-by: Simon Glass --- (no changes since v1) doc/develop/devicetree/dt_update.rst | 74 +++- 1 file changed, 8 insertions(+), 66 deletions(-) diff --git a/doc/develop/devicetree/dt_update.rst b/doc/develop/devicetree/dt_update.rst index a1429d6e21a..1461af60f29 100644 --- a/doc/develop/devicetree/dt_update.rst +++ b/doc/develop/devicetree/dt_update.rst @@ -32,66 +32,6 @@ that board on suitable hardware (or emulation). This is specified using the `CONFIG DEFAULT_DEVICE_TREE` option. -Current situation (October 2021) -~~ - -As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, -e.g. if `CONFIG_OF_BOARD` is used. This has unfortunately created an enormous -amount of confusion and some wasted effort. This was not intended. Support for -an empty `CONFIG_DEFAULT_DEVICE_TREE` will be dropped soon. - -Some of the problems created are: - -- It is not obvious that the devicetree is coming from another project - -- There is no way to see even a sample devicetree for these platform in U-Boot, - so it is hard to know what is going on, e.g. which devices are typically - present - -- The other project may not provide a way to support U-Boot's requirements for - devicetree, such as the /config node. Note: On the U-Boot mailing linst, this - was only discovered after weeks of discussion and confusion - -- For QEMU specifically, consulting two QEMU source files is required, for which - there are no references in U-Boot documentation. The code is generating a - devicetree, but it is not clear what controls affect this generation. - -Specifically on the changes in U-Bootm `CONFIG_OF_BOARD` was added in -rpi_patch_ for Raspberry Pi, which does have an in-tree devicetree, but this -feature has since been used for boards that don't - -Once this bug is fixed, CONFIG_OF_BOARD will override (at runtime) the -evicetree suppled with U-Boot, but will otherwise use CONFIG_OF_SEPARATE for the -in-tree build. So these two will become options, moving out of the 'choice' in -`dts/Kconfig`. - -This means that there is a basic devicetree build in the U-Boot tree, for -build-testing, consistency and documentation purposes, but at runtime U-Boot can -accept its devicetree from another source. The in-tree devicetree may contain -U-Boot-specific features (in u-boot*.dtsi files) and this may prove useful for -the other project, so it can ensure that U-Boot functions correctly and supports -all its expected features. - -To be clear, while U-Boot has its own copy of the devicetree source for each -board, this must match the Linux source, perhaps with some u-boot.dtsi -additions. The intent here is not to create a separate binding, just to provide -a representative devicetree in U-Boot. - -Offending boards are: - -- rpi_4 and rpi_4_32b (other rpi boards do have an in-tree devicetree) -- qemu_arm64 -- qemu_arm -- qemu-ppce500 -- qemu-riscv32 -- qemu-riscv32_smode -- qemu-riscv64 -- qemu-riscv64_smode - -All of these need to have a devicetree added in-tree. This is targeted to be -fixed in the 2022.01 release. - - Building the devicetree --- @@ -200,15 +140,18 @@ Operating System. Also, while Linux has a (sometimes extremely long) command line, U-Boot does not support this. The devicetree provides a more structured approach in any case. +Note: Dicussions on adding a binding for this to the Linux devicetree bindings +are ongoing as of October 2021. + Devicetree in another project - -In some cases U-Boot receive its devicetree at runtime from a program that calls -it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it -passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging -the firmware, the U-Boot devicetree may in fact be left out if it can be -guaranteed that it will receive one from another project. +In some cases U-Boot receives its devicetree at runtime from a program that +calls it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree +that it passes to U-Boot. This overrides any devicetree build by U-Boot. When +packaging the firmware, the U-Boot devicetree may in fact be left out if it can +be guaranteed that it will receive one from another project. In this case, the devicetree in the other project must track U-Boot's use of device tree, for the following reasons: @@ -546,7 +489,6 @@ Overall, adding a second devicetree would create enormous confusion and complexity. It seems a lot cheaper to solve this by a change of attitude. -.. _rpi_patch: https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-de...@google.com/ .. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a .. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c .. _`QEMU
[PATCH v6 18/25] fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup()
This logic is a bit convoluted for one function. Move the mulit-FIT part
into its own function.
Signed-off-by: Simon Glass
Reviewed-by: Ilias Apalodimas
---
(no changes since v1)
lib/fdtdec.c | 62
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 7681f272d27..e0ce2532f95 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1594,13 +1594,46 @@ __weak int fdtdec_board_setup(const void *fdt_blob)
return 0;
}
+/**
+ * setup_multi_dtb_fit() - locate the correct dtb from a FIT
+ *
+ * This supports the CONFIG_MULTI_DTB_FIT feature, looking for the dtb in a
+ * supplied FIT
+ *
+ * It accepts the current value of gd->fdt_blob, which points to the FIT, then
+ * updates that gd->fdt_blob, to point to the chosen dtb so that U-Boot uses
the
+ * correct one
+ */
+static void setup_multi_dtb_fit(void)
+{
+# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
+ void *blob;
+
+ /*
+* Try and uncompress the blob.
+* Unfortunately there is no way to know how big the input blob really
+* is. So let us set the maximum input size arbitrarily high. 16MB
+* ought to be more than enough for packed DTBs.
+*/
+ if (uncompress_blob(gd->fdt_blob, 0x100, ) == 0)
+ gd->fdt_blob = blob;
+
+ /*
+* Check if blob is a FIT images containings DTBs.
+* If so, pick the most relevant
+*/
+ blob = locate_dtb_in_fit(gd->fdt_blob);
+ if (blob) {
+ gd->multi_dtb_fit = gd->fdt_blob;
+ gd->fdt_blob = blob;
+ }
+#endif /* # MULTI_DTB_FIT */
+}
+
int fdtdec_setup(void)
{
int ret;
#if CONFIG_IS_ENABLED(OF_CONTROL)
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- void *fdt_blob;
-# endif
# ifdef CONFIG_OF_EMBED
/* Get a pointer to the FDT */
# ifdef CONFIG_SPL_BUILD
@@ -1621,27 +1654,8 @@ int fdtdec_setup(void)
(unsigned long)map_to_sysmem(gd->fdt_blob)), 0);
# endif
-# if CONFIG_IS_ENABLED(MULTI_DTB_FIT)
- /*
-* Try and uncompress the blob.
-* Unfortunately there is no way to know how big the input blob really
-* is. So let us set the maximum input size arbitrarily high. 16MB
-* ought to be more than enough for packed DTBs.
-*/
- if (uncompress_blob(gd->fdt_blob, 0x100, _blob) == 0)
- gd->fdt_blob = fdt_blob;
-
- /*
-* Check if blob is a FIT images containings DTBs.
-* If so, pick the most relevant
-*/
- fdt_blob = locate_dtb_in_fit(gd->fdt_blob);
- if (fdt_blob) {
- gd->multi_dtb_fit = gd->fdt_blob;
- gd->fdt_blob = fdt_blob;
- }
-
-# endif
+ if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
+ setup_multi_dtb_fit();
#endif
ret = fdtdec_prepare_fdt();
--
2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 16/25] Drop CONFIG_BINMAN_STANDALONE_FDT
This was added as a hack to work around not having an in-tree devicetree. Now that this is fixed it is not needed. Drop it. Signed-off-by: Simon Glass --- (no changes since v1) Makefile| 3 +-- dts/Kconfig | 18 -- tools/binman/binman.rst | 20 3 files changed, 1 insertion(+), 40 deletions(-) diff --git a/Makefile b/Makefile index 57c3643d9a8..87e13ec6f53 100644 --- a/Makefile +++ b/Makefile @@ -945,7 +945,6 @@ endif endif INPUTS-$(CONFIG_TPL) += tpl/u-boot-tpl.bin INPUTS-$(CONFIG_OF_SEPARATE) += u-boot.dtb -INPUTS-$(CONFIG_BINMAN_STANDALONE_FDT) += u-boot.dtb ifeq ($(CONFIG_SPL_FRAMEWORK),y) INPUTS-$(CONFIG_OF_SEPARATE) += u-boot-dtb.img endif @@ -1412,7 +1411,7 @@ u-boot-lzma.img: u-boot.bin.lzma FORCE u-boot-dtb.img u-boot.img u-boot.kwb u-boot.pbl u-boot-ivt.img: \ $(if $(CONFIG_SPL_LOAD_FIT),u-boot-nodtb.bin \ - $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX)$(CONFIG_BINMAN_STANDALONE_FDT),dts/dt.dtb) \ + $(if $(CONFIG_OF_SEPARATE)$(CONFIG_OF_EMBED)$(CONFIG_SANDBOX),dts/dt.dtb) \ ,$(UBOOT_BIN)) FORCE $(call if_changed,mkimage) $(BOARD_SIZE_CHECK) diff --git a/dts/Kconfig b/dts/Kconfig index 9994ab13dcb..6ebbac2a649 100644 --- a/dts/Kconfig +++ b/dts/Kconfig @@ -16,24 +16,6 @@ config BINMAN bool select DTOC -config BINMAN_STANDALONE_FDT - bool - depends on BINMAN - default y if OF_BOARD - help - This option tells U-Boot build system that a standalone device tree - source is explicitly required when using binman to package U-Boot. - - This is not necessary in a common scenario where a device tree source - that contains the binman node is provided in the arch//dts - directory for a specific board. Such device tree sources are built for - OF_SEPARATE or OF_EMBED. However for a scenario like the board device - tree blob is not provided in the U-Boot build tree, but fed to U-Boot - in the runtime, e.g.: in the OF_BOARD case that it is passed by - a prior stage bootloader. For such scenario, a standalone device tree - blob containing binman node to describe how to package U-Boot should - be provided explicitly. - menu "Device Tree Control" depends on SUPPORT_OF_CONTROL diff --git a/tools/binman/binman.rst b/tools/binman/binman.rst index 35de93bd898..9ef6dc9db6a 100644 --- a/tools/binman/binman.rst +++ b/tools/binman/binman.rst @@ -232,26 +232,6 @@ You can use other, more specific CONFIG options - see 'Automatic .dtsi inclusion' below. -Using binman with OF_BOARD - - -Normally binman is used with a board configured with OF_SEPARATE or OF_EMBED. -This is a typical scenario where a device tree source that contains the binman -node is provided in the arch//dts directory for a specific board. - -However for a board configured with OF_BOARD, no device tree blob is provided -in the U-Boot build phase hence the binman node information is not available. -In order to support such use case, a new Kconfig option BINMAN_STANDALONE_FDT -is introduced, to tell the build system that a standalone device tree blob -containing binman node is explicitly required. - -Note there is a Kconfig option BINMAN_FDT which enables U-Boot run time to -access information about binman entries, stored in the device tree in a binman -node. Generally speaking, this option makes sense for OF_SEPARATE or OF_EMBED. -For the other OF_CONTROL methods, it's quite possible binman node is not -available as binman is invoked during the build phase, thus this option is not -turned on by default for these OF_CONTROL methods. - Access to binman entry offsets at run time (symbols) -- 2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 22/25] fdt: Use if() for fdtcontroladdr check
Change this to use if() instead of #if
Signed-off-by: Simon Glass
---
(no changes since v1)
lib/fdtdec.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/fdtdec.c b/lib/fdtdec.c
index 299a2c3a32f..659aeffd82e 100644
--- a/lib/fdtdec.c
+++ b/lib/fdtdec.c
@@ -1634,12 +1634,11 @@ int fdtdec_setup(void)
if (ret)
return ret;
# endif
-# ifndef CONFIG_SPL_BUILD
- /* Allow the early environment to override the fdt address */
- gd->fdt_blob = map_sysmem
- (env_get_ulong("fdtcontroladdr", 16,
+ if (!IS_ENABLED(CONFIG_SPL_BUILD)) {
+ /* Allow the early environment to override the fdt address */
+ gd->fdt_blob = map_sysmem(env_get_ulong("fdtcontroladdr", 16,
(unsigned long)map_to_sysmem(gd->fdt_blob)), 0);
-# endif
+ }
if (CONFIG_IS_ENABLED(MULTI_DTB_FIT))
setup_multi_dtb_fit();
--
2.34.0.rc2.393.gf8c9666880-goog
Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
Hi Heinrich, On Thu, 2 Dec 2021 at 09:35, Heinrich Schuchardt wrote: > > On 12/2/21 16:58, Simon Glass wrote: > > QEMU currently generates a devicetree for use with U-Boot. Explain how to > > obtain it. > > > > Also explain how to merge it to produce a devicetree with the U-Boot > > features included. > > Information like the number of CPUs and the memory must be accurate in > the devicetree and match the call parameter of QEMU. > > This worked without this series and must work afterwards. How do you > achieve this? Because it does not change how things work. Please test it for yourself and let me know if you have any problems. Regards, Simon
Re: [PATCH v6 03/25] arm: riscv: qemu: Explain how to extract the generated dt
On Thu, Dec 02, 2021 at 05:30:20PM +0100, Heinrich Schuchardt wrote: > On 12/2/21 16:58, Simon Glass wrote: > > QEMU currently generates a devicetree for use with U-Boot. Explain how to > > obtain it. > > > > Also explain how to merge it to produce a devicetree with the U-Boot > > features included. > > Information like the number of CPUs and the memory must be accurate in > the devicetree and match the call parameter of QEMU. > > This worked without this series and must work afterwards. How do you > achieve this? I don't see the problem with _this_ patch. It documents how to have QEMU dump the would-be-used device tree, and how to then modify and pass in a new one. Perhaps it needs a sentence stressing that the included commands are samples and need to match how QEMU is actually invoked? -- Tom signature.asc Description: PGP signature
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > Hi Simon > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > 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-...@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 > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > not in favor of this new version either. > > If you make a version without « fake DTs » as you name them, there are good > > advances in the documentation and other areas that would be better in > > mainline…. > > If I am the only one thinking this way and the patch can be accepted, I > > would love there is a warning in capital letters at the top of the DTS fake > > files that explains the intent of this fake DT, the possible outcomes of > > not using the one provided by the platform and the right way of dealing > > with DTs for the platform. > > This is the part that I too am still unhappy about. I do not want > reference or fake or whatever device trees in the U-Boot source tree. > We should be able to _remove_ the ones we have, that are not required, > with doc/board/...rst explaining how to get / view one. Not adding > more. So this is a key point for me and the reason I completely disagree with this approach. This proposal is working in the *exact* opposite direction and we'll never be able to get rid of device trees from U-Boot, even if at some point they move out of the kernel to a 'common' repo'. I'll just repeat what I've been saying since v1. Personally I'd be way happier if we could figure out were the specific U-Boot config nodes are needed and when are they needed. Based on what we figure out we could, pick up the device tree from a previous state bootloader and fix it up with our special nodes before we start using it, using internal DTS files (compiled to .dtbos or similar) that indeed belong in the u-boot tree. Regards /Ilias > > -- > Tom
Re: [PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
> From: Simon Glass
> Date: Thu, 2 Dec 2021 08:59:01 -0700
>
> Add this file, obtained from the Raspbian boot disk, so there is a
> reference devicetree in the U-Boot tree. The same one is used for
> 32- and 64-bit variants.
>
> Note that U-Boot does not normally need this at runtime, since
> CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
> devicetree at runtime.
>
> Signed-off-by: Simon Glass
> ---
>
> (no changes since v1)
>
> arch/arm/dts/Makefile|3 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
> configs/rpi_4_32b_defconfig |1 +
> configs/rpi_4_defconfig |1 +
> configs/rpi_arm64_defconfig |1 +
> 5 files changed, 1963 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index 2d92b2f940d..9cddab37207 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
> bcm2837-rpi-3-a-plus.dtb \
> bcm2837-rpi-3-b.dtb \
> bcm2837-rpi-3-b-plus.dtb \
> - bcm2837-rpi-cm3-io3.dtb
> + bcm2837-rpi-cm3-io3.dtb \
> + bcm2711-rpi-4-b.dtb
>
> dtb-$(CONFIG_ARCH_BCM63158) += \
> bcm963158.dtb
> diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts
> b/arch/arm/dts/bcm2711-rpi-4-b.dts
> new file mode 100644
> index 000..425e9fb91c4
> --- /dev/null
> +++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
> @@ -0,0 +1,1958 @@
> +// SPDX-License-Identifier: GPL-2.0+ OR MIT
> +/*
> + * Sample device tree for rpi_4
> +
> + * Copyright 2021 Google LLC
> + */
This is of course an utter lie. This wasn't written from scratch by a
Google employee.
The original copyright and license for the dtb files you
"disassembled" applies. You don't specify exactly where you obtained
the file from, but it probably came from here:
https://github.com/raspberrypi/firmware
And the README.md for that repo states that:
"The dtbs, overlays and associated README are built from Linux
kernel sources, released under the GPL (see boot/COPYING.linux)"
They're probably talking about their own fork of the Linux kernel
sources here as there are still differences between their device trees
and the the device trees in the official Linux tree. But if you
insist on having a device tree in the U-Boot tree, that's where you
should look.
> +
> +/dts-v1/;
> +
> +/memreserve/ 0x 0x1000;
> +/ {
> + compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
> + model = "Raspberry Pi 4 Model B";
> + interrupt-parent = <0x01>;
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> +
> + aliases {
> + serial0 = "/soc/serial@7e215040";
> + serial1 = "/soc/serial@7e201000";
> + audio = "/soc/audio";
> + aux = "/soc/aux@7e215000";
> + sound = "/soc/sound";
> + soc = "/soc";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e10";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e20";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e34";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + i2c0 = "/soc/i2c@7e205000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + mmc = "/soc/mmc@7e30";
> + mmc1 = "/soc/mmcnr@7e30";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e98";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d58";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e00 0x00 0xfe00 0x180
> + 0x7c00 0x00 0xfc00 0x200
> + 0x4000 0x00 0xff80 0x80>;
> + dma-ranges = <0xc000 0x00
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 11:03, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 10:07:13AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > > > Hi Tom, > > > > > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > > Hi Simon > > > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a > > > > > > écrit : > > > > > > > > > > > > > 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-...@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 > > > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so > > > > > > I am > > > > > > not in favor of this new version either. > > > > > > If you make a version without « fake DTs » as you name them, there > > > > > > are good > > > > > > advances in the documentation and other areas that would be better > > > > > > in > > > > > > mainline…. > > > > > > If I am the only one thinking this way and the patch can be > > > > > > accepted, I > > > > > > would love there is a warning in capital letters at the top of the > > > > > > DTS fake > > > > > > files that explains the intent of this fake DT, the possible > > > > > > outcomes of > > > > > > not using the one provided by the platform and the right way of > > > > > > dealing > > > > > > with DTs for the platform. > > > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > > We should be able to _remove_ the ones we have, that are not required, > > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > > more. > > > > > > > > I understand you don't like it and that others don't as well. I wish > > > > it had not come to this. > > > > > > > > However we are only talking about 10 boards, three of which don't even > > > > have a devicetree anywhere I can find. > > > > > > > > I think on balance this is a substantial clean-up. I am happy to add > > > > whatever caveats and documentation people want to clarify what is > > > > going on here. I'm happy to look at future options where the > > > > devicetree is hosted elsewhere, so long as it is trivial to build it > > > > within U-Boot for development purposes. > >
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
On Thu, Dec 02, 2021 at 11:21:22AM -0700, Simon Glass wrote: > Hi Mark, > > On Thu, 2 Dec 2021 at 11:15, Mark Kettenis wrote: > > > > > From: Ilias Apalodimas > > > Date: Thu, 2 Dec 2021 19:03:46 +0200 > > > > > > On Thu, 2 Dec 2021 at 18:38, Tom Rini wrote: > > > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > > Hi Simon > > > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > > > 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-...@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 > > > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I > > > > > am > > > > > not in favor of this new version either. > > > > > If you make a version without « fake DTs » as you name them, there > > > > > are good > > > > > advances in the documentation and other areas that would be better in > > > > > mainline…. > > > > > If I am the only one thinking this way and the patch can be accepted, > > > > > I > > > > > would love there is a warning in capital letters at the top of the > > > > > DTS fake > > > > > files that explains the intent of this fake DT, the possible outcomes > > > > > of > > > > > not using the one provided by the platform and the right way of > > > > > dealing > > > > > with DTs for the platform. > > > > > > > > This is the part that I too am still unhappy about. I do not want > > > > reference or fake or whatever device trees in the U-Boot source tree. > > > > We should be able to _remove_ the ones we have, that are not required, > > > > with doc/board/...rst explaining how to get / view one. Not adding > > > > more. > > > > > > So this is a key point for me and the reason I completely disagree > > > with this approach. This proposal is working in the *exact* opposite > > > direction and we'll never be able to get rid of device trees from > > > U-Boot, even if at some point they move out of the kernel to a > > > 'common' repo'. I'll just repeat what I've been saying since v1. > > > Personally I'd be way happier if we could figure out were the specific > > > U-Boot config nodes are needed and when are they needed. Based on > > > what we figure out we could, pick up the device tree from a previous > > > state bootloader and fix it up with our special nodes before we start > > > using it, using internal DTS files (compiled to .dtbos or similar) > > > that indeed belong in the u-boot tree. > > > > I don't think it makes sense to put stuff in the DT that is specific > > for U-Boot only to pull it out moments later. Maybe it does make some > > sense
[PATCH v6 07/25] arm: rpi: Add a devicetree file for rpi_4
Add this file, obtained from the Raspbian boot disk, so there is a
reference devicetree in the U-Boot tree. The same one is used for
32- and 64-bit variants.
Note that U-Boot does not normally need this at runtime, since
CONFIG_OF_BOARD is enabled. The previous firmware stage provides a
devicetree at runtime.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/Makefile|3 +-
arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++
configs/rpi_4_32b_defconfig |1 +
configs/rpi_4_defconfig |1 +
configs/rpi_arm64_defconfig |1 +
5 files changed, 1963 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 2d92b2f940d..9cddab37207 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1077,7 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM283X) += \
bcm2837-rpi-3-a-plus.dtb \
bcm2837-rpi-3-b.dtb \
bcm2837-rpi-3-b-plus.dtb \
- bcm2837-rpi-cm3-io3.dtb
+ bcm2837-rpi-cm3-io3.dtb \
+ bcm2711-rpi-4-b.dtb
dtb-$(CONFIG_ARCH_BCM63158) += \
bcm963158.dtb
diff --git a/arch/arm/dts/bcm2711-rpi-4-b.dts b/arch/arm/dts/bcm2711-rpi-4-b.dts
new file mode 100644
index 000..425e9fb91c4
--- /dev/null
+++ b/arch/arm/dts/bcm2711-rpi-4-b.dts
@@ -0,0 +1,1958 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for rpi_4
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/memreserve/ 0x 0x1000;
+/ {
+ compatible = "raspberrypi,4-model-b\0brcm,bcm2838\0brcm,bcm2837";
+ model = "Raspberry Pi 4 Model B";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+
+ aliases {
+ serial0 = "/soc/serial@7e215040";
+ serial1 = "/soc/serial@7e201000";
+ audio = "/soc/audio";
+ aux = "/soc/aux@7e215000";
+ sound = "/soc/sound";
+ soc = "/soc";
+ dma = "/soc/dma@7e007000";
+ watchdog = "/soc/watchdog@7e10";
+ random = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e20";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ mmc0 = "/soc/emmc2@7e34";
+ i2s = "/soc/i2s@7e203000";
+ spi0 = "/soc/spi@7e204000";
+ i2c0 = "/soc/i2c@7e205000";
+ uart1 = "/soc/serial@7e215040";
+ spi1 = "/soc/spi@7e215080";
+ spi2 = "/soc/spi@7e2150c0";
+ mmc = "/soc/mmc@7e30";
+ mmc1 = "/soc/mmcnr@7e30";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ usb = "/soc/usb@7e98";
+ leds = "/leds";
+ fb = "/soc/fb";
+ thermal = "/soc/thermal@7d5d2200";
+ axiperf = "/soc/axiperf";
+ mmc2 = "/soc/mmc@7e202000";
+ ethernet0 = "/scb/genet@7d58";
+ };
+
+ chosen {
+ bootargs = "8250.nr_uarts=1 cma=64M";
+ };
+
+ thermal-zones {
+
+ cpu-thermal {
+ polling-delay-passive = <0x00>;
+ polling-delay = <0x3e8>;
+ thermal-sensors = <0x02>;
+ coefficients = <0xfe19 0x641b8>;
+ phandle = <0x2f>;
+
+ cooling-maps {
+ };
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7e00 0x00 0xfe00 0x180
+ 0x7c00 0x00 0xfc00 0x200
+ 0x4000 0x00 0xff80 0x80>;
+ dma-ranges = <0xc000 0x00 0x00 0x3c00>;
+ phandle = <0x30>;
+
+ txp@7e004000 {
+ compatible = "brcm,bcm2835-txp";
+ reg = <0x7e004000 0x20>;
+ interrupts = <0x00 0x4b 0x04>;
+ status = "disabled";
+ phandle = <0x31>;
+ };
+
+ dma@7e007000 {
+ compatible = "brcm,bcm2835-dma";
+ reg = <0x7e007000 0xb00>;
+ interrupts = <0x00 0x50 0x04 0x00 0x51 0x04 0x00 0x52
+ 0x04 0x00 0x53 0x04 0x00 0x54 0x04 0x00
+ 0x55 0x04 0x00 0x56 0x04 0x00 0x57 0x04
+ 0x00 0x57 0x04 0x00 0x58 0x04 0x00 0x58
+ 0x04>;
+ interrupt-names =
"dma0\0dma1\0dma2\0dma3\0dma4\0dma5\0dma6\0dma7\0dma8\0dma9\0dma10";
+
[PATCH v6 13/25] arm: qemu-ppce500: Add a devicetree file
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-ppc64 -machine ppce500 -cpu e6500 -M dumpdtb=dtb.dtb
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/qemu-ppce500.dts | 264 ++
configs/qemu-ppce500_defconfig| 1 +
3 files changed, 266 insertions(+)
create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
diff --git a/arch/powerpc/dts/Makefile b/arch/powerpc/dts/Makefile
index ceaa8ce5c82..66d22ae8a45 100644
--- a/arch/powerpc/dts/Makefile
+++ b/arch/powerpc/dts/Makefile
@@ -18,6 +18,7 @@ dtb-$(CONFIG_TARGET_P2041RDB) += p2041rdb.dtb
dtb-$(CONFIG_TARGET_P3041DS) += p3041ds.dtb
dtb-$(CONFIG_TARGET_P4080DS) += p4080ds.dtb
dtb-$(CONFIG_TARGET_P5040DS) += p5040ds.dtb
+dtb-$(CONFIG_TARGET_QEMU_PPCE500) += qemu-ppce500.dtb
dtb-$(CONFIG_TARGET_SOCRATES) += socrates.dtb
dtb-$(CONFIG_TARGET_T1024RDB) += t1024rdb.dtb
dtb-$(CONFIG_TARGET_T1042D4RDB) += t1042d4rdb.dtb
diff --git a/arch/powerpc/dts/qemu-ppce500.dts
b/arch/powerpc/dts/qemu-ppce500.dts
new file mode 100644
index 000..92368e4d731
--- /dev/null
+++ b/arch/powerpc/dts/qemu-ppce500.dts
@@ -0,0 +1,264 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu-ppce400
+
+ * Copyright 2021 Google LLC
+ */
+/dts-v1/;
+
+/ {
+ compatible = "fsl,qemu-e500";
+ model = "QEMU ppce500";
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+
+ platform@f {
+ interrupt-parent = <0x8003>;
+ ranges = <0x00 0x0f 0x00 0x800>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ pci@fe0008000 {
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ clock-frequency = <0x3f940aa>;
+ reg = <0x0f 0xe0008000 0x00 0x1000>;
+ ranges = <0x200 0x00 0xe000 0x0c
+0x00 0x00 0x2000 0x100
+0x00 0x00 0x0f 0xe100
+0x00 0x1>;
+ fsl,msi = <0x8004>;
+ bus-range = <0x00 0xff>;
+ interrupts = <0x18 0x02>;
+ interrupt-parent = <0x8003>;
+ interrupt-map = <0x800 0x00 0x00 0x01 0x8003 0x02 0x01 0x800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x1000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x1000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x1000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x1000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x1800 0x00 0x00 0x01 0x8003 0x04 0x01 0x1800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x1800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x1800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x2000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x2000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x2000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x2000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x2800 0x00 0x00 0x01 0x8003 0x02 0x01 0x2800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x2800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x2800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x3000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x3000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x3000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x3000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x3800 0x00 0x00 0x01 0x8003 0x04 0x01 0x3800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x3800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x3800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x4000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x4000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x4000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x4000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x4800 0x00 0x00 0x01 0x8003 0x02 0x01 0x4800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x4800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x4800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x5000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x5000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x5000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x5000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x5800 0x00 0x00 0x01 0x8003 0x04 0x01 0x5800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x5800 0x00
+ 0x00 0x03 0x8003 0x02 0x01
[PATCH v6 11/25] arm: xilinx_versal_virt: Add a devicetree file
Add a devicetree file obtained from qemu for this board. This was obtained
with:
qemu-system-aarch64 -M xlnx-versal-virt -machine dumpdtb=dtb.dtb
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/Makefile| 3 +-
arch/arm/dts/xilinx-versal-virt.dts | 307 +++
configs/xilinx_versal_virt_defconfig | 1 +
3 files changed, 310 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 91302118598..b07a1b3378e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -360,7 +360,8 @@ dtb-$(CONFIG_ARCH_ZYNQMP) += \
dtb-$(CONFIG_ARCH_VERSAL) += \
versal-mini.dtb \
versal-mini-emmc0.dtb \
- versal-mini-emmc1.dtb
+ versal-mini-emmc1.dtb \
+ xilinx-versal-virt.dtb
dtb-$(CONFIG_ARCH_ZYNQMP_R5) += \
zynqmp-r5.dtb
dtb-$(CONFIG_AM33XX) += \
diff --git a/arch/arm/dts/xilinx-versal-virt.dts
b/arch/arm/dts/xilinx-versal-virt.dts
new file mode 100644
index 000..3712af9e7a4
--- /dev/null
+++ b/arch/arm/dts/xilinx-versal-virt.dts
@@ -0,0 +1,307 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for versal-virt board
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ compatible = "xlnx-versal-virt";
+ model = "Xilinx Versal Virtual development board";
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ interrupt-parent = <0x8000>;
+
+ memory@0 {
+ reg = <0x00 0x00 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ clk25 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ phandle = <0x8003>;
+ };
+
+ clk125 {
+ u-boot,dm-pre-reloc;
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x7735940>;
+ phandle = <0x8004>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ cpu@0 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x00>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72";
+ device_type = "cpu";
+ reg = <0x01>;
+ };
+ };
+
+ rtc@f12a {
+ compatible = "xlnx,zynqmp-rtc";
+ reg = <0x00 0xf12a 0x00 0x1>;
+ interrupt-names = "alarm\0sec";
+ interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
+ };
+
+ sdhci@f104 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf104 0x00 0x1>;
+ interrupts = <0x00 0x7e 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ sdhci@f105 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf105 0x00 0x1>;
+ interrupts = <0x00 0x80 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ usb@ff9d {
+ phandle = <0x8005>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ ranges;
+ clocks = <0x8003 0x8004>;
+ clock-names = "bus_clk\0ref_clk";
+ reg = <0x00 0xff9d 0x00 0x1>;
+ compatible = "xlnx,versal-dwc3";
+
+ dwc3@fe20 {
+ maximum-speed = "high-speed";
+ phandle = <0x8006>;
+ snps,mask_phy_reset;
+ snps,refclk_fladj;
+ snps,dis_u3_susphy_quirk;
+ snps,dis_u2_susphy_quirk;
+ phy-names = "usb3-phy";
+ dr_mode = "host";
+ #stream-id-cells = <0x01>;
+ snps,quirk-frame-length-adjustment = <0x20>;
+ interrupts = <0x00 0x16 0x04>;
+ interrupt-names = "dwc_usb3";
+ reg = <0x00 0xfe20 0x00 0x1>;
+ compatible = "snps,dwc3";
+ };
+ };
+
+ dma@ffa8 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa8 0x00 0x1000>;
+ interrupts = <0x00 0x3c 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffa9 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa9 0x00 0x1000>;
+
[PATCH v6 14/25] arm: highbank: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
Unfortunately there are no build instructions in the U-Boot tree to enable
a real file to be created.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/highbank.dts | 14 ++
configs/highbank_defconfig | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/highbank.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 8bb15b96cc7..453e2fd1a98 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -871,6 +871,8 @@ dtb-$(CONFIG_MX7) += imx7d-sdb.dtb \
dtb-$(CONFIG_ARCH_MX7ULP) += imx7ulp-com.dtb \
imx7ulp-evk.dtb
+dtb-$(CONFIG_ARCH_HIGHBANK) += highbank.dtb
+
dtb-$(CONFIG_ARCH_IMX8) += \
fsl-imx8qm-apalis.dtb \
fsl-imx8qm-mek.dtb \
diff --git a/arch/arm/dts/highbank.dts b/arch/arm/dts/highbank.dts
new file mode 100644
index 000..29ac48f5788
--- /dev/null
+++ b/arch/arm/dts/highbank.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for highbank board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * There appears to be no in-tree documentation about this board at all.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/highbank_defconfig b/configs/highbank_defconfig
index 85b42c70f55..3e8bfcf73a6 100644
--- a/configs/highbank_defconfig
+++ b/configs/highbank_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x8000
CONFIG_SYS_MALLOC_LEN=0x8
CONFIG_NR_DRAM_BANKS=2
CONFIG_ENV_SIZE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="highbank"
CONFIG_SYS_BOOTCOUNT_ADDR=0xfff3cf0c
CONFIG_SYS_BOOTCOUNT_SINGLEWORD=y
CONFIG_DISTRO_DEFAULTS=y
@@ -21,7 +22,6 @@ CONFIG_AUTOBOOT_KEYED_CTRLC=y
# CONFIG_DISPLAY_BOARDINFO is not set
CONFIG_MISC_INIT_R=y
# CONFIG_CMD_SETEXPR is not set
-CONFIG_OF_BOARD=y
CONFIG_ENV_IS_IN_NVRAM=y
CONFIG_ENV_ADDR=0xFFF88000
CONFIG_SCSI_AHCI=y
--
2.34.0.rc2.393.gf8c9666880-goog
[PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Add an empty file to prevent build errors when building with
CONFIG_OF_SEPARATE enabled.
The build instructions in U-Boot do not provide enough detail to build a
useful devicetree, unfortunately.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/arm/dts/Makefile| 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++
configs/xenguest_arm64_defconfig | 2 +-
3 files changed, 18 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d53bae2c350..f6345988c8c 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1140,6 +1140,8 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
mt8516-pumpkin.dtb \
mt8518-ap1-emmc.dtb
+dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/xenguest-arm64.dts b/arch/arm/dts/xenguest-arm64.dts
new file mode 100644
index 000..52d3b062248
--- /dev/null
+++ b/arch/arm/dts/xenguest-arm64.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for xenguest_arm64
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * Build instructions at xenguest_arm64.rst are inadequate for obtaining a real
+ * devicetree.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/xenguest_arm64_defconfig b/configs/xenguest_arm64_defconfig
index 8d9d9133a2e..edce34346d3 100644
--- a/configs/xenguest_arm64_defconfig
+++ b/configs/xenguest_arm64_defconfig
@@ -3,7 +3,7 @@ CONFIG_POSITION_INDEPENDENT=y
CONFIG_TARGET_XENGUEST_ARM64=y
CONFIG_SYS_TEXT_BASE=0x4008
CONFIG_SYS_MALLOC_LEN=0x200
-CONFIG_SYS_MALLOC_F_LEN=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
CONFIG_IDENT_STRING=" xenguest"
CONFIG_SYS_LOAD_ADDR=0x4000
CONFIG_BOOTDELAY=10
--
2.34.0.rc2.393.gf8c9666880-goog
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi Oleksandr, On Thu, 2 Dec 2021 at 10:40, Oleksandr Andrushchenko wrote: > > Hi, Simon! > > Sorry for being late to the party > > On 02.12.21 17:59, Simon Glass wrote: > > Add an empty file to prevent build errors when building with > > CONFIG_OF_SEPARATE enabled. > > > > The build instructions in U-Boot do not provide enough detail to build a > > useful devicetree, unfortunately. > Xen guest doesn't use any built-in device trees as the guest's device tree is > provided > by the Xen hypervisor itself and is generated at the virtual machine creation > time: it is > populated with memory size, number of CPUs etc. based on [1]. > So, even if we provide some device tree here it must not be used by U-boot at > the end of the day. Thus, it might be a reasonable solution to provide an > empty device > tree as you do, but put a comment that it is not used. OK we can go with an empty one if we have to, but where are the instructions to create the DT that is used? I'm not even sure how to run U-Boot with Xen? The in-tree instructions don't help... Regards, Simon
[PATCH v4 3/6] ARM: dts: sync Actions Semi S700 DT from Linux v5.16-rc3
From: Amit Singh Tomar
This Synchronizes the Actions Semi S700 SoC DT changes from
commit "g58e1100fdc59" ("Linux v5.16-rc3").
Signed-off-by: Amit Singh Tomar
---
arch/arm/dts/s700.dtsi| 17 -
.../dt-bindings/power/owl-s700-powergate.h| 19 +++
2 files changed, 35 insertions(+), 1 deletion(-)
create mode 100644 include/dt-bindings/power/owl-s700-powergate.h
diff --git a/arch/arm/dts/s700.dtsi b/arch/arm/dts/s700.dtsi
index 2006ad5424fa..2c78caebf515 100644
--- a/arch/arm/dts/s700.dtsi
+++ b/arch/arm/dts/s700.dtsi
@@ -5,6 +5,7 @@
#include
#include
+#include
#include
/ {
@@ -231,7 +232,7 @@
pinctrl: pinctrl@e01b {
compatible = "actions,s700-pinctrl";
- reg = <0x0 0xe01b 0x0 0x1000>;
+ reg = <0x0 0xe01b 0x0 0x100>;
clocks = < CLK_GPIO>;
gpio-controller;
gpio-ranges = < 0 0 136>;
@@ -244,5 +245,19 @@
,
;
};
+
+ dma: dma-controller@e023 {
+ compatible = "actions,s700-dma";
+ reg = <0x0 0xe023 0x0 0x1000>;
+ interrupts = ,
+,
+,
+;
+ #dma-cells = <1>;
+ dma-channels = <10>;
+ dma-requests = <44>;
+ clocks = < CLK_DMAC>;
+ power-domains = < S700_PD_DMA>;
+ };
};
};
diff --git a/include/dt-bindings/power/owl-s700-powergate.h
b/include/dt-bindings/power/owl-s700-powergate.h
new file mode 100644
index ..4cf1aefbf09c
--- /dev/null
+++ b/include/dt-bindings/power/owl-s700-powergate.h
@@ -0,0 +1,19 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Actions Semi S700 SPS
+ *
+ * Copyright (c) 2017 Andreas Färber
+ */
+#ifndef DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+#define DT_BINDINGS_POWER_OWL_S700_POWERGATE_H
+
+#define S700_PD_VDE0
+#define S700_PD_VCE_SI 1
+#define S700_PD_USB2_1 2
+#define S700_PD_HDE3
+#define S700_PD_DMA4
+#define S700_PD_DS 5
+#define S700_PD_USB3 6
+#define S700_PD_USB2_0 7
+
+#endif
--
2.27.0
[PATCH 01/15] i2c: muxes: pca954x: add PCA9847 variant
This seems to be very similar to the already existing PCA9547, save for
the fact that it supports 0.8V and doesn't support 5V. In fact, it is so
similar to the PCA9547 that the NXP LS1028A-RDB board has been driving
this chip using a "nxp,pca9547" compatible string.
Create a new compatible for the PCA9847 (which is the same as in Linux)
and define the same operating parameters for it as for PCA9547.
Cc: Heiko Schocher
Signed-off-by: Vladimir Oltean
---
drivers/i2c/muxes/pca954x.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/muxes/pca954x.c b/drivers/i2c/muxes/pca954x.c
index 55858cf653f2..0034dfbf6daf 100644
--- a/drivers/i2c/muxes/pca954x.c
+++ b/drivers/i2c/muxes/pca954x.c
@@ -23,7 +23,8 @@ enum pca_type {
PCA9546,
PCA9547,
PCA9548,
- PCA9646
+ PCA9646,
+ PCA9847,
};
struct chip_desc {
@@ -68,6 +69,11 @@ static const struct chip_desc chips[] = {
.muxtype = pca954x_isswi,
.width = 4,
},
+ [PCA9847] = {
+ .enable = 0x8,
+ .muxtype = pca954x_ismux,
+ .width = 8,
+ },
};
static int pca954x_deselect(struct udevice *mux, struct udevice *bus,
@@ -106,6 +112,7 @@ static const struct udevice_id pca954x_ids[] = {
{ .compatible = "nxp,pca9547", .data = PCA9547 },
{ .compatible = "nxp,pca9548", .data = PCA9548 },
{ .compatible = "nxp,pca9646", .data = PCA9646 },
+ { .compatible = "nxp,pca9847", .data = PCA9847 },
{ }
};
--
2.25.1
[PATCH 02/15] rtc: pcf2127: sync with Linux compatible strings
Allow this driver to be used by boards which inherit their device trees
from Linux. Compatibility is temporarily retained with the old
compatible string which is U-Boot specific, and will be removed after a
few changes.
Cc: Simon Glass
Signed-off-by: Vladimir Oltean
---
drivers/rtc/pcf2127.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/rtc/pcf2127.c b/drivers/rtc/pcf2127.c
index 57f86401d371..291ef0329a3e 100644
--- a/drivers/rtc/pcf2127.c
+++ b/drivers/rtc/pcf2127.c
@@ -121,6 +121,9 @@ static const struct rtc_ops pcf2127_rtc_ops = {
static const struct udevice_id pcf2127_rtc_ids[] = {
{ .compatible = "pcf2127-rtc" },
+ { .compatible = "nxp,pcf2127" },
+ { .compatible = "nxp,pcf2129" },
+ { .compatible = "nxp,pca2129" },
{ }
};
--
2.25.1
[PATCH 04/15] arm: ls1088a-qds: use Linux compatible string for RTC
During the LS1028A-RDB sync with Linux device trees, it was observed
that the same RTC is present on the two boards, and the wrong compatible
string is used in both places. This change updates the RTC from the
LS1088A-QDS to use the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1088a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1088a-qds.dtsi
b/arch/arm/dts/fsl-ls1088a-qds.dtsi
index a7d0edcf0aa9..21c50078c3a4 100644
--- a/arch/arm/dts/fsl-ls1088a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1088a-qds.dtsi
@@ -88,7 +88,7 @@
reg = <0x3>;
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
[PATCH 03/15] arm: dts: ls1028a-qds: use Linux compatible string for RTC
The LS1028A-QDS board won't be synced with the Linux device trees right
now, since those are currently still in progress (Ethernet is missing).
However, while we're at converting the RDB, it can be observed that the
same RTC is present on the two boards, and the wrong compatible string
is used in both places. This change updates the RTC from the QDS to use
the compatible string that was established in Linux.
Signed-off-by: Vladimir Oltean
---
arch/arm/dts/fsl-ls1028a-qds.dtsi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/dts/fsl-ls1028a-qds.dtsi
b/arch/arm/dts/fsl-ls1028a-qds.dtsi
index bd1b1c607fab..d2bc96633d00 100644
--- a/arch/arm/dts/fsl-ls1028a-qds.dtsi
+++ b/arch/arm/dts/fsl-ls1028a-qds.dtsi
@@ -195,7 +195,7 @@
status = "okay";
rtc@51 {
- compatible = "pcf2127-rtc";
+ compatible = "nxp,pcf2129";
reg = <0x51>;
};
};
--
2.25.1
Re: [PATCH 5/5] clk: Add clk_get_by_name_optional
Hi Sean,
On Thu, 2 Dec 2021 at 07:25, Sean Anderson wrote:
>
> Hi Simon,
>
> On 12/2/21 8:43 AM, Simon Glass wrote:
> > Hi Sean,
> >
> > On Wed, 1 Dec 2021 at 11:43, Sean Anderson wrote:
> >>
> >> This adds a helper function for clk_get_by_name in cases where the clock is
> >> optional. Hopefully this helps point driver writers in the right direction.
> >> Also convert some existing users.
> >>
> >> Signed-off-by: Sean Anderson
> >> ---
> >>
> >> drivers/clk/clk_zynq.c | 5 +++--
> >> drivers/rng/meson-rng.c | 4 ++--
> >> include/clk.h | 24
> >> 3 files changed, 29 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/drivers/clk/clk_zynq.c b/drivers/clk/clk_zynq.c
> >> index 18915c3e04..e80500e382 100644
> >> --- a/drivers/clk/clk_zynq.c
> >> +++ b/drivers/clk/clk_zynq.c
> >> @@ -472,8 +472,9 @@ static int zynq_clk_probe(struct udevice *dev)
> >>
> >> for (i = 0; i < 2; i++) {
> >> sprintf(name, "gem%d_emio_clk", i);
> >> - ret = clk_get_by_name(dev, name, >gem_emio_clk[i]);
> >> - if (ret < 0 && ret != -ENODATA) {
> >> + ret = clk_get_by_name_optional(dev, name,
> >> + >gem_emio_clk[i]);
> >> + if (ret) {
> >> dev_err(dev, "failed to get %s clock\n", name);
> >> return ret;
> >> }
> >> diff --git a/drivers/rng/meson-rng.c b/drivers/rng/meson-rng.c
> >> index 5a4f45ad5a..e0a1e8c7e0 100644
> >> --- a/drivers/rng/meson-rng.c
> >> +++ b/drivers/rng/meson-rng.c
> >> @@ -91,8 +91,8 @@ static int meson_rng_of_to_plat(struct udevice *dev)
> >> return -ENODEV;
> >>
> >> /* Get optional "core" clock */
> >> - err = clk_get_by_name(dev, "core", >clk);
> >> - if (err && err != -ENODATA)
> >> + err = clk_get_by_name_optional(dev, "core", >clk);
> >> + if (err)
> >> return err;
> >>
> >> return 0;
> >> diff --git a/include/clk.h b/include/clk.h
> >> index 103ef16bf9..36721188d0 100644
> >> --- a/include/clk.h
> >> +++ b/include/clk.h
> >> @@ -292,6 +292,30 @@ static inline int clk_release_all(struct clk *clk,
> >> int count)
> >> }
> >> #endif
> >>
> >> +/**
> >> + * clk_get_by_name_optional() - Get/request a optional clock by name.
> >
> > Can I suggest we rename this to ..._opt as it is shorter?
>
> This follows the general trend of suffixing _optional. For example (and
> several of these are borrowed from Linux):
>
> clk_get_optional
> reset_control_bulk_get_optional_exclusive
> gpiod_get_optional
> platform_get_irq_byname_optional
>
> and particularly, the Linux clock subsystem uses _optional and not _opt
> as a suffix. While some of these names can get fairly long-winded, I
> think we should go for consistency here.
Yes I agree.
I do wish people would consider brevity as these names are pretty
hopeless for readability.
Regards,
Simon
Question/issues about i.MX6 DDR configuration
Hello Fabio, Tim and all, in the last few weeks I have been debugging some sporadic i.MX6 board boot failures (2020.07 U-Boot, if that matters) and we have some loose indication that they could be RAM related. The effect is that SPL is not able to load U-Boot from the eMMC to DDR and dqs|write_level calibration is failing. We do write the memory configuration in a pretty simple way, SPL is just iterating thought a list of register address/value, in a very similar way to what was done using the DCD table. Today most of the boards however use a more programmatic approach as introduced by Tim in 2014 [1]. Contrary to that, however, Fabio moved away from this new approach to just raw registers writing for the sabre board [2][3]. I'm a little bit puzzled at the moment, according to the iMX6 reference manual[4], 44.4.2 MMDC initialization, a specific sequence is required to be followed and this is implemented by the `mx6_dram_cfg()`[5] function, but according to what Fabio wrote the raw initialization of registers was just more reliable for mx6sabresd. Fabio, what was the reason? I would expect that using `mx6_dram_cfg()` is the correct approach and I would expect issue if doing in a different way from what is described in the reference manual. Regarding that I found also this note in the manual interesting: "A Precharge All command must be issued prior to the MRW command to ensure robust DDR initialization. This command is required to be issued to both chip selects if two chip selects are utilized in the system." In my tests adding 1ms delay after each MMDC register write seems to have a positive effect and this is going into the direction that using `mx6_dram_cfg()` is the way to go. Any suggestion? Do I miss something? Francesco [1] https://lore.kernel.org/all/1401750807-5975-7-git-send-email-thar...@gateworks.com/ [2] https://lore.kernel.org/all/1474892066-32005-1-git-send-email-feste...@gmail.com/ [3] https://source.denx.de/u-boot/u-boot/-/commit/3b30eece271cfc4096c2d20048c89e8bed0bbbfd [4] https://www.nxp.com/webapp/Download?colCode=IMX6DQRM [5] https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-imx/mx6/ddr.c#L1672
Re: [PATCH v6 09/25] arm: xenguest_arm64: Add a fake devicetree file
Hi François, On Thu, 2 Dec 2021 at 11:17, François Ozog wrote: > > Hi Simon > > On Thu, 2 Dec 2021 at 19:05, Simon Glass wrote: >> >> Hi Tom, >> >> On Thu, 2 Dec 2021 at 10:56, Tom Rini wrote: >> > >> > On Thu, Dec 02, 2021 at 05:40:46PM +, Oleksandr Andrushchenko wrote: >> > > Hi, Simon! >> > > >> > > Sorry for being late to the party >> > > >> > > On 02.12.21 17:59, Simon Glass wrote: >> > > > Add an empty file to prevent build errors when building with >> > > > CONFIG_OF_SEPARATE enabled. >> > > > >> > > > The build instructions in U-Boot do not provide enough detail to build >> > > > a >> > > > useful devicetree, unfortunately. >> > > Xen guest doesn't use any built-in device trees as the guest's device >> > > tree is provided >> > > by the Xen hypervisor itself and is generated at the virtual machine >> > > creation time: it is >> > > populated with memory size, number of CPUs etc. based on [1]. >> > > So, even if we provide some device tree here it must not be used by >> > > U-boot at >> > > the end of the day. Thus, it might be a reasonable solution to provide >> > > an empty device >> > > tree as you do, but put a comment that it is not used. >> > >> > So another example of why this series is taking things in the wrong >> > direction. >> >> Why? > > I only had that comment in mind: "there is none so deaf as he who will not > hear." Hey, stop the pile-on. It's not useful. I've guided U-Boot's use of devicetree for 10 years successfully. The current state is a mess and I just to straighten it out. >> >> At least we might figure out where to get the DT and how to run >> Xen with U-Boot. I don't see any down-side to having a basic DT in the >> tree along with instructions on how to run Xen. > > If an EMPTY device is what is required to pass current build constraints, so > be it, and let's correct that in a later patch. And EMPTY is not basic. The problem here is a difference in philosophy around device tree. Regards, Simon
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi François, On Thu, 2 Dec 2021 at 09:34, François Ozog wrote: > > Hi Simon > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : >> >> 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-...@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 > > You haven’t addressed any concerns expressed on the mailing list.so I am not > in favor of this new version either. Please see the change log. I have addressed everything except the fundamental disagreement we have. > If you make a version without « fake DTs » as you name them, there are good > advances in the documentation and other areas that would be better in > mainline…. > If I am the only one thinking this way and the patch can be accepted, I would > love there is a warning in capital letters at the top of the DTS fake files > that explains the intent of this fake DT, the possible outcomes of not using > the one provided by the platform and the right way of dealing with DTs for > the platform. The word 'fake' applies to only three of the boards (highbank, bcm7xxx and octeontx), where I could not even figure out where to get a devicetree. One might think this would be a significant problem! Anyway yes I can add a comment to all the files, but please try to ask for everything at once as there is a cost to continually reworking this series. Regards, Simon >> >> >> 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 >>
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 2 Dec 2021 at 09:59, Tom Rini wrote: > > On Thu, Dec 02, 2021 at 09:49:51AM -0700, Simon Glass wrote: > > Hi Tom, > > > > On Thu, 2 Dec 2021 at 09:38, Tom Rini wrote: > > > > > > On Thu, Dec 02, 2021 at 05:33:53PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le jeu. 2 déc. 2021 à 17:00, Simon Glass a écrit : > > > > > > > > > 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-...@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 > > > > > > > > You haven’t addressed any concerns expressed on the mailing list.so I am > > > > not in favor of this new version either. > > > > If you make a version without « fake DTs » as you name them, there are > > > > good > > > > advances in the documentation and other areas that would be better in > > > > mainline…. > > > > If I am the only one thinking this way and the patch can be accepted, I > > > > would love there is a warning in capital letters at the top of the DTS > > > > fake > > > > files that explains the intent of this fake DT, the possible outcomes of > > > > not using the one provided by the platform and the right way of dealing > > > > with DTs for the platform. > > > > > > This is the part that I too am still unhappy about. I do not want > > > reference or fake or whatever device trees in the U-Boot source tree. > > > We should be able to _remove_ the ones we have, that are not required, > > > with doc/board/...rst explaining how to get / view one. Not adding > > > more. > > > > I understand you don't like it and that others don't as well. I wish > > it had not come to this. > > > > However we are only talking about 10 boards, three of which don't even > > have a devicetree anywhere I can find. > > > > I think on balance this is a substantial clean-up. I am happy to add > > whatever caveats and documentation people want to clarify what is > > going on here. I'm happy to look at future options where the > > devicetree is hosted elsewhere, so long as it is trivial to build it > > within U-Boot for development purposes. > > > > I'll also note that the bootstd series shows the devicetree source: > > > > Core: 246 devices, 88 uclasses, devicetree: board > > > > But for now, I still feel this is the best path forward. > > I'm not sure how to proceed here. The reviews are rather strongly > against the "include a device tree that won't be used". The use case of > "but for development someone might need to modify the device tree" is > handled by platforms documenting where / how to get the real one. We > should even update the Kconfig help to note that if you enable this your > board docs MUST explain where the device tree can be seen (or have some > legal reason you think it's OK to not...). Right, we can do
