* [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Ashok Reddy Soma, Atish Patra, Bin Meng,
Bin Meng, Christian Hewitt, David Abdurachmanov,
Dimitri John Ledkov, Fabio Estevam, Green Wan, Heiko Schocher,
Heinrich Schuchardt, Heinrich Schuchardt, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, Valentin Longchamp,
Vladimir Oltean, Wolfgang Denk, Zong Li, qemu-devel
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 at [1].
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.
It also provides a few qemu clean-ups discovered along the way.
This series is based on Ilias' two series for OF_HOSTFILE and
OF_PRIOR_STAGE removal.
It is available at u-boot-dm/ofb-working
[1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
Simon Glass (16):
arm: qemu: Mention -nographic in the docs
arm: qemu: Explain how to extract the generate devicetree
riscv: qemu: Explain how to extract the generate devicetree
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
Makefile | 3 +-
arch/arm/dts/Makefile | 20 +-
arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
arch/arm/dts/bcm7xxx.dts | 15 +
arch/arm/dts/highbank.dts | 14 +
arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
arch/arm/dts/octeontx.dts | 14 +
arch/arm/dts/qemu-arm.dts | 402 +++++
arch/arm/dts/qemu-arm64.dts | 381 +++++
arch/arm/dts/xenguest-arm64.dts | 15 +
arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
arch/powerpc/dts/Makefile | 1 +
arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++
arch/riscv/dts/qemu-virt64.dts | 217 +++
configs/bcm7260_defconfig | 1 +
configs/bcm7445_defconfig | 1 +
configs/highbank_defconfig | 2 +-
configs/octeontx2_95xx_defconfig | 1 +
configs/octeontx2_96xx_defconfig | 1 +
configs/octeontx_81xx_defconfig | 1 +
configs/octeontx_83xx_defconfig | 1 +
configs/qemu-ppce500_defconfig | 2 +
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 4 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 3 +-
configs/qemu_arm64_defconfig | 1 +
configs/qemu_arm_defconfig | 1 +
configs/rpi_4_32b_defconfig | 1 +
configs/rpi_4_defconfig | 1 +
configs/rpi_arm64_defconfig | 1 +
configs/vexpress_aemv8a_juno_defconfig | 1 +
configs/xenguest_arm64_defconfig | 1 +
configs/xilinx_versal_virt_defconfig | 1 +
doc/board/emulation/qemu-arm.rst | 19 +-
doc/board/emulation/qemu-riscv.rst | 12 +
dts/Kconfig | 27 +-
tools/binman/binman.rst | 20 -
43 files changed, 4922 insertions(+), 61 deletions(-)
create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
create mode 100644 arch/arm/dts/bcm7xxx.dts
create mode 100644 arch/arm/dts/highbank.dts
create mode 100644 arch/arm/dts/juno-r2.dts
create mode 100644 arch/arm/dts/octeontx.dts
create mode 100644 arch/arm/dts/qemu-arm.dts
create mode 100644 arch/arm/dts/qemu-arm64.dts
create mode 100644 arch/arm/dts/xenguest-arm64.dts
create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply [flat|nested] 164+ messages in thread* [PATCH 01/16] arm: qemu: Mention -nographic in the docs
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud, qemu-devel
Without this option QEMU appears to hang. Add it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 8d7fda10f15..97b6ec64905 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.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread
* [PATCH 01/16] arm: qemu: Mention -nographic in the docs
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Simon Glass, Ilias Apalodimas, qemu-devel, Albert Aribaud
Without this option QEMU appears to hang. Add it to avoid confusion.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 8d7fda10f15..97b6ec64905 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.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread
* [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud, qemu-devel
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 97b6ec64905..b458a398c69 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
CONFIG_DEBUG_UART_PL010=y
CONFIG_DEBUG_UART_BASE=0x9000000
CONFIG_DEBUG_UART_CLOCK=0
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+QEMU generates its own devicetree to pass to U-Boot and does this by default.
+You 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=dtb.dtb`,
+e.g.::
+
+ qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
+ -bios u-boot.bin -machine dumpdtb=dtb.dtb
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Simon Glass, Ilias Apalodimas, qemu-devel, Albert Aribaud
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
index 97b6ec64905..b458a398c69 100644
--- a/doc/board/emulation/qemu-arm.rst
+++ b/doc/board/emulation/qemu-arm.rst
@@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
CONFIG_DEBUG_UART_PL010=y
CONFIG_DEBUG_UART_BASE=0x9000000
CONFIG_DEBUG_UART_CLOCK=0
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+QEMU generates its own devicetree to pass to U-Boot and does this by default.
+You 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=dtb.dtb`,
+e.g.::
+
+ qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
+ -bios u-boot.bin -machine dumpdtb=dtb.dtb
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:19 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:19 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Ilias Apalodimas, Tom Rini, U-Boot Mailing List,
qemu-devel
Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
> QEMU currently generates a devicetree for use with U-Boot. Explain how to
> obtain it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/doc/board/emulation/qemu-arm.rst
> b/doc/board/emulation/qemu-arm.rst
> index 97b6ec64905..b458a398c69 100644
> --- a/doc/board/emulation/qemu-arm.rst
> +++ b/doc/board/emulation/qemu-arm.rst
> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these
> settings::
> CONFIG_DEBUG_UART_PL010=y
> CONFIG_DEBUG_UART_BASE=0x9000000
> CONFIG_DEBUG_UART_CLOCK=0
> +
> +Obtaining the QEMU devicetree
> +-----------------------------
> +
> +QEMU generates its own devicetree to pass to U-Boot and does this by
> default.
> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree
> version.
this is for either Qemu experts or u-boot for Qemu maintainers. Not for the
kernel développer as it is recipe for problems: could you add this warning ?
>
> +
> +To obtain the devicetree that qemu generates, add `-machine
> dumpdtb=dtb.dtb`,
> +e.g.::
> +
> + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
> + -bios u-boot.bin -machine dumpdtb=dtb.dtb
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
@ 2021-10-13 1:19 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:19 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Albert Aribaud, Ilias Apalodimas,
qemu-devel, Tom Rini
[-- Attachment #1: Type: text/plain, Size: 1541 bytes --]
Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
> QEMU currently generates a devicetree for use with U-Boot. Explain how to
> obtain it.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
> diff --git a/doc/board/emulation/qemu-arm.rst
> b/doc/board/emulation/qemu-arm.rst
> index 97b6ec64905..b458a398c69 100644
> --- a/doc/board/emulation/qemu-arm.rst
> +++ b/doc/board/emulation/qemu-arm.rst
> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these
> settings::
> CONFIG_DEBUG_UART_PL010=y
> CONFIG_DEBUG_UART_BASE=0x9000000
> CONFIG_DEBUG_UART_CLOCK=0
> +
> +Obtaining the QEMU devicetree
> +-----------------------------
> +
> +QEMU generates its own devicetree to pass to U-Boot and does this by
> default.
> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree
> version.
this is for either Qemu experts or u-boot for Qemu maintainers. Not for the
kernel développer as it is recipe for problems: could you add this warning ?
>
> +
> +To obtain the devicetree that qemu generates, add `-machine
> dumpdtb=dtb.dtb`,
> +e.g.::
> +
> + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
> + -bios u-boot.bin -machine dumpdtb=dtb.dtb
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 3461 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
2021-10-13 1:19 ` François Ozog
@ 2021-10-13 16:58 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 16:58 UTC (permalink / raw)
To: François Ozog
Cc: Albert Aribaud, Ilias Apalodimas, Tom Rini, U-Boot Mailing List,
QEMU Developers
Hi François,
On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
>>
>> QEMU currently generates a devicetree for use with U-Boot. Explain how to
>> obtain it.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
>> index 97b6ec64905..b458a398c69 100644
>> --- a/doc/board/emulation/qemu-arm.rst
>> +++ b/doc/board/emulation/qemu-arm.rst
>> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
>> CONFIG_DEBUG_UART_PL010=y
>> CONFIG_DEBUG_UART_BASE=0x9000000
>> CONFIG_DEBUG_UART_CLOCK=0
>> +
>> +Obtaining the QEMU devicetree
>> +-----------------------------
>> +
>> +QEMU generates its own devicetree to pass to U-Boot and does this by default.
>> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
>
> this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ?
Yes I can do that...or would it be better to hide this in doc/develop
somewhere with a link here?
>>
>>
>> +
>> +To obtain the devicetree that qemu generates, add `-machine dumpdtb=dtb.dtb`,
>> +e.g.::
>> +
>> + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
>> + -bios u-boot.bin -machine dumpdtb=dtb.dtb
>> --
>> 2.33.0.882.g93a45727a2-goog
>>
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
@ 2021-10-13 16:58 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 16:58 UTC (permalink / raw)
To: François Ozog
Cc: U-Boot Mailing List, Albert Aribaud, Ilias Apalodimas,
QEMU Developers, Tom Rini
Hi François,
On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
>>
>> QEMU currently generates a devicetree for use with U-Boot. Explain how to
>> obtain it.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
>> 1 file changed, 12 insertions(+)
>>
>> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
>> index 97b6ec64905..b458a398c69 100644
>> --- a/doc/board/emulation/qemu-arm.rst
>> +++ b/doc/board/emulation/qemu-arm.rst
>> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
>> CONFIG_DEBUG_UART_PL010=y
>> CONFIG_DEBUG_UART_BASE=0x9000000
>> CONFIG_DEBUG_UART_CLOCK=0
>> +
>> +Obtaining the QEMU devicetree
>> +-----------------------------
>> +
>> +QEMU generates its own devicetree to pass to U-Boot and does this by default.
>> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
>
> this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ?
Yes I can do that...or would it be better to hide this in doc/develop
somewhere with a link here?
>>
>>
>> +
>> +To obtain the devicetree that qemu generates, add `-machine dumpdtb=dtb.dtb`,
>> +e.g.::
>> +
>> + qemu-system-aarch64 -machine virt -nographic -cpu cortex-a57 \
>> + -bios u-boot.bin -machine dumpdtb=dtb.dtb
>> --
>> 2.33.0.882.g93a45727a2-goog
>>
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
2021-10-13 16:58 ` Simon Glass
@ 2021-10-13 17:36 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-13 17:36 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Albert Aribaud, Ilias Apalodimas,
U-Boot Mailing List, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]
On Wed, Oct 13, 2021 at 10:58:31AM -0600, Simon Glass wrote:
> Hi François,
>
> On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote:
> >
> >
> >
> > Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> QEMU currently generates a devicetree for use with U-Boot. Explain how to
> >> obtain it.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>
> >> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
> >> index 97b6ec64905..b458a398c69 100644
> >> --- a/doc/board/emulation/qemu-arm.rst
> >> +++ b/doc/board/emulation/qemu-arm.rst
> >> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
> >> CONFIG_DEBUG_UART_PL010=y
> >> CONFIG_DEBUG_UART_BASE=0x9000000
> >> CONFIG_DEBUG_UART_CLOCK=0
> >> +
> >> +Obtaining the QEMU devicetree
> >> +-----------------------------
> >> +
> >> +QEMU generates its own devicetree to pass to U-Boot and does this by default.
> >> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
> >
> > this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ?
>
> Yes I can do that...or would it be better to hide this in doc/develop
> somewhere with a link here?
Somewhere under doc/develop and an external link to the QEMU
documentation on dumpdtb would be good, as it's (as you demonstrate
throughout this series) a generic feature.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
@ 2021-10-13 17:36 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-13 17:36 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, François Ozog, Ilias Apalodimas,
QEMU Developers, Albert Aribaud
[-- Attachment #1: Type: text/plain, Size: 1677 bytes --]
On Wed, Oct 13, 2021 at 10:58:31AM -0600, Simon Glass wrote:
> Hi François,
>
> On Tue, 12 Oct 2021 at 19:20, François Ozog <francois.ozog@linaro.org> wrote:
> >
> >
> >
> > Le mer. 13 oct. 2021 à 03:02, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> QEMU currently generates a devicetree for use with U-Boot. Explain how to
> >> obtain it.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>
> >> doc/board/emulation/qemu-arm.rst | 12 ++++++++++++
> >> 1 file changed, 12 insertions(+)
> >>
> >> diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst
> >> index 97b6ec64905..b458a398c69 100644
> >> --- a/doc/board/emulation/qemu-arm.rst
> >> +++ b/doc/board/emulation/qemu-arm.rst
> >> @@ -91,3 +91,15 @@ The debug UART on the ARM virt board uses these settings::
> >> CONFIG_DEBUG_UART_PL010=y
> >> CONFIG_DEBUG_UART_BASE=0x9000000
> >> CONFIG_DEBUG_UART_CLOCK=0
> >> +
> >> +Obtaining the QEMU devicetree
> >> +-----------------------------
> >> +
> >> +QEMU generates its own devicetree to pass to U-Boot and does this by default.
> >> +You can use `-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version.
> >
> > this is for either Qemu experts or u-boot for Qemu maintainers. Not for the kernel développer as it is recipe for problems: could you add this warning ?
>
> Yes I can do that...or would it be better to hide this in doc/develop
> somewhere with a link here?
Somewhere under doc/develop and an external link to the QEMU
documentation on dumpdtb would be good, as it's (as you demonstrate
throughout this series) a generic feature.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 03/16] riscv: qemu: Explain how to extract the generate devicetree
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Atish Patra, Bin Meng,
Heinrich Schuchardt, Rick Chen, qemu-devel
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
doc/board/emulation/qemu-riscv.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 4b8e104a215..b3cf7085847 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -113,3 +113,15 @@ An attached disk can be emulated by adding::
-device ide-hd,drive=mydisk,bus=ahci.0
You will have to run 'scsi scan' to use it.
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+QEMU generates its own devicetree to pass to U-Boot and does this by default.
+You 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=dtb.dtb`,
+e.g.::
+
+ qemu-system-riscv64 -nographic -machine virt -bios u-boot \
+ -machine dumpdtb=dtb.dtb
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 03/16] riscv: qemu: Explain how to extract the generate devicetree
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Heinrich Schuchardt, Simon Glass,
Bin Meng, Rick Chen, qemu-devel, Atish Patra
QEMU currently generates a devicetree for use with U-Boot. Explain how to
obtain it.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
doc/board/emulation/qemu-riscv.rst | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst
index 4b8e104a215..b3cf7085847 100644
--- a/doc/board/emulation/qemu-riscv.rst
+++ b/doc/board/emulation/qemu-riscv.rst
@@ -113,3 +113,15 @@ An attached disk can be emulated by adding::
-device ide-hd,drive=mydisk,bus=ahci.0
You will have to run 'scsi scan' to use it.
+
+Obtaining the QEMU devicetree
+-----------------------------
+
+QEMU generates its own devicetree to pass to U-Boot and does this by default.
+You 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=dtb.dtb`,
+e.g.::
+
+ qemu-system-riscv64 -nographic -machine virt -bios u-boot \
+ -machine dumpdtb=dtb.dtb
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread
* [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Christian Hewitt, Fabio Estevam, Heiko Schocher,
Jagan Teki, Kever Yang, Neil Armstrong, Peter Robinson,
Rick Chen, Sean Anderson, Tim Harvey, Tuomas Tynkkynen,
qemu-devel
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 b8a382d1539..e2fc0cb65fc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,6 +1145,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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 00000000000..790571a9d9e
--- /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 = <0x84000005>;
+ cpu_on = <0x84000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0x84000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 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 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ gpio-keys {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ compatible = "gpio-keys";
+
+ poweroff {
+ gpios = <0x8003 0x03 0x00>;
+ linux,code = <0x74>;
+ label = "GPIO Key Poweroff";
+ };
+ };
+
+ pl061@9030000 {
+ phandle = <0x8003>;
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x07 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ compatible = "arm,pl061\0arm,primecell";
+ reg = <0x00 0x9030000 0x00 0x1000>;
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x00 0x3f000000 0x00 0x1000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0x0f>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a15";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index ded58d387ad..81ca4ca9166 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm"
CONFIG_TARGET_QEMU_ARM_32BIT=y
CONFIG_ARMV7_LPAE=y
CONFIG_AHCI=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, qemu-devel, Andre Przywara,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang,
Rick Chen, Neil Armstrong, Tuomas Tynkkynen, Jagan Teki,
Sean Anderson, Heiko Schocher, Fabio Estevam, Tim Harvey,
Peter Robinson
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 b8a382d1539..e2fc0cb65fc 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,6 +1145,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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 00000000000..790571a9d9e
--- /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 = <0x84000005>;
+ cpu_on = <0x84000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0x84000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 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 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ gpio-keys {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ compatible = "gpio-keys";
+
+ poweroff {
+ gpios = <0x8003 0x03 0x00>;
+ linux,code = <0x74>;
+ label = "GPIO Key Poweroff";
+ };
+ };
+
+ pl061@9030000 {
+ phandle = <0x8003>;
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x07 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ compatible = "arm,pl061\0arm,primecell";
+ reg = <0x00 0x9030000 0x00 0x1000>;
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x00 0x3f000000 0x00 0x1000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0x0f>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a15";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm_defconfig b/configs/qemu_arm_defconfig
index ded58d387ad..81ca4ca9166 100644
--- a/configs/qemu_arm_defconfig
+++ b/configs/qemu_arm_defconfig
@@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm"
CONFIG_TARGET_QEMU_ARM_32BIT=y
CONFIG_ARMV7_LPAE=y
CONFIG_AHCI=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread
* [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Albert Aribaud, qemu-devel, Andre Przywara,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Kever Yang,
Rick Chen, Neil Armstrong, Tuomas Tynkkynen, Jagan Teki,
Sean Anderson, Heiko Schocher, Fabio Estevam, Tim Harvey,
Peter Robinson
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 e2fc0cb65fc..52c586f3974 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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 00000000000..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 = <0xc4000005>;
+ cpu_on = <0xc4000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0xc4000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 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 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x40 0x10000000 0x00 0x10000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ interrupts = <0x01 0x07 0x104>;
+ compatible = "arm,armv8-pmuv3";
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a57";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv8-timer\0arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index cf5a03e8a2f..e51ce5c799f 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x40200000
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Christian Hewitt, Fabio Estevam, Heiko Schocher,
Jagan Teki, Kever Yang, Neil Armstrong, Peter Robinson,
Rick Chen, Sean Anderson, Tim Harvey, Tuomas Tynkkynen,
qemu-devel
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
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 e2fc0cb65fc..52c586f3974 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) += imx8mm-cl-iot-gate.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 00000000000..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 = <0xc4000005>;
+ cpu_on = <0xc4000003>;
+ cpu_off = <0x84000002>;
+ cpu_suspend = <0xc4000001>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@40000000 {
+ reg = <0x00 0x40000000 0x00 0x8000000>;
+ device_type = "memory";
+ };
+
+ platform@c000000 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc000000 0x2000000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@9020000 {
+ dma-coherent;
+ reg = <0x00 0x9020000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a000000 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa000000 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 {
+ dma-coherent;
+ interrupts = <0x00 0x19 0x01>;
+ reg = <0x00 0xa001200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001400 {
+ dma-coherent;
+ interrupts = <0x00 0x1a 0x01>;
+ reg = <0x00 0xa001400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001600 {
+ dma-coherent;
+ interrupts = <0x00 0x1b 0x01>;
+ reg = <0x00 0xa001600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001800 {
+ dma-coherent;
+ interrupts = <0x00 0x1c 0x01>;
+ reg = <0x00 0xa001800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001a00 {
+ dma-coherent;
+ interrupts = <0x00 0x1d 0x01>;
+ reg = <0x00 0xa001a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001c00 {
+ dma-coherent;
+ interrupts = <0x00 0x1e 0x01>;
+ reg = <0x00 0xa001c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001e00 {
+ dma-coherent;
+ interrupts = <0x00 0x1f 0x01>;
+ reg = <0x00 0xa001e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002000 {
+ dma-coherent;
+ interrupts = <0x00 0x20 0x01>;
+ reg = <0x00 0xa002000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002200 {
+ dma-coherent;
+ interrupts = <0x00 0x21 0x01>;
+ reg = <0x00 0xa002200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002400 {
+ dma-coherent;
+ interrupts = <0x00 0x22 0x01>;
+ reg = <0x00 0xa002400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002600 {
+ dma-coherent;
+ interrupts = <0x00 0x23 0x01>;
+ reg = <0x00 0xa002600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002800 {
+ dma-coherent;
+ interrupts = <0x00 0x24 0x01>;
+ reg = <0x00 0xa002800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002a00 {
+ dma-coherent;
+ interrupts = <0x00 0x25 0x01>;
+ reg = <0x00 0xa002a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002c00 {
+ dma-coherent;
+ interrupts = <0x00 0x26 0x01>;
+ reg = <0x00 0xa002c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a002e00 {
+ dma-coherent;
+ interrupts = <0x00 0x27 0x01>;
+ reg = <0x00 0xa002e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003000 {
+ dma-coherent;
+ interrupts = <0x00 0x28 0x01>;
+ reg = <0x00 0xa003000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003200 {
+ dma-coherent;
+ interrupts = <0x00 0x29 0x01>;
+ reg = <0x00 0xa003200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003400 {
+ dma-coherent;
+ interrupts = <0x00 0x2a 0x01>;
+ reg = <0x00 0xa003400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003600 {
+ dma-coherent;
+ interrupts = <0x00 0x2b 0x01>;
+ reg = <0x00 0xa003600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003800 {
+ dma-coherent;
+ interrupts = <0x00 0x2c 0x01>;
+ reg = <0x00 0xa003800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003a00 {
+ dma-coherent;
+ interrupts = <0x00 0x2d 0x01>;
+ reg = <0x00 0xa003a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003c00 {
+ dma-coherent;
+ interrupts = <0x00 0x2e 0x01>;
+ reg = <0x00 0xa003c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a003e00 {
+ dma-coherent;
+ interrupts = <0x00 0x2f 0x01>;
+ reg = <0x00 0xa003e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ pcie@10000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
+ 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
+ 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
+ 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
+ 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
+ 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
+ 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
+ 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
+ #interrupt-cells = <0x01>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3eff0000 0x00 0x10000 0x2000000
+ 0x00 0x10000000 0x00 0x10000000
+ 0x00 0x2eff0000 0x3000000 0x80
+ 0x00 0x80 0x00 0x80
+ 0x00>;
+ reg = <0x40 0x10000000 0x00 0x10000000>;
+ msi-parent = <0x8002>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ #size-cells = <0x02>;
+ #address-cells = <0x03>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ };
+
+ pl031@9010000 {
+ clock-names = "apb_pclk";
+ clocks = <0x8000>;
+ interrupts = <0x00 0x02 0x04>;
+ reg = <0x00 0x9010000 0x00 0x1000>;
+ compatible = "arm,pl031\0arm,primecell";
+ };
+
+ pl011@9000000 {
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8000 0x8000>;
+ interrupts = <0x00 0x01 0x04>;
+ reg = <0x00 0x9000000 0x00 0x1000>;
+ compatible = "arm,pl011\0arm,primecell";
+ };
+
+ pmu {
+ interrupts = <0x01 0x07 0x104>;
+ compatible = "arm,armv8-pmuv3";
+ };
+
+ intc@8000000 {
+ phandle = <0x8001>;
+ reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000>;
+ compatible = "arm,cortex-a15-gic";
+ ranges;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+
+ v2m@8020000 {
+ phandle = <0x8002>;
+ reg = <0x00 0x8020000 0x00 0x1000>;
+ msi-controller;
+ compatible = "arm,gic-v2m-frame";
+ };
+ };
+
+ flash@0 {
+ bank-width = <0x04>;
+ reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000>;
+ compatible = "cfi-flash";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ cpu@0 {
+ reg = <0x00>;
+ compatible = "arm,cortex-a57";
+ device_type = "cpu";
+ };
+ };
+
+ timer {
+ interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104>;
+ always-on;
+ compatible = "arm,armv8-timer\0arm,armv7-timer";
+ };
+
+ apb-pclk {
+ phandle = <0x8000>;
+ clock-output-names = "clk24mhz";
+ clock-frequency = <0x16e3600>;
+ #clock-cells = <0x00>;
+ compatible = "fixed-clock";
+ };
+
+ chosen {
+ stdout-path = "/pl011@9000000";
+ };
+};
diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
index cf5a03e8a2f..e51ce5c799f 100644
--- a/configs/qemu_arm64_defconfig
+++ b/configs/qemu_arm64_defconfig
@@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x40000
CONFIG_ENV_SECT_SIZE=0x40000
CONFIG_SYS_MALLOC_LEN=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
CONFIG_AHCI=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x40200000
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:15 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:15 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Andre Przywara, Christian Hewitt, Fabio Estevam,
Heiko Schocher, Ilias Apalodimas, Jagan Teki, Kever Yang,
Neil Armstrong, Peter Robinson, Rick Chen, Sean Anderson,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
qemu-devel
Hi Simon
The only place I could agree with this file presence is in the
documentation directory, not in dts. It creates a mental picture for the
reader an entirely bad mind scheme around Qemu and DT.
And even in a documentation directory I would place a bug warning: don’t
use this with any kernel , Qemu generates a DT dynamically based on cpu,
memory and devices specified at the command line.
I would also document how to get the DT that Qemu generates (and lkvm btw)
outside any firmware/os provided.
Cheers
FF
Le mer. 13 oct. 2021 à 03:03, Simon Glass <sjg@chromium.org> a écrit :
> Add this file, generated from qemu, so there is a reference devicetree
> in the U-Boot tree.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> 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 e2fc0cb65fc..52c586f3974 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
> imx8mm-cl-iot-gate.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 00000000000..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 = <0xc4000005>;
> + cpu_on = <0xc4000003>;
> + cpu_off = <0x84000002>;
> + cpu_suspend = <0xc4000001>;
> + method = "hvc";
> + compatible = "arm,psci-0.2\0arm,psci";
> + };
> +
> + memory@40000000 {
> + reg = <0x00 0x40000000 0x00 0x8000000>;
> + device_type = "memory";
> + };
> +
> + platform@c000000 {
> + interrupt-parent = <0x8001>;
> + ranges = <0x00 0x00 0xc000000 0x2000000>;
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + compatible = "qemu,platform\0simple-bus";
> + };
> +
> + fw-cfg@9020000 {
> + dma-coherent;
> + reg = <0x00 0x9020000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + virtio_mmio@a000000 {
> + dma-coherent;
> + interrupts = <0x00 0x10 0x01>;
> + reg = <0x00 0xa000000 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 {
> + dma-coherent;
> + interrupts = <0x00 0x19 0x01>;
> + reg = <0x00 0xa001200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001400 {
> + dma-coherent;
> + interrupts = <0x00 0x1a 0x01>;
> + reg = <0x00 0xa001400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001600 {
> + dma-coherent;
> + interrupts = <0x00 0x1b 0x01>;
> + reg = <0x00 0xa001600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001800 {
> + dma-coherent;
> + interrupts = <0x00 0x1c 0x01>;
> + reg = <0x00 0xa001800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001a00 {
> + dma-coherent;
> + interrupts = <0x00 0x1d 0x01>;
> + reg = <0x00 0xa001a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001c00 {
> + dma-coherent;
> + interrupts = <0x00 0x1e 0x01>;
> + reg = <0x00 0xa001c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001e00 {
> + dma-coherent;
> + interrupts = <0x00 0x1f 0x01>;
> + reg = <0x00 0xa001e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002000 {
> + dma-coherent;
> + interrupts = <0x00 0x20 0x01>;
> + reg = <0x00 0xa002000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002200 {
> + dma-coherent;
> + interrupts = <0x00 0x21 0x01>;
> + reg = <0x00 0xa002200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002400 {
> + dma-coherent;
> + interrupts = <0x00 0x22 0x01>;
> + reg = <0x00 0xa002400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002600 {
> + dma-coherent;
> + interrupts = <0x00 0x23 0x01>;
> + reg = <0x00 0xa002600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002800 {
> + dma-coherent;
> + interrupts = <0x00 0x24 0x01>;
> + reg = <0x00 0xa002800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002a00 {
> + dma-coherent;
> + interrupts = <0x00 0x25 0x01>;
> + reg = <0x00 0xa002a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002c00 {
> + dma-coherent;
> + interrupts = <0x00 0x26 0x01>;
> + reg = <0x00 0xa002c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002e00 {
> + dma-coherent;
> + interrupts = <0x00 0x27 0x01>;
> + reg = <0x00 0xa002e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003000 {
> + dma-coherent;
> + interrupts = <0x00 0x28 0x01>;
> + reg = <0x00 0xa003000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003200 {
> + dma-coherent;
> + interrupts = <0x00 0x29 0x01>;
> + reg = <0x00 0xa003200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003400 {
> + dma-coherent;
> + interrupts = <0x00 0x2a 0x01>;
> + reg = <0x00 0xa003400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003600 {
> + dma-coherent;
> + interrupts = <0x00 0x2b 0x01>;
> + reg = <0x00 0xa003600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003800 {
> + dma-coherent;
> + interrupts = <0x00 0x2c 0x01>;
> + reg = <0x00 0xa003800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003a00 {
> + dma-coherent;
> + interrupts = <0x00 0x2d 0x01>;
> + reg = <0x00 0xa003a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003c00 {
> + dma-coherent;
> + interrupts = <0x00 0x2e 0x01>;
> + reg = <0x00 0xa003c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003e00 {
> + dma-coherent;
> + interrupts = <0x00 0x2f 0x01>;
> + reg = <0x00 0xa003e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + pcie@10000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
> + 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
> + 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
> + 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
> + #interrupt-cells = <0x01>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3eff0000 0x00 0x10000 0x2000000
> + 0x00 0x10000000 0x00 0x10000000
> + 0x00 0x2eff0000 0x3000000 0x80
> + 0x00 0x80 0x00 0x80
> + 0x00>;
> + reg = <0x40 0x10000000 0x00 0x10000000>;
> + msi-parent = <0x8002>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + #size-cells = <0x02>;
> + #address-cells = <0x03>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + };
> +
> + pl031@9010000 {
> + clock-names = "apb_pclk";
> + clocks = <0x8000>;
> + interrupts = <0x00 0x02 0x04>;
> + reg = <0x00 0x9010000 0x00 0x1000>;
> + compatible = "arm,pl031\0arm,primecell";
> + };
> +
> + pl011@9000000 {
> + clock-names = "uartclk\0apb_pclk";
> + clocks = <0x8000 0x8000>;
> + interrupts = <0x00 0x01 0x04>;
> + reg = <0x00 0x9000000 0x00 0x1000>;
> + compatible = "arm,pl011\0arm,primecell";
> + };
> +
> + pmu {
> + interrupts = <0x01 0x07 0x104>;
> + compatible = "arm,armv8-pmuv3";
> + };
> +
> + intc@8000000 {
> + phandle = <0x8001>;
> + reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00
> 0x10000>;
> + compatible = "arm,cortex-a15-gic";
> + ranges;
> + #size-cells = <0x02>;
> + #address-cells = <0x02>;
> + interrupt-controller;
> + #interrupt-cells = <0x03>;
> +
> + v2m@8020000 {
> + phandle = <0x8002>;
> + reg = <0x00 0x8020000 0x00 0x1000>;
> + msi-controller;
> + compatible = "arm,gic-v2m-frame";
> + };
> + };
> +
> + flash@0 {
> + bank-width = <0x04>;
> + reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00
> 0x4000000>;
> + compatible = "cfi-flash";
> + };
> +
> + cpus {
> + #size-cells = <0x00>;
> + #address-cells = <0x01>;
> +
> + cpu@0 {
> + reg = <0x00>;
> + compatible = "arm,cortex-a57";
> + device_type = "cpu";
> + };
> + };
> +
> + timer {
> + interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b
> 0x104 0x01 0x0a 0x104>;
> + always-on;
> + compatible = "arm,armv8-timer\0arm,armv7-timer";
> + };
> +
> + apb-pclk {
> + phandle = <0x8000>;
> + clock-output-names = "clk24mhz";
> + clock-frequency = <0x16e3600>;
> + #clock-cells = <0x00>;
> + compatible = "fixed-clock";
> + };
> +
> + chosen {
> + stdout-path = "/pl011@9000000";
> + };
> +};
> diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
> index cf5a03e8a2f..e51ce5c799f 100644
> --- a/configs/qemu_arm64_defconfig
> +++ b/configs/qemu_arm64_defconfig
> @@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x40000
> CONFIG_ENV_SECT_SIZE=0x40000
> CONFIG_SYS_MALLOC_LEN=0x1000000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x40200000
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-13 1:15 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:15 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, qemu-devel, Neil Armstrong, U-Boot Mailing List,
Andre Przywara, Tim Harvey, Ilias Apalodimas, Christian Hewitt,
Kever Yang, Rick Chen, Tuomas Tynkkynen, Jagan Teki,
Sean Anderson, Heiko Schocher, Fabio Estevam, Tom Rini,
Peter Robinson
[-- Attachment #1: Type: text/plain, Size: 16023 bytes --]
Hi Simon
The only place I could agree with this file presence is in the
documentation directory, not in dts. It creates a mental picture for the
reader an entirely bad mind scheme around Qemu and DT.
And even in a documentation directory I would place a bug warning: don’t
use this with any kernel , Qemu generates a DT dynamically based on cpu,
memory and devices specified at the command line.
I would also document how to get the DT that Qemu generates (and lkvm btw)
outside any firmware/os provided.
Cheers
FF
Le mer. 13 oct. 2021 à 03:03, Simon Glass <sjg@chromium.org> a écrit :
> Add this file, generated from qemu, so there is a reference devicetree
> in the U-Boot tree.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> 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 e2fc0cb65fc..52c586f3974 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1145,7 +1145,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE) +=
> imx8mm-cl-iot-gate.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 00000000000..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 = <0xc4000005>;
> + cpu_on = <0xc4000003>;
> + cpu_off = <0x84000002>;
> + cpu_suspend = <0xc4000001>;
> + method = "hvc";
> + compatible = "arm,psci-0.2\0arm,psci";
> + };
> +
> + memory@40000000 {
> + reg = <0x00 0x40000000 0x00 0x8000000>;
> + device_type = "memory";
> + };
> +
> + platform@c000000 {
> + interrupt-parent = <0x8001>;
> + ranges = <0x00 0x00 0xc000000 0x2000000>;
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + compatible = "qemu,platform\0simple-bus";
> + };
> +
> + fw-cfg@9020000 {
> + dma-coherent;
> + reg = <0x00 0x9020000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + virtio_mmio@a000000 {
> + dma-coherent;
> + interrupts = <0x00 0x10 0x01>;
> + reg = <0x00 0xa000000 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 {
> + dma-coherent;
> + interrupts = <0x00 0x19 0x01>;
> + reg = <0x00 0xa001200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001400 {
> + dma-coherent;
> + interrupts = <0x00 0x1a 0x01>;
> + reg = <0x00 0xa001400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001600 {
> + dma-coherent;
> + interrupts = <0x00 0x1b 0x01>;
> + reg = <0x00 0xa001600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001800 {
> + dma-coherent;
> + interrupts = <0x00 0x1c 0x01>;
> + reg = <0x00 0xa001800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001a00 {
> + dma-coherent;
> + interrupts = <0x00 0x1d 0x01>;
> + reg = <0x00 0xa001a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001c00 {
> + dma-coherent;
> + interrupts = <0x00 0x1e 0x01>;
> + reg = <0x00 0xa001c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a001e00 {
> + dma-coherent;
> + interrupts = <0x00 0x1f 0x01>;
> + reg = <0x00 0xa001e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002000 {
> + dma-coherent;
> + interrupts = <0x00 0x20 0x01>;
> + reg = <0x00 0xa002000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002200 {
> + dma-coherent;
> + interrupts = <0x00 0x21 0x01>;
> + reg = <0x00 0xa002200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002400 {
> + dma-coherent;
> + interrupts = <0x00 0x22 0x01>;
> + reg = <0x00 0xa002400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002600 {
> + dma-coherent;
> + interrupts = <0x00 0x23 0x01>;
> + reg = <0x00 0xa002600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002800 {
> + dma-coherent;
> + interrupts = <0x00 0x24 0x01>;
> + reg = <0x00 0xa002800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002a00 {
> + dma-coherent;
> + interrupts = <0x00 0x25 0x01>;
> + reg = <0x00 0xa002a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002c00 {
> + dma-coherent;
> + interrupts = <0x00 0x26 0x01>;
> + reg = <0x00 0xa002c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a002e00 {
> + dma-coherent;
> + interrupts = <0x00 0x27 0x01>;
> + reg = <0x00 0xa002e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003000 {
> + dma-coherent;
> + interrupts = <0x00 0x28 0x01>;
> + reg = <0x00 0xa003000 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003200 {
> + dma-coherent;
> + interrupts = <0x00 0x29 0x01>;
> + reg = <0x00 0xa003200 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003400 {
> + dma-coherent;
> + interrupts = <0x00 0x2a 0x01>;
> + reg = <0x00 0xa003400 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003600 {
> + dma-coherent;
> + interrupts = <0x00 0x2b 0x01>;
> + reg = <0x00 0xa003600 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003800 {
> + dma-coherent;
> + interrupts = <0x00 0x2c 0x01>;
> + reg = <0x00 0xa003800 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003a00 {
> + dma-coherent;
> + interrupts = <0x00 0x2d 0x01>;
> + reg = <0x00 0xa003a00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003c00 {
> + dma-coherent;
> + interrupts = <0x00 0x2e 0x01>;
> + reg = <0x00 0xa003c00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@a003e00 {
> + dma-coherent;
> + interrupts = <0x00 0x2f 0x01>;
> + reg = <0x00 0xa003e00 0x00 0x200>;
> + compatible = "virtio,mmio";
> + };
> +
> + pcie@10000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04
> + 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04
> + 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04
> + 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00
> + 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00
> + 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03
> + 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00
> + 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04>;
> + #interrupt-cells = <0x01>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3eff0000 0x00 0x10000 0x2000000
> + 0x00 0x10000000 0x00 0x10000000
> + 0x00 0x2eff0000 0x3000000 0x80
> + 0x00 0x80 0x00 0x80
> + 0x00>;
> + reg = <0x40 0x10000000 0x00 0x10000000>;
> + msi-parent = <0x8002>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + #size-cells = <0x02>;
> + #address-cells = <0x03>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + };
> +
> + pl031@9010000 {
> + clock-names = "apb_pclk";
> + clocks = <0x8000>;
> + interrupts = <0x00 0x02 0x04>;
> + reg = <0x00 0x9010000 0x00 0x1000>;
> + compatible = "arm,pl031\0arm,primecell";
> + };
> +
> + pl011@9000000 {
> + clock-names = "uartclk\0apb_pclk";
> + clocks = <0x8000 0x8000>;
> + interrupts = <0x00 0x01 0x04>;
> + reg = <0x00 0x9000000 0x00 0x1000>;
> + compatible = "arm,pl011\0arm,primecell";
> + };
> +
> + pmu {
> + interrupts = <0x01 0x07 0x104>;
> + compatible = "arm,armv8-pmuv3";
> + };
> +
> + intc@8000000 {
> + phandle = <0x8001>;
> + reg = <0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00
> 0x10000>;
> + compatible = "arm,cortex-a15-gic";
> + ranges;
> + #size-cells = <0x02>;
> + #address-cells = <0x02>;
> + interrupt-controller;
> + #interrupt-cells = <0x03>;
> +
> + v2m@8020000 {
> + phandle = <0x8002>;
> + reg = <0x00 0x8020000 0x00 0x1000>;
> + msi-controller;
> + compatible = "arm,gic-v2m-frame";
> + };
> + };
> +
> + flash@0 {
> + bank-width = <0x04>;
> + reg = <0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00
> 0x4000000>;
> + compatible = "cfi-flash";
> + };
> +
> + cpus {
> + #size-cells = <0x00>;
> + #address-cells = <0x01>;
> +
> + cpu@0 {
> + reg = <0x00>;
> + compatible = "arm,cortex-a57";
> + device_type = "cpu";
> + };
> + };
> +
> + timer {
> + interrupts = <0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b
> 0x104 0x01 0x0a 0x104>;
> + always-on;
> + compatible = "arm,armv8-timer\0arm,armv7-timer";
> + };
> +
> + apb-pclk {
> + phandle = <0x8000>;
> + clock-output-names = "clk24mhz";
> + clock-frequency = <0x16e3600>;
> + #clock-cells = <0x00>;
> + compatible = "fixed-clock";
> + };
> +
> + chosen {
> + stdout-path = "/pl011@9000000";
> + };
> +};
> diff --git a/configs/qemu_arm64_defconfig b/configs/qemu_arm64_defconfig
> index cf5a03e8a2f..e51ce5c799f 100644
> --- a/configs/qemu_arm64_defconfig
> +++ b/configs/qemu_arm64_defconfig
> @@ -5,6 +5,7 @@ CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x40000
> CONFIG_ENV_SECT_SIZE=0x40000
> CONFIG_SYS_MALLOC_LEN=0x1000000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-arm64"
> CONFIG_AHCI=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x40200000
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 22346 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-13 1:15 ` François Ozog
@ 2021-10-27 14:44 ` Alex Bennée
-1 siblings, 0 replies; 164+ messages in thread
From: Alex Bennée @ 2021-10-27 14:44 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, Albert Aribaud, Neil Armstrong, U-Boot Mailing List,
Andre Przywara, Tim Harvey, Ilias Apalodimas, Christian Hewitt,
Kever Yang, Rick Chen, Tuomas Tynkkynen, Jagan Teki,
Sean Anderson, Heiko Schocher, Fabio Estevam, Tom Rini,
Peter Robinson, qemu-devel
François Ozog <francois.ozog@linaro.org> writes:
> Hi Simon
>
> The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> an entirely bad mind scheme around Qemu and DT.
>
> And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> based on cpu, memory and devices specified at the command line.
Certainly for the arm, aarch64 and riscv "virt" machines you should
always use the QEMU generated DTB. I'm not entirely clear what a
qemu_arm and qemu_arm64 def targets are meant to be in this context.
--
Alex Bennée
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-27 14:44 ` Alex Bennée
0 siblings, 0 replies; 164+ messages in thread
From: Alex Bennée @ 2021-10-27 14:44 UTC (permalink / raw)
To: François Ozog
Cc: Albert Aribaud, Tom Rini, Heiko Schocher, Neil Armstrong,
qemu-devel, Andre Przywara, Simon Glass, Ilias Apalodimas,
Christian Hewitt, Kever Yang, Rick Chen, U-Boot Mailing List,
Jagan Teki, Sean Anderson, Tuomas Tynkkynen, Fabio Estevam,
Tim Harvey, Peter Robinson
François Ozog <francois.ozog@linaro.org> writes:
> Hi Simon
>
> The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> an entirely bad mind scheme around Qemu and DT.
>
> And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> based on cpu, memory and devices specified at the command line.
Certainly for the arm, aarch64 and riscv "virt" machines you should
always use the QEMU generated DTB. I'm not entirely clear what a
qemu_arm and qemu_arm64 def targets are meant to be in this context.
--
Alex Bennée
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-27 14:44 ` Alex Bennée
@ 2021-10-27 14:56 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:56 UTC (permalink / raw)
To: Alex Bennée
Cc: François Ozog, Simon Glass, Albert Aribaud, Neil Armstrong,
U-Boot Mailing List, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher,
Fabio Estevam, Peter Robinson, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
>
> François Ozog <francois.ozog@linaro.org> writes:
>
> > Hi Simon
> >
> > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > an entirely bad mind scheme around Qemu and DT.
> >
> > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > based on cpu, memory and devices specified at the command line.
>
> Certainly for the arm, aarch64 and riscv "virt" machines you should
> always use the QEMU generated DTB. I'm not entirely clear what a
> qemu_arm and qemu_arm64 def targets are meant to be in this context.
Agreed. We cannot include random device trees in U-Boot for devices
that generate their own at run time or otherwise have the source of
truth elsewhere.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-27 14:56 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:56 UTC (permalink / raw)
To: Alex Bennée
Cc: Heiko Schocher, François Ozog, Albert Aribaud,
Neil Armstrong, qemu-devel, Andre Przywara, Simon Glass,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
U-Boot Mailing List, Jagan Teki, Sean Anderson, Tuomas Tynkkynen,
Fabio Estevam, Tim Harvey, Peter Robinson
[-- Attachment #1: Type: text/plain, Size: 944 bytes --]
On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
>
> François Ozog <francois.ozog@linaro.org> writes:
>
> > Hi Simon
> >
> > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > an entirely bad mind scheme around Qemu and DT.
> >
> > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > based on cpu, memory and devices specified at the command line.
>
> Certainly for the arm, aarch64 and riscv "virt" machines you should
> always use the QEMU generated DTB. I'm not entirely clear what a
> qemu_arm and qemu_arm64 def targets are meant to be in this context.
Agreed. We cannot include random device trees in U-Boot for devices
that generate their own at run time or otherwise have the source of
truth elsewhere.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-27 14:56 ` Tom Rini
@ 2021-10-27 18:34 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-27 18:34 UTC (permalink / raw)
To: Tom Rini
Cc: Alex Bennée, François Ozog, Albert Aribaud,
Neil Armstrong, U-Boot Mailing List, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher,
Fabio Estevam, Peter Robinson, QEMU Developers
Hi all,
On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> >
> > François Ozog <francois.ozog@linaro.org> writes:
> >
> > > Hi Simon
> > >
> > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > > an entirely bad mind scheme around Qemu and DT.
> > >
> > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > > based on cpu, memory and devices specified at the command line.
> >
> > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > always use the QEMU generated DTB. I'm not entirely clear what a
> > qemu_arm and qemu_arm64 def targets are meant to be in this context.
>
> Agreed. We cannot include random device trees in U-Boot for devices
> that generate their own at run time or otherwise have the source of
> truth elsewhere.
Until we have a way of bringing in the u-boot.dtsi that people in QEMU
can agree on, I don't see an alternative. I will send a series for the
bloblist handoff next week and I think you will all see what I mean.
Perhaps all this will be easier a year or so, if we continue to make
progress on the devicetree validation/sharing stuff, but for now, this
seems like the only viable approach to me.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-27 18:34 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-27 18:34 UTC (permalink / raw)
To: Tom Rini
Cc: Heiko Schocher, François Ozog, Albert Aribaud,
Neil Armstrong, QEMU Developers, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
U-Boot Mailing List, Jagan Teki, Sean Anderson, Fabio Estevam,
Tuomas Tynkkynen, Alex Bennée, Peter Robinson
Hi all,
On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> >
> > François Ozog <francois.ozog@linaro.org> writes:
> >
> > > Hi Simon
> > >
> > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > > an entirely bad mind scheme around Qemu and DT.
> > >
> > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > > based on cpu, memory and devices specified at the command line.
> >
> > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > always use the QEMU generated DTB. I'm not entirely clear what a
> > qemu_arm and qemu_arm64 def targets are meant to be in this context.
>
> Agreed. We cannot include random device trees in U-Boot for devices
> that generate their own at run time or otherwise have the source of
> truth elsewhere.
Until we have a way of bringing in the u-boot.dtsi that people in QEMU
can agree on, I don't see an alternative. I will send a series for the
bloblist handoff next week and I think you will all see what I mean.
Perhaps all this will be easier a year or so, if we continue to make
progress on the devicetree validation/sharing stuff, but for now, this
seems like the only viable approach to me.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-27 18:34 ` Simon Glass
@ 2021-10-27 18:39 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:39 UTC (permalink / raw)
To: Simon Glass
Cc: Alex Bennée, François Ozog, Albert Aribaud,
Neil Armstrong, U-Boot Mailing List, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher,
Fabio Estevam, Peter Robinson, QEMU Developers
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote:
> Hi all,
>
> On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > >
> > > François Ozog <francois.ozog@linaro.org> writes:
> > >
> > > > Hi Simon
> > > >
> > > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > > > an entirely bad mind scheme around Qemu and DT.
> > > >
> > > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > > > based on cpu, memory and devices specified at the command line.
> > >
> > > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > > always use the QEMU generated DTB. I'm not entirely clear what a
> > > qemu_arm and qemu_arm64 def targets are meant to be in this context.
> >
> > Agreed. We cannot include random device trees in U-Boot for devices
> > that generate their own at run time or otherwise have the source of
> > truth elsewhere.
>
> Until we have a way of bringing in the u-boot.dtsi that people in QEMU
> can agree on, I don't see an alternative. I will send a series for the
> bloblist handoff next week and I think you will all see what I mean.
I think the alternative is that QEMU in U-Boot just can't be used for
certain features. Which is annoying in that it would be good to use it
to test certain feature, yes. It's generating a good and valid enough
dtb for Linux, so it should be good enough for us in general.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-27 18:39 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:39 UTC (permalink / raw)
To: Simon Glass
Cc: Heiko Schocher, François Ozog, Albert Aribaud,
Neil Armstrong, QEMU Developers, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
U-Boot Mailing List, Jagan Teki, Sean Anderson, Fabio Estevam,
Tuomas Tynkkynen, Alex Bennée, Peter Robinson
[-- Attachment #1: Type: text/plain, Size: 1673 bytes --]
On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote:
> Hi all,
>
> On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > >
> > > François Ozog <francois.ozog@linaro.org> writes:
> > >
> > > > Hi Simon
> > > >
> > > > The only place I could agree with this file presence is in the documentation directory, not in dts. It creates a mental picture for the reader
> > > > an entirely bad mind scheme around Qemu and DT.
> > > >
> > > > And even in a documentation directory I would place a bug warning: don’t use this with any kernel , Qemu generates a DT dynamically
> > > > based on cpu, memory and devices specified at the command line.
> > >
> > > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > > always use the QEMU generated DTB. I'm not entirely clear what a
> > > qemu_arm and qemu_arm64 def targets are meant to be in this context.
> >
> > Agreed. We cannot include random device trees in U-Boot for devices
> > that generate their own at run time or otherwise have the source of
> > truth elsewhere.
>
> Until we have a way of bringing in the u-boot.dtsi that people in QEMU
> can agree on, I don't see an alternative. I will send a series for the
> bloblist handoff next week and I think you will all see what I mean.
I think the alternative is that QEMU in U-Boot just can't be used for
certain features. Which is annoying in that it would be good to use it
to test certain feature, yes. It's generating a good and valid enough
dtb for Linux, so it should be good enough for us in general.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
2021-10-27 18:39 ` Tom Rini
@ 2021-10-27 19:45 ` Alex Bennée
-1 siblings, 0 replies; 164+ messages in thread
From: Alex Bennée @ 2021-10-27 19:45 UTC (permalink / raw)
To: Tom Rini
Cc: Simon Glass, François Ozog, Albert Aribaud, Neil Armstrong,
U-Boot Mailing List, Andre Przywara, Tim Harvey,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
Tuomas Tynkkynen, Jagan Teki, Sean Anderson, Heiko Schocher,
Fabio Estevam, Peter Robinson, QEMU Developers
There are QEMU targets that have fixed hardware which do rely on the
firmware to have a fixed view of the hardware. sbsa-ref is one such board
although there will be some versioning required for later levels.
On Wed, 27 Oct 2021, 19:39 Tom Rini, <trini@konsulko.com> wrote:
> On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > > >
> > > > François Ozog <francois.ozog@linaro.org> writes:
> > > >
> > > > > Hi Simon
> > > > >
> > > > > The only place I could agree with this file presence is in the
> documentation directory, not in dts. It creates a mental picture for the
> reader
> > > > > an entirely bad mind scheme around Qemu and DT.
> > > > >
> > > > > And even in a documentation directory I would place a bug warning:
> don’t use this with any kernel , Qemu generates a DT dynamically
> > > > > based on cpu, memory and devices specified at the command line.
> > > >
> > > > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > > > always use the QEMU generated DTB. I'm not entirely clear what a
> > > > qemu_arm and qemu_arm64 def targets are meant to be in this context.
> > >
> > > Agreed. We cannot include random device trees in U-Boot for devices
> > > that generate their own at run time or otherwise have the source of
> > > truth elsewhere.
> >
> > Until we have a way of bringing in the u-boot.dtsi that people in QEMU
> > can agree on, I don't see an alternative. I will send a series for the
> > bloblist handoff next week and I think you will all see what I mean.
>
> I think the alternative is that QEMU in U-Boot just can't be used for
> certain features. Which is annoying in that it would be good to use it
> to test certain feature, yes. It's generating a good and valid enough
> dtb for Linux, so it should be good enough for us in general.
>
> --
> Tom
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
@ 2021-10-27 19:45 ` Alex Bennée
0 siblings, 0 replies; 164+ messages in thread
From: Alex Bennée @ 2021-10-27 19:45 UTC (permalink / raw)
To: Tom Rini
Cc: Heiko Schocher, François Ozog, Albert Aribaud,
Neil Armstrong, QEMU Developers, Andre Przywara, Simon Glass,
Ilias Apalodimas, Christian Hewitt, Kever Yang, Rick Chen,
U-Boot Mailing List, Jagan Teki, Sean Anderson, Tuomas Tynkkynen,
Fabio Estevam, Tim Harvey, Peter Robinson
[-- Attachment #1: Type: text/plain, Size: 2034 bytes --]
There are QEMU targets that have fixed hardware which do rely on the
firmware to have a fixed view of the hardware. sbsa-ref is one such board
although there will be some versioning required for later levels.
On Wed, 27 Oct 2021, 19:39 Tom Rini, <trini@konsulko.com> wrote:
> On Wed, Oct 27, 2021 at 12:34:26PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Wed, 27 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote:
> > > >
> > > > François Ozog <francois.ozog@linaro.org> writes:
> > > >
> > > > > Hi Simon
> > > > >
> > > > > The only place I could agree with this file presence is in the
> documentation directory, not in dts. It creates a mental picture for the
> reader
> > > > > an entirely bad mind scheme around Qemu and DT.
> > > > >
> > > > > And even in a documentation directory I would place a bug warning:
> don’t use this with any kernel , Qemu generates a DT dynamically
> > > > > based on cpu, memory and devices specified at the command line.
> > > >
> > > > Certainly for the arm, aarch64 and riscv "virt" machines you should
> > > > always use the QEMU generated DTB. I'm not entirely clear what a
> > > > qemu_arm and qemu_arm64 def targets are meant to be in this context.
> > >
> > > Agreed. We cannot include random device trees in U-Boot for devices
> > > that generate their own at run time or otherwise have the source of
> > > truth elsewhere.
> >
> > Until we have a way of bringing in the u-boot.dtsi that people in QEMU
> > can agree on, I don't see an alternative. I will send a series for the
> > bloblist handoff next week and I think you will all see what I mean.
>
> I think the alternative is that QEMU in U-Boot just can't be used for
> certain features. Which is annoying in that it would be good to use it
> to test certain feature, yes. It's generating a good and valid enough
> dtb for Linux, so it should be good enough for us in general.
>
> --
> Tom
>
[-- Attachment #2: Type: text/html, Size: 2751 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, qemu-devel, Leo, David Abdurachmanov, Simon Glass,
Ilias Apalodimas, Rick Chen, Green Wan, Sean Anderson,
Heinrich Schuchardt, Zong Li, Tianrui Wei, Bin Meng,
Dimitri John Ledkov, Padmarao Begari
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 <sjg@chromium.org>
---
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..00000000000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
- */
-
-/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 00000000000..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 <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ 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@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts
new file mode 100644
index 00000000000..61bc084e280
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt64.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ 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 = "rv64imafdcsu";
+ mmu-type = "riscv,sv48";
+
+ 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@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index e77e3ed53a0..54953cd347b 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x80200000
diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
index 03787416f10..21ee08a643e 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
index b0e655be416..3909c9a15ad 100644
--- a/configs/qemu-riscv32_spl_defconfig
+++ b/configs/qemu-riscv32_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 1f8dc2d2053..303ad2d5f39 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
index bdcec1fdaba..62cdf91699f 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
index 9745c1a586a..34d88da41b0 100644
--- a/configs/qemu-riscv64_spl_defconfig
+++ b/configs/qemu-riscv64_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
@ 2021-10-13 1:01 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Bin Meng,
David Abdurachmanov, Dimitri John Ledkov, Green Wan,
Heinrich Schuchardt, Leo, Padmarao Begari, Rick Chen,
Sean Anderson, Tianrui Wei, Zong Li, qemu-devel
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 <sjg@chromium.org>
---
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..00000000000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
- */
-
-/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 00000000000..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 <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ 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@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts
new file mode 100644
index 00000000000..61bc084e280
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt64.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@10100000 {
+ dma-coherent;
+ reg = <0x00 0x10100000 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@20000000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x20000000 0x00 0x2000000
+ 0x00 0x22000000 0x00 0x2000000>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@10000000";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x8000000>;
+ };
+
+ 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 = "rv64imafdcsu";
+ mmu-type = "riscv,sv48";
+
+ 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@10000000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+ reg = <0x00 0x10000000 0x00 0x100>;
+ compatible = "ns16550a";
+ };
+
+ poweroff {
+ value = <0x5555>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-poweroff";
+ };
+
+ reboot {
+ value = <0x7777>;
+ offset = <0x00>;
+ regmap = <0x04>;
+ compatible = "syscon-reboot";
+ };
+
+ test@100000 {
+ phandle = <0x04>;
+ reg = <0x00 0x100000 0x00 0x1000>;
+ compatible = "sifive,test1\0sifive,test0\0syscon";
+ };
+
+ pci@30000000 {
+ interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
+ 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
+ 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
+ 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
+ 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
+ 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
+ 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
+ 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
+ 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
+ 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
+ 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
+ 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x3000000 0x00 0x10000 0x2000000
+ 0x00 0x40000000 0x00 0x40000000
+ 0x00 0x40000000 0x3000000 0x03
+ 0x00 0x03 0x00 0x01
+ 0x00>;
+ reg = <0x00 0x30000000 0x00 0x10000000>;
+ dma-coherent;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ device_type = "pci";
+ compatible = "pci-host-ecam-generic";
+ #size-cells = <0x02>;
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x03>;
+ };
+
+ virtio_mmio@10008000 {
+ interrupts = <0x08>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10008000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10007000 {
+ interrupts = <0x07>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10007000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10006000 {
+ interrupts = <0x06>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10006000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10005000 {
+ interrupts = <0x05>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10005000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10004000 {
+ interrupts = <0x04>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10004000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10003000 {
+ interrupts = <0x03>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10003000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10002000 {
+ interrupts = <0x02>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10002000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@10001000 {
+ interrupts = <0x01>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x10001000 0x00 0x1000>;
+ compatible = "virtio,mmio";
+ };
+
+ plic@c000000 {
+ phandle = <0x03>;
+ riscv,ndev = <0x35>;
+ reg = <0x00 0xc000000 0x00 0x210000>;
+ interrupts-extended = <0x02 0x0b 0x02 0x09>;
+ interrupt-controller;
+ compatible = "sifive,plic-1.0.0\0riscv,plic0";
+ #interrupt-cells = <0x01>;
+ #address-cells = <0x00>;
+ };
+
+ clint@2000000 {
+ interrupts-extended = <0x02 0x03 0x02 0x07>;
+ reg = <0x00 0x2000000 0x00 0x10000>;
+ compatible = "sifive,clint0\0riscv,clint0";
+ };
+ };
+};
diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
index e77e3ed53a0..54953cd347b 100644
--- a/configs/qemu-riscv32_defconfig
+++ b/configs/qemu-riscv32_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x80200000
diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
index 03787416f10..21ee08a643e 100644
--- a/configs/qemu-riscv32_smode_defconfig
+++ b/configs/qemu-riscv32_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
index b0e655be416..3909c9a15ad 100644
--- a/configs/qemu-riscv32_spl_defconfig
+++ b/configs/qemu-riscv32_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
index 1f8dc2d2053..303ad2d5f39 100644
--- a/configs/qemu-riscv64_defconfig
+++ b/configs/qemu-riscv64_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_DISTRO_DEFAULTS=y
diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
index bdcec1fdaba..62cdf91699f 100644
--- a/configs/qemu-riscv64_smode_defconfig
+++ b/configs/qemu-riscv64_smode_defconfig
@@ -2,6 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
CONFIG_RISCV_SMODE=y
diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
index 9745c1a586a..34d88da41b0 100644
--- a/configs/qemu-riscv64_spl_defconfig
+++ b/configs/qemu-riscv64_spl_defconfig
@@ -2,7 +2,7 @@ CONFIG_RISCV=y
CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x20000
CONFIG_SYS_MALLOC_LEN=0x800000
-CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
+CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
CONFIG_SPL=y
CONFIG_TARGET_QEMU_VIRT=y
CONFIG_ARCH_RV64I=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 4:21 ` Heinrich Schuchardt
-1 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-13 4:21 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, Ilias Apalodimas, Bin Meng, David Abdurachmanov,
Dimitri John Ledkov, Green Wan, Leo, Padmarao Begari, Rick Chen,
Sean Anderson, Tianrui Wei, Zong Li, qemu-devel,
U-Boot Mailing List
On 10/13/21 03:01, Simon Glass wrote:
> 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.
>
You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
complete patchsets instead of selected patches which cannot be reviewed
without the context.
Which devices exist depends on the QEMU comannd line.
The files you create here do neither reflect the superset of all QEMU
settings nor the minimum set. They do not include all devices supported
on QEMU by U-Boot either.
You cannot assume that the values in this patch will match values used
by the next invocation of QEMU.
Hence it is totally unclear what this patch might be good for.
Best regards
Heinrich
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> 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..00000000000
> --- a/arch/riscv/dts/qemu-virt.dts
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
> - */
> -
> -/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 00000000000..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 <bmeng.cn@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "binman.dtsi"
> +
> +/ {
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> + compatible = "riscv-virtio";
> + model = "riscv-virtio,qemu";
> +
> + fw-cfg@10100000 {
> + dma-coherent;
> + reg = <0x00 0x10100000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + flash@20000000 {
> + bank-width = <0x04>;
> + reg = <0x00 0x20000000 0x00 0x2000000
> + 0x00 0x22000000 0x00 0x2000000>;
> + compatible = "cfi-flash";
> + };
> +
> + chosen {
> + bootargs = [00];
> + stdout-path = "/soc/uart@10000000";
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00 0x80000000 0x00 0x8000000>;
> + };
> +
> + 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@10000000 {
> + interrupts = <0x0a>;
> + interrupt-parent = <0x03>;
> + clock-frequency = <0x384000>;
> + reg = <0x00 0x10000000 0x00 0x100>;
> + compatible = "ns16550a";
> + };
> +
> + poweroff {
> + value = <0x5555>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-poweroff";
> + };
> +
> + reboot {
> + value = <0x7777>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-reboot";
> + };
> +
> + test@100000 {
> + phandle = <0x04>;
> + reg = <0x00 0x100000 0x00 0x1000>;
> + compatible = "sifive,test1\0sifive,test0\0syscon";
> + };
> +
> + pci@30000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
> + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
> + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
> + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
> + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
> + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
> + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
> + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
> + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
> + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
> + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
> + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3000000 0x00 0x10000 0x2000000
> + 0x00 0x40000000 0x00 0x40000000
> + 0x00 0x40000000 0x3000000 0x03
> + 0x00 0x03 0x00 0x01
> + 0x00>;
> + reg = <0x00 0x30000000 0x00 0x10000000>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + #size-cells = <0x02>;
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x03>;
> + };
> +
> + virtio_mmio@10008000 {
> + interrupts = <0x08>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10008000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10007000 {
> + interrupts = <0x07>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10007000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10006000 {
> + interrupts = <0x06>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10006000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10005000 {
> + interrupts = <0x05>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10005000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10004000 {
> + interrupts = <0x04>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10004000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10003000 {
> + interrupts = <0x03>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10003000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10002000 {
> + interrupts = <0x02>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10002000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10001000 {
> + interrupts = <0x01>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10001000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + plic@c000000 {
> + phandle = <0x03>;
> + riscv,ndev = <0x35>;
> + reg = <0x00 0xc000000 0x00 0x210000>;
> + interrupts-extended = <0x02 0x0b 0x02 0x09>;
> + interrupt-controller;
> + compatible = "sifive,plic-1.0.0\0riscv,plic0";
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x00>;
> + };
> +
> + clint@2000000 {
> + interrupts-extended = <0x02 0x03 0x02 0x07>;
> + reg = <0x00 0x2000000 0x00 0x10000>;
> + compatible = "sifive,clint0\0riscv,clint0";
> + };
> + };
> +};
> diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts
> new file mode 100644
> index 00000000000..61bc084e280
> --- /dev/null
> +++ b/arch/riscv/dts/qemu-virt64.dts
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "binman.dtsi"
> +
> +/ {
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> + compatible = "riscv-virtio";
> + model = "riscv-virtio,qemu";
> +
> + fw-cfg@10100000 {
> + dma-coherent;
> + reg = <0x00 0x10100000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + flash@20000000 {
> + bank-width = <0x04>;
> + reg = <0x00 0x20000000 0x00 0x2000000
> + 0x00 0x22000000 0x00 0x2000000>;
> + compatible = "cfi-flash";
> + };
> +
> + chosen {
> + bootargs = [00];
> + stdout-path = "/soc/uart@10000000";
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00 0x80000000 0x00 0x8000000>;
> + };
> +
> + 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 = "rv64imafdcsu";
> + mmu-type = "riscv,sv48";
> +
> + 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@10000000 {
> + interrupts = <0x0a>;
> + interrupt-parent = <0x03>;
> + clock-frequency = <0x384000>;
> + reg = <0x00 0x10000000 0x00 0x100>;
> + compatible = "ns16550a";
> + };
> +
> + poweroff {
> + value = <0x5555>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-poweroff";
> + };
> +
> + reboot {
> + value = <0x7777>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-reboot";
> + };
> +
> + test@100000 {
> + phandle = <0x04>;
> + reg = <0x00 0x100000 0x00 0x1000>;
> + compatible = "sifive,test1\0sifive,test0\0syscon";
> + };
> +
> + pci@30000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
> + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
> + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
> + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
> + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
> + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
> + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
> + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
> + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
> + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
> + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
> + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3000000 0x00 0x10000 0x2000000
> + 0x00 0x40000000 0x00 0x40000000
> + 0x00 0x40000000 0x3000000 0x03
> + 0x00 0x03 0x00 0x01
> + 0x00>;
> + reg = <0x00 0x30000000 0x00 0x10000000>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + #size-cells = <0x02>;
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x03>;
> + };
> +
> + virtio_mmio@10008000 {
> + interrupts = <0x08>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10008000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10007000 {
> + interrupts = <0x07>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10007000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10006000 {
> + interrupts = <0x06>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10006000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10005000 {
> + interrupts = <0x05>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10005000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10004000 {
> + interrupts = <0x04>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10004000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10003000 {
> + interrupts = <0x03>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10003000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10002000 {
> + interrupts = <0x02>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10002000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10001000 {
> + interrupts = <0x01>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10001000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + plic@c000000 {
> + phandle = <0x03>;
> + riscv,ndev = <0x35>;
> + reg = <0x00 0xc000000 0x00 0x210000>;
> + interrupts-extended = <0x02 0x0b 0x02 0x09>;
> + interrupt-controller;
> + compatible = "sifive,plic-1.0.0\0riscv,plic0";
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x00>;
> + };
> +
> + clint@2000000 {
> + interrupts-extended = <0x02 0x03 0x02 0x07>;
> + reg = <0x00 0x2000000 0x00 0x10000>;
> + compatible = "sifive,clint0\0riscv,clint0";
> + };
> + };
> +};
> diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
> index e77e3ed53a0..54953cd347b 100644
> --- a/configs/qemu-riscv32_defconfig
> +++ b/configs/qemu-riscv32_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x80200000
> diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
> index 03787416f10..21ee08a643e 100644
> --- a/configs/qemu-riscv32_smode_defconfig
> +++ b/configs/qemu-riscv32_smode_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_RISCV_SMODE=y
> CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
> index b0e655be416..3909c9a15ad 100644
> --- a/configs/qemu-riscv32_spl_defconfig
> +++ b/configs/qemu-riscv32_spl_defconfig
> @@ -2,7 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_SPL=y
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_RISCV_SMODE=y
> diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
> index 1f8dc2d2053..303ad2d5f39 100644
> --- a/configs/qemu-riscv64_defconfig
> +++ b/configs/qemu-riscv64_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
> CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
> index bdcec1fdaba..62cdf91699f 100644
> --- a/configs/qemu-riscv64_smode_defconfig
> +++ b/configs/qemu-riscv64_smode_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
> CONFIG_RISCV_SMODE=y
> diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
> index 9745c1a586a..34d88da41b0 100644
> --- a/configs/qemu-riscv64_spl_defconfig
> +++ b/configs/qemu-riscv64_spl_defconfig
> @@ -2,7 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_SPL=y
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
@ 2021-10-13 4:21 ` Heinrich Schuchardt
0 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-13 4:21 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, qemu-devel, Leo, David Abdurachmanov, Ilias Apalodimas,
Rick Chen, Green Wan, Sean Anderson, U-Boot Mailing List,
Zong Li, Tianrui Wei, Bin Meng, Dimitri John Ledkov,
Padmarao Begari
On 10/13/21 03:01, Simon Glass wrote:
> 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.
>
You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
complete patchsets instead of selected patches which cannot be reviewed
without the context.
Which devices exist depends on the QEMU comannd line.
The files you create here do neither reflect the superset of all QEMU
settings nor the minimum set. They do not include all devices supported
on QEMU by U-Boot either.
You cannot assume that the values in this patch will match values used
by the next invocation of QEMU.
Hence it is totally unclear what this patch might be good for.
Best regards
Heinrich
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> 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..00000000000
> --- a/arch/riscv/dts/qemu-virt.dts
> +++ /dev/null
> @@ -1,8 +0,0 @@
> -// SPDX-License-Identifier: GPL-2.0+
> -/*
> - * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
> - */
> -
> -/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 00000000000..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 <bmeng.cn@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "binman.dtsi"
> +
> +/ {
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> + compatible = "riscv-virtio";
> + model = "riscv-virtio,qemu";
> +
> + fw-cfg@10100000 {
> + dma-coherent;
> + reg = <0x00 0x10100000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + flash@20000000 {
> + bank-width = <0x04>;
> + reg = <0x00 0x20000000 0x00 0x2000000
> + 0x00 0x22000000 0x00 0x2000000>;
> + compatible = "cfi-flash";
> + };
> +
> + chosen {
> + bootargs = [00];
> + stdout-path = "/soc/uart@10000000";
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00 0x80000000 0x00 0x8000000>;
> + };
> +
> + 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@10000000 {
> + interrupts = <0x0a>;
> + interrupt-parent = <0x03>;
> + clock-frequency = <0x384000>;
> + reg = <0x00 0x10000000 0x00 0x100>;
> + compatible = "ns16550a";
> + };
> +
> + poweroff {
> + value = <0x5555>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-poweroff";
> + };
> +
> + reboot {
> + value = <0x7777>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-reboot";
> + };
> +
> + test@100000 {
> + phandle = <0x04>;
> + reg = <0x00 0x100000 0x00 0x1000>;
> + compatible = "sifive,test1\0sifive,test0\0syscon";
> + };
> +
> + pci@30000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
> + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
> + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
> + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
> + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
> + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
> + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
> + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
> + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
> + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
> + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
> + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3000000 0x00 0x10000 0x2000000
> + 0x00 0x40000000 0x00 0x40000000
> + 0x00 0x40000000 0x3000000 0x03
> + 0x00 0x03 0x00 0x01
> + 0x00>;
> + reg = <0x00 0x30000000 0x00 0x10000000>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + #size-cells = <0x02>;
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x03>;
> + };
> +
> + virtio_mmio@10008000 {
> + interrupts = <0x08>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10008000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10007000 {
> + interrupts = <0x07>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10007000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10006000 {
> + interrupts = <0x06>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10006000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10005000 {
> + interrupts = <0x05>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10005000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10004000 {
> + interrupts = <0x04>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10004000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10003000 {
> + interrupts = <0x03>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10003000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10002000 {
> + interrupts = <0x02>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10002000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10001000 {
> + interrupts = <0x01>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10001000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + plic@c000000 {
> + phandle = <0x03>;
> + riscv,ndev = <0x35>;
> + reg = <0x00 0xc000000 0x00 0x210000>;
> + interrupts-extended = <0x02 0x0b 0x02 0x09>;
> + interrupt-controller;
> + compatible = "sifive,plic-1.0.0\0riscv,plic0";
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x00>;
> + };
> +
> + clint@2000000 {
> + interrupts-extended = <0x02 0x03 0x02 0x07>;
> + reg = <0x00 0x2000000 0x00 0x10000>;
> + compatible = "sifive,clint0\0riscv,clint0";
> + };
> + };
> +};
> diff --git a/arch/riscv/dts/qemu-virt64.dts b/arch/riscv/dts/qemu-virt64.dts
> new file mode 100644
> index 00000000000..61bc084e280
> --- /dev/null
> +++ b/arch/riscv/dts/qemu-virt64.dts
> @@ -0,0 +1,217 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Copyright (C) 2021, Bin Meng <bmeng.cn@gmail.com>
> + */
> +
> +/dts-v1/;
> +
> +#include "binman.dtsi"
> +
> +/ {
> + #address-cells = <0x02>;
> + #size-cells = <0x02>;
> + compatible = "riscv-virtio";
> + model = "riscv-virtio,qemu";
> +
> + fw-cfg@10100000 {
> + dma-coherent;
> + reg = <0x00 0x10100000 0x00 0x18>;
> + compatible = "qemu,fw-cfg-mmio";
> + };
> +
> + flash@20000000 {
> + bank-width = <0x04>;
> + reg = <0x00 0x20000000 0x00 0x2000000
> + 0x00 0x22000000 0x00 0x2000000>;
> + compatible = "cfi-flash";
> + };
> +
> + chosen {
> + bootargs = [00];
> + stdout-path = "/soc/uart@10000000";
> + };
> +
> + memory@80000000 {
> + device_type = "memory";
> + reg = <0x00 0x80000000 0x00 0x8000000>;
> + };
> +
> + 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 = "rv64imafdcsu";
> + mmu-type = "riscv,sv48";
> +
> + 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@10000000 {
> + interrupts = <0x0a>;
> + interrupt-parent = <0x03>;
> + clock-frequency = <0x384000>;
> + reg = <0x00 0x10000000 0x00 0x100>;
> + compatible = "ns16550a";
> + };
> +
> + poweroff {
> + value = <0x5555>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-poweroff";
> + };
> +
> + reboot {
> + value = <0x7777>;
> + offset = <0x00>;
> + regmap = <0x04>;
> + compatible = "syscon-reboot";
> + };
> +
> + test@100000 {
> + phandle = <0x04>;
> + reg = <0x00 0x100000 0x00 0x1000>;
> + compatible = "sifive,test1\0sifive,test0\0syscon";
> + };
> +
> + pci@30000000 {
> + interrupt-map-mask = <0x1800 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01 0x03 0x20 0x00 0x00
> + 0x00 0x02 0x03 0x21 0x00 0x00 0x00 0x03
> + 0x03 0x22 0x00 0x00 0x00 0x04 0x03 0x23
> + 0x800 0x00 0x00 0x01 0x03 0x21 0x800 0x00
> + 0x00 0x02 0x03 0x22 0x800 0x00 0x00 0x03
> + 0x03 0x23 0x800 0x00 0x00 0x04 0x03 0x20
> + 0x1000 0x00 0x00 0x01 0x03 0x22 0x1000 0x00
> + 0x00 0x02 0x03 0x23 0x1000 0x00 0x00 0x03
> + 0x03 0x20 0x1000 0x00 0x00 0x04 0x03 0x21
> + 0x1800 0x00 0x00 0x01 0x03 0x23 0x1800 0x00
> + 0x00 0x02 0x03 0x20 0x1800 0x00 0x00 0x03
> + 0x03 0x21 0x1800 0x00 0x00 0x04 0x03 0x22>;
> + ranges = <0x1000000 0x00 0x00 0x00
> + 0x3000000 0x00 0x10000 0x2000000
> + 0x00 0x40000000 0x00 0x40000000
> + 0x00 0x40000000 0x3000000 0x03
> + 0x00 0x03 0x00 0x01
> + 0x00>;
> + reg = <0x00 0x30000000 0x00 0x10000000>;
> + dma-coherent;
> + bus-range = <0x00 0xff>;
> + linux,pci-domain = <0x00>;
> + device_type = "pci";
> + compatible = "pci-host-ecam-generic";
> + #size-cells = <0x02>;
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x03>;
> + };
> +
> + virtio_mmio@10008000 {
> + interrupts = <0x08>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10008000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10007000 {
> + interrupts = <0x07>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10007000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10006000 {
> + interrupts = <0x06>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10006000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10005000 {
> + interrupts = <0x05>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10005000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10004000 {
> + interrupts = <0x04>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10004000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10003000 {
> + interrupts = <0x03>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10003000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10002000 {
> + interrupts = <0x02>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10002000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + virtio_mmio@10001000 {
> + interrupts = <0x01>;
> + interrupt-parent = <0x03>;
> + reg = <0x00 0x10001000 0x00 0x1000>;
> + compatible = "virtio,mmio";
> + };
> +
> + plic@c000000 {
> + phandle = <0x03>;
> + riscv,ndev = <0x35>;
> + reg = <0x00 0xc000000 0x00 0x210000>;
> + interrupts-extended = <0x02 0x0b 0x02 0x09>;
> + interrupt-controller;
> + compatible = "sifive,plic-1.0.0\0riscv,plic0";
> + #interrupt-cells = <0x01>;
> + #address-cells = <0x00>;
> + };
> +
> + clint@2000000 {
> + interrupts-extended = <0x02 0x03 0x02 0x07>;
> + reg = <0x00 0x2000000 0x00 0x10000>;
> + compatible = "sifive,clint0\0riscv,clint0";
> + };
> + };
> +};
> diff --git a/configs/qemu-riscv32_defconfig b/configs/qemu-riscv32_defconfig
> index e77e3ed53a0..54953cd347b 100644
> --- a/configs/qemu-riscv32_defconfig
> +++ b/configs/qemu-riscv32_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x80200000
> diff --git a/configs/qemu-riscv32_smode_defconfig b/configs/qemu-riscv32_smode_defconfig
> index 03787416f10..21ee08a643e 100644
> --- a/configs/qemu-riscv32_smode_defconfig
> +++ b/configs/qemu-riscv32_smode_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_RISCV_SMODE=y
> CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/qemu-riscv32_spl_defconfig b/configs/qemu-riscv32_spl_defconfig
> index b0e655be416..3909c9a15ad 100644
> --- a/configs/qemu-riscv32_spl_defconfig
> +++ b/configs/qemu-riscv32_spl_defconfig
> @@ -2,7 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt32"
> CONFIG_SPL=y
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_RISCV_SMODE=y
> diff --git a/configs/qemu-riscv64_defconfig b/configs/qemu-riscv64_defconfig
> index 1f8dc2d2053..303ad2d5f39 100644
> --- a/configs/qemu-riscv64_defconfig
> +++ b/configs/qemu-riscv64_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
> CONFIG_DISTRO_DEFAULTS=y
> diff --git a/configs/qemu-riscv64_smode_defconfig b/configs/qemu-riscv64_smode_defconfig
> index bdcec1fdaba..62cdf91699f 100644
> --- a/configs/qemu-riscv64_smode_defconfig
> +++ b/configs/qemu-riscv64_smode_defconfig
> @@ -2,6 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
> CONFIG_RISCV_SMODE=y
> diff --git a/configs/qemu-riscv64_spl_defconfig b/configs/qemu-riscv64_spl_defconfig
> index 9745c1a586a..34d88da41b0 100644
> --- a/configs/qemu-riscv64_spl_defconfig
> +++ b/configs/qemu-riscv64_spl_defconfig
> @@ -2,7 +2,7 @@ CONFIG_RISCV=y
> CONFIG_NR_DRAM_BANKS=1
> CONFIG_ENV_SIZE=0x20000
> CONFIG_SYS_MALLOC_LEN=0x800000
> -CONFIG_DEFAULT_DEVICE_TREE="qemu-virt"
> +CONFIG_DEFAULT_DEVICE_TREE="qemu-virt64"
> CONFIG_SPL=y
> CONFIG_TARGET_QEMU_VIRT=y
> CONFIG_ARCH_RV64I=y
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4
2021-10-13 1:01 ` Simon Glass
` (6 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
2021-10-13 1:24 ` François Ozog
-1 siblings, 1 reply; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Christian Hewitt, Fabio Estevam, Heiko Schocher,
Jagan Teki, Kever Yang, Matthias Brugger, Neil Armstrong,
Peter Robinson, Stephen Warren, Stephen Warren, Tim Harvey
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 <sjg@chromium.org>
---
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 52c586f3974..efc01a70bf2 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1062,7 +1062,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 00000000000..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/ 0x0000000000000000 0x0000000000001000;
+/ {
+ 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@7e100000";
+ random = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e200000";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ mmc0 = "/soc/emmc2@7e340000";
+ 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@7e300000";
+ mmc1 = "/soc/mmcnr@7e300000";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ usb = "/soc/usb@7e980000";
+ leds = "/leds";
+ fb = "/soc/fb";
+ thermal = "/soc/thermal@7d5d2200";
+ axiperf = "/soc/axiperf";
+ mmc2 = "/soc/mmc@7e202000";
+ ethernet0 = "/scb/genet@7d580000";
+ };
+
+ chosen {
+ bootargs = "8250.nr_uarts=1 cma=64M";
+ };
+
+ thermal-zones {
+
+ cpu-thermal {
+ polling-delay-passive = <0x00>;
+ polling-delay = <0x3e8>;
+ thermal-sensors = <0x02>;
+ coefficients = <0xfffffe19 0x641b8>;
+ phandle = <0x2f>;
+
+ cooling-maps {
+ };
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7e000000 0x00 0xfe000000 0x1800000
+ 0x7c000000 0x00 0xfc000000 0x2000000
+ 0x40000000 0x00 0xff800000 0x800000>;
+ dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>;
+ 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";
+ #dma-cells = <0x01>;
+ brcm,dma-channel-mask = <0x7ef5>;
+ phandle = <0x0a>;
+ };
+
+ watchdog@7e100000 {
+ compatible = "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";
+ #power-domain-cells = <0x01>;
+ #reset-cells = <0x01>;
+ reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000 0x20>;
+ clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>;
+ clock-names = "v3d\0peri_image\0h264\0isp";
+ system-power-controller;
+ phandle = <0x1c>;
+ };
+
+ cprman@7e101000 {
+ compatible = "brcm,bcm2838-cprman";
+ #clock-cells = <0x01>;
+ reg = <0x7e101000 0x2000>;
+ clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06
+ 0x00 0x06 0x01 0x06 0x02>;
+ firmware = <0x07>;
+ phandle = <0x03>;
+ };
+
+ rng@7e104000 {
+ compatible = "brcm,bcm2838-rng200";
+ reg = <0x7e104000 0x10>;
+ interrupts = <0x00 0x7d 0x04>;
+ phandle = <0x26>;
+ };
+
+ mailbox@7e00b880 {
+ compatible = "brcm,bcm2835-mbox";
+ reg = <0x7e00b880 0x40>;
+ interrupts = <0x00 0x21 0x04>;
+ #mbox-cells = <0x00>;
+ phandle = <0x1a>;
+ };
+
+ gpio: gpio@7e200000 {
+ compatible = "brcm,bcm2835-gpio";
+ reg = <0x7e200000 0xb4>;
+ interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x02>;
+ phandle = <0x0f>;
+
+ dpi_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03 0x04
+ 0x05 0x06 0x07 0x08 0x09
+ 0x0a 0x0b 0x0c 0x0d 0x0e
+ 0x0f 0x10 0x11 0x12 0x13
+ 0x14 0x15 0x16 0x17 0x18
+ 0x19 0x1a 0x1b>;
+ brcm,function = <0x06>;
+ phandle = <0x32>;
+ };
+
+ emmc_gpio22 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x07>;
+ phandle = <0x33>;
+ };
+
+ emmc_gpio34 {
+ brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
+ phandle = <0x34>;
+ };
+
+ emmc_gpio48 {
+ brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
+ brcm,function = <0x07>;
+ phandle = <0x35>;
+ };
+
+ gpclk0_gpio4 {
+ brcm,pins = <0x04>;
+ brcm,function = <0x04>;
+ phandle = <0x36>;
+ };
+
+ gpclk1_gpio5 {
+ brcm,pins = <0x05>;
+ brcm,function = <0x04>;
+ phandle = <0x37>;
+ };
+
+ gpclk1_gpio42 {
+ brcm,pins = <0x2a>;
+ brcm,function = <0x04>;
+ phandle = <0x38>;
+ };
+
+ gpclk1_gpio44 {
+ brcm,pins = <0x2c>;
+ brcm,function = <0x04>;
+ phandle = <0x39>;
+ };
+
+ gpclk2_gpio6 {
+ brcm,pins = <0x06>;
+ brcm,function = <0x04>;
+ phandle = <0x3a>;
+ };
+
+ gpclk2_gpio43 {
+ brcm,pins = <0x2b>;
+ brcm,function = <0x04>;
+ brcm,pull = <0x00>;
+ phandle = <0x3b>;
+ };
+
+ i2c0_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x04>;
+ phandle = <0x3c>;
+ };
+
+ i2c0_gpio28 {
+ brcm,pins = <0x1c 0x1d>;
+ brcm,function = <0x04>;
+ phandle = <0x3d>;
+ };
+
+ i2c0_gpio44 {
+ brcm,pins = <0x2c 0x2d>;
+ brcm,function = <0x05>;
+ phandle = <0x3e>;
+ };
+
+ i2c1_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x04>;
+ phandle = <0x3f>;
+ };
+
+ i2c1_gpio44 {
+ brcm,pins = <0x2c 0x2d>;
+ brcm,function = <0x06>;
+ phandle = <0x40>;
+ };
+
+ jtag_gpio22 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x03>;
+ phandle = <0x41>;
+ };
+
+ pcm_gpio18 {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x04>;
+ phandle = <0x42>;
+ };
+
+ pcm_gpio28 {
+ brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
+ brcm,function = <0x06>;
+ phandle = <0x43>;
+ };
+
+ pwm0_gpio12 {
+ brcm,pins = <0x0c>;
+ brcm,function = <0x04>;
+ phandle = <0x44>;
+ };
+
+ pwm0_gpio18 {
+ brcm,pins = <0x12>;
+ brcm,function = <0x02>;
+ phandle = <0x45>;
+ };
+
+ pwm0_gpio40 {
+ brcm,pins = <0x28>;
+ brcm,function = <0x04>;
+ phandle = <0x46>;
+ };
+
+ pwm1_gpio13 {
+ brcm,pins = <0x0d>;
+ brcm,function = <0x04>;
+ phandle = <0x47>;
+ };
+
+ pwm1_gpio19 {
+ brcm,pins = <0x13>;
+ brcm,function = <0x02>;
+ phandle = <0x48>;
+ };
+
+ pwm1_gpio41 {
+ brcm,pins = <0x29>;
+ brcm,function = <0x04>;
+ phandle = <0x49>;
+ };
+
+ pwm1_gpio45 {
+ brcm,pins = <0x2d>;
+ brcm,function = <0x04>;
+ phandle = <0x4a>;
+ };
+
+ sdhost_gpio48 {
+ brcm,pins = <0x16 0x17 0x18 0x19 0x1a 0x1b>;
+ brcm,function = <0x04>;
+ phandle = <0x0b>;
+ };
+
+ spi0_gpio7 {
+ brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>;
+ brcm,function = <0x04>;
+ phandle = <0x4b>;
+ };
+
+ spi0_gpio35 {
+ brcm,pins = <0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x04>;
+ phandle = <0x4c>;
+ };
+
+ spi1_gpio16 {
+ brcm,pins = <0x10 0x11 0x12 0x13 0x14 0x15>;
+ brcm,function = <0x03>;
+ phandle = <0x4d>;
+ };
+
+ spi2_gpio40 {
+ brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c 0x2d>;
+ brcm,function = <0x03>;
+ phandle = <0x4e>;
+ };
+
+ uart0_gpio14: uart0_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x04>;
+ phandle = <0x4f>;
+ };
+
+ uart0: uart0_ctsrts_gpio16 {
+ brcm,pins = <0x10 0x11>;
+ brcm,function = <0x07>;
+ phandle = <0x50>;
+ };
+
+ uart0_ctsrts_gpio30 {
+ brcm,pins = <0x1e 0x1f>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x51>;
+ };
+
+ uart0_gpio32 {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x52>;
+ };
+
+ uart0_gpio36 {
+ brcm,pins = <0x24 0x25>;
+ brcm,function = <0x06>;
+ phandle = <0x53>;
+ };
+
+ uart0_ctsrts_gpio38 {
+ brcm,pins = <0x26 0x27>;
+ brcm,function = <0x06>;
+ phandle = <0x54>;
+ };
+
+ uart1_gpio14: uart1_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x02>;
+ phandle = <0x55>;
+ };
+
+ uart1: uart1_ctsrts_gpio16 {
+ brcm,pins = <0x10 0x11>;
+ brcm,function = <0x02>;
+ phandle = <0x56>;
+ };
+
+ uart1_gpio32 {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x02>;
+ phandle = <0x57>;
+ };
+
+ uart1_ctsrts_gpio30 {
+ brcm,pins = <0x1e 0x1f>;
+ brcm,function = <0x02>;
+ phandle = <0x58>;
+ };
+
+ uart1_gpio40 {
+ brcm,pins = <0x28 0x29>;
+ brcm,function = <0x02>;
+ phandle = <0x59>;
+ };
+
+ uart1_ctsrts_gpio42 {
+ brcm,pins = <0x2a 0x2b>;
+ brcm,function = <0x02>;
+ phandle = <0x5a>;
+ };
+
+ gpclk0_gpio49 {
+ brcm,pins = <0x31>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5b>;
+ };
+
+ gpclk1_gpio50 {
+ brcm,pins = <0x32>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5c>;
+ };
+
+ gpclk2_gpio51 {
+ brcm,pins = <0x33>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x5d>;
+ };
+
+ i2c0_gpio46 {
+ brcm,pins = <0x2e 0x2f>;
+ brcm,function = <0x04>;
+ phandle = <0x5e>;
+ };
+
+ i2c1_gpio46 {
+ brcm,pins = <0x2e 0x2f>;
+ brcm,function = <0x05>;
+ phandle = <0x5f>;
+ };
+
+ i2c3_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x02>;
+ phandle = <0x60>;
+ };
+
+ i2c3_gpio4 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x02>;
+ phandle = <0x61>;
+ };
+
+ i2c4_gpio6 {
+ brcm,pins = <0x06 0x07>;
+ brcm,function = <0x02>;
+ phandle = <0x62>;
+ };
+
+ i2c4_gpio8 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x02>;
+ phandle = <0x63>;
+ };
+
+ i2c5_gpio10 {
+ brcm,pins = <0x0a 0x0b>;
+ brcm,function = <0x02>;
+ phandle = <0x64>;
+ };
+
+ i2c5_gpio12 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x02>;
+ phandle = <0x65>;
+ };
+
+ i2c6_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x02>;
+ phandle = <0x66>;
+ };
+
+ i2c6_gpio22 {
+ brcm,pins = <0x16 0x17>;
+ brcm,function = <0x02>;
+ phandle = <0x67>;
+ };
+
+ i2c_slave_gpio8 {
+ brcm,pins = <0x08 0x09 0x0a 0x0b>;
+ brcm,function = <0x07>;
+ phandle = <0x68>;
+ };
+
+ jtag_gpio48 {
+ brcm,pins = <0x30 0x31 0x32 0x33 0x34 0x35>;
+ brcm,function = <0x03>;
+ phandle = <0x69>;
+ };
+
+ mii_gpio28 {
+ brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
+ brcm,function = <0x03>;
+ phandle = <0x6a>;
+ };
+
+ mii_gpio36 {
+ brcm,pins = <0x24 0x25 0x26 0x27>;
+ brcm,function = <0x02>;
+ phandle = <0x6b>;
+ };
+
+ pcm_gpio50 {
+ brcm,pins = <0x32 0x33 0x34 0x35>;
+ brcm,function = <0x06>;
+ phandle = <0x6c>;
+ };
+
+ pwm0_gpio52 {
+ brcm,pins = <0x34>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x6d>;
+ };
+
+ pwm1_gpio53 {
+ brcm,pins = <0x35>;
+ brcm,function = <0x05>;
+ brcm,pull = <0x00>;
+ phandle = <0x6e>;
+ };
+
+ rgmii_gpio35 {
+ brcm,pins = <0x23 0x24>;
+ brcm,function = <0x03>;
+ phandle = <0x6f>;
+ };
+
+ rgmii_irq_gpio34 {
+ brcm,pins = <0x22>;
+ brcm,function = <0x02>;
+ phandle = <0x70>;
+ };
+
+ rgmii_irq_gpio39 {
+ brcm,pins = <0x27>;
+ brcm,function = <0x03>;
+ phandle = <0x71>;
+ };
+
+ rgmii_mdio_gpio28 {
+ brcm,pins = <0x1c 0x1d>;
+ brcm,function = <0x02>;
+ phandle = <0x72>;
+ };
+
+ rgmii_mdio_gpio37 {
+ brcm,pins = <0x25 0x26>;
+ brcm,function = <0x03>;
+ phandle = <0x73>;
+ };
+
+ spi0_gpio46 {
+ brcm,pins = <0x2e 0x2f 0x30 0x31>;
+ brcm,function = <0x06>;
+ phandle = <0x74>;
+ };
+
+ spi2_gpio46 {
+ brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>;
+ brcm,function = <0x02>;
+ phandle = <0x75>;
+ };
+
+ spi3_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03>;
+ brcm,function = <0x07>;
+ phandle = <0x76>;
+ };
+
+ spi4_gpio4 {
+ brcm,pins = <0x04 0x05 0x06 0x07>;
+ brcm,function = <0x07>;
+ phandle = <0x77>;
+ };
+
+ spi5_gpio12 {
+ brcm,pins = <0x0c 0x0d 0x0e 0x0f>;
+ brcm,function = <0x07>;
+ phandle = <0x78>;
+ };
+
+ spi6_gpio18 {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x07>;
+ phandle = <0x79>;
+ };
+
+ uart2_gpio0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7a>;
+ };
+
+ uart2_ctsrts_gpio2 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7b>;
+ };
+
+ uart3_gpio4 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7c>;
+ };
+
+ uart3_ctsrts_gpio6 {
+ brcm,pins = <0x06 0x07>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7d>;
+ };
+
+ uart4_gpio8 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x7e>;
+ };
+
+ uart4_ctsrts_gpio10 {
+ brcm,pins = <0x0a 0x0b>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x7f>;
+ };
+
+ uart5_gpio12 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x80>;
+ };
+
+ uart5_ctsrts_gpio14 {
+ brcm,pins = <0x0e 0x0f>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x02 0x00>;
+ phandle = <0x81>;
+ };
+
+ dpi_18bit_gpio0 {
+ brcm,pins = <0x00 0x01 0x02 0x03
+ 0x04 0x05 0x06 0x07
+ 0x08 0x09 0x0a 0x0b
+ 0x0c 0x0d 0x0e 0x0f
+ 0x10 0x11 0x12 0x13
+ 0x14 0x15>;
+ brcm,function = <0x06>;
+ phandle = <0x82>;
+ };
+
+ spi0_pins {
+ brcm,pins = <0x09 0x0a 0x0b>;
+ brcm,function = <0x04>;
+ phandle = <0x0d>;
+ };
+
+ spi0_cs_pins {
+ brcm,pins = <0x08 0x07>;
+ brcm,function = <0x01>;
+ phandle = <0x0e>;
+ };
+
+ spi3_pins {
+ brcm,pins = <0x01 0x02 0x03>;
+ brcm,function = <0x07>;
+ phandle = <0x83>;
+ };
+
+ spi3_cs_pins {
+ brcm,pins = <0x00 0x18>;
+ brcm,function = <0x01>;
+ phandle = <0x84>;
+ };
+
+ spi4_pins {
+ brcm,pins = <0x05 0x06 0x07>;
+ brcm,function = <0x07>;
+ phandle = <0x85>;
+ };
+
+ spi4_cs_pins {
+ brcm,pins = <0x04 0x19>;
+ brcm,function = <0x01>;
+ phandle = <0x86>;
+ };
+
+ spi5_pins {
+ brcm,pins = <0x0d 0x0e 0x0f>;
+ brcm,function = <0x07>;
+ phandle = <0x87>;
+ };
+
+ spi5_cs_pins {
+ brcm,pins = <0x0c 0x1a>;
+ brcm,function = <0x01>;
+ phandle = <0x88>;
+ };
+
+ spi6_pins {
+ brcm,pins = <0x13 0x14 0x15>;
+ brcm,function = <0x07>;
+ phandle = <0x89>;
+ };
+
+ spi6_cs_pins {
+ brcm,pins = <0x12 0x1b>;
+ brcm,function = <0x01>;
+ phandle = <0x8a>;
+ };
+
+ i2c0 {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x04>;
+ phandle = <0x10>;
+ };
+
+ i2c1 {
+ brcm,pins = <0x02 0x03>;
+ brcm,function = <0x04>;
+ phandle = <0x14>;
+ };
+
+ i2c3 {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x02>;
+ phandle = <0x8b>;
+ };
+
+ i2c4 {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x02>;
+ phandle = <0x8c>;
+ };
+
+ i2c5 {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x02>;
+ phandle = <0x8d>;
+ };
+
+ i2c6 {
+ brcm,pins = <0x16 0x17>;
+ brcm,function = <0x02>;
+ phandle = <0x8e>;
+ };
+
+ i2s {
+ brcm,pins = <0x12 0x13 0x14 0x15>;
+ brcm,function = <0x04>;
+ phandle = <0x0c>;
+ };
+
+ sdio_pins {
+ brcm,pins = <0x22 0x23 0x24 0x25 0x26 0x27>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02 0x02 0x02 0x02 0x02>;
+ phandle = <0x19>;
+ };
+
+ bt_pins {
+ brcm,pins = [2d 00];
+ brcm,function = <0x00>;
+ brcm,pull = <0x02>;
+ phandle = <0x09>;
+ };
+
+ uart0_pins {
+ brcm,pins = <0x20 0x21>;
+ brcm,function = <0x07>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x08>;
+ };
+
+ uart1_pins {
+ brcm,pins;
+ brcm,function;
+ brcm,pull;
+ phandle = <0x12>;
+ };
+
+ uart2_pins {
+ brcm,pins = <0x00 0x01>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x8f>;
+ };
+
+ uart3_pins {
+ brcm,pins = <0x04 0x05>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x90>;
+ };
+
+ uart4_pins {
+ brcm,pins = <0x08 0x09>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x91>;
+ };
+
+ uart5_pins {
+ brcm,pins = <0x0c 0x0d>;
+ brcm,function = <0x03>;
+ brcm,pull = <0x00 0x02>;
+ phandle = <0x92>;
+ };
+
+ audio_pins {
+ brcm,pins = <0x28 0x29>;
+ brcm,function = <0x04>;
+ phandle = <0x1b>;
+ };
+ };
+
+ serial@7e201000 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201000 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ cts-event-workaround;
+ pinctrl-names = "default";
+ pinctrl-0 = <0x08 0x09>;
+ status = "okay";
+ phandle = <0x1f>;
+ };
+
+ mmc@7e202000 {
+ compatible = "brcm,bcm2835-sdhost";
+ reg = <0x7e202000 0x100>;
+ interrupts = <0x00 0x78 0x04>;
+ clocks = <0x03 0x14>;
+ dmas = <0x0a 0x2000000d>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0b>;
+ bus-width = <0x04>;
+ brcm,overclock-50 = <0x00>;
+ brcm,pio-limit = <0x01>;
+ phandle = <0x27>;
+ };
+
+ i2s@7e203000 {
+ compatible = "brcm,bcm2835-i2s";
+ reg = <0x7e203000 0x24>;
+ clocks = <0x03 0x1f>;
+ dmas = <0x0a 0x02 0x0a 0x03>;
+ dma-names = "tx\0rx";
+ status = "disabled";
+ #sound-dai-cells = <0x00>;
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0c>;
+ phandle = <0x21>;
+ };
+
+ spi@7e204000 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204000 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ dmas = <0x0a 0x06 0x0a 0x07>;
+ dma-names = "tx\0rx";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x0d 0x0e>;
+ cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>;
+ phandle = <0x22>;
+
+ spidev@0 {
+ compatible = "spidev";
+ reg = <0x00>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ spi-max-frequency = <0x7735940>;
+ phandle = <0x93>;
+ };
+
+ spidev@1 {
+ compatible = "spidev";
+ reg = <0x01>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ spi-max-frequency = <0x7735940>;
+ phandle = <0x94>;
+ };
+ };
+
+ i2c@7e205000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205000 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x10>;
+ clock-frequency = <0x186a0>;
+ phandle = <0x23>;
+ };
+
+ pixelvalve@7e206000 {
+ compatible = "brcm,bcm2835-pixelvalve0";
+ reg = <0x7e206000 0x100>;
+ interrupts = <0x00 0x6d 0x04>;
+ status = "disabled";
+ phandle = <0x95>;
+ };
+
+ pixelvalve@7e207000 {
+ compatible = "brcm,bcm2835-pixelvalve1";
+ reg = <0x7e207000 0x100>;
+ interrupts = <0x00 0x6e 0x04>;
+ status = "disabled";
+ phandle = <0x96>;
+ };
+
+ dpi@7e208000 {
+ compatible = "brcm,bcm2835-dpi";
+ reg = <0x7e208000 0x8c>;
+ clocks = <0x03 0x14 0x03 0x2c>;
+ clock-names = "core\0pixel";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x97>;
+ };
+
+ dsi@7e209000 {
+ compatible = "brcm,bcm2835-dsi0";
+ reg = <0x7e209000 0x78>;
+ interrupts = <0x00 0x64 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>;
+ clock-names = "phy\0escape\0pixel";
+ clock-output-names = "dsi0_byte\0dsi0_ddr2\0dsi0_ddr";
+ phandle = <0x05>;
+ };
+
+ aux@7e215000 {
+ compatible = "brcm,bcm2835-aux";
+ #clock-cells = <0x01>;
+ reg = <0x7e215000 0x08>;
+ clocks = <0x03 0x14>;
+ phandle = <0x11>;
+ };
+
+ serial@7e215040 {
+ compatible = "brcm,bcm2835-aux-uart";
+ reg = <0x7e215040 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x00>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x12>;
+ phandle = <0x20>;
+ };
+
+ spi@7e215080 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e215080 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x01>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x98>;
+ };
+
+ spi@7e2150c0 {
+ compatible = "brcm,bcm2835-aux-spi";
+ reg = <0x7e2150c0 0x40>;
+ interrupts = <0x00 0x5d 0x04>;
+ clocks = <0x11 0x02>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0x99>;
+ };
+
+ pwm@7e20c000 {
+ compatible = "brcm,bcm2835-pwm";
+ reg = <0x7e20c000 0x28>;
+ clocks = <0x03 0x1e>;
+ assigned-clocks = <0x03 0x1e>;
+ assigned-clock-rates = <0x989680>;
+ #pwm-cells = <0x02>;
+ status = "disabled";
+ phandle = <0x9a>;
+ };
+
+ hvs@7e400000 {
+ compatible = "brcm,bcm2835-hvs";
+ reg = <0x7e400000 0x6000>;
+ interrupts = <0x00 0x61 0x04>;
+ status = "disabled";
+ phandle = <0x9b>;
+ };
+
+ dsi@7e700000 {
+ compatible = "brcm,bcm2835-dsi1";
+ reg = <0x7e700000 0x8c>;
+ interrupts = <0x00 0x6c 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ clocks = <0x03 0x23 0x03 0x30 0x03 0x32>;
+ clock-names = "phy\0escape\0pixel";
+ clock-output-names = "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";
+ status = "disabled";
+ phandle = <0x06>;
+ };
+
+ csi@7e800000 {
+ compatible = "brcm,bcm2835-unicam";
+ reg = <0x7e800000 0x800 0x7e802000 0x04>;
+ interrupts = <0x00 0x66 0x04>;
+ clocks = <0x03 0x2d>;
+ clock-names = "lp";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ status = "disabled";
+ power-domains = <0x13 0x0c>;
+ phandle = <0x9c>;
+ };
+
+ csi@7e801000 {
+ compatible = "brcm,bcm2835-unicam";
+ reg = <0x7e801000 0x800 0x7e802004 0x04>;
+ interrupts = <0x00 0x67 0x04>;
+ clocks = <0x03 0x2e>;
+ clock-names = "lp";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ #clock-cells = <0x01>;
+ status = "disabled";
+ power-domains = <0x13 0x0d>;
+ phandle = <0x9d>;
+
+ port {
+
+ endpoint {
+ data-lanes = <0x01 0x02>;
+ };
+ };
+ };
+
+ i2c@7e804000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e804000 0x1000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x14>;
+ clock-frequency = <0x186a0>;
+ phandle = <0x24>;
+ };
+
+ i2c@7e805000 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e805000 0x1000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ clock-frequency = <0x186a0>;
+ phandle = <0x15>;
+ };
+
+ vec@7e806000 {
+ compatible = "brcm,bcm2835-vec";
+ reg = <0x7e806000 0x1000>;
+ clocks = <0x03 0x18>;
+ interrupts = <0x00 0x7b 0x04>;
+ status = "disabled";
+ phandle = <0x9e>;
+ };
+
+ pixelvalve@7e807000 {
+ compatible = "brcm,bcm2835-pixelvalve2";
+ reg = <0x7e807000 0x100>;
+ interrupts = <0x00 0x6a 0x04>;
+ status = "disabled";
+ phandle = <0x9f>;
+ };
+
+ hdmi@7e902000 {
+ compatible = "brcm,bcm2835-hdmi";
+ reg = <0x7e902000 0x600 0x7e808000 0x100>;
+ interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>;
+ ddc = <0x15>;
+ clocks = <0x03 0x10 0x03 0x19>;
+ clock-names = "pixel\0hdmi";
+ dmas = <0x0a 0x11>;
+ dma-names = "audio-rx";
+ status = "disabled";
+ power-domains = <0x13 0x05>;
+ phandle = <0xa0>;
+ };
+
+ usb@7e980000 {
+ compatible = "brcm,bcm2708-usb";
+ reg = <0x7e980000 0x10000 0x7e00b200 0x200>;
+ interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ clocks = <0x16>;
+ clock-names = "otg";
+ phys = <0x17>;
+ phy-names = "usb2-phy";
+ interrupt-names = "usb\0soft";
+ power-domains = <0x13 0x06>;
+ phandle = <0xa1>;
+ };
+
+ gpu {
+ compatible = "brcm,bcm2835-vc4";
+ status = "disabled";
+ phandle = <0xa2>;
+ };
+
+ local_intc@40000000 {
+ compatible = "brcm,bcm2836-l1-intc";
+ reg = <0x40000000 0x100>;
+ phandle = <0xa3>;
+ };
+
+ gic400@40041000 {
+ interrupt-controller;
+ #interrupt-cells = <0x03>;
+ compatible = "arm,gic-400";
+ reg = <0x40041000 0x1000 0x40042000 0x2000 0x40046000 0x2000 0x40048000 0x2000>;
+ phandle = <0x01>;
+ };
+
+ thermal@7d5d2200 {
+ compatible = "brcm,avs-tmon-bcm2838";
+ reg = <0x7d5d2200 0x2c>;
+ interrupts = <0x00 0x89 0x04>;
+ interrupt-names = "tmon";
+ clocks = <0x03 0x1b>;
+ #thermal-sensor-cells = <0x00>;
+ status = "okay";
+ phandle = <0x02>;
+ };
+
+ serial@7e201400 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201400 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa4>;
+ };
+
+ serial@7e201600 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201600 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa5>;
+ };
+
+ serial@7e201800 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201800 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa6>;
+ };
+
+ serial@7e201a00 {
+ compatible = "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
+ reg = <0x7e201a00 0x200>;
+ interrupts = <0x00 0x79 0x04>;
+ clocks = <0x03 0x13 0x03 0x14>;
+ clock-names = "uartclk\0apb_pclk";
+ arm,primecell-periphid = <0x241011>;
+ status = "disabled";
+ phandle = <0xa7>;
+ };
+
+ spi@7e204600 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204600 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xa8>;
+ };
+
+ spi@7e204800 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204800 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xa9>;
+ };
+
+ spi@7e204a00 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204a00 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xaa>;
+ };
+
+ spi@7e204c00 {
+ compatible = "brcm,bcm2835-spi";
+ reg = <0x7e204c00 0x200>;
+ interrupts = <0x00 0x76 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xab>;
+ };
+
+ i2c@7e205600 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205600 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xac>;
+ };
+
+ i2c@7e205800 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205800 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xad>;
+ };
+
+ i2c@7e205a00 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205a00 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xae>;
+ };
+
+ i2c@7e205c00 {
+ compatible = "brcm,bcm2835-i2c";
+ reg = <0x7e205c00 0x200>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x03 0x14>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ status = "disabled";
+ phandle = <0xaf>;
+ };
+
+ emmc2@7e340000 {
+ compatible = "brcm,bcm2711-emmc2";
+ status = "okay";
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x33>;
+ reg = <0x7e340000 0x100>;
+ broken-cd;
+ vqmmc-supply = <0x18>;
+ phandle = <0xb0>;
+ };
+
+ mmc@7e300000 {
+ compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
+ reg = <0x7e300000 0x100>;
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x1c>;
+ dmas = <0x0a 0x0b>;
+ dma-names = "rx-tx";
+ brcm,overclock-50 = <0x00>;
+ status = "disabled";
+ phandle = <0x28>;
+ };
+
+ mmcnr@7e300000 {
+ compatible = "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
+ reg = <0x7e300000 0x100>;
+ interrupts = <0x00 0x7e 0x04>;
+ clocks = <0x03 0x1c>;
+ dmas = <0x0a 0x0b>;
+ dma-names = "rx-tx";
+ brcm,overclock-50 = <0x00>;
+ non-removable;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x19>;
+ bus-width = <0x04>;
+ phandle = <0x29>;
+ };
+
+ firmwarekms@7e600000 {
+ compatible = "raspberrypi,rpi-firmware-kms";
+ reg = <0x7e600000 0x100>;
+ interrupts = <0x00 0x70 0x04>;
+ brcm,firmware = <0x07>;
+ status = "disabled";
+ phandle = <0xb1>;
+ };
+
+ smi@7e600000 {
+ compatible = "brcm,bcm2835-smi";
+ reg = <0x7e600000 0x100>;
+ interrupts = <0x00 0x70 0x04>;
+ clocks = <0x03 0x2a>;
+ assigned-clocks = <0x03 0x2a>;
+ assigned-clock-rates = <0x7735940>;
+ dmas = <0x0a 0x04>;
+ dma-names = "rx-tx";
+ status = "disabled";
+ phandle = <0xb2>;
+ };
+
+ axiperf {
+ compatible = "brcm,bcm2835-axiperf";
+ reg = <0x7e009800 0x100 0x7ee08000 0x100>;
+ firmware = <0x07>;
+ status = "disabled";
+ phandle = <0x2a>;
+ };
+
+ gpiomem {
+ compatible = "brcm,bcm2835-gpiomem";
+ reg = <0x7e200000 0x1000>;
+ };
+
+ firmware {
+ compatible = "raspberrypi,bcm2835-firmware\0simple-bus";
+ #address-cells = <0x00>;
+ #size-cells = <0x00>;
+ mboxes = <0x1a>;
+ phandle = <0x07>;
+
+ expgpio {
+ compatible = "raspberrypi,firmware-gpio";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ status = "okay";
+ phandle = <0x2d>;
+ };
+ };
+
+ power {
+ compatible = "raspberrypi,bcm2835-power";
+ firmware = <0x07>;
+ #power-domain-cells = <0x01>;
+ phandle = <0x13>;
+ };
+
+ fb {
+ compatible = "brcm,bcm2708-fb";
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb3>;
+ };
+
+ vcsm {
+ compatible = "raspberrypi,bcm2835-vcsm";
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb4>;
+ };
+
+ audio {
+ compatible = "brcm,bcm2835-audio";
+ brcm,pwm-channels = <0x08>;
+ status = "disabled";
+ pinctrl-names = "default";
+ pinctrl-0 = <0x1b>;
+ phandle = <0x25>;
+ };
+
+ sound {
+ status = "disabled";
+ phandle = <0xb5>;
+ };
+
+ virtgpio {
+ compatible = "brcm,bcm2835-virtgpio";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ firmware = <0x07>;
+ status = "okay";
+ phandle = <0xb6>;
+ };
+ };
+
+ clocks {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ clock@3 {
+ compatible = "fixed-clock";
+ reg = <0x03>;
+ #clock-cells = <0x00>;
+ clock-output-names = "osc";
+ clock-frequency = <0x337f980>;
+ phandle = <0x04>;
+ };
+
+ clock@4 {
+ compatible = "fixed-clock";
+ reg = <0x04>;
+ #clock-cells = <0x00>;
+ clock-output-names = "otg";
+ clock-frequency = <0x1c9c3800>;
+ phandle = <0x16>;
+ };
+ };
+
+ phy {
+ compatible = "usb-nop-xceiv";
+ #phy-cells = <0x00>;
+ phandle = <0x17>;
+ };
+
+ arm-pmu {
+ compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu";
+ interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04 0x00 0x13 0x04>;
+ };
+
+ timer {
+ compatible = "arm,armv7-timer";
+ interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b 0xf08 0x01 0x0a 0xf08>;
+ arm,cpu-registers-not-fw-configured;
+ always-on;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ enable-method = "brcm,bcm2836-smp";
+ phandle = <0xb7>;
+
+ cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x00>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xd8>;
+ phandle = <0xb8>;
+ };
+
+ cpu@1 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x01>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xe0>;
+ phandle = <0xb9>;
+ };
+
+ cpu@2 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x02>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xe8>;
+ phandle = <0xba>;
+ };
+
+ cpu@3 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a72";
+ reg = <0x03>;
+ enable-method = "spin-table";
+ cpu-release-addr = <0x00 0xf0>;
+ phandle = <0xbb>;
+ };
+ };
+
+ v3dbus {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000 0x00 0xff800000 0x800000>;
+ dma-ranges = <0x00 0x00 0x00 0x3c000000>;
+
+ v3d@7ec04000 {
+ compatible = "brcm,2711-v3d";
+ reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>;
+ reg-names = "hub\0core0";
+ power-domains = <0x1c 0x01>;
+ resets = <0x1c 0x00>;
+ clocks = <0x03 0x15>;
+ interrupts = <0x00 0x4a 0x04>;
+ status = "okay";
+ phandle = <0xbc>;
+ };
+ };
+
+ scb {
+ compatible = "simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x7c000000 0x00 0xfc000000
+ 0x3800000 0x00 0x40000000 0x00
+ 0xff800000 0x800000 0x06 0x00
+ 0x06 0x00 0x40000000 0x00
+ 0x00 0x00 0x00 0xfc000000>;
+ dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;
+ phandle = <0xbd>;
+
+ pcie@7d500000 {
+ reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300 0x20>;
+ msi-controller;
+ msi-parent = <0x1d>;
+ #address-cells = <0x03>;
+ #interrupt-cells = <0x01>;
+ #size-cells = <0x02>;
+ bus-range = <0x00 0x01>;
+ compatible = "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev";
+ max-link-speed = <0x02>;
+ tot-num-pcie = <0x01>;
+ linux,pci-domain = <0x00>;
+ interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>;
+ interrupt-names = "pcie\0msi";
+ interrupt-map-mask = <0x00 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01
+ 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02
+ 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03
+ 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04
+ 0x01 0x00 0x92 0x04>;
+ ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00 0x4000000>;
+ dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01 0x00>;
+ status = "okay";
+ phandle = <0x1d>;
+ };
+
+ genet@7d580000 {
+ compatible = "brcm,genet-v5";
+ reg = <0x00 0x7d580000 0x10000>;
+ status = "okay";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>;
+ phy-handle = <0x1e>;
+ phy-mode = "rgmii";
+ phandle = <0xbe>;
+
+ mdio@e14 {
+ #address-cells = <0x00>;
+ #size-cells = <0x01>;
+ compatible = "brcm,genet-mdio-v5";
+ reg = <0xe14 0x08>;
+ reg-names = "mdio";
+
+ genet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ max-speed = <0x3e8>;
+ reg = <0x01>;
+ phandle = <0x1e>;
+ };
+ };
+ };
+
+ dma@7e007b00 {
+ compatible = "brcm,bcm2838-dma";
+ reg = <0x00 0x7e007b00 0x400>;
+ interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00 0x5b
+ 0x04 0x00 0x5c 0x04>;
+ interrupt-names = "dma11\0dma12\0dma13\0dma14";
+ #dma-cells = <0x01>;
+ brcm,dma-channel-mask = <0x7000>;
+ phandle = <0xbf>;
+ };
+
+ xhci@7e9c0000 {
+ compatible = "generic-xhci";
+ status = "disabled";
+ reg = <0x00 0x7e9c0000 0x100000>;
+ interrupts = <0x00 0xb0 0x04>;
+ phandle = <0xc0>;
+ };
+
+ mailbox@7e00b840 {
+ compatible = "brcm,bcm2838-vchiq";
+ reg = <0x00 0x7e00b840 0x3c>;
+ interrupts = <0x00 0x22 0x04>;
+ phandle = <0xc1>;
+ };
+
+ hevc-decoder@7eb00000 {
+ compatible = "raspberrypi,argon-hevc-decoder";
+ reg = <0x00 0x7eb00000 0x10000>;
+ status = "okay";
+ };
+
+ argon-local-intc@7eb10000 {
+ compatible = "raspberrypi,argon-local-intc";
+ reg = <0x00 0x7eb10000 0x1000>;
+ status = "okay";
+ interrupts = <0x00 0x62 0x04>;
+ };
+
+ h264-decoder@7eb20000 {
+ compatible = "raspberrypi,argon-h264-decoder";
+ reg = <0x00 0x7eb20000 0x10000>;
+ status = "okay";
+ };
+
+ vp9-decoder@7eb30000 {
+ compatible = "raspberrypi,argon-vp9-decoder";
+ reg = <0x00 0x7eb30000 0x10000>;
+ status = "okay";
+ };
+ };
+
+ fixedregulator_5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-min-microvolt = <0x4c4b40>;
+ regulator-max-microvolt = <0x4c4b40>;
+ regulator-always-on;
+ phandle = <0x2e>;
+ };
+
+ fixedregulator_3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-min-microvolt = <0x325aa0>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-always-on;
+ phandle = <0xc2>;
+ };
+
+ __overrides__ {
+ cam0-pwdn-ctrl;
+ cam0-pwdn;
+ cam0-led-ctrl;
+ cam0-led;
+ cache_line_size;
+ uart0 = [00 00 00 1f 73 74 61 74 75 73 00];
+ uart1 = "\0\0\0 status";
+ i2s = "\0\0\0!status";
+ spi = "\0\0\0\"status";
+ i2c0 = "\0\0\0#status";
+ i2c1 = "\0\0\0$status";
+ i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
+ i2c0_baudrate = "\0\0\0#clock-frequency:0";
+ i2c1_baudrate = "\0\0\0$clock-frequency:0";
+ i2c2_baudrate = [00 00 00 15 63 6c 6f 63
+ 6b 2d 66 72 65 71 75 65
+ 6e 63 79 3a 30 00];
+ audio = "\0\0\0%status";
+ watchdog = [00 00 00 1c 73 74 61 74 75 73 00];
+ random = "\0\0\0&status";
+ sd_overclock = "\0\0\0'brcm,overclock-50:0";
+ sd_force_pio = "\0\0\0'brcm,force-pio?";
+ sd_pio_limit = "\0\0\0'brcm,pio-limit:0";
+ sd_debug = "\0\0\0'brcm,debug";
+ sdio_overclock = "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0";
+ axiperf = "\0\0\0*status";
+ arm_freq;
+ act_led_gpio = "\0\0\0+gpios:4";
+ act_led_activelow = "\0\0\0+gpios:8";
+ act_led_trigger = "\0\0\0+linux,default-trigger";
+ pwr_led_gpio = "\0\0\0,gpios:4";
+ pwr_led_activelow = "\0\0\0,gpios:8";
+ pwr_led_trigger = "\0\0\0,linux,default-trigger";
+ };
+
+ memory {
+ device_type = "memory";
+ reg = <0x00 0x00 0x00>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ phandle = <0xc3>;
+
+ act {
+ label = "led0";
+ linux,default-trigger = "mmc0";
+ gpios = <0x0f 0x2a 0x00>;
+ phandle = <0x2b>;
+ };
+
+ pwr {
+ label = "led1";
+ linux,default-trigger = "input";
+ gpios = <0x2d 0x02 0x00>;
+ phandle = <0x2c>;
+ };
+ };
+
+ sd_io_1v8_reg {
+ status = "okay";
+ compatible = "regulator-gpio";
+ vin-supply = <0x2e>;
+ regulator-name = "vdd-sd-io";
+ regulator-min-microvolt = <0x1b7740>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-settling-time-us = <0x1388>;
+ gpios = <0x2d 0x04 0x00>;
+ states = <0x1b7740 0x01 0x325aa0 0x00>;
+ phandle = <0x18>;
+ };
+
+ __symbols__ {
+ cpu_thermal = "/thermal-zones/cpu-thermal";
+ soc = "/soc";
+ txp = "/soc/txp@7e004000";
+ dma = "/soc/dma@7e007000";
+ watchdog = "/soc/watchdog@7e100000";
+ pm = "/soc/watchdog@7e100000";
+ clocks = "/soc/cprman@7e101000";
+ random = "/soc/rng@7e104000";
+ rng = "/soc/rng@7e104000";
+ mailbox = "/soc/mailbox@7e00b880";
+ gpio = "/soc/gpio@7e200000";
+ dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0";
+ emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22";
+ emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34";
+ emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48";
+ gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4";
+ gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5";
+ gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42";
+ gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44";
+ gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6";
+ gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43";
+ i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0";
+ i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28";
+ i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44";
+ i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
+ i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44";
+ jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22";
+ pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18";
+ pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28";
+ pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12";
+ pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18";
+ pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40";
+ pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13";
+ pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19";
+ pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41";
+ pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45";
+ sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48";
+ sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48";
+ spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7";
+ spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35";
+ spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16";
+ spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40";
+ uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14";
+ uart0_ctsrts_gpio16 = "/soc/gpio@7e200000/uart0_ctsrts_gpio16";
+ uart0_ctsrts_gpio30 = "/soc/gpio@7e200000/uart0_ctsrts_gpio30";
+ uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32";
+ uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36";
+ uart0_ctsrts_gpio38 = "/soc/gpio@7e200000/uart0_ctsrts_gpio38";
+ uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14";
+ uart1_ctsrts_gpio16 = "/soc/gpio@7e200000/uart1_ctsrts_gpio16";
+ uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32";
+ uart1_ctsrts_gpio30 = "/soc/gpio@7e200000/uart1_ctsrts_gpio30";
+ uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40";
+ uart1_ctsrts_gpio42 = "/soc/gpio@7e200000/uart1_ctsrts_gpio42";
+ gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49";
+ gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50";
+ gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51";
+ i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46";
+ i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46";
+ i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
+ i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4";
+ i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6";
+ i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8";
+ i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10";
+ i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12";
+ i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0";
+ i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22";
+ i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8";
+ jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48";
+ mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28";
+ mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36";
+ pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50";
+ pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52";
+ pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53";
+ rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35";
+ rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34";
+ rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39";
+ rgmii_mdio_gpio28 = "/soc/gpio@7e200000/rgmii_mdio_gpio28";
+ rgmii_mdio_gpio37 = "/soc/gpio@7e200000/rgmii_mdio_gpio37";
+ spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46";
+ spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46";
+ spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0";
+ spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4";
+ spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12";
+ spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18";
+ uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0";
+ uart2_ctsrts_gpio2 = "/soc/gpio@7e200000/uart2_ctsrts_gpio2";
+ uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4";
+ uart3_ctsrts_gpio6 = "/soc/gpio@7e200000/uart3_ctsrts_gpio6";
+ uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8";
+ uart4_ctsrts_gpio10 = "/soc/gpio@7e200000/uart4_ctsrts_gpio10";
+ uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12";
+ uart5_ctsrts_gpio14 = "/soc/gpio@7e200000/uart5_ctsrts_gpio14";
+ dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0";
+ spi0_pins = "/soc/gpio@7e200000/spi0_pins";
+ spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins";
+ spi3_pins = "/soc/gpio@7e200000/spi3_pins";
+ spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins";
+ spi4_pins = "/soc/gpio@7e200000/spi4_pins";
+ spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins";
+ spi5_pins = "/soc/gpio@7e200000/spi5_pins";
+ spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins";
+ spi6_pins = "/soc/gpio@7e200000/spi6_pins";
+ spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins";
+ i2c0_pins = "/soc/gpio@7e200000/i2c0";
+ i2c1_pins = "/soc/gpio@7e200000/i2c1";
+ i2c3_pins = "/soc/gpio@7e200000/i2c3";
+ i2c4_pins = "/soc/gpio@7e200000/i2c4";
+ i2c5_pins = "/soc/gpio@7e200000/i2c5";
+ i2c6_pins = "/soc/gpio@7e200000/i2c6";
+ i2s_pins = "/soc/gpio@7e200000/i2s";
+ sdio_pins = "/soc/gpio@7e200000/sdio_pins";
+ bt_pins = "/soc/gpio@7e200000/bt_pins";
+ uart0_pins = "/soc/gpio@7e200000/uart0_pins";
+ uart1_pins = "/soc/gpio@7e200000/uart1_pins";
+ uart2_pins = "/soc/gpio@7e200000/uart2_pins";
+ uart3_pins = "/soc/gpio@7e200000/uart3_pins";
+ uart4_pins = "/soc/gpio@7e200000/uart4_pins";
+ uart5_pins = "/soc/gpio@7e200000/uart5_pins";
+ audio_pins = "/soc/gpio@7e200000/audio_pins";
+ uart0 = "/soc/serial@7e201000";
+ sdhost = "/soc/mmc@7e202000";
+ i2s = "/soc/i2s@7e203000";
+ spi0 = "/soc/spi@7e204000";
+ spi = "/soc/spi@7e204000";
+ spidev0 = "/soc/spi@7e204000/spidev@0";
+ spidev1 = "/soc/spi@7e204000/spidev@1";
+ i2c0 = "/soc/i2c@7e205000";
+ pixelvalve0 = "/soc/pixelvalve@7e206000";
+ pixelvalve1 = "/soc/pixelvalve@7e207000";
+ dpi = "/soc/dpi@7e208000";
+ dsi0 = "/soc/dsi@7e209000";
+ aux = "/soc/aux@7e215000";
+ uart1 = "/soc/serial@7e215040";
+ spi1 = "/soc/spi@7e215080";
+ spi2 = "/soc/spi@7e2150c0";
+ pwm = "/soc/pwm@7e20c000";
+ hvs = "/soc/hvs@7e400000";
+ dsi1 = "/soc/dsi@7e700000";
+ csi0 = "/soc/csi@7e800000";
+ csi1 = "/soc/csi@7e801000";
+ i2c1 = "/soc/i2c@7e804000";
+ i2c2 = "/soc/i2c@7e805000";
+ vec = "/soc/vec@7e806000";
+ pixelvalve2 = "/soc/pixelvalve@7e807000";
+ hdmi = "/soc/hdmi@7e902000";
+ usb = "/soc/usb@7e980000";
+ vc4 = "/soc/gpu";
+ local_intc = "/soc/local_intc@40000000";
+ gicv2 = "/soc/gic400@40041000";
+ thermal = "/soc/thermal@7d5d2200";
+ uart2 = "/soc/serial@7e201400";
+ uart3 = "/soc/serial@7e201600";
+ uart4 = "/soc/serial@7e201800";
+ uart5 = "/soc/serial@7e201a00";
+ spi3 = "/soc/spi@7e204600";
+ spi4 = "/soc/spi@7e204800";
+ spi5 = "/soc/spi@7e204a00";
+ spi6 = "/soc/spi@7e204c00";
+ i2c3 = "/soc/i2c@7e205600";
+ i2c4 = "/soc/i2c@7e205800";
+ i2c5 = "/soc/i2c@7e205a00";
+ i2c6 = "/soc/i2c@7e205c00";
+ emmc2 = "/soc/emmc2@7e340000";
+ mmc = "/soc/mmc@7e300000";
+ mmcnr = "/soc/mmcnr@7e300000";
+ firmwarekms = "/soc/firmwarekms@7e600000";
+ smi = "/soc/smi@7e600000";
+ axiperf = "/soc/axiperf";
+ firmware = "/soc/firmware";
+ expgpio = "/soc/firmware/expgpio";
+ power = "/soc/power";
+ fb = "/soc/fb";
+ vcsm = "/soc/vcsm";
+ audio = "/soc/audio";
+ sound = "/soc/sound";
+ virtgpio = "/soc/virtgpio";
+ clk_osc = "/clocks/clock@3";
+ clk_usb = "/clocks/clock@4";
+ usbphy = "/phy";
+ cpus = "/cpus";
+ cpu0 = "/cpus/cpu@0";
+ cpu1 = "/cpus/cpu@1";
+ cpu2 = "/cpus/cpu@2";
+ cpu3 = "/cpus/cpu@3";
+ v3d = "/v3dbus/v3d@7ec04000";
+ scb = "/scb";
+ pcie_0 = "/scb/pcie@7d500000";
+ genet = "/scb/genet@7d580000";
+ phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0";
+ dma40 = "/scb/dma@7e007b00";
+ xhci = "/scb/xhci@7e9c0000";
+ vchiq = "/scb/mailbox@7e00b840";
+ vdd_5v0_reg = "/fixedregulator_5v0";
+ vdd_3v3_reg = "/fixedregulator_3v3";
+ leds = "/leds";
+ act_led = "/leds/act";
+ pwr_led = "/leds/pwr";
+ sd_io_1v8_reg = "/sd_io_1v8_reg";
+ };
+};
diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
index d592df50706..31d77dbe4eb 100644
--- a/configs/rpi_4_32b_defconfig
+++ b/configs/rpi_4_32b_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_TARGET_RPI_4_32B=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
CONFIG_OF_BOARD_SETUP=y
diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
index ab5cc90d912..a2a88d66dbd 100644
--- a/configs/rpi_4_defconfig
+++ b/configs/rpi_4_defconfig
@@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000
CONFIG_TARGET_RPI_4=y
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
CONFIG_OF_BOARD_SETUP=y
diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
index 382d99dc2eb..fb8abbccc45 100644
--- a/configs/rpi_arm64_defconfig
+++ b/configs/rpi_arm64_defconfig
@@ -6,6 +6,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_ENV_SIZE=0x4000
CONFIG_DISTRO_DEFAULTS=y
CONFIG_SYS_LOAD_ADDR=0x1000000
+CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
CONFIG_OF_BOARD_SETUP=y
CONFIG_USE_PREBOOT=y
CONFIG_PREBOOT="pci enum; usb start;"
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4
2021-10-13 1:01 ` [PATCH 07/16] arm: rpi: Add a devicetree file for rpi_4 Simon Glass
@ 2021-10-13 1:24 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:24 UTC (permalink / raw)
To: Simon Glass
Cc: Albert Aribaud, Andre Przywara, Christian Hewitt, Fabio Estevam,
Heiko Schocher, Ilias Apalodimas, Jagan Teki, Kever Yang,
Matthias Brugger, Neil Armstrong, Peter Robinson, Stephen Warren,
Stephen Warren, Tim Harvey, Tom Rini, U-Boot Mailing List
Hi Simon
This is making a clean environment go in the wrong direction. I have
witnessed that bus to mmio changed for instance, have seen patches to patch
live u-boot embedded DT because it does not do the work that Videocore
does.
The Videocore handles that properly so why adding this?
Si i would agree to have the file on the documentation directory not on the
dts with the same warning I mentioned earlier
Le mer. 13 oct. 2021 à 03:03, Simon Glass <sjg@chromium.org> a écrit :
> 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 <sjg@chromium.org>
> ---
>
> 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 52c586f3974..efc01a70bf2 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1062,7 +1062,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 00000000000..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/ 0x0000000000000000 0x0000000000001000;
> +/ {
> + 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@7e100000";
> + random = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e200000";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + mmc0 = "/soc/emmc2@7e340000";
> + 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@7e300000";
> + mmc1 = "/soc/mmcnr@7e300000";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + usb = "/soc/usb@7e980000";
> + leds = "/leds";
> + fb = "/soc/fb";
> + thermal = "/soc/thermal@7d5d2200";
> + axiperf = "/soc/axiperf";
> + mmc2 = "/soc/mmc@7e202000";
> + ethernet0 = "/scb/genet@7d580000";
> + };
> +
> + chosen {
> + bootargs = "8250.nr_uarts=1 cma=64M";
> + };
> +
> + thermal-zones {
> +
> + cpu-thermal {
> + polling-delay-passive = <0x00>;
> + polling-delay = <0x3e8>;
> + thermal-sensors = <0x02>;
> + coefficients = <0xfffffe19 0x641b8>;
> + phandle = <0x2f>;
> +
> + cooling-maps {
> + };
> + };
> + };
> +
> + soc {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7e000000 0x00 0xfe000000 0x1800000
> + 0x7c000000 0x00 0xfc000000 0x2000000
> + 0x40000000 0x00 0xff800000 0x800000>;
> + dma-ranges = <0xc0000000 0x00 0x00 0x3c000000>;
> + 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";
> + #dma-cells = <0x01>;
> + brcm,dma-channel-mask = <0x7ef5>;
> + phandle = <0x0a>;
> + };
> +
> + watchdog@7e100000 {
> + compatible =
> "brcm,bcm2835-pm\0brcm,bcm2835-pm-wdt";
> + #power-domain-cells = <0x01>;
> + #reset-cells = <0x01>;
> + reg = <0x7e100000 0x114 0x7e00a000 0x24 0x7ec11000
> 0x20>;
> + clocks = <0x03 0x15 0x03 0x1d 0x03 0x17 0x03 0x16>;
> + clock-names = "v3d\0peri_image\0h264\0isp";
> + system-power-controller;
> + phandle = <0x1c>;
> + };
> +
> + cprman@7e101000 {
> + compatible = "brcm,bcm2838-cprman";
> + #clock-cells = <0x01>;
> + reg = <0x7e101000 0x2000>;
> + clocks = <0x04 0x05 0x00 0x05 0x01 0x05 0x02 0x06
> + 0x00 0x06 0x01 0x06 0x02>;
> + firmware = <0x07>;
> + phandle = <0x03>;
> + };
> +
> + rng@7e104000 {
> + compatible = "brcm,bcm2838-rng200";
> + reg = <0x7e104000 0x10>;
> + interrupts = <0x00 0x7d 0x04>;
> + phandle = <0x26>;
> + };
> +
> + mailbox@7e00b880 {
> + compatible = "brcm,bcm2835-mbox";
> + reg = <0x7e00b880 0x40>;
> + interrupts = <0x00 0x21 0x04>;
> + #mbox-cells = <0x00>;
> + phandle = <0x1a>;
> + };
> +
> + gpio: gpio@7e200000 {
> + compatible = "brcm,bcm2835-gpio";
> + reg = <0x7e200000 0xb4>;
> + interrupts = <0x00 0x71 0x04 0x00 0x72 0x04>;
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + interrupt-controller;
> + #interrupt-cells = <0x02>;
> + phandle = <0x0f>;
> +
> + dpi_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03 0x04
> + 0x05 0x06 0x07 0x08 0x09
> + 0x0a 0x0b 0x0c 0x0d 0x0e
> + 0x0f 0x10 0x11 0x12 0x13
> + 0x14 0x15 0x16 0x17 0x18
> + 0x19 0x1a 0x1b>;
> + brcm,function = <0x06>;
> + phandle = <0x32>;
> + };
> +
> + emmc_gpio22 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> + brcm,function = <0x07>;
> + phandle = <0x33>;
> + };
> +
> + emmc_gpio34 {
> + brcm,pins = <0x22 0x23 0x24 0x25 0x26
> 0x27>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02 0x02 0x02 0x02
> 0x02>;
> + phandle = <0x34>;
> + };
> +
> + emmc_gpio48 {
> + brcm,pins = <0x30 0x31 0x32 0x33 0x34
> 0x35>;
> + brcm,function = <0x07>;
> + phandle = <0x35>;
> + };
> +
> + gpclk0_gpio4 {
> + brcm,pins = <0x04>;
> + brcm,function = <0x04>;
> + phandle = <0x36>;
> + };
> +
> + gpclk1_gpio5 {
> + brcm,pins = <0x05>;
> + brcm,function = <0x04>;
> + phandle = <0x37>;
> + };
> +
> + gpclk1_gpio42 {
> + brcm,pins = <0x2a>;
> + brcm,function = <0x04>;
> + phandle = <0x38>;
> + };
> +
> + gpclk1_gpio44 {
> + brcm,pins = <0x2c>;
> + brcm,function = <0x04>;
> + phandle = <0x39>;
> + };
> +
> + gpclk2_gpio6 {
> + brcm,pins = <0x06>;
> + brcm,function = <0x04>;
> + phandle = <0x3a>;
> + };
> +
> + gpclk2_gpio43 {
> + brcm,pins = <0x2b>;
> + brcm,function = <0x04>;
> + brcm,pull = <0x00>;
> + phandle = <0x3b>;
> + };
> +
> + i2c0_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x04>;
> + phandle = <0x3c>;
> + };
> +
> + i2c0_gpio28 {
> + brcm,pins = <0x1c 0x1d>;
> + brcm,function = <0x04>;
> + phandle = <0x3d>;
> + };
> +
> + i2c0_gpio44 {
> + brcm,pins = <0x2c 0x2d>;
> + brcm,function = <0x05>;
> + phandle = <0x3e>;
> + };
> +
> + i2c1_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x04>;
> + phandle = <0x3f>;
> + };
> +
> + i2c1_gpio44 {
> + brcm,pins = <0x2c 0x2d>;
> + brcm,function = <0x06>;
> + phandle = <0x40>;
> + };
> +
> + jtag_gpio22 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> + brcm,function = <0x03>;
> + phandle = <0x41>;
> + };
> +
> + pcm_gpio18 {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x04>;
> + phandle = <0x42>;
> + };
> +
> + pcm_gpio28 {
> + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> + brcm,function = <0x06>;
> + phandle = <0x43>;
> + };
> +
> + pwm0_gpio12 {
> + brcm,pins = <0x0c>;
> + brcm,function = <0x04>;
> + phandle = <0x44>;
> + };
> +
> + pwm0_gpio18 {
> + brcm,pins = <0x12>;
> + brcm,function = <0x02>;
> + phandle = <0x45>;
> + };
> +
> + pwm0_gpio40 {
> + brcm,pins = <0x28>;
> + brcm,function = <0x04>;
> + phandle = <0x46>;
> + };
> +
> + pwm1_gpio13 {
> + brcm,pins = <0x0d>;
> + brcm,function = <0x04>;
> + phandle = <0x47>;
> + };
> +
> + pwm1_gpio19 {
> + brcm,pins = <0x13>;
> + brcm,function = <0x02>;
> + phandle = <0x48>;
> + };
> +
> + pwm1_gpio41 {
> + brcm,pins = <0x29>;
> + brcm,function = <0x04>;
> + phandle = <0x49>;
> + };
> +
> + pwm1_gpio45 {
> + brcm,pins = <0x2d>;
> + brcm,function = <0x04>;
> + phandle = <0x4a>;
> + };
> +
> + sdhost_gpio48 {
> + brcm,pins = <0x16 0x17 0x18 0x19 0x1a
> 0x1b>;
> + brcm,function = <0x04>;
> + phandle = <0x0b>;
> + };
> +
> + spi0_gpio7 {
> + brcm,pins = <0x07 0x08 0x09 0x0a 0x0b>;
> + brcm,function = <0x04>;
> + phandle = <0x4b>;
> + };
> +
> + spi0_gpio35 {
> + brcm,pins = <0x23 0x24 0x25 0x26 0x27>;
> + brcm,function = <0x04>;
> + phandle = <0x4c>;
> + };
> +
> + spi1_gpio16 {
> + brcm,pins = <0x10 0x11 0x12 0x13 0x14
> 0x15>;
> + brcm,function = <0x03>;
> + phandle = <0x4d>;
> + };
> +
> + spi2_gpio40 {
> + brcm,pins = <0x28 0x29 0x2a 0x2b 0x2c
> 0x2d>;
> + brcm,function = <0x03>;
> + phandle = <0x4e>;
> + };
> +
> + uart0_gpio14: uart0_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x04>;
> + phandle = <0x4f>;
> + };
> +
> + uart0: uart0_ctsrts_gpio16 {
> + brcm,pins = <0x10 0x11>;
> + brcm,function = <0x07>;
> + phandle = <0x50>;
> + };
> +
> + uart0_ctsrts_gpio30 {
> + brcm,pins = <0x1e 0x1f>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x51>;
> + };
> +
> + uart0_gpio32 {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x52>;
> + };
> +
> + uart0_gpio36 {
> + brcm,pins = <0x24 0x25>;
> + brcm,function = <0x06>;
> + phandle = <0x53>;
> + };
> +
> + uart0_ctsrts_gpio38 {
> + brcm,pins = <0x26 0x27>;
> + brcm,function = <0x06>;
> + phandle = <0x54>;
> + };
> +
> + uart1_gpio14: uart1_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x02>;
> + phandle = <0x55>;
> + };
> +
> + uart1: uart1_ctsrts_gpio16 {
> + brcm,pins = <0x10 0x11>;
> + brcm,function = <0x02>;
> + phandle = <0x56>;
> + };
> +
> + uart1_gpio32 {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x02>;
> + phandle = <0x57>;
> + };
> +
> + uart1_ctsrts_gpio30 {
> + brcm,pins = <0x1e 0x1f>;
> + brcm,function = <0x02>;
> + phandle = <0x58>;
> + };
> +
> + uart1_gpio40 {
> + brcm,pins = <0x28 0x29>;
> + brcm,function = <0x02>;
> + phandle = <0x59>;
> + };
> +
> + uart1_ctsrts_gpio42 {
> + brcm,pins = <0x2a 0x2b>;
> + brcm,function = <0x02>;
> + phandle = <0x5a>;
> + };
> +
> + gpclk0_gpio49 {
> + brcm,pins = <0x31>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5b>;
> + };
> +
> + gpclk1_gpio50 {
> + brcm,pins = <0x32>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5c>;
> + };
> +
> + gpclk2_gpio51 {
> + brcm,pins = <0x33>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x5d>;
> + };
> +
> + i2c0_gpio46 {
> + brcm,pins = <0x2e 0x2f>;
> + brcm,function = <0x04>;
> + phandle = <0x5e>;
> + };
> +
> + i2c1_gpio46 {
> + brcm,pins = <0x2e 0x2f>;
> + brcm,function = <0x05>;
> + phandle = <0x5f>;
> + };
> +
> + i2c3_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x02>;
> + phandle = <0x60>;
> + };
> +
> + i2c3_gpio4 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x02>;
> + phandle = <0x61>;
> + };
> +
> + i2c4_gpio6 {
> + brcm,pins = <0x06 0x07>;
> + brcm,function = <0x02>;
> + phandle = <0x62>;
> + };
> +
> + i2c4_gpio8 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x02>;
> + phandle = <0x63>;
> + };
> +
> + i2c5_gpio10 {
> + brcm,pins = <0x0a 0x0b>;
> + brcm,function = <0x02>;
> + phandle = <0x64>;
> + };
> +
> + i2c5_gpio12 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x02>;
> + phandle = <0x65>;
> + };
> +
> + i2c6_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x02>;
> + phandle = <0x66>;
> + };
> +
> + i2c6_gpio22 {
> + brcm,pins = <0x16 0x17>;
> + brcm,function = <0x02>;
> + phandle = <0x67>;
> + };
> +
> + i2c_slave_gpio8 {
> + brcm,pins = <0x08 0x09 0x0a 0x0b>;
> + brcm,function = <0x07>;
> + phandle = <0x68>;
> + };
> +
> + jtag_gpio48 {
> + brcm,pins = <0x30 0x31 0x32 0x33 0x34
> 0x35>;
> + brcm,function = <0x03>;
> + phandle = <0x69>;
> + };
> +
> + mii_gpio28 {
> + brcm,pins = <0x1c 0x1d 0x1e 0x1f>;
> + brcm,function = <0x03>;
> + phandle = <0x6a>;
> + };
> +
> + mii_gpio36 {
> + brcm,pins = <0x24 0x25 0x26 0x27>;
> + brcm,function = <0x02>;
> + phandle = <0x6b>;
> + };
> +
> + pcm_gpio50 {
> + brcm,pins = <0x32 0x33 0x34 0x35>;
> + brcm,function = <0x06>;
> + phandle = <0x6c>;
> + };
> +
> + pwm0_gpio52 {
> + brcm,pins = <0x34>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x6d>;
> + };
> +
> + pwm1_gpio53 {
> + brcm,pins = <0x35>;
> + brcm,function = <0x05>;
> + brcm,pull = <0x00>;
> + phandle = <0x6e>;
> + };
> +
> + rgmii_gpio35 {
> + brcm,pins = <0x23 0x24>;
> + brcm,function = <0x03>;
> + phandle = <0x6f>;
> + };
> +
> + rgmii_irq_gpio34 {
> + brcm,pins = <0x22>;
> + brcm,function = <0x02>;
> + phandle = <0x70>;
> + };
> +
> + rgmii_irq_gpio39 {
> + brcm,pins = <0x27>;
> + brcm,function = <0x03>;
> + phandle = <0x71>;
> + };
> +
> + rgmii_mdio_gpio28 {
> + brcm,pins = <0x1c 0x1d>;
> + brcm,function = <0x02>;
> + phandle = <0x72>;
> + };
> +
> + rgmii_mdio_gpio37 {
> + brcm,pins = <0x25 0x26>;
> + brcm,function = <0x03>;
> + phandle = <0x73>;
> + };
> +
> + spi0_gpio46 {
> + brcm,pins = <0x2e 0x2f 0x30 0x31>;
> + brcm,function = <0x06>;
> + phandle = <0x74>;
> + };
> +
> + spi2_gpio46 {
> + brcm,pins = <0x2e 0x2f 0x30 0x31 0x32>;
> + brcm,function = <0x02>;
> + phandle = <0x75>;
> + };
> +
> + spi3_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03>;
> + brcm,function = <0x07>;
> + phandle = <0x76>;
> + };
> +
> + spi4_gpio4 {
> + brcm,pins = <0x04 0x05 0x06 0x07>;
> + brcm,function = <0x07>;
> + phandle = <0x77>;
> + };
> +
> + spi5_gpio12 {
> + brcm,pins = <0x0c 0x0d 0x0e 0x0f>;
> + brcm,function = <0x07>;
> + phandle = <0x78>;
> + };
> +
> + spi6_gpio18 {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x07>;
> + phandle = <0x79>;
> + };
> +
> + uart2_gpio0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7a>;
> + };
> +
> + uart2_ctsrts_gpio2 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7b>;
> + };
> +
> + uart3_gpio4 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7c>;
> + };
> +
> + uart3_ctsrts_gpio6 {
> + brcm,pins = <0x06 0x07>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7d>;
> + };
> +
> + uart4_gpio8 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x7e>;
> + };
> +
> + uart4_ctsrts_gpio10 {
> + brcm,pins = <0x0a 0x0b>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x7f>;
> + };
> +
> + uart5_gpio12 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x80>;
> + };
> +
> + uart5_ctsrts_gpio14 {
> + brcm,pins = <0x0e 0x0f>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x02 0x00>;
> + phandle = <0x81>;
> + };
> +
> + dpi_18bit_gpio0 {
> + brcm,pins = <0x00 0x01 0x02 0x03
> + 0x04 0x05 0x06 0x07
> + 0x08 0x09 0x0a 0x0b
> + 0x0c 0x0d 0x0e 0x0f
> + 0x10 0x11 0x12 0x13
> + 0x14 0x15>;
> + brcm,function = <0x06>;
> + phandle = <0x82>;
> + };
> +
> + spi0_pins {
> + brcm,pins = <0x09 0x0a 0x0b>;
> + brcm,function = <0x04>;
> + phandle = <0x0d>;
> + };
> +
> + spi0_cs_pins {
> + brcm,pins = <0x08 0x07>;
> + brcm,function = <0x01>;
> + phandle = <0x0e>;
> + };
> +
> + spi3_pins {
> + brcm,pins = <0x01 0x02 0x03>;
> + brcm,function = <0x07>;
> + phandle = <0x83>;
> + };
> +
> + spi3_cs_pins {
> + brcm,pins = <0x00 0x18>;
> + brcm,function = <0x01>;
> + phandle = <0x84>;
> + };
> +
> + spi4_pins {
> + brcm,pins = <0x05 0x06 0x07>;
> + brcm,function = <0x07>;
> + phandle = <0x85>;
> + };
> +
> + spi4_cs_pins {
> + brcm,pins = <0x04 0x19>;
> + brcm,function = <0x01>;
> + phandle = <0x86>;
> + };
> +
> + spi5_pins {
> + brcm,pins = <0x0d 0x0e 0x0f>;
> + brcm,function = <0x07>;
> + phandle = <0x87>;
> + };
> +
> + spi5_cs_pins {
> + brcm,pins = <0x0c 0x1a>;
> + brcm,function = <0x01>;
> + phandle = <0x88>;
> + };
> +
> + spi6_pins {
> + brcm,pins = <0x13 0x14 0x15>;
> + brcm,function = <0x07>;
> + phandle = <0x89>;
> + };
> +
> + spi6_cs_pins {
> + brcm,pins = <0x12 0x1b>;
> + brcm,function = <0x01>;
> + phandle = <0x8a>;
> + };
> +
> + i2c0 {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x04>;
> + phandle = <0x10>;
> + };
> +
> + i2c1 {
> + brcm,pins = <0x02 0x03>;
> + brcm,function = <0x04>;
> + phandle = <0x14>;
> + };
> +
> + i2c3 {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x02>;
> + phandle = <0x8b>;
> + };
> +
> + i2c4 {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x02>;
> + phandle = <0x8c>;
> + };
> +
> + i2c5 {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x02>;
> + phandle = <0x8d>;
> + };
> +
> + i2c6 {
> + brcm,pins = <0x16 0x17>;
> + brcm,function = <0x02>;
> + phandle = <0x8e>;
> + };
> +
> + i2s {
> + brcm,pins = <0x12 0x13 0x14 0x15>;
> + brcm,function = <0x04>;
> + phandle = <0x0c>;
> + };
> +
> + sdio_pins {
> + brcm,pins = <0x22 0x23 0x24 0x25 0x26
> 0x27>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02 0x02 0x02 0x02
> 0x02>;
> + phandle = <0x19>;
> + };
> +
> + bt_pins {
> + brcm,pins = [2d 00];
> + brcm,function = <0x00>;
> + brcm,pull = <0x02>;
> + phandle = <0x09>;
> + };
> +
> + uart0_pins {
> + brcm,pins = <0x20 0x21>;
> + brcm,function = <0x07>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x08>;
> + };
> +
> + uart1_pins {
> + brcm,pins;
> + brcm,function;
> + brcm,pull;
> + phandle = <0x12>;
> + };
> +
> + uart2_pins {
> + brcm,pins = <0x00 0x01>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x8f>;
> + };
> +
> + uart3_pins {
> + brcm,pins = <0x04 0x05>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x90>;
> + };
> +
> + uart4_pins {
> + brcm,pins = <0x08 0x09>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x91>;
> + };
> +
> + uart5_pins {
> + brcm,pins = <0x0c 0x0d>;
> + brcm,function = <0x03>;
> + brcm,pull = <0x00 0x02>;
> + phandle = <0x92>;
> + };
> +
> + audio_pins {
> + brcm,pins = <0x28 0x29>;
> + brcm,function = <0x04>;
> + phandle = <0x1b>;
> + };
> + };
> +
> + serial@7e201000 {
> + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201000 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + cts-event-workaround;
> + pinctrl-names = "default";
> + pinctrl-0 = <0x08 0x09>;
> + status = "okay";
> + phandle = <0x1f>;
> + };
> +
> + mmc@7e202000 {
> + compatible = "brcm,bcm2835-sdhost";
> + reg = <0x7e202000 0x100>;
> + interrupts = <0x00 0x78 0x04>;
> + clocks = <0x03 0x14>;
> + dmas = <0x0a 0x2000000d>;
> + dma-names = "rx-tx";
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0b>;
> + bus-width = <0x04>;
> + brcm,overclock-50 = <0x00>;
> + brcm,pio-limit = <0x01>;
> + phandle = <0x27>;
> + };
> +
> + i2s@7e203000 {
> + compatible = "brcm,bcm2835-i2s";
> + reg = <0x7e203000 0x24>;
> + clocks = <0x03 0x1f>;
> + dmas = <0x0a 0x02 0x0a 0x03>;
> + dma-names = "tx\0rx";
> + status = "disabled";
> + #sound-dai-cells = <0x00>;
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0c>;
> + phandle = <0x21>;
> + };
> +
> + spi@7e204000 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204000 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + dmas = <0x0a 0x06 0x0a 0x07>;
> + dma-names = "tx\0rx";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x0d 0x0e>;
> + cs-gpios = <0x0f 0x08 0x01 0x0f 0x07 0x01>;
> + phandle = <0x22>;
> +
> + spidev@0 {
> + compatible = "spidev";
> + reg = <0x00>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + spi-max-frequency = <0x7735940>;
> + phandle = <0x93>;
> + };
> +
> + spidev@1 {
> + compatible = "spidev";
> + reg = <0x01>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + spi-max-frequency = <0x7735940>;
> + phandle = <0x94>;
> + };
> + };
> +
> + i2c@7e205000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205000 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x10>;
> + clock-frequency = <0x186a0>;
> + phandle = <0x23>;
> + };
> +
> + pixelvalve@7e206000 {
> + compatible = "brcm,bcm2835-pixelvalve0";
> + reg = <0x7e206000 0x100>;
> + interrupts = <0x00 0x6d 0x04>;
> + status = "disabled";
> + phandle = <0x95>;
> + };
> +
> + pixelvalve@7e207000 {
> + compatible = "brcm,bcm2835-pixelvalve1";
> + reg = <0x7e207000 0x100>;
> + interrupts = <0x00 0x6e 0x04>;
> + status = "disabled";
> + phandle = <0x96>;
> + };
> +
> + dpi@7e208000 {
> + compatible = "brcm,bcm2835-dpi";
> + reg = <0x7e208000 0x8c>;
> + clocks = <0x03 0x14 0x03 0x2c>;
> + clock-names = "core\0pixel";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x97>;
> + };
> +
> + dsi@7e209000 {
> + compatible = "brcm,bcm2835-dsi0";
> + reg = <0x7e209000 0x78>;
> + interrupts = <0x00 0x64 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + clocks = <0x03 0x20 0x03 0x2f 0x03 0x31>;
> + clock-names = "phy\0escape\0pixel";
> + clock-output-names =
> "dsi0_byte\0dsi0_ddr2\0dsi0_ddr";
> + phandle = <0x05>;
> + };
> +
> + aux@7e215000 {
> + compatible = "brcm,bcm2835-aux";
> + #clock-cells = <0x01>;
> + reg = <0x7e215000 0x08>;
> + clocks = <0x03 0x14>;
> + phandle = <0x11>;
> + };
> +
> + serial@7e215040 {
> + compatible = "brcm,bcm2835-aux-uart";
> + reg = <0x7e215040 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x00>;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x12>;
> + phandle = <0x20>;
> + };
> +
> + spi@7e215080 {
> + compatible = "brcm,bcm2835-aux-spi";
> + reg = <0x7e215080 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x01>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x98>;
> + };
> +
> + spi@7e2150c0 {
> + compatible = "brcm,bcm2835-aux-spi";
> + reg = <0x7e2150c0 0x40>;
> + interrupts = <0x00 0x5d 0x04>;
> + clocks = <0x11 0x02>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0x99>;
> + };
> +
> + pwm@7e20c000 {
> + compatible = "brcm,bcm2835-pwm";
> + reg = <0x7e20c000 0x28>;
> + clocks = <0x03 0x1e>;
> + assigned-clocks = <0x03 0x1e>;
> + assigned-clock-rates = <0x989680>;
> + #pwm-cells = <0x02>;
> + status = "disabled";
> + phandle = <0x9a>;
> + };
> +
> + hvs@7e400000 {
> + compatible = "brcm,bcm2835-hvs";
> + reg = <0x7e400000 0x6000>;
> + interrupts = <0x00 0x61 0x04>;
> + status = "disabled";
> + phandle = <0x9b>;
> + };
> +
> + dsi@7e700000 {
> + compatible = "brcm,bcm2835-dsi1";
> + reg = <0x7e700000 0x8c>;
> + interrupts = <0x00 0x6c 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + clocks = <0x03 0x23 0x03 0x30 0x03 0x32>;
> + clock-names = "phy\0escape\0pixel";
> + clock-output-names =
> "dsi1_byte\0dsi1_ddr2\0dsi1_ddr";
> + status = "disabled";
> + phandle = <0x06>;
> + };
> +
> + csi@7e800000 {
> + compatible = "brcm,bcm2835-unicam";
> + reg = <0x7e800000 0x800 0x7e802000 0x04>;
> + interrupts = <0x00 0x66 0x04>;
> + clocks = <0x03 0x2d>;
> + clock-names = "lp";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + status = "disabled";
> + power-domains = <0x13 0x0c>;
> + phandle = <0x9c>;
> + };
> +
> + csi@7e801000 {
> + compatible = "brcm,bcm2835-unicam";
> + reg = <0x7e801000 0x800 0x7e802004 0x04>;
> + interrupts = <0x00 0x67 0x04>;
> + clocks = <0x03 0x2e>;
> + clock-names = "lp";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + #clock-cells = <0x01>;
> + status = "disabled";
> + power-domains = <0x13 0x0d>;
> + phandle = <0x9d>;
> +
> + port {
> +
> + endpoint {
> + data-lanes = <0x01 0x02>;
> + };
> + };
> + };
> +
> + i2c@7e804000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e804000 0x1000>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x14>;
> + clock-frequency = <0x186a0>;
> + phandle = <0x24>;
> + };
> +
> + i2c@7e805000 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e805000 0x1000>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + clock-frequency = <0x186a0>;
> + phandle = <0x15>;
> + };
> +
> + vec@7e806000 {
> + compatible = "brcm,bcm2835-vec";
> + reg = <0x7e806000 0x1000>;
> + clocks = <0x03 0x18>;
> + interrupts = <0x00 0x7b 0x04>;
> + status = "disabled";
> + phandle = <0x9e>;
> + };
> +
> + pixelvalve@7e807000 {
> + compatible = "brcm,bcm2835-pixelvalve2";
> + reg = <0x7e807000 0x100>;
> + interrupts = <0x00 0x6a 0x04>;
> + status = "disabled";
> + phandle = <0x9f>;
> + };
> +
> + hdmi@7e902000 {
> + compatible = "brcm,bcm2835-hdmi";
> + reg = <0x7e902000 0x600 0x7e808000 0x100>;
> + interrupts = <0x00 0x68 0x04 0x00 0x69 0x04>;
> + ddc = <0x15>;
> + clocks = <0x03 0x10 0x03 0x19>;
> + clock-names = "pixel\0hdmi";
> + dmas = <0x0a 0x11>;
> + dma-names = "audio-rx";
> + status = "disabled";
> + power-domains = <0x13 0x05>;
> + phandle = <0xa0>;
> + };
> +
> + usb@7e980000 {
> + compatible = "brcm,bcm2708-usb";
> + reg = <0x7e980000 0x10000 0x7e00b200 0x200>;
> + interrupts = <0x00 0x49 0x04 0x00 0x28 0x04>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + clocks = <0x16>;
> + clock-names = "otg";
> + phys = <0x17>;
> + phy-names = "usb2-phy";
> + interrupt-names = "usb\0soft";
> + power-domains = <0x13 0x06>;
> + phandle = <0xa1>;
> + };
> +
> + gpu {
> + compatible = "brcm,bcm2835-vc4";
> + status = "disabled";
> + phandle = <0xa2>;
> + };
> +
> + local_intc@40000000 {
> + compatible = "brcm,bcm2836-l1-intc";
> + reg = <0x40000000 0x100>;
> + phandle = <0xa3>;
> + };
> +
> + gic400@40041000 {
> + interrupt-controller;
> + #interrupt-cells = <0x03>;
> + compatible = "arm,gic-400";
> + reg = <0x40041000 0x1000 0x40042000 0x2000
> 0x40046000 0x2000 0x40048000 0x2000>;
> + phandle = <0x01>;
> + };
> +
> + thermal@7d5d2200 {
> + compatible = "brcm,avs-tmon-bcm2838";
> + reg = <0x7d5d2200 0x2c>;
> + interrupts = <0x00 0x89 0x04>;
> + interrupt-names = "tmon";
> + clocks = <0x03 0x1b>;
> + #thermal-sensor-cells = <0x00>;
> + status = "okay";
> + phandle = <0x02>;
> + };
> +
> + serial@7e201400 {
> + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201400 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa4>;
> + };
> +
> + serial@7e201600 {
> + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201600 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa5>;
> + };
> +
> + serial@7e201800 {
> + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201800 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa6>;
> + };
> +
> + serial@7e201a00 {
> + compatible =
> "brcm,bcm2835-pl011\0arm,pl011\0arm,primecell";
> + reg = <0x7e201a00 0x200>;
> + interrupts = <0x00 0x79 0x04>;
> + clocks = <0x03 0x13 0x03 0x14>;
> + clock-names = "uartclk\0apb_pclk";
> + arm,primecell-periphid = <0x241011>;
> + status = "disabled";
> + phandle = <0xa7>;
> + };
> +
> + spi@7e204600 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204600 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xa8>;
> + };
> +
> + spi@7e204800 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204800 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xa9>;
> + };
> +
> + spi@7e204a00 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204a00 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xaa>;
> + };
> +
> + spi@7e204c00 {
> + compatible = "brcm,bcm2835-spi";
> + reg = <0x7e204c00 0x200>;
> + interrupts = <0x00 0x76 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xab>;
> + };
> +
> + i2c@7e205600 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205600 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xac>;
> + };
> +
> + i2c@7e205800 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205800 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xad>;
> + };
> +
> + i2c@7e205a00 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205a00 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xae>;
> + };
> +
> + i2c@7e205c00 {
> + compatible = "brcm,bcm2835-i2c";
> + reg = <0x7e205c00 0x200>;
> + interrupts = <0x00 0x75 0x04>;
> + clocks = <0x03 0x14>;
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + status = "disabled";
> + phandle = <0xaf>;
> + };
> +
> + emmc2@7e340000 {
> + compatible = "brcm,bcm2711-emmc2";
> + status = "okay";
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x33>;
> + reg = <0x7e340000 0x100>;
> + broken-cd;
> + vqmmc-supply = <0x18>;
> + phandle = <0xb0>;
> + };
> +
> + mmc@7e300000 {
> + compatible =
> "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> + reg = <0x7e300000 0x100>;
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x1c>;
> + dmas = <0x0a 0x0b>;
> + dma-names = "rx-tx";
> + brcm,overclock-50 = <0x00>;
> + status = "disabled";
> + phandle = <0x28>;
> + };
> +
> + mmcnr@7e300000 {
> + compatible =
> "brcm,bcm2835-mmc\0brcm,bcm2835-sdhci";
> + reg = <0x7e300000 0x100>;
> + interrupts = <0x00 0x7e 0x04>;
> + clocks = <0x03 0x1c>;
> + dmas = <0x0a 0x0b>;
> + dma-names = "rx-tx";
> + brcm,overclock-50 = <0x00>;
> + non-removable;
> + status = "okay";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x19>;
> + bus-width = <0x04>;
> + phandle = <0x29>;
> + };
> +
> + firmwarekms@7e600000 {
> + compatible = "raspberrypi,rpi-firmware-kms";
> + reg = <0x7e600000 0x100>;
> + interrupts = <0x00 0x70 0x04>;
> + brcm,firmware = <0x07>;
> + status = "disabled";
> + phandle = <0xb1>;
> + };
> +
> + smi@7e600000 {
> + compatible = "brcm,bcm2835-smi";
> + reg = <0x7e600000 0x100>;
> + interrupts = <0x00 0x70 0x04>;
> + clocks = <0x03 0x2a>;
> + assigned-clocks = <0x03 0x2a>;
> + assigned-clock-rates = <0x7735940>;
> + dmas = <0x0a 0x04>;
> + dma-names = "rx-tx";
> + status = "disabled";
> + phandle = <0xb2>;
> + };
> +
> + axiperf {
> + compatible = "brcm,bcm2835-axiperf";
> + reg = <0x7e009800 0x100 0x7ee08000 0x100>;
> + firmware = <0x07>;
> + status = "disabled";
> + phandle = <0x2a>;
> + };
> +
> + gpiomem {
> + compatible = "brcm,bcm2835-gpiomem";
> + reg = <0x7e200000 0x1000>;
> + };
> +
> + firmware {
> + compatible =
> "raspberrypi,bcm2835-firmware\0simple-bus";
> + #address-cells = <0x00>;
> + #size-cells = <0x00>;
> + mboxes = <0x1a>;
> + phandle = <0x07>;
> +
> + expgpio {
> + compatible = "raspberrypi,firmware-gpio";
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + status = "okay";
> + phandle = <0x2d>;
> + };
> + };
> +
> + power {
> + compatible = "raspberrypi,bcm2835-power";
> + firmware = <0x07>;
> + #power-domain-cells = <0x01>;
> + phandle = <0x13>;
> + };
> +
> + fb {
> + compatible = "brcm,bcm2708-fb";
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb3>;
> + };
> +
> + vcsm {
> + compatible = "raspberrypi,bcm2835-vcsm";
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb4>;
> + };
> +
> + audio {
> + compatible = "brcm,bcm2835-audio";
> + brcm,pwm-channels = <0x08>;
> + status = "disabled";
> + pinctrl-names = "default";
> + pinctrl-0 = <0x1b>;
> + phandle = <0x25>;
> + };
> +
> + sound {
> + status = "disabled";
> + phandle = <0xb5>;
> + };
> +
> + virtgpio {
> + compatible = "brcm,bcm2835-virtgpio";
> + gpio-controller;
> + #gpio-cells = <0x02>;
> + firmware = <0x07>;
> + status = "okay";
> + phandle = <0xb6>;
> + };
> + };
> +
> + clocks {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> +
> + clock@3 {
> + compatible = "fixed-clock";
> + reg = <0x03>;
> + #clock-cells = <0x00>;
> + clock-output-names = "osc";
> + clock-frequency = <0x337f980>;
> + phandle = <0x04>;
> + };
> +
> + clock@4 {
> + compatible = "fixed-clock";
> + reg = <0x04>;
> + #clock-cells = <0x00>;
> + clock-output-names = "otg";
> + clock-frequency = <0x1c9c3800>;
> + phandle = <0x16>;
> + };
> + };
> +
> + phy {
> + compatible = "usb-nop-xceiv";
> + #phy-cells = <0x00>;
> + phandle = <0x17>;
> + };
> +
> + arm-pmu {
> + compatible = "arm,cortex-a72-pmu\0arm,cortex-a53-pmu";
> + interrupts = <0x00 0x10 0x04 0x00 0x11 0x04 0x00 0x12 0x04
> 0x00 0x13 0x04>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <0x01 0x0d 0xf08 0x01 0x0e 0xf08 0x01 0x0b
> 0xf08 0x01 0x0a 0xf08>;
> + arm,cpu-registers-not-fw-configured;
> + always-on;
> + };
> +
> + cpus {
> + #address-cells = <0x01>;
> + #size-cells = <0x00>;
> + enable-method = "brcm,bcm2836-smp";
> + phandle = <0xb7>;
> +
> + cpu@0 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x00>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xd8>;
> + phandle = <0xb8>;
> + };
> +
> + cpu@1 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x01>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xe0>;
> + phandle = <0xb9>;
> + };
> +
> + cpu@2 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x02>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xe8>;
> + phandle = <0xba>;
> + };
> +
> + cpu@3 {
> + device_type = "cpu";
> + compatible = "arm,cortex-a72";
> + reg = <0x03>;
> + enable-method = "spin-table";
> + cpu-release-addr = <0x00 0xf0>;
> + phandle = <0xbb>;
> + };
> + };
> +
> + v3dbus {
> + compatible = "simple-bus";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + ranges = <0x7c500000 0x00 0xfc500000 0x3300000 0x40000000
> 0x00 0xff800000 0x800000>;
> + dma-ranges = <0x00 0x00 0x00 0x3c000000>;
> +
> + v3d@7ec04000 {
> + compatible = "brcm,2711-v3d";
> + reg = <0x7ec00000 0x4000 0x7ec04000 0x4000>;
> + reg-names = "hub\0core0";
> + power-domains = <0x1c 0x01>;
> + resets = <0x1c 0x00>;
> + clocks = <0x03 0x15>;
> + interrupts = <0x00 0x4a 0x04>;
> + status = "okay";
> + phandle = <0xbc>;
> + };
> + };
> +
> + scb {
> + compatible = "simple-bus";
> + #address-cells = <0x02>;
> + #size-cells = <0x01>;
> + ranges = <0x00 0x7c000000 0x00 0xfc000000
> + 0x3800000 0x00 0x40000000 0x00
> + 0xff800000 0x800000 0x06 0x00
> + 0x06 0x00 0x40000000 0x00
> + 0x00 0x00 0x00 0xfc000000>;
> + dma-ranges = <0x00 0x00 0x00 0x00 0xfc000000>;
> + phandle = <0xbd>;
> +
> + pcie@7d500000 {
> + reg = <0x00 0x7d500000 0x9310 0x00 0x7e00f300
> 0x20>;
> + msi-controller;
> + msi-parent = <0x1d>;
> + #address-cells = <0x03>;
> + #interrupt-cells = <0x01>;
> + #size-cells = <0x02>;
> + bus-range = <0x00 0x01>;
> + compatible =
> "brcm,bcm7211-pcie\0brcm,bcm7445-pcie\0brcm,pci-plat-dev";
> + max-link-speed = <0x02>;
> + tot-num-pcie = <0x01>;
> + linux,pci-domain = <0x00>;
> + interrupts = <0x00 0x94 0x04 0x00 0x94 0x04>;
> + interrupt-names = "pcie\0msi";
> + interrupt-map-mask = <0x00 0x00 0x00 0x07>;
> + interrupt-map = <0x00 0x00 0x00 0x01
> + 0x01 0x00 0x8f 0x04 0x00 0x00 0x00 0x02
> + 0x01 0x00 0x90 0x04 0x00 0x00 0x00 0x03
> + 0x01 0x00 0x91 0x04 0x00 0x00 0x00 0x04
> + 0x01 0x00 0x92 0x04>;
> + ranges = <0x2000000 0x00 0xf8000000 0x06 0x00 0x00
> 0x4000000>;
> + dma-ranges = <0x2000000 0x00 0x00 0x00 0x00 0x01
> 0x00>;
> + status = "okay";
> + phandle = <0x1d>;
> + };
> +
> + genet@7d580000 {
> + compatible = "brcm,genet-v5";
> + reg = <0x00 0x7d580000 0x10000>;
> + status = "okay";
> + #address-cells = <0x01>;
> + #size-cells = <0x01>;
> + interrupts = <0x00 0x9d 0x04 0x00 0x9e 0x04>;
> + phy-handle = <0x1e>;
> + phy-mode = "rgmii";
> + phandle = <0xbe>;
> +
> + mdio@e14 {
> + #address-cells = <0x00>;
> + #size-cells = <0x01>;
> + compatible = "brcm,genet-mdio-v5";
> + reg = <0xe14 0x08>;
> + reg-names = "mdio";
> +
> + genet-phy@0 {
> + compatible =
> "ethernet-phy-ieee802.3-c22";
> + max-speed = <0x3e8>;
> + reg = <0x01>;
> + phandle = <0x1e>;
> + };
> + };
> + };
> +
> + dma@7e007b00 {
> + compatible = "brcm,bcm2838-dma";
> + reg = <0x00 0x7e007b00 0x400>;
> + interrupts = <0x00 0x59 0x04 0x00 0x5a 0x04 0x00
> 0x5b
> + 0x04 0x00 0x5c 0x04>;
> + interrupt-names = "dma11\0dma12\0dma13\0dma14";
> + #dma-cells = <0x01>;
> + brcm,dma-channel-mask = <0x7000>;
> + phandle = <0xbf>;
> + };
> +
> + xhci@7e9c0000 {
> + compatible = "generic-xhci";
> + status = "disabled";
> + reg = <0x00 0x7e9c0000 0x100000>;
> + interrupts = <0x00 0xb0 0x04>;
> + phandle = <0xc0>;
> + };
> +
> + mailbox@7e00b840 {
> + compatible = "brcm,bcm2838-vchiq";
> + reg = <0x00 0x7e00b840 0x3c>;
> + interrupts = <0x00 0x22 0x04>;
> + phandle = <0xc1>;
> + };
> +
> + hevc-decoder@7eb00000 {
> + compatible = "raspberrypi,argon-hevc-decoder";
> + reg = <0x00 0x7eb00000 0x10000>;
> + status = "okay";
> + };
> +
> + argon-local-intc@7eb10000 {
> + compatible = "raspberrypi,argon-local-intc";
> + reg = <0x00 0x7eb10000 0x1000>;
> + status = "okay";
> + interrupts = <0x00 0x62 0x04>;
> + };
> +
> + h264-decoder@7eb20000 {
> + compatible = "raspberrypi,argon-h264-decoder";
> + reg = <0x00 0x7eb20000 0x10000>;
> + status = "okay";
> + };
> +
> + vp9-decoder@7eb30000 {
> + compatible = "raspberrypi,argon-vp9-decoder";
> + reg = <0x00 0x7eb30000 0x10000>;
> + status = "okay";
> + };
> + };
> +
> + fixedregulator_5v0 {
> + compatible = "regulator-fixed";
> + regulator-name = "5v0";
> + regulator-min-microvolt = <0x4c4b40>;
> + regulator-max-microvolt = <0x4c4b40>;
> + regulator-always-on;
> + phandle = <0x2e>;
> + };
> +
> + fixedregulator_3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "3v3";
> + regulator-min-microvolt = <0x325aa0>;
> + regulator-max-microvolt = <0x325aa0>;
> + regulator-always-on;
> + phandle = <0xc2>;
> + };
> +
> + __overrides__ {
> + cam0-pwdn-ctrl;
> + cam0-pwdn;
> + cam0-led-ctrl;
> + cam0-led;
> + cache_line_size;
> + uart0 = [00 00 00 1f 73 74 61 74 75 73 00];
> + uart1 = "\0\0\0 status";
> + i2s = "\0\0\0!status";
> + spi = "\0\0\0\"status";
> + i2c0 = "\0\0\0#status";
> + i2c1 = "\0\0\0$status";
> + i2c2_iknowwhatimdoing = [00 00 00 15 73 74 61 74 75 73 00];
> + i2c0_baudrate = "\0\0\0#clock-frequency:0";
> + i2c1_baudrate = "\0\0\0$clock-frequency:0";
> + i2c2_baudrate = [00 00 00 15 63 6c 6f 63
> + 6b 2d 66 72 65 71 75 65
> + 6e 63 79 3a 30 00];
> + audio = "\0\0\0%status";
> + watchdog = [00 00 00 1c 73 74 61 74 75 73 00];
> + random = "\0\0\0&status";
> + sd_overclock = "\0\0\0'brcm,overclock-50:0";
> + sd_force_pio = "\0\0\0'brcm,force-pio?";
> + sd_pio_limit = "\0\0\0'brcm,pio-limit:0";
> + sd_debug = "\0\0\0'brcm,debug";
> + sdio_overclock =
> "\0\0\0(brcm,overclock-50:0\0\0\0\0)brcm,overclock-50:0";
> + axiperf = "\0\0\0*status";
> + arm_freq;
> + act_led_gpio = "\0\0\0+gpios:4";
> + act_led_activelow = "\0\0\0+gpios:8";
> + act_led_trigger = "\0\0\0+linux,default-trigger";
> + pwr_led_gpio = "\0\0\0,gpios:4";
> + pwr_led_activelow = "\0\0\0,gpios:8";
> + pwr_led_trigger = "\0\0\0,linux,default-trigger";
> + };
> +
> + memory {
> + device_type = "memory";
> + reg = <0x00 0x00 0x00>;
> + };
> +
> + leds {
> + compatible = "gpio-leds";
> + phandle = <0xc3>;
> +
> + act {
> + label = "led0";
> + linux,default-trigger = "mmc0";
> + gpios = <0x0f 0x2a 0x00>;
> + phandle = <0x2b>;
> + };
> +
> + pwr {
> + label = "led1";
> + linux,default-trigger = "input";
> + gpios = <0x2d 0x02 0x00>;
> + phandle = <0x2c>;
> + };
> + };
> +
> + sd_io_1v8_reg {
> + status = "okay";
> + compatible = "regulator-gpio";
> + vin-supply = <0x2e>;
> + regulator-name = "vdd-sd-io";
> + regulator-min-microvolt = <0x1b7740>;
> + regulator-max-microvolt = <0x325aa0>;
> + regulator-boot-on;
> + regulator-always-on;
> + regulator-settling-time-us = <0x1388>;
> + gpios = <0x2d 0x04 0x00>;
> + states = <0x1b7740 0x01 0x325aa0 0x00>;
> + phandle = <0x18>;
> + };
> +
> + __symbols__ {
> + cpu_thermal = "/thermal-zones/cpu-thermal";
> + soc = "/soc";
> + txp = "/soc/txp@7e004000";
> + dma = "/soc/dma@7e007000";
> + watchdog = "/soc/watchdog@7e100000";
> + pm = "/soc/watchdog@7e100000";
> + clocks = "/soc/cprman@7e101000";
> + random = "/soc/rng@7e104000";
> + rng = "/soc/rng@7e104000";
> + mailbox = "/soc/mailbox@7e00b880";
> + gpio = "/soc/gpio@7e200000";
> + dpi_gpio0 = "/soc/gpio@7e200000/dpi_gpio0";
> + emmc_gpio22 = "/soc/gpio@7e200000/emmc_gpio22";
> + emmc_gpio34 = "/soc/gpio@7e200000/emmc_gpio34";
> + emmc_gpio48 = "/soc/gpio@7e200000/emmc_gpio48";
> + gpclk0_gpio4 = "/soc/gpio@7e200000/gpclk0_gpio4";
> + gpclk1_gpio5 = "/soc/gpio@7e200000/gpclk1_gpio5";
> + gpclk1_gpio42 = "/soc/gpio@7e200000/gpclk1_gpio42";
> + gpclk1_gpio44 = "/soc/gpio@7e200000/gpclk1_gpio44";
> + gpclk2_gpio6 = "/soc/gpio@7e200000/gpclk2_gpio6";
> + gpclk2_gpio43 = "/soc/gpio@7e200000/gpclk2_gpio43";
> + i2c0_gpio0 = "/soc/gpio@7e200000/i2c0_gpio0";
> + i2c0_gpio28 = "/soc/gpio@7e200000/i2c0_gpio28";
> + i2c0_gpio44 = "/soc/gpio@7e200000/i2c0_gpio44";
> + i2c1_gpio2 = "/soc/gpio@7e200000/i2c1_gpio2";
> + i2c1_gpio44 = "/soc/gpio@7e200000/i2c1_gpio44";
> + jtag_gpio22 = "/soc/gpio@7e200000/jtag_gpio22";
> + pcm_gpio18 = "/soc/gpio@7e200000/pcm_gpio18";
> + pcm_gpio28 = "/soc/gpio@7e200000/pcm_gpio28";
> + pwm0_gpio12 = "/soc/gpio@7e200000/pwm0_gpio12";
> + pwm0_gpio18 = "/soc/gpio@7e200000/pwm0_gpio18";
> + pwm0_gpio40 = "/soc/gpio@7e200000/pwm0_gpio40";
> + pwm1_gpio13 = "/soc/gpio@7e200000/pwm1_gpio13";
> + pwm1_gpio19 = "/soc/gpio@7e200000/pwm1_gpio19";
> + pwm1_gpio41 = "/soc/gpio@7e200000/pwm1_gpio41";
> + pwm1_gpio45 = "/soc/gpio@7e200000/pwm1_gpio45";
> + sdhost_pins = "/soc/gpio@7e200000/sdhost_gpio48";
> + sdhost_gpio48 = "/soc/gpio@7e200000/sdhost_gpio48";
> + spi0_gpio7 = "/soc/gpio@7e200000/spi0_gpio7";
> + spi0_gpio35 = "/soc/gpio@7e200000/spi0_gpio35";
> + spi1_gpio16 = "/soc/gpio@7e200000/spi1_gpio16";
> + spi2_gpio40 = "/soc/gpio@7e200000/spi2_gpio40";
> + uart0_gpio14 = "/soc/gpio@7e200000/uart0_gpio14";
> + uart0_ctsrts_gpio16 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio16";
> + uart0_ctsrts_gpio30 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio30";
> + uart0_gpio32 = "/soc/gpio@7e200000/uart0_gpio32";
> + uart0_gpio36 = "/soc/gpio@7e200000/uart0_gpio36";
> + uart0_ctsrts_gpio38 = "/soc/gpio@7e200000
> /uart0_ctsrts_gpio38";
> + uart1_gpio14 = "/soc/gpio@7e200000/uart1_gpio14";
> + uart1_ctsrts_gpio16 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio16";
> + uart1_gpio32 = "/soc/gpio@7e200000/uart1_gpio32";
> + uart1_ctsrts_gpio30 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio30";
> + uart1_gpio40 = "/soc/gpio@7e200000/uart1_gpio40";
> + uart1_ctsrts_gpio42 = "/soc/gpio@7e200000
> /uart1_ctsrts_gpio42";
> + gpclk0_gpio49 = "/soc/gpio@7e200000/gpclk0_gpio49";
> + gpclk1_gpio50 = "/soc/gpio@7e200000/gpclk1_gpio50";
> + gpclk2_gpio51 = "/soc/gpio@7e200000/gpclk2_gpio51";
> + i2c0_gpio46 = "/soc/gpio@7e200000/i2c0_gpio46";
> + i2c1_gpio46 = "/soc/gpio@7e200000/i2c1_gpio46";
> + i2c3_gpio2 = "/soc/gpio@7e200000/i2c3_gpio2";
> + i2c3_gpio4 = "/soc/gpio@7e200000/i2c3_gpio4";
> + i2c4_gpio6 = "/soc/gpio@7e200000/i2c4_gpio6";
> + i2c4_gpio8 = "/soc/gpio@7e200000/i2c4_gpio8";
> + i2c5_gpio10 = "/soc/gpio@7e200000/i2c5_gpio10";
> + i2c5_gpio12 = "/soc/gpio@7e200000/i2c5_gpio12";
> + i2c6_gpio0 = "/soc/gpio@7e200000/i2c6_gpio0";
> + i2c6_gpio22 = "/soc/gpio@7e200000/i2c6_gpio22";
> + i2c_slave_gpio8 = "/soc/gpio@7e200000/i2c_slave_gpio8";
> + jtag_gpio48 = "/soc/gpio@7e200000/jtag_gpio48";
> + mii_gpio28 = "/soc/gpio@7e200000/mii_gpio28";
> + mii_gpio36 = "/soc/gpio@7e200000/mii_gpio36";
> + pcm_gpio50 = "/soc/gpio@7e200000/pcm_gpio50";
> + pwm0_gpio52 = "/soc/gpio@7e200000/pwm0_gpio52";
> + pwm1_gpio53 = "/soc/gpio@7e200000/pwm1_gpio53";
> + rgmii_gpio35 = "/soc/gpio@7e200000/rgmii_gpio35";
> + rgmii_irq_gpio34 = "/soc/gpio@7e200000/rgmii_irq_gpio34";
> + rgmii_irq_gpio39 = "/soc/gpio@7e200000/rgmii_irq_gpio39";
> + rgmii_mdio_gpio28 = "/soc/gpio@7e200000
> /rgmii_mdio_gpio28";
> + rgmii_mdio_gpio37 = "/soc/gpio@7e200000
> /rgmii_mdio_gpio37";
> + spi0_gpio46 = "/soc/gpio@7e200000/spi0_gpio46";
> + spi2_gpio46 = "/soc/gpio@7e200000/spi2_gpio46";
> + spi3_gpio0 = "/soc/gpio@7e200000/spi3_gpio0";
> + spi4_gpio4 = "/soc/gpio@7e200000/spi4_gpio4";
> + spi5_gpio12 = "/soc/gpio@7e200000/spi5_gpio12";
> + spi6_gpio18 = "/soc/gpio@7e200000/spi6_gpio18";
> + uart2_gpio0 = "/soc/gpio@7e200000/uart2_gpio0";
> + uart2_ctsrts_gpio2 = "/soc/gpio@7e200000
> /uart2_ctsrts_gpio2";
> + uart3_gpio4 = "/soc/gpio@7e200000/uart3_gpio4";
> + uart3_ctsrts_gpio6 = "/soc/gpio@7e200000
> /uart3_ctsrts_gpio6";
> + uart4_gpio8 = "/soc/gpio@7e200000/uart4_gpio8";
> + uart4_ctsrts_gpio10 = "/soc/gpio@7e200000
> /uart4_ctsrts_gpio10";
> + uart5_gpio12 = "/soc/gpio@7e200000/uart5_gpio12";
> + uart5_ctsrts_gpio14 = "/soc/gpio@7e200000
> /uart5_ctsrts_gpio14";
> + dpi_18bit_gpio0 = "/soc/gpio@7e200000/dpi_18bit_gpio0";
> + spi0_pins = "/soc/gpio@7e200000/spi0_pins";
> + spi0_cs_pins = "/soc/gpio@7e200000/spi0_cs_pins";
> + spi3_pins = "/soc/gpio@7e200000/spi3_pins";
> + spi3_cs_pins = "/soc/gpio@7e200000/spi3_cs_pins";
> + spi4_pins = "/soc/gpio@7e200000/spi4_pins";
> + spi4_cs_pins = "/soc/gpio@7e200000/spi4_cs_pins";
> + spi5_pins = "/soc/gpio@7e200000/spi5_pins";
> + spi5_cs_pins = "/soc/gpio@7e200000/spi5_cs_pins";
> + spi6_pins = "/soc/gpio@7e200000/spi6_pins";
> + spi6_cs_pins = "/soc/gpio@7e200000/spi6_cs_pins";
> + i2c0_pins = "/soc/gpio@7e200000/i2c0";
> + i2c1_pins = "/soc/gpio@7e200000/i2c1";
> + i2c3_pins = "/soc/gpio@7e200000/i2c3";
> + i2c4_pins = "/soc/gpio@7e200000/i2c4";
> + i2c5_pins = "/soc/gpio@7e200000/i2c5";
> + i2c6_pins = "/soc/gpio@7e200000/i2c6";
> + i2s_pins = "/soc/gpio@7e200000/i2s";
> + sdio_pins = "/soc/gpio@7e200000/sdio_pins";
> + bt_pins = "/soc/gpio@7e200000/bt_pins";
> + uart0_pins = "/soc/gpio@7e200000/uart0_pins";
> + uart1_pins = "/soc/gpio@7e200000/uart1_pins";
> + uart2_pins = "/soc/gpio@7e200000/uart2_pins";
> + uart3_pins = "/soc/gpio@7e200000/uart3_pins";
> + uart4_pins = "/soc/gpio@7e200000/uart4_pins";
> + uart5_pins = "/soc/gpio@7e200000/uart5_pins";
> + audio_pins = "/soc/gpio@7e200000/audio_pins";
> + uart0 = "/soc/serial@7e201000";
> + sdhost = "/soc/mmc@7e202000";
> + i2s = "/soc/i2s@7e203000";
> + spi0 = "/soc/spi@7e204000";
> + spi = "/soc/spi@7e204000";
> + spidev0 = "/soc/spi@7e204000/spidev@0";
> + spidev1 = "/soc/spi@7e204000/spidev@1";
> + i2c0 = "/soc/i2c@7e205000";
> + pixelvalve0 = "/soc/pixelvalve@7e206000";
> + pixelvalve1 = "/soc/pixelvalve@7e207000";
> + dpi = "/soc/dpi@7e208000";
> + dsi0 = "/soc/dsi@7e209000";
> + aux = "/soc/aux@7e215000";
> + uart1 = "/soc/serial@7e215040";
> + spi1 = "/soc/spi@7e215080";
> + spi2 = "/soc/spi@7e2150c0";
> + pwm = "/soc/pwm@7e20c000";
> + hvs = "/soc/hvs@7e400000";
> + dsi1 = "/soc/dsi@7e700000";
> + csi0 = "/soc/csi@7e800000";
> + csi1 = "/soc/csi@7e801000";
> + i2c1 = "/soc/i2c@7e804000";
> + i2c2 = "/soc/i2c@7e805000";
> + vec = "/soc/vec@7e806000";
> + pixelvalve2 = "/soc/pixelvalve@7e807000";
> + hdmi = "/soc/hdmi@7e902000";
> + usb = "/soc/usb@7e980000";
> + vc4 = "/soc/gpu";
> + local_intc = "/soc/local_intc@40000000";
> + gicv2 = "/soc/gic400@40041000";
> + thermal = "/soc/thermal@7d5d2200";
> + uart2 = "/soc/serial@7e201400";
> + uart3 = "/soc/serial@7e201600";
> + uart4 = "/soc/serial@7e201800";
> + uart5 = "/soc/serial@7e201a00";
> + spi3 = "/soc/spi@7e204600";
> + spi4 = "/soc/spi@7e204800";
> + spi5 = "/soc/spi@7e204a00";
> + spi6 = "/soc/spi@7e204c00";
> + i2c3 = "/soc/i2c@7e205600";
> + i2c4 = "/soc/i2c@7e205800";
> + i2c5 = "/soc/i2c@7e205a00";
> + i2c6 = "/soc/i2c@7e205c00";
> + emmc2 = "/soc/emmc2@7e340000";
> + mmc = "/soc/mmc@7e300000";
> + mmcnr = "/soc/mmcnr@7e300000";
> + firmwarekms = "/soc/firmwarekms@7e600000";
> + smi = "/soc/smi@7e600000";
> + axiperf = "/soc/axiperf";
> + firmware = "/soc/firmware";
> + expgpio = "/soc/firmware/expgpio";
> + power = "/soc/power";
> + fb = "/soc/fb";
> + vcsm = "/soc/vcsm";
> + audio = "/soc/audio";
> + sound = "/soc/sound";
> + virtgpio = "/soc/virtgpio";
> + clk_osc = "/clocks/clock@3";
> + clk_usb = "/clocks/clock@4";
> + usbphy = "/phy";
> + cpus = "/cpus";
> + cpu0 = "/cpus/cpu@0";
> + cpu1 = "/cpus/cpu@1";
> + cpu2 = "/cpus/cpu@2";
> + cpu3 = "/cpus/cpu@3";
> + v3d = "/v3dbus/v3d@7ec04000";
> + scb = "/scb";
> + pcie_0 = "/scb/pcie@7d500000";
> + genet = "/scb/genet@7d580000";
> + phy1 = "/scb/genet@7d580000/mdio@e14/genet-phy@0";
> + dma40 = "/scb/dma@7e007b00";
> + xhci = "/scb/xhci@7e9c0000";
> + vchiq = "/scb/mailbox@7e00b840";
> + vdd_5v0_reg = "/fixedregulator_5v0";
> + vdd_3v3_reg = "/fixedregulator_3v3";
> + leds = "/leds";
> + act_led = "/leds/act";
> + pwr_led = "/leds/pwr";
> + sd_io_1v8_reg = "/sd_io_1v8_reg";
> + };
> +};
> diff --git a/configs/rpi_4_32b_defconfig b/configs/rpi_4_32b_defconfig
> index d592df50706..31d77dbe4eb 100644
> --- a/configs/rpi_4_32b_defconfig
> +++ b/configs/rpi_4_32b_defconfig
> @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
> CONFIG_TARGET_RPI_4_32B=y
> CONFIG_SYS_MALLOC_F_LEN=0x2000
> CONFIG_ENV_SIZE=0x4000
> +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x1000000
> CONFIG_OF_BOARD_SETUP=y
> diff --git a/configs/rpi_4_defconfig b/configs/rpi_4_defconfig
> index ab5cc90d912..a2a88d66dbd 100644
> --- a/configs/rpi_4_defconfig
> +++ b/configs/rpi_4_defconfig
> @@ -4,6 +4,7 @@ CONFIG_SYS_TEXT_BASE=0x00080000
> CONFIG_TARGET_RPI_4=y
> CONFIG_SYS_MALLOC_F_LEN=0x2000
> CONFIG_ENV_SIZE=0x4000
> +CONFIG_DEFAULT_DEVICE_TREE="bcm2711-rpi-4-b"
> CONFIG_DISTRO_DEFAULTS=y
> CONFIG_SYS_LOAD_ADDR=0x1000000
> CONFIG_OF_BOARD_SETUP=y
> diff --git a/configs/rpi_arm64_defconfig b/configs/rpi_arm64_defconfig
> index 382d99dc2eb..fb8abbccc45 100644
> --- a/configs/rpi_arm64_defconfig
> +++ b/configs/rpi_arm64_defconfig
> @@ -6,6 +6,7 @@ CONFIG_S
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 08/16] arm: vexpress: Add a devicetree file for juno
2021-10-13 1:01 ` Simon Glass
` (7 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Bin Meng, Christian Hewitt, Fabio Estevam,
Heiko Schocher, Jagan Teki, Kever Yang, Linus Walleij,
Liviu Dudau, Neil Armstrong, Peter Robinson, Rick Chen,
Sean Anderson, Tim Harvey
Add this file, obtained from the Linaro website[1], so there is a
reference file in the U-Boot tree.
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.
[1] https://releases.linaro.org/android/reference-lcr/juno/7.1-17.05/
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/dts/Makefile | 3 +
arch/arm/dts/juno-r2.dts | 1038 ++++++++++++++++++++++++
configs/vexpress_aemv8a_juno_defconfig | 1 +
3 files changed, 1042 insertions(+)
create mode 100644 arch/arm/dts/juno-r2.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index efc01a70bf2..57f06670b23 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1134,7 +1134,10 @@ dtb-$(CONFIG_TARGET_GE_BX50V3) += \
dtb-$(CONFIG_TARGET_GE_B1X5V2) += imx6dl-b1x5v2.dtb
dtb-$(CONFIG_TARGET_MX53PPD) += imx53-ppd.dtb
+# TODO(Linus Walleij <linus.walleij@linaro.org>): Should us a single vexpress
+# Kconfig option to build all of these. See examples above.
dtb-$(CONFIG_TARGET_VEXPRESS_CA9X4) += vexpress-v2p-ca9.dtb
+dtb-$(CONFIG_TARGET_VEXPRESS64_JUNO) += juno-r2.dtb
dtb-$(CONFIG_TARGET_TOTAL_COMPUTE) += total_compute.dtb
diff --git a/arch/arm/dts/juno-r2.dts b/arch/arm/dts/juno-r2.dts
new file mode 100644
index 00000000000..5a536d8100e
--- /dev/null
+++ b/arch/arm/dts/juno-r2.dts
@@ -0,0 +1,1038 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for juno
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ model = "ARM Juno development board (r2)";
+ compatible = "arm,juno-r2\0arm,juno";
+ interrupt-parent = <0x01>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+
+ aliases {
+ serial0 = "/uart@7ff80000";
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ psci {
+ compatible = "arm,psci-0.2";
+ method = "smc";
+ };
+
+ cpus {
+ #address-cells = <0x02>;
+ #size-cells = <0x00>;
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x02>;
+ };
+
+ core1 {
+ cpu = <0x03>;
+ };
+ };
+
+ cluster1 {
+
+ core0 {
+ cpu = <0x04>;
+ };
+
+ core1 {
+ cpu = <0x05>;
+ };
+
+ core2 {
+ cpu = <0x06>;
+ };
+
+ core3 {
+ cpu = <0x07>;
+ };
+ };
+ };
+
+ idle-states {
+ entry-method = "arm,psci";
+
+ cpu-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x10000>;
+ local-timer-stop;
+ entry-latency-us = <0x12c>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x7d0>;
+ linux,phandle = <0x0a>;
+ phandle = <0x0a>;
+ };
+
+ cluster-sleep-0 {
+ compatible = "arm,idle-state";
+ arm,psci-suspend-param = <0x1010000>;
+ local-timer-stop;
+ entry-latency-us = <0x190>;
+ exit-latency-us = <0x4b0>;
+ min-residency-us = <0x9c4>;
+ linux,phandle = <0x0b>;
+ phandle = <0x0b>;
+ };
+ };
+
+ cpu@0 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg = <0x00 0x00>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x08>;
+ clocks = <0x09 0x00>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0c 0x0d>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x1c2>;
+ linux,phandle = <0x02>;
+ phandle = <0x02>;
+ };
+
+ cpu@1 {
+ compatible = "arm,cortex-a72\0arm,armv8";
+ reg = <0x00 0x01>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x08>;
+ clocks = <0x09 0x00>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0c 0x0d>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x1c2>;
+ linux,phandle = <0x03>;
+ phandle = <0x03>;
+ };
+
+ cpu@100 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x100>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x04>;
+ phandle = <0x04>;
+ };
+
+ cpu@101 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x101>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x05>;
+ phandle = <0x05>;
+ };
+
+ cpu@102 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x102>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x06>;
+ phandle = <0x06>;
+ };
+
+ cpu@103 {
+ compatible = "arm,cortex-a53\0arm,armv8";
+ reg = <0x00 0x103>;
+ device_type = "cpu";
+ enable-method = "psci";
+ next-level-cache = <0x0e>;
+ clocks = <0x09 0x01>;
+ cpu-idle-states = <0x0a 0x0b>;
+ sched-energy-costs = <0x0f 0x10>;
+ #cooling-cells = <0x02>;
+ dynamic-power-coefficient = <0x8c>;
+ linux,phandle = <0x07>;
+ phandle = <0x07>;
+ };
+
+ l2-cache0 {
+ compatible = "cache";
+ linux,phandle = <0x08>;
+ phandle = <0x08>;
+ };
+
+ l2-cache1 {
+ compatible = "cache";
+ linux,phandle = <0x0e>;
+ phandle = <0x0e>;
+ };
+
+ energy-costs {
+
+ core-cost0 {
+ busy-cost-data = <0x1f5 0xae 0x351 0x158 0x3ff 0x20e>;
+ idle-cost-data = <0x30 0x30 0x00 0x00>;
+ linux,phandle = <0x0c>;
+ phandle = <0x0c>;
+ };
+
+ core-cost1 {
+ busy-cost-data = <0x114 0x25 0x1f5 0x3b 0x251 0x75>;
+ idle-cost-data = <0x21 0x21 0x00 0x00>;
+ linux,phandle = <0x0f>;
+ phandle = <0x0f>;
+ };
+
+ cluster-cost0 {
+ busy-cost-data = <0x1f5 0x30 0x351 0x49 0x400 0x6b>;
+ idle-cost-data = <0x30 0x30 0x30 0x12>;
+ linux,phandle = <0x0d>;
+ phandle = <0x0d>;
+ };
+
+ cluster-cost1 {
+ busy-cost-data = <0x114 0x29 0x1f5 0x56 0x251 0x6b>;
+ idle-cost-data = <0x29 0x29 0x29 0x0e>;
+ linux,phandle = <0x10>;
+ phandle = <0x10>;
+ };
+ };
+ };
+
+ pmu_a72 {
+ compatible = "arm,cortex-a72-pmu";
+ interrupts = <0x00 0x02 0x04 0x00 0x06 0x04>;
+ interrupt-affinity = <0x02 0x03>;
+ };
+
+ pmu_a53 {
+ compatible = "arm,cortex-a53-pmu";
+ interrupts = <0x00 0x12 0x04 0x00 0x16 0x04 0x00 0x1a 0x04 0x00 0x1e 0x04>;
+ interrupt-affinity = <0x04 0x05 0x06 0x07>;
+ };
+
+ timer@2a810000 {
+ compatible = "arm,armv7-timer-mem";
+ reg = <0x00 0x2a810000 0x00 0x10000>;
+ clock-frequency = <0x2faf080>;
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ ranges;
+ status = "okay";
+
+ frame@2a830000 {
+ frame-number = <0x01>;
+ interrupts = <0x00 0x3c 0x04>;
+ reg = <0x00 0x2a830000 0x00 0x10000>;
+ };
+ };
+
+ mhu@2b1f0000 {
+ compatible = "arm,mhu\0arm,primecell";
+ reg = <0x00 0x2b1f0000 0x00 0x1000>;
+ interrupts = <0x00 0x24 0x04 0x00 0x23 0x04>;
+ interrupt-names = "mhu_lpri_rx\0mhu_hpri_rx";
+ #mbox-cells = <0x01>;
+ clocks = <0x11>;
+ clock-names = "apb_pclk";
+ linux,phandle = <0x13>;
+ phandle = <0x13>;
+ };
+
+ interrupt-controller@2c010000 {
+ compatible = "arm,gic-400\0arm,cortex-a15-gic";
+ reg = <0x00 0x2c010000 0x00 0x1000
+ 0x00 0x2c02f000 0x00 0x2000
+ 0x00 0x2c04f000 0x00 0x2000
+ 0x00 0x2c06f000 0x00 0x2000>;
+ #address-cells = <0x02>;
+ #interrupt-cells = <0x03>;
+ #size-cells = <0x02>;
+ interrupt-controller;
+ interrupts = <0x01 0x09 0x3f04>;
+ ranges = <0x00 0x00 0x00 0x2c1c0000 0x00 0x40000>;
+ linux,phandle = <0x01>;
+ phandle = <0x01>;
+
+ v2m@0 {
+ compatible = "arm,gic-v2m-frame";
+ msi-controller;
+ reg = <0x00 0x00 0x00 0x1000>;
+ linux,phandle = <0x12>;
+ phandle = <0x12>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <0x01 0x0d 0x3f08 0x01 0x0e 0x3f08 0x01 0x0b 0x3f08 0x01 0x0a 0x3f08>;
+ };
+
+ sram@2e000000 {
+ compatible = "arm,juno-sram-ns\0mmio-sram";
+ reg = <0x00 0x2e000000 0x00 0x8000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x2e000000 0x8000>;
+
+ scp-shmem@0 {
+ compatible = "arm,juno-scp-shmem";
+ reg = <0x00 0x200>;
+ };
+
+ scp-shmem@200 {
+ compatible = "arm,juno-scp-shmem";
+ reg = <0x200 0x200>;
+ linux,phandle = <0x14>;
+ phandle = <0x14>;
+ };
+ };
+
+ pcie-controller@40000000 {
+ compatible = "arm,juno-r1-pcie\0plda,xpressrich3-axi\0pci-host-ecam-generic";
+ device_type = "pci";
+ reg = <0x00 0x40000000 0x00 0x10000000>;
+ bus-range = <0x00 0xff>;
+ linux,pci-domain = <0x00>;
+ #address-cells = <0x03>;
+ #size-cells = <0x02>;
+ dma-coherent;
+ ranges = <0x1000000 0x00 0x00 0x00
+ 0x5f800000 0x00 0x800000 0x2000000
+ 0x00 0x50000000 0x00 0x50000000
+ 0x00 0x8000000 0x42000000 0x40
+ 0x00 0x40 0x00 0x01 0x00>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00 0x00 0x07>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x01 0x00 0x00 0x00
+ 0x88 0x04 0x00 0x00 0x00 0x02 0x01 0x00
+ 0x00 0x00 0x89 0x04 0x00 0x00 0x00 0x03
+ 0x01 0x00 0x00 0x00 0x8a 0x04 0x00 0x00
+ 0x00 0x04 0x01 0x00 0x00 0x00 0x8b 0x04>;
+ msi-parent = <0x12>;
+ status = "okay";
+ };
+
+ scpi {
+ compatible = "arm,scpi";
+ mboxes = <0x13 0x01>;
+ shmem = <0x14>;
+
+ clocks {
+ compatible = "arm,scpi-clocks";
+
+ scpi-dvfs {
+ compatible = "arm,scpi-dvfs-clocks";
+ #clock-cells = <0x01>;
+ clock-indices = <0x00 0x01 0x02>;
+ clock-output-names = "atlclk\0aplclk\0clk_mali";
+ linux,phandle = <0x09>;
+ phandle = <0x09>;
+ };
+
+ scpi-clk {
+ compatible = "arm,scpi-variable-clocks";
+ #clock-cells = <0x01>;
+ clock-indices = <0x03 0x04 0x05>;
+ clock-output-names = "pxlclk\0pxlclk1\0i2sclk";
+ linux,phandle = <0x19>;
+ phandle = <0x19>;
+ };
+ };
+
+ scpi-power-domains {
+ compatible = "arm,scpi-power-domains";
+ num-domains = <0x02>;
+ #power-domain-cells = <0x01>;
+ linux,phandle = <0x22>;
+ phandle = <0x22>;
+ };
+
+ sensors {
+ compatible = "arm,scpi-sensors";
+ #thermal-sensor-cells = <0x01>;
+ linux,phandle = <0x15>;
+ phandle = <0x15>;
+ };
+ };
+
+ thermal-zones {
+
+ pmic {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x00>;
+ };
+
+ soc {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ sustainable-power = <0x9c4>;
+ thermal-sensors = <0x15 0x03>;
+
+ trips {
+
+ threshold {
+ temperature = <0xd6d8>;
+ hysteresis = <0x3e8>;
+ type = "passive";
+ };
+
+ target {
+ temperature = <0xfde8>;
+ hysteresis = <0x3e8>;
+ type = "passive";
+ linux,phandle = <0x16>;
+ phandle = <0x16>;
+ };
+ };
+
+ cooling-maps {
+
+ map0 {
+ trip = <0x16>;
+ cooling-device = <0x04 0xffffffff 0xffffffff>;
+ contribution = <0x800>;
+ };
+
+ map1 {
+ trip = <0x16>;
+ contribution = <0x400>;
+ cooling-device = <0x02 0xffffffff 0xffffffff>;
+ };
+
+ map2 {
+ trip = <0x16>;
+ cooling-device = <0x17 0xffffffff 0xffffffff>;
+ contribution = <0x400>;
+ };
+ };
+ };
+
+ big_cluster {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x15>;
+ status = "okay";
+ };
+
+ little_cluster {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x16>;
+ status = "okay";
+ };
+
+ gpu0 {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x17>;
+ status = "okay";
+ };
+
+ gpu1 {
+ polling-delay = <0x3e8>;
+ polling-delay-passive = <0x64>;
+ thermal-sensors = <0x15 0x18>;
+ status = "okay";
+ };
+ };
+
+ refclk7273800hz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x6efd48>;
+ clock-output-names = "juno:uartclk";
+ linux,phandle = <0x1b>;
+ phandle = <0x1b>;
+ };
+
+ clk48mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x2dc6c00>;
+ clock-output-names = "clk48mhz";
+ linux,phandle = <0x1e>;
+ phandle = <0x1e>;
+ };
+
+ clk50mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x2faf080>;
+ clock-output-names = "smc_clk";
+ linux,phandle = <0x1c>;
+ phandle = <0x1c>;
+ };
+
+ refclk100mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x5f5e100>;
+ clock-output-names = "apb_pclk";
+ linux,phandle = <0x11>;
+ phandle = <0x11>;
+ };
+
+ refclk400mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d78400>;
+ clock-output-names = "faxi_clk";
+ linux,phandle = <0x18>;
+ phandle = <0x18>;
+ };
+
+ dma@7ff00000 {
+ compatible = "arm,pl330\0arm,primecell";
+ reg = <0x00 0x7ff00000 0x00 0x1000>;
+ #dma-cells = <0x01>;
+ #dma-channels = <0x08>;
+ #dma-requests = <0x20>;
+ interrupts = <0x00 0x58 0x04 0x00 0x59 0x04 0x00 0x5a
+ 0x04 0x00 0x5b 0x04 0x00 0x5c 0x04 0x00
+ 0x6c 0x04 0x00 0x6d 0x04 0x00 0x6e 0x04
+ 0x00 0x6f 0x04>;
+ clocks = <0x18>;
+ clock-names = "apb_pclk";
+ linux,phandle = <0x1f>;
+ phandle = <0x1f>;
+ };
+
+ hdlcd@7ff60000 {
+ compatible = "arm,hdlcd";
+ reg = <0x00 0x7ff60000 0x00 0x1000>;
+ interrupts = <0x00 0x55 0x04>;
+ clocks = <0x19 0x03>;
+ clock-names = "pxlclk";
+
+ port {
+
+ hdlcd0-endpoint {
+ remote-endpoint = <0x1a>;
+ linux,phandle = <0x1d>;
+ phandle = <0x1d>;
+ };
+ };
+ };
+
+ uart@7ff80000 {
+ compatible = "arm,pl011\0arm,primecell";
+ reg = <0x00 0x7ff80000 0x00 0x1000>;
+ interrupts = <0x00 0x53 0x04>;
+ clocks = <0x1b 0x11>;
+ clock-names = "uartclk\0apb_pclk";
+ };
+
+ i2c@7ffa0000 {
+ compatible = "snps,designware-i2c";
+ reg = <0x00 0x7ffa0000 0x00 0x1000>;
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ interrupts = <0x00 0x68 0x04>;
+ clock-frequency = <0x186a0>;
+ i2c-sda-hold-time-ns = <0x1f4>;
+ clocks = <0x1c>;
+
+ hdmi-transmitter@70 {
+ compatible = "nxp,tda998x";
+ reg = <0x70>;
+ audio-ports = <0x03 0x04>;
+ audio-port-names = "i2s\0spdif";
+ #sound-dai-cells = <0x01>;
+ linux,phandle = <0x21>;
+ phandle = <0x21>;
+
+ port {
+
+ tda998x-0-endpoint {
+ remote-endpoint = <0x1d>;
+ linux,phandle = <0x1a>;
+ phandle = <0x1a>;
+ };
+ };
+ };
+
+ hdmi-transmitter@71 {
+ compatible = "nxp,tda998x";
+ reg = <0x71>;
+
+ port {
+ };
+ };
+ };
+
+ ohci@7ffb0000 {
+ compatible = "generic-ohci";
+ reg = <0x00 0x7ffb0000 0x00 0x10000>;
+ interrupts = <0x00 0x74 0x04>;
+ clocks = <0x1e>;
+ };
+
+ ehci@7ffc0000 {
+ compatible = "generic-ehci";
+ reg = <0x00 0x7ffc0000 0x00 0x10000>;
+ interrupts = <0x00 0x75 0x04>;
+ clocks = <0x1e>;
+ };
+
+ memory-controller@7ffd0000 {
+ compatible = "arm,pl354\0arm,primecell";
+ reg = <0x00 0x7ffd0000 0x00 0x1000>;
+ interrupts = <0x00 0x56 0x04 0x00 0x57 0x04>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x00 0x80000000 0x00 0x7f000000 0x08 0x80000000 0x01 0x80000000>;
+ };
+
+ reserved-memory {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ ranges;
+
+ optee@0xfee00000 {
+ reg = <0x00 0xfee00000 0x00 0x200000>;
+ no-map;
+ };
+ };
+
+ i2s@7ff90000 {
+ compatible = "snps,designware-i2s";
+ reg = <0x00 0x7ff90000 0x00 0x1000>;
+ clocks = <0x19 0x05 0x11>;
+ clock-names = "i2sclk\0apb_pclk";
+ #sound-dai-cells = <0x00>;
+ dmas = <0x1f 0x05>;
+ dma-names = "tx";
+ linux,phandle = <0x20>;
+ phandle = <0x20>;
+ };
+
+ hdmi_audio@0 {
+ compatible = "linux,hdmi-audio";
+ #sound-dai-cells = <0x00>;
+ status = "okay";
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,format = "i2s";
+
+ simple-audio-card,cpu {
+ sound-dai = <0x20>;
+ };
+
+ simple-audio-card,codec {
+ sound-dai = <0x21 0x00>;
+ };
+ };
+
+ gpu@0x2d000000 {
+ compatible = "arm,malit6xx\0arm,mali-midgard";
+ #cooling-cells = <0x02>;
+ reg = <0x00 0x2d000000 0x00 0x4000>;
+ interrupts = <0x00 0x21 0x04 0x00 0x22 0x04 0x00 0x20 0x04>;
+ interrupt-names = "JOB\0MMU\0GPU";
+ clocks = <0x09 0x02>;
+ clock-names = "clk_mali";
+ power-domains = <0x22 0x01>;
+ linux,phandle = <0x17>;
+ phandle = <0x17>;
+
+ power_model {
+ compatible = "arm,mali-simple-power-model";
+ voltage = <0x320>;
+ frequency = <0x1f4>;
+ static-power = <0x1f4>;
+ dynamic-power = <0x5dc>;
+ ts = <0x4e20 0x7d0 0xffffffec 0x02>;
+ thermal-zone = "soc";
+ };
+ };
+
+ smb@08000000 {
+ compatible = "simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x00 0x8000000
+ 0x4000000 0x01 0x00 0x00
+ 0x14000000 0x4000000 0x02 0x00
+ 0x00 0x18000000 0x4000000 0x03
+ 0x00 0x00 0x1c000000 0x4000000
+ 0x04 0x00 0x00 0xc000000
+ 0x4000000 0x05 0x00 0x00
+ 0x10000000 0x4000000>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00 0x0f>;
+ interrupt-map = <0x00 0x00 0x00 0x01 0x00 0x00 0x00 0x44
+ 0x04 0x00 0x00 0x01 0x01 0x00 0x00 0x00
+ 0x45 0x04 0x00 0x00 0x02 0x01 0x00 0x00
+ 0x00 0x46 0x04 0x00 0x00 0x03 0x01 0x00
+ 0x00 0x00 0xa0 0x04 0x00 0x00 0x04 0x01
+ 0x00 0x00 0x00 0xa1 0x04 0x00 0x00 0x05
+ 0x01 0x00 0x00 0x00 0xa2 0x04 0x00 0x00
+ 0x06 0x01 0x00 0x00 0x00 0xa3 0x04 0x00
+ 0x00 0x07 0x01 0x00 0x00 0x00 0xa4 0x04
+ 0x00 0x00 0x08 0x01 0x00 0x00 0x00 0xa5
+ 0x04 0x00 0x00 0x09 0x01 0x00 0x00 0x00
+ 0xa6 0x04 0x00 0x00 0x0a 0x01 0x00 0x00
+ 0x00 0xa7 0x04 0x00 0x00 0x0b 0x01 0x00
+ 0x00 0x00 0xa8 0x04 0x00 0x00 0x0c 0x01
+ 0x00 0x00 0x00 0xa9 0x04>;
+
+ clk24mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x16e3600>;
+ clock-output-names = "juno_mb:clk24mhz";
+ linux,phandle = <0x28>;
+ phandle = <0x28>;
+ };
+
+ clk25mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x17d7840>;
+ clock-output-names = "juno_mb:clk25mhz";
+ linux,phandle = <0x24>;
+ phandle = <0x24>;
+ };
+
+ refclk1mhz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0xf4240>;
+ clock-output-names = "juno_mb:refclk1mhz";
+ linux,phandle = <0x27>;
+ phandle = <0x27>;
+ };
+
+ refclk32khz {
+ compatible = "fixed-clock";
+ #clock-cells = <0x00>;
+ clock-frequency = <0x8000>;
+ clock-output-names = "juno_mb:refclk32khz";
+ linux,phandle = <0x26>;
+ phandle = <0x26>;
+ };
+
+ motherboard {
+ compatible = "arm,vexpress,v2p-p1\0simple-bus";
+ #address-cells = <0x02>;
+ #size-cells = <0x01>;
+ #interrupt-cells = <0x01>;
+ ranges;
+ model = "V2M-Juno";
+ arm,hbi = <0x252>;
+ arm,vexpress,site = <0x00>;
+ arm,v2m-memory-map = "rs1";
+
+ mcc-sb-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "MCC_SB_3V3";
+ regulator-min-microvolt = <0x325aa0>;
+ regulator-max-microvolt = <0x325aa0>;
+ regulator-always-on;
+ linux,phandle = <0x25>;
+ phandle = <0x25>;
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+
+ power-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x74>;
+ label = "POWER";
+ gpios = <0x23 0x00 0x04>;
+ };
+
+ home-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x66>;
+ label = "HOME";
+ gpios = <0x23 0x01 0x04>;
+ };
+
+ rlock-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x98>;
+ label = "RLOCK";
+ gpios = <0x23 0x02 0x04>;
+ };
+
+ vol-up-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x73>;
+ label = "VOL+";
+ gpios = <0x23 0x03 0x04>;
+ };
+
+ vol-down-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x72>;
+ label = "VOL-";
+ gpios = <0x23 0x04 0x04>;
+ };
+
+ nmi-button {
+ debounce_interval = <0x32>;
+ wakeup-source;
+ linux,code = <0x63>;
+ label = "NMI";
+ gpios = <0x23 0x05 0x04>;
+ };
+ };
+
+ flash@0,00000000 {
+ compatible = "arm,vexpress-flash\0cfi-flash";
+ linux,part-probe = "afs";
+ reg = <0x00 0x00 0x4000000>;
+ bank-width = <0x04>;
+ status = "disabled";
+ };
+
+ ethernet@2,00000000 {
+ compatible = "smsc,lan9118\0smsc,lan9115";
+ reg = <0x02 0x00 0x10000>;
+ interrupts = <0x03>;
+ phy-mode = "mii";
+ reg-io-width = <0x04>;
+ smsc,irq-active-high;
+ smsc,irq-push-pull;
+ clocks = <0x24>;
+ vdd33a-supply = <0x25>;
+ vddvario-supply = <0x25>;
+ status = "disabled";
+ };
+
+ usb@5,00000000 {
+ compatible = "nxp,usb-isp1763";
+ reg = <0x05 0x00 0x20000>;
+ bus-width = <0x10>;
+ interrupts = <0x04>;
+ };
+
+ iofpga@3,00000000 {
+ compatible = "arm,amba-bus\0simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x03 0x00 0x200000>;
+
+ sysctl@020000 {
+ compatible = "arm,sp810\0arm,primecell";
+ reg = <0x20000 0x1000>;
+ clocks = <0x26 0x27 0x28>;
+ clock-names = "refclk\0timclk\0apb_pclk";
+ #clock-cells = <0x01>;
+ clock-output-names = "timerclken0\0timerclken1\0timerclken2\0timerclken3";
+ assigned-clocks = <0x29 0x00 0x29 0x01 0x29 0x03 0x29 0x03>;
+ assigned-clock-parents = <0x27 0x27 0x27 0x27>;
+ linux,phandle = <0x29>;
+ phandle = <0x29>;
+ };
+
+ apbregs@010000 {
+ compatible = "syscon\0simple-mfd";
+ reg = <0x10000 0x1000>;
+
+ led0 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x01>;
+ label = "vexpress:0";
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ };
+
+ led1 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x02>;
+ label = "vexpress:1";
+ linux,default-trigger = "mmc0";
+ default-state = "off";
+ };
+
+ led2 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x04>;
+ label = "vexpress:2";
+ linux,default-trigger = "cpu0";
+ default-state = "off";
+ };
+
+ led3 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x08>;
+ label = "vexpress:3";
+ linux,default-trigger = "cpu1";
+ default-state = "off";
+ };
+
+ led4 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x10>;
+ label = "vexpress:4";
+ linux,default-trigger = "cpu2";
+ default-state = "off";
+ };
+
+ led5 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x20>;
+ label = "vexpress:5";
+ linux,default-trigger = "cpu3";
+ default-state = "off";
+ };
+
+ led6 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x40>;
+ label = "vexpress:6";
+ default-state = "off";
+ };
+
+ led7 {
+ compatible = "register-bit-led";
+ offset = <0x08>;
+ mask = <0x80>;
+ label = "vexpress:7";
+ default-state = "off";
+ };
+ };
+
+ mmci@050000 {
+ compatible = "arm,pl180\0arm,primecell";
+ reg = <0x50000 0x1000>;
+ interrupts = <0x05>;
+ max-frequency = <0xb71b00>;
+ vmmc-supply = <0x25>;
+ clocks = <0x28 0x1c>;
+ clock-names = "mclk\0apb_pclk";
+ };
+
+ kmi@060000 {
+ compatible = "arm,pl050\0arm,primecell";
+ reg = <0x60000 0x1000>;
+ interrupts = <0x08>;
+ clocks = <0x28 0x1c>;
+ clock-names = "KMIREFCLK\0apb_pclk";
+ };
+
+ kmi@070000 {
+ compatible = "arm,pl050\0arm,primecell";
+ reg = <0x70000 0x1000>;
+ interrupts = <0x08>;
+ clocks = <0x28 0x1c>;
+ clock-names = "KMIREFCLK\0apb_pclk";
+ };
+
+ wdt@0f0000 {
+ compatible = "arm,sp805\0arm,primecell";
+ reg = <0xf0000 0x10000>;
+ interrupts = <0x07>;
+ clocks = <0x28 0x1c>;
+ clock-names = "wdogclk\0apb_pclk";
+ };
+
+ timer@110000 {
+ compatible = "arm,sp804\0arm,primecell";
+ reg = <0x110000 0x10000>;
+ interrupts = <0x09>;
+ clocks = <0x29 0x00 0x29 0x01 0x28>;
+ clock-names = "timclken1\0timclken2\0apb_pclk";
+ };
+
+ timer@120000 {
+ compatible = "arm,sp804\0arm,primecell";
+ reg = <0x120000 0x10000>;
+ interrupts = <0x09>;
+ clocks = <0x29 0x02 0x29 0x03 0x28>;
+ clock-names = "timclken1\0timclken2\0apb_pclk";
+ };
+
+ rtc@170000 {
+ compatible = "arm,pl031\0arm,primecell";
+ reg = <0x170000 0x10000>;
+ interrupts = <0x00>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ };
+
+ gpio@1d0000 {
+ compatible = "arm,pl061\0arm,primecell";
+ reg = <0x1d0000 0x1000>;
+ interrupts = <0x06>;
+ clocks = <0x1c>;
+ clock-names = "apb_pclk";
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-controller;
+ #interrupt-cells = <0x02>;
+ linux,phandle = <0x23>;
+ phandle = <0x23>;
+ };
+ };
+ };
+ };
+
+ tlx@60000000 {
+ compatible = "simple-bus";
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ ranges = <0x00 0x00 0x60000000 0x10000000>;
+ #interrupt-cells = <0x01>;
+ interrupt-map-mask = <0x00 0x00>;
+ interrupt-map = <0x00 0x00 0x01 0x00 0x00 0x00 0xa8 0x04>;
+ };
+
+ firmware {
+
+ optee {
+ compatible = "linaro,optee-tz";
+ method = "smc";
+ };
+ };
+};
diff --git a/configs/vexpress_aemv8a_juno_defconfig b/configs/vexpress_aemv8a_juno_defconfig
index 3125adaf5c4..95b4fe2c0a9 100644
--- a/configs/vexpress_aemv8a_juno_defconfig
+++ b/configs/vexpress_aemv8a_juno_defconfig
@@ -52,3 +52,4 @@ CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_GENERIC=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_GENERIC=y
+CONFIG_DEFAULT_DEVICE_TREE="juno-r2"
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 09/16] arm: xenguest_arm64: Add a fake devicetree file
2021-10-13 1:01 ` Simon Glass
` (8 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Anastasiia Lukianenko, Andre Przywara, Bin Meng,
Christian Hewitt, Fabio Estevam, Heiko Schocher, Jagan Teki,
Kever Yang, Neil Armstrong, Oleksandr Andrushchenko,
Peter Robinson, Rick Chen, Sean Anderson, Tim Harvey
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 <sjg@chromium.org>
---
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/xenguest-arm64.dts | 15 +++++++++++++++
configs/xenguest_arm64_defconfig | 1 +
3 files changed, 18 insertions(+)
create mode 100644 arch/arm/dts/xenguest-arm64.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 57f06670b23..f09a81eea8e 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1125,6 +1125,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 00000000000..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 b72e40a1399..8e32cd63229 100644
--- a/configs/xenguest_arm64_defconfig
+++ b/configs/xenguest_arm64_defconfig
@@ -4,6 +4,7 @@ CONFIG_TARGET_XENGUEST_ARM64=y
CONFIG_SYS_TEXT_BASE=0x40080000
CONFIG_SYS_MALLOC_F_LEN=0x2000
CONFIG_SYS_MALLOC_LEN=0x2000000
+CONFIG_DEFAULT_DEVICE_TREE="xenguest-arm64"
CONFIG_IDENT_STRING=" xenguest"
CONFIG_SYS_LOAD_ADDR=0x40000000
CONFIG_BOOTDELAY=10
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 10/16] arm: octeontx: Add a fake devicetree file
2021-10-13 1:01 ` Simon Glass
` (9 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
2021-10-13 1:27 ` François Ozog
-1 siblings, 1 reply; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Aaron Williams,
Albert Aribaud, Andre Przywara, Christian Hewitt, Fabio Estevam,
Heiko Schocher, Jagan Teki, Kever Yang, Neil Armstrong,
Peter Robinson, Rick Chen, Sean Anderson, Stefan Roese,
Tero Kristo, Tim Harvey
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 <sjg@chromium.org>
---
arch/arm/dts/Makefile | 3 +++
arch/arm/dts/octeontx.dts | 14 ++++++++++++++
configs/octeontx2_95xx_defconfig | 1 +
configs/octeontx2_96xx_defconfig | 1 +
configs/octeontx_81xx_defconfig | 1 +
configs/octeontx_83xx_defconfig | 1 +
6 files changed, 21 insertions(+)
create mode 100644 arch/arm/dts/octeontx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index f09a81eea8e..0fec648dd77 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1127,6 +1127,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
+dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
+
dtb-$(CONFIG_TARGET_GE_BX50V3) += \
imx6q-bx50v3.dtb \
imx6q-b850v3.dtb \
diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
new file mode 100644
index 00000000000..60a15f5df23
--- /dev/null
+++ b/arch/arm/dts/octeontx.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for octeontx2 boards
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * I could not find any in-tree documentation at all so this is a dummy file.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/octeontx2_95xx_defconfig b/configs/octeontx2_95xx_defconfig
index 6d8457f1d07..fac4c50aec4 100644
--- a/configs/octeontx2_95xx_defconfig
+++ b/configs/octeontx2_95xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX2_95XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx2_96xx_defconfig b/configs/octeontx2_96xx_defconfig
index b72caef77d8..db883b5542c 100644
--- a/configs/octeontx2_96xx_defconfig
+++ b/configs/octeontx2_96xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX2_96XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_81xx_defconfig b/configs/octeontx_81xx_defconfig
index 52678d59ff1..8309c29c091 100644
--- a/configs/octeontx_81xx_defconfig
+++ b/configs/octeontx_81xx_defconfig
@@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX_81XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
diff --git a/configs/octeontx_83xx_defconfig b/configs/octeontx_83xx_defconfig
index 3890c1e97d4..dae1d4880f8 100644
--- a/configs/octeontx_83xx_defconfig
+++ b/configs/octeontx_83xx_defconfig
@@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_TARGET_OCTEONTX_83XX=y
CONFIG_SYS_MALLOC_LEN=0x4008000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="octeontx"
CONFIG_DEBUG_UART_BASE=0x87e028000000
CONFIG_DEBUG_UART_CLOCK=24000000
CONFIG_DEBUG_UART=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 10/16] arm: octeontx: Add a fake devicetree file
2021-10-13 1:01 ` [PATCH 10/16] arm: octeontx: " Simon Glass
@ 2021-10-13 1:27 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 1:27 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Andre Przywara, Christian Hewitt,
Fabio Estevam, Heiko Schocher, Ilias Apalodimas, Jagan Teki,
Kever Yang, Neil Armstrong, Peter Robinson, Rick Chen,
Sean Anderson, Stefan Roese, Tero Kristo, Tim Harvey, Tom Rini,
U-Boot Mailing List
Hi Simon
It’s even in the title!
The idea of having a DT in dts for ALL boards is not properly rooted. You
may add some sample dts with warnings in the doc tree though.
Le mer. 13 oct. 2021 à 03:04, Simon Glass <sjg@chromium.org> a écrit :
> 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 <sjg@chromium.org>
> ---
>
> arch/arm/dts/Makefile | 3 +++
> arch/arm/dts/octeontx.dts | 14 ++++++++++++++
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> 6 files changed, 21 insertions(+)
> create mode 100644 arch/arm/dts/octeontx.dts
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index f09a81eea8e..0fec648dd77 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -1127,6 +1127,9 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
>
> dtb-$(CONFIG_XEN) += xenguest-arm64.dtb
>
> +dtb-$(CONFIG_ARCH_OCTEONTX) += octeontx.dtb
> +dtb-$(CONFIG_ARCH_OCTEONTX2) += octeontx.dtb
> +
> dtb-$(CONFIG_TARGET_GE_BX50V3) += \
> imx6q-bx50v3.dtb \
> imx6q-b850v3.dtb \
> diff --git a/arch/arm/dts/octeontx.dts b/arch/arm/dts/octeontx.dts
> new file mode 100644
> index 00000000000..60a15f5df23
> --- /dev/null
> +++ b/arch/arm/dts/octeontx.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * Dummy devicetre file for octeontx2 boards
> + *
> + * This is required to make the board build with CONFIG OF_SEPARATE
> + * I could not find any in-tree documentation at all so this is a dummy
> file.
> + *
> + * Copyright 2021 Google LLC
> + */
> +
> +/dts-v1/;
> +
> +/ {
> +};
> diff --git a/configs/octeontx2_95xx_defconfig
> b/configs/octeontx2_95xx_defconfig
> index 6d8457f1d07..fac4c50aec4 100644
> --- a/configs/octeontx2_95xx_defconfig
> +++ b/configs/octeontx2_95xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
> CONFIG_TARGET_OCTEONTX2_95XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e028000000
> CONFIG_DEBUG_UART_CLOCK=24000000
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx2_96xx_defconfig
> b/configs/octeontx2_96xx_defconfig
> index b72caef77d8..db883b5542c 100644
> --- a/configs/octeontx2_96xx_defconfig
> +++ b/configs/octeontx2_96xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
> CONFIG_TARGET_OCTEONTX2_96XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e028000000
> CONFIG_DEBUG_UART_CLOCK=24000000
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_81xx_defconfig
> b/configs/octeontx_81xx_defconfig
> index 52678d59ff1..8309c29c091 100644
> --- a/configs/octeontx_81xx_defconfig
> +++ b/configs/octeontx_81xx_defconfig
> @@ -12,6 +12,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
> CONFIG_TARGET_OCTEONTX_81XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e028000000
> CONFIG_DEBUG_UART_CLOCK=24000000
> CONFIG_DEBUG_UART=y
> diff --git a/configs/octeontx_83xx_defconfig
> b/configs/octeontx_83xx_defconfig
> index 3890c1e97d4..dae1d4880f8 100644
> --- a/configs/octeontx_83xx_defconfig
> +++ b/configs/octeontx_83xx_defconfig
> @@ -10,6 +10,7 @@ CONFIG_ENV_SECT_SIZE=0x10000
> CONFIG_TARGET_OCTEONTX_83XX=y
> CONFIG_SYS_MALLOC_LEN=0x4008000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="octeontx"
> CONFIG_DEBUG_UART_BASE=0x87e028000000
> CONFIG_DEBUG_UART_CLOCK=24000000
> CONFIG_DEBUG_UART=y
> --
> 2.33.0.882.g93a45727a2-goog
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 11/16] arm: xilinx_versal_virt: Add a devicetree file
2021-10-13 1:01 ` Simon Glass
` (10 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
2021-10-13 6:13 ` Michal Simek
-1 siblings, 1 reply; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Ashok Reddy Soma, Christian Hewitt,
Fabio Estevam, Heiko Schocher, Jagan Teki, Kever Yang,
Michal Simek, Michal Simek, Neil Armstrong, Peter Robinson,
T Karthik Reddy, Tim Harvey
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 <sjg@chromium.org>
---
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 0fec648dd77..dd6d66af5e6 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -352,7 +352,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 00000000000..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 0x8000000>;
+ 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@f12a0000 {
+ compatible = "xlnx,zynqmp-rtc";
+ reg = <0x00 0xf12a0000 0x00 0x10000>;
+ interrupt-names = "alarm\0sec";
+ interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
+ };
+
+ sdhci@f1040000 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf1040000 0x00 0x10000>;
+ interrupts = <0x00 0x7e 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ sdhci@f1050000 {
+ compatible = "arasan,sdhci-8.9a";
+ reg = <0x00 0xf1050000 0x00 0x10000>;
+ interrupts = <0x00 0x80 0x04>;
+ clock-names = "clk_xin\0clk_ahb";
+ clocks = <0x8003 0x8003>;
+ };
+
+ usb@ff9d0000 {
+ phandle = <0x8005>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ ranges;
+ clocks = <0x8003 0x8004>;
+ clock-names = "bus_clk\0ref_clk";
+ reg = <0x00 0xff9d0000 0x00 0x10000>;
+ compatible = "xlnx,versal-dwc3";
+
+ dwc3@fe200000 {
+ 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 0xfe200000 0x00 0x10000>;
+ compatible = "snps,dwc3";
+ };
+ };
+
+ dma@ffa80000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa80000 0x00 0x1000>;
+ interrupts = <0x00 0x3c 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffa90000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffa90000 0x00 0x1000>;
+ interrupts = <0x00 0x3d 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffaa0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffaa0000 0x00 0x1000>;
+ interrupts = <0x00 0x3e 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffab0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffab0000 0x00 0x1000>;
+ interrupts = <0x00 0x3f 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffac0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffac0000 0x00 0x1000>;
+ interrupts = <0x00 0x40 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffad0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffad0000 0x00 0x1000>;
+ interrupts = <0x00 0x41 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffae0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffae0000 0x00 0x1000>;
+ interrupts = <0x00 0x42 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ dma@ffaf0000 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x00 0xffaf0000 0x00 0x1000>;
+ interrupts = <0x00 0x43 0x04>;
+ clock-names = "clk_main\0clk_apb";
+ clocks = <0x8003 0x8003>;
+ xlnx,bus-width = <0x40>;
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ interrupts = <0x01 0x0d 0x04 0x01 0x0e 0x04 0x01 0x0b 0x04 0x01 0x0a 0x04>;
+ };
+
+ gic@f9000000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <0x03>;
+ reg = <0x00 0xf9000000 0x00 0x10000 0x00 0xf9080000 0x00 0x80000>;
+ interrupt-controller;
+ interrupts = <0x01 0x09 0x04>;
+ phandle = <0x8000>;
+ };
+
+ uart@ff000000 {
+ u-boot,dm-pre-reloc;
+ compatible = "arm,pl011\0arm,sbsa-uart";
+ reg = <0x00 0xff000000 0x00 0x1000>;
+ interrupts = <0x00 0x12 0x04>;
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8004 0x8004>;
+ current-speed = <0x1c200>;
+ };
+
+ uart@ff010000 {
+ u-boot,dm-pre-reloc;
+ compatible = "arm,pl011\0arm,sbsa-uart";
+ reg = <0x00 0xff010000 0x00 0x1000>;
+ interrupts = <0x00 0x13 0x04>;
+ clock-names = "uartclk\0apb_pclk";
+ clocks = <0x8004 0x8004>;
+ current-speed = <0x1c200>;
+ };
+
+ ethernet@ff0c0000 {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+ compatible = "cdns,zynqmp-gem\0cdns,gem";
+ reg = <0x00 0xff0c0000 0x00 0x1000>;
+ interrupts = <0x00 0x38 0x04 0x00 0x38 0x04>;
+ clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
+ clocks = <0x8003 0x8003 0x8004 0x8004>;
+ phy-handle = <0x8002>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <0x3e8>;
+ full-duplex;
+ phandle = <0x8002>;
+ };
+ };
+
+ ethernet@ff0d0000 {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+ compatible = "cdns,zynqmp-gem\0cdns,gem";
+ reg = <0x00 0xff0d0000 0x00 0x1000>;
+ interrupts = <0x00 0x3a 0x04 0x00 0x3a 0x04>;
+ clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
+ clocks = <0x8003 0x8003 0x8004 0x8004>;
+ phy-handle = <0x8001>;
+ phy-mode = "rgmii-id";
+
+ fixed-link {
+ speed = <0x3e8>;
+ full-duplex;
+ phandle = <0x8001>;
+ };
+ };
+
+ virtio_mmio@a0000e00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000e00 0x00 0x200>;
+ interrupts = <0x00 0x76 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000c00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000c00 0x00 0x200>;
+ interrupts = <0x00 0x75 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000a00 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000a00 0x00 0x200>;
+ interrupts = <0x00 0x74 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000800 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000800 0x00 0x200>;
+ interrupts = <0x00 0x73 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000600 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000600 0x00 0x200>;
+ interrupts = <0x00 0x72 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000400 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000400 0x00 0x200>;
+ interrupts = <0x00 0x71 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000200 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000200 0x00 0x200>;
+ interrupts = <0x00 0x70 0x01>;
+ dma-coherent;
+ };
+
+ virtio_mmio@a0000000 {
+ compatible = "virtio,mmio";
+ reg = <0x00 0xa0000000 0x00 0x200>;
+ interrupts = <0x00 0x6f 0x01>;
+ dma-coherent;
+ };
+
+ chosen {
+ stdout-path = "/uart@ff000000";
+ };
+};
diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig
index 11598623954..f0ec2639a38 100644
--- a/configs/xilinx_versal_virt_defconfig
+++ b/configs/xilinx_versal_virt_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x100000
CONFIG_SYS_MEMTEST_START=0x00000000
CONFIG_SYS_MEMTEST_END=0x00001000
CONFIG_DM_GPIO=y
+CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-virt"
CONFIG_CMD_FRU=y
CONFIG_DEFINE_TCM_OCM_MMAP=y
CONFIG_COUNTER_FREQUENCY=100000000
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 11/16] arm: xilinx_versal_virt: Add a devicetree file
2021-10-13 1:01 ` [PATCH 11/16] arm: xilinx_versal_virt: Add a " Simon Glass
@ 2021-10-13 6:13 ` Michal Simek
2021-10-13 16:58 ` Simon Glass
0 siblings, 1 reply; 164+ messages in thread
From: Michal Simek @ 2021-10-13 6:13 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Albert Aribaud, Andre Przywara,
Ashok Reddy Soma, Christian Hewitt, Fabio Estevam,
Heiko Schocher, Jagan Teki, Kever Yang, Michal Simek,
Michal Simek, Neil Armstrong, Peter Robinson, T Karthik Reddy,
Tim Harvey
On 10/13/21 03:01, Simon Glass wrote:
> 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 <sjg@chromium.org>
> ---
>
> 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 0fec648dd77..dd6d66af5e6 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -352,7 +352,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 00000000000..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 0x8000000>;
> + 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@f12a0000 {
> + compatible = "xlnx,zynqmp-rtc";
> + reg = <0x00 0xf12a0000 0x00 0x10000>;
> + interrupt-names = "alarm\0sec";
> + interrupts = <0x00 0x8e 0x04 0x00 0x8f 0x04>;
> + };
> +
> + sdhci@f1040000 {
> + compatible = "arasan,sdhci-8.9a";
> + reg = <0x00 0xf1040000 0x00 0x10000>;
> + interrupts = <0x00 0x7e 0x04>;
> + clock-names = "clk_xin\0clk_ahb";
> + clocks = <0x8003 0x8003>;
> + };
> +
> + sdhci@f1050000 {
> + compatible = "arasan,sdhci-8.9a";
> + reg = <0x00 0xf1050000 0x00 0x10000>;
> + interrupts = <0x00 0x80 0x04>;
> + clock-names = "clk_xin\0clk_ahb";
> + clocks = <0x8003 0x8003>;
> + };
> +
> + usb@ff9d0000 {
> + phandle = <0x8005>;
> + #size-cells = <0x02>;
> + #address-cells = <0x02>;
> + ranges;
> + clocks = <0x8003 0x8004>;
> + clock-names = "bus_clk\0ref_clk";
> + reg = <0x00 0xff9d0000 0x00 0x10000>;
> + compatible = "xlnx,versal-dwc3";
> +
> + dwc3@fe200000 {
> + 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 0xfe200000 0x00 0x10000>;
> + compatible = "snps,dwc3";
> + };
> + };
> +
> + dma@ffa80000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffa80000 0x00 0x1000>;
> + interrupts = <0x00 0x3c 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffa90000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffa90000 0x00 0x1000>;
> + interrupts = <0x00 0x3d 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffaa0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffaa0000 0x00 0x1000>;
> + interrupts = <0x00 0x3e 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffab0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffab0000 0x00 0x1000>;
> + interrupts = <0x00 0x3f 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffac0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffac0000 0x00 0x1000>;
> + interrupts = <0x00 0x40 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffad0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffad0000 0x00 0x1000>;
> + interrupts = <0x00 0x41 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffae0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffae0000 0x00 0x1000>;
> + interrupts = <0x00 0x42 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + dma@ffaf0000 {
> + compatible = "xlnx,zynqmp-dma-1.0";
> + reg = <0x00 0xffaf0000 0x00 0x1000>;
> + interrupts = <0x00 0x43 0x04>;
> + clock-names = "clk_main\0clk_apb";
> + clocks = <0x8003 0x8003>;
> + xlnx,bus-width = <0x40>;
> + };
> +
> + timer {
> + compatible = "arm,armv8-timer";
> + interrupts = <0x01 0x0d 0x04 0x01 0x0e 0x04 0x01 0x0b 0x04 0x01 0x0a 0x04>;
> + };
> +
> + gic@f9000000 {
> + compatible = "arm,gic-v3";
> + #interrupt-cells = <0x03>;
> + reg = <0x00 0xf9000000 0x00 0x10000 0x00 0xf9080000 0x00 0x80000>;
> + interrupt-controller;
> + interrupts = <0x01 0x09 0x04>;
> + phandle = <0x8000>;
> + };
> +
> + uart@ff000000 {
> + u-boot,dm-pre-reloc;
> + compatible = "arm,pl011\0arm,sbsa-uart";
> + reg = <0x00 0xff000000 0x00 0x1000>;
> + interrupts = <0x00 0x12 0x04>;
> + clock-names = "uartclk\0apb_pclk";
> + clocks = <0x8004 0x8004>;
> + current-speed = <0x1c200>;
> + };
> +
> + uart@ff010000 {
> + u-boot,dm-pre-reloc;
> + compatible = "arm,pl011\0arm,sbsa-uart";
> + reg = <0x00 0xff010000 0x00 0x1000>;
> + interrupts = <0x00 0x13 0x04>;
> + clock-names = "uartclk\0apb_pclk";
> + clocks = <0x8004 0x8004>;
> + current-speed = <0x1c200>;
> + };
> +
> + ethernet@ff0c0000 {
> + #size-cells = <0x00>;
> + #address-cells = <0x01>;
> + compatible = "cdns,zynqmp-gem\0cdns,gem";
> + reg = <0x00 0xff0c0000 0x00 0x1000>;
> + interrupts = <0x00 0x38 0x04 0x00 0x38 0x04>;
> + clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
> + clocks = <0x8003 0x8003 0x8004 0x8004>;
> + phy-handle = <0x8002>;
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <0x3e8>;
> + full-duplex;
> + phandle = <0x8002>;
> + };
> + };
> +
> + ethernet@ff0d0000 {
> + #size-cells = <0x00>;
> + #address-cells = <0x01>;
> + compatible = "cdns,zynqmp-gem\0cdns,gem";
> + reg = <0x00 0xff0d0000 0x00 0x1000>;
> + interrupts = <0x00 0x3a 0x04 0x00 0x3a 0x04>;
> + clock-names = "pclk\0hclk\0tx_clk\0rx_clk";
> + clocks = <0x8003 0x8003 0x8004 0x8004>;
> + phy-handle = <0x8001>;
> + phy-mode = "rgmii-id";
> +
> + fixed-link {
> + speed = <0x3e8>;
> + full-duplex;
> + phandle = <0x8001>;
> + };
> + };
> +
> + virtio_mmio@a0000e00 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000e00 0x00 0x200>;
> + interrupts = <0x00 0x76 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000c00 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000c00 0x00 0x200>;
> + interrupts = <0x00 0x75 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000a00 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000a00 0x00 0x200>;
> + interrupts = <0x00 0x74 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000800 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000800 0x00 0x200>;
> + interrupts = <0x00 0x73 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000600 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000600 0x00 0x200>;
> + interrupts = <0x00 0x72 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000400 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000400 0x00 0x200>;
> + interrupts = <0x00 0x71 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000200 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000200 0x00 0x200>;
> + interrupts = <0x00 0x70 0x01>;
> + dma-coherent;
> + };
> +
> + virtio_mmio@a0000000 {
> + compatible = "virtio,mmio";
> + reg = <0x00 0xa0000000 0x00 0x200>;
> + interrupts = <0x00 0x6f 0x01>;
> + dma-coherent;
> + };
> +
> + chosen {
> + stdout-path = "/uart@ff000000";
> + };
> +};
> diff --git a/configs/xilinx_versal_virt_defconfig b/configs/xilinx_versal_virt_defconfig
> index 11598623954..f0ec2639a38 100644
> --- a/configs/xilinx_versal_virt_defconfig
> +++ b/configs/xilinx_versal_virt_defconfig
> @@ -7,6 +7,7 @@ CONFIG_SYS_MALLOC_F_LEN=0x100000
> CONFIG_SYS_MEMTEST_START=0x00000000
> CONFIG_SYS_MEMTEST_END=0x00001000
> CONFIG_DM_GPIO=y
> +CONFIG_DEFAULT_DEVICE_TREE="xilinx-versal-virt"
> CONFIG_CMD_FRU=y
> CONFIG_DEFINE_TCM_OCM_MMAP=y
> CONFIG_COUNTER_FREQUENCY=100000000
>
I have also concern about adding these files. When this series is
accepted from high level point of view it would be better to simply use
what we use already which describe standard versal boards. I just didn't
push that files yet.
Thanks,
Michal
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 11/16] arm: xilinx_versal_virt: Add a devicetree file
2021-10-13 6:13 ` Michal Simek
@ 2021-10-13 16:58 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 16:58 UTC (permalink / raw)
To: Michal Simek
Cc: U-Boot Mailing List, Tom Rini, Ilias Apalodimas, Albert Aribaud,
Andre Przywara, Ashok Reddy Soma, Christian Hewitt,
Fabio Estevam, Heiko Schocher, Jagan Teki, Kever Yang,
Michal Simek, Neil Armstrong, Peter Robinson, T Karthik Reddy,
Tim Harvey
Hi Michal,
On Wed, 13 Oct 2021 at 00:13, Michal Simek <michal.simek@xilinx.com> wrote:
>
>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > 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 <sjg@chromium.org>
> > ---
> >
> > 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
> >
[.]
>
> I have also concern about adding these files. When this series is
> accepted from high level point of view it would be better to simply use
> what we use already which describe standard versal boards. I just didn't
> push that files yet.
That's fine and there is no need to wait, you could add the files now.
I also suggest a few notes in doc/board/emulation and doc/board/xilinx
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 12/16] arm: bcm7xxx: Add a devicetree file
2021-10-13 1:01 ` Simon Glass
` (11 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Christian Hewitt, Fabio Estevam, Heiko Schocher,
Jagan Teki, Kever Yang, Neil Armstrong, Peter Robinson,
Thomas Fitzsimmons, Tim Harvey
Add a dummy devicetree file for these boards. It seems to be possible to
obtain a real one from another bootloader called 'bolt' but I will leave
this to the maintainer.
Signed-off-by: Simon Glass <sjg@chromium.org>
---
arch/arm/dts/Makefile | 2 ++
arch/arm/dts/bcm7xxx.dts | 15 +++++++++++++++
configs/bcm7260_defconfig | 1 +
configs/bcm7445_defconfig | 1 +
4 files changed, 19 insertions(+)
create mode 100644 arch/arm/dts/bcm7xxx.dts
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index dd6d66af5e6..ea7a4cf87de 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1077,6 +1077,8 @@ dtb-$(CONFIG_ARCH_BCM6858) += \
dtb-$(CONFIG_TARGET_BCMNS3) += ns3-board.dtb
+dtb-$(CONFIG_ARCH_BCMSTB) += bcm7xxx.dtb
+
dtb-$(CONFIG_ASPEED_AST2500) += ast2500-evb.dtb
dtb-$(CONFIG_ASPEED_AST2600) += ast2600-evb.dtb
diff --git a/arch/arm/dts/bcm7xxx.dts b/arch/arm/dts/bcm7xxx.dts
new file mode 100644
index 00000000000..799cc9caad4
--- /dev/null
+++ b/arch/arm/dts/bcm7xxx.dts
@@ -0,0 +1,15 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Dummy devicetre file for bcm7260 board
+ *
+ * This is required to make the board build with CONFIG OF_SEPARATE
+ * In-tree document explains how to obtain a real devicetree using 'bolt' but
+ * I did not attempt this.
+ *
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+};
diff --git a/configs/bcm7260_defconfig b/configs/bcm7260_defconfig
index 3afb909f712..89b5b01ad76 100644
--- a/configs/bcm7260_defconfig
+++ b/configs/bcm7260_defconfig
@@ -7,6 +7,7 @@ CONFIG_NR_DRAM_BANKS=1
CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0x814800
CONFIG_SYS_MALLOC_LEN=0x2800000
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x824800
CONFIG_SYS_LOAD_ADDR=0x02000000
CONFIG_FIT=y
diff --git a/configs/bcm7445_defconfig b/configs/bcm7445_defconfig
index 3726abd7354..92c1b36185a 100644
--- a/configs/bcm7445_defconfig
+++ b/configs/bcm7445_defconfig
@@ -8,6 +8,7 @@ CONFIG_ENV_SIZE=0x10000
CONFIG_ENV_OFFSET=0x1E0000
CONFIG_ENV_SECT_SIZE=0x10000
CONFIG_SYS_MALLOC_LEN=0xa00000
+CONFIG_DEFAULT_DEVICE_TREE="bcm7xxx"
CONFIG_ENV_OFFSET_REDUND=0x1F0000
CONFIG_SYS_LOAD_ADDR=0x02000000
CONFIG_FIT=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 13/16] arm: qemu-ppce500: Add a devicetree file
2021-10-13 1:01 ` Simon Glass
` (12 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Alexander Graf, Bin Meng, Niel Fourie, Priyanka Jain,
Rainer Boschung, Sinan Akman, Valentin Longchamp,
Vladimir Oltean, Wolfgang Denk
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 <sjg@chromium.org>
---
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 00000000000..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@f00000000 {
+ interrupt-parent = <0x8003>;
+ ranges = <0x00 0x0f 0x00 0x8000000>;
+ #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 = <0x2000000 0x00 0xe0000000 0x0c
+ 0x00 0x00 0x20000000 0x1000000
+ 0x00 0x00 0x0f 0xe1000000
+ 0x00 0x10000>;
+ 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 0x5800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x6000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x6000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x6000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x6000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x6800 0x00 0x00 0x01 0x8003 0x02 0x01 0x6800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x6800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x6800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x7000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x7000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x7000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x7000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x7800 0x00 0x00 0x01 0x8003 0x04 0x01 0x7800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x7800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x7800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0x8000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0x8000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0x8000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0x8000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0x8800 0x00 0x00 0x01 0x8003 0x02 0x01 0x8800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0x8800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0x8800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0x9000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0x9000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0x9000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0x9000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0x9800 0x00 0x00 0x01 0x8003 0x04 0x01 0x9800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0x9800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0x9800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xa000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xa000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xa000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xa000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xa800 0x00 0x00 0x01 0x8003 0x02 0x01 0xa800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xa800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xa800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xb000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xb000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xb000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xb000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xb800 0x00 0x00 0x01 0x8003 0x04 0x01 0xb800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xb800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xb800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xc000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xc000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xc000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xc000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xc800 0x00 0x00 0x01 0x8003 0x02 0x01 0xc800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xc800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xc800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xd000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xd000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xd000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xd000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xd800 0x00 0x00 0x01 0x8003 0x04 0x01 0xd800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xd800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xd800 0x00 0x00
+ 0x04 0x8003 0x03 0x01 0xe000 0x00 0x00 0x01
+ 0x8003 0x01 0x01 0xe000 0x00 0x00 0x02 0x8003
+ 0x02 0x01 0xe000 0x00 0x00 0x03 0x8003 0x03
+ 0x01 0xe000 0x00 0x00 0x04 0x8003 0x04 0x01
+ 0xe800 0x00 0x00 0x01 0x8003 0x02 0x01 0xe800
+ 0x00 0x00 0x02 0x8003 0x03 0x01 0xe800 0x00
+ 0x00 0x03 0x8003 0x04 0x01 0xe800 0x00 0x00
+ 0x04 0x8003 0x01 0x01 0xf000 0x00 0x00 0x01
+ 0x8003 0x03 0x01 0xf000 0x00 0x00 0x02 0x8003
+ 0x04 0x01 0xf000 0x00 0x00 0x03 0x8003 0x01
+ 0x01 0xf000 0x00 0x00 0x04 0x8003 0x02 0x01
+ 0xf800 0x00 0x00 0x01 0x8003 0x04 0x01 0xf800
+ 0x00 0x00 0x02 0x8003 0x01 0x01 0xf800 0x00
+ 0x00 0x03 0x8003 0x02 0x01 0xf800 0x00 0x00
+ 0x04 0x8003 0x03 0x01>;
+ interrupt-map-mask = <0xf800 0x00 0x00 0x07>;
+ device_type = "pci";
+ compatible = "fsl,mpc8540-pci";
+ cell-index = <0x00>;
+ };
+
+ soc@fe0000000 {
+ bus-frequency = <0x00>;
+ ranges = <0x00 0x0f 0xe0000000 0x100000>;
+ #size-cells = <0x01>;
+ #address-cells = <0x01>;
+ compatible = "fsl,mpc8544-immr\0simple-bus";
+ device_type = "soc";
+
+ power-off {
+ gpios = <0x8005 0x00 0x00>;
+ compatible = "gpio-poweroff";
+ };
+
+ gpio@ff000 {
+ linux,phandle = <0x8005>;
+ phandle = <0x8005>;
+ gpio-controller;
+ #gpio-cells = <0x02>;
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2f 0x02>;
+ reg = <0xff000 0x1000>;
+ compatible = "fsl,qoriq-gpio";
+ };
+
+ msi@41600 {
+ linux,phandle = <0x8004>;
+ phandle = <0x8004>;
+ interrupts = <0xe0 0x00 0xe1 0x00 0xe2 0x00 0xe3 0x00
+ 0xe4 0x00 0xe5 0x00 0xe6 0x00 0xe7 0x00>;
+ interrupt-parent = <0x8003>;
+ msi-available-ranges = <0x00 0x100>;
+ reg = <0x41600 0x200>;
+ compatible = "fsl,mpic-msi";
+ };
+
+ global-utilities@e0000 {
+ fsl,has-rstcr;
+ reg = <0xe0000 0x1000>;
+ compatible = "fsl,mpc8544-guts";
+ };
+
+ i2c@3000 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2b 0x02>;
+ cell-index = <0x00>;
+ reg = <0x3000 0x14>;
+ compatible = "fsl-i2c";
+ device_type = "i2c";
+
+ rtc@68 {
+ reg = <0x68>;
+ compatible = "pericom,pt7c4338";
+ };
+ };
+
+ serial@4500 {
+ interrupt-parent = <0x8003>;
+ interrupts = <0x2a 0x02>;
+ clock-frequency = <0x17d78400>;
+ cell-index = <0x00>;
+ reg = <0x4500 0x100>;
+ compatible = "ns16550";
+ device_type = "serial";
+ };
+
+ pic@40000 {
+ interrupt-controller;
+ linux,phandle = <0x8003>;
+ phandle = <0x8003>;
+ #interrupt-cells = <0x02>;
+ #address-cells = <0x00>;
+ reg = <0x40000 0x40000>;
+ compatible = "fsl,mpic";
+ device_type = "open-pic";
+ };
+ };
+
+ aliases {
+ pci0 = "/pci@fe0008000";
+ rtc = "i2c/rtc@68";
+ i2c = "/soc@fe0000000/i2c@3000";
+ serial0 = "/soc@fe0000000/serial@4500";
+ };
+
+ cpus {
+ #size-cells = <0x00>;
+ #address-cells = <0x01>;
+
+ PowerPC,8544@0 {
+ status = "okay";
+ bus-frequency = <0x00>;
+ i-cache-size = <0x8000>;
+ d-cache-size = <0x8000>;
+ i-cache-line-size = <0x20>;
+ d-cache-line-size = <0x20>;
+ reg = <0x00>;
+ device_type = "cpu";
+ timebase-frequency = <0x17d78400>;
+ clock-frequency = <0x17d78400>;
+ };
+ };
+
+ chosen {
+ stdout-path = "/soc@fe0000000/serial@4500";
+ linux,stdout-path = "/soc@fe0000000/serial@4500";
+ bootargs = [00];
+ };
+
+ memory {
+ reg = <0x00 0x00 0x00 0x8000000>;
+ device_type = "memory";
+ };
+};
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 55f646537b2..5bf3e8de37a 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -1,6 +1,7 @@
CONFIG_PPC=y
CONFIG_SYS_TEXT_BASE=0xf01000
CONFIG_ENV_SIZE=0x2000
+CONFIG_DEFAULT_DEVICE_TREE="qemu-ppce500"
CONFIG_MPC85xx=y
# CONFIG_CMD_ERRATA is not set
CONFIG_TARGET_QEMU_PPCE500=y
--
2.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 14/16] arm: highbank: Add a fake devicetree file
2021-10-13 1:01 ` Simon Glass
` (13 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Albert Aribaud,
Andre Przywara, Christian Hewitt, Fabio Estevam, Heiko Schocher,
Jagan Teki, Kever Yang, Neil Armstrong, Peter Robinson,
Ramon Fried, Rick Chen, Sean Anderson, Tim Harvey
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 <sjg@chromium.org>
---
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 ea7a4cf87de..3499966bc23 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -858,6 +858,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 00000000000..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 43a070e7233..b9d325d391a 100644
--- a/configs/highbank_defconfig
+++ b/configs/highbank_defconfig
@@ -7,6 +7,7 @@ CONFIG_SYS_TEXT_BASE=0x00008000
CONFIG_NR_DRAM_BANKS=2
CONFIG_ENV_SIZE=0x2000
CONFIG_SYS_MALLOC_LEN=0x80000
+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.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* [PATCH 15/16] fdt: Make OF_BOARD a bool option
2021-10-13 1:01 ` Simon Glass
` (14 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
2021-10-13 4:22 ` Heinrich Schuchardt
-1 siblings, 1 reply; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Bin Meng,
Heinrich Schuchardt, Jerry Van Baren, Leo Yu-Chi Liang,
Priyanka Jain, Rick Chen, Sean Anderson, Vladimir Oltean
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 <sjg@chromium.org>
---
configs/qemu-ppce500_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 ++
configs/qemu-riscv64_spl_defconfig | 1 +
dts/Kconfig | 9 +++++----
4 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
index 5bf3e8de37a..66411f73a11 100644
--- a/configs/qemu-ppce500_defconfig
+++ b/configs/qemu-ppce500_defconfig
@@ -54,4 +54,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 3909c9a15ad..4621afb1a87 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=0x80200000
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 34d88da41b0..6f8ff91df9e 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 313b9e5d70b..6be5710df7d 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -104,7 +104,6 @@ choice
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.
@@ -117,14 +116,16 @@ 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"
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.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 15/16] fdt: Make OF_BOARD a bool option
2021-10-13 1:01 ` [PATCH 15/16] fdt: Make OF_BOARD a bool option Simon Glass
@ 2021-10-13 4:22 ` Heinrich Schuchardt
2021-10-13 16:58 ` Simon Glass
0 siblings, 1 reply; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-13 4:22 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, Ilias Apalodimas, Bin Meng, Jerry Van Baren,
Leo Yu-Chi Liang, Priyanka Jain, Rick Chen, Sean Anderson,
Vladimir Oltean, U-Boot Mailing List
On 10/13/21 03:01, Simon Glass wrote:
> 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.
You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
complete patch sets instead of selected patches which cannot be reviewed
without the context.
Best regards
Heinrich
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> configs/qemu-ppce500_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 2 ++
> configs/qemu-riscv64_spl_defconfig | 1 +
> dts/Kconfig | 9 +++++----
> 4 files changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/configs/qemu-ppce500_defconfig b/configs/qemu-ppce500_defconfig
> index 5bf3e8de37a..66411f73a11 100644
> --- a/configs/qemu-ppce500_defconfig
> +++ b/configs/qemu-ppce500_defconfig
> @@ -54,4 +54,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 3909c9a15ad..4621afb1a87 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=0x80200000
> 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 34d88da41b0..6f8ff91df9e 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 313b9e5d70b..6be5710df7d 100644
> --- a/dts/Kconfig
> +++ b/dts/Kconfig
> @@ -104,7 +104,6 @@ choice
>
> 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.
> @@ -117,14 +116,16 @@ 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"
> 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"
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 15/16] fdt: Make OF_BOARD a bool option
2021-10-13 4:22 ` Heinrich Schuchardt
@ 2021-10-13 16:58 ` Simon Glass
2021-10-13 17:30 ` Sean Anderson
0 siblings, 1 reply; 164+ messages in thread
From: Simon Glass @ 2021-10-13 16:58 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Tom Rini, Ilias Apalodimas, Bin Meng, Jerry Van Baren,
Leo Yu-Chi Liang, Priyanka Jain, Rick Chen, Sean Anderson,
Vladimir Oltean, U-Boot Mailing List
Hi Heinrich,
On Tue, 12 Oct 2021 at 22:22, Heinrich Schuchardt
<heinrich.schuchardt@canonical.com> wrote:
>
>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > 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.
>
> You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
> complete patch sets instead of selected patches which cannot be reviewed
> without the context.
I actually only explicitly cc'd Ilias (who has been working on similar
things) and Tom. Everyone else came in via maintainer files. Can you
see the rest in the mailing list, assuming you are subscribed? I can
add you to the next version.
For the record, here is what patman produced:
$ patman -n
Cleaned 16 patches
...
checkpatch.pl found 0 error(s), 14 warning(s), 0 checks(s)
Not sending emails due to errors/warnings
Dry run, so not doing much. But I would do this:
Send a total of 16 patches with a cover letter.
0001-arm-qemu-Mention-nographic-in-the-docs.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Simon Glass <sjg@chromium.org>
Cc: qemu-devel@nongnu.org
0002-arm-qemu-Explain-how-to-extract-the-generate-devicet.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Simon Glass <sjg@chromium.org>
Cc: qemu-devel@nongnu.org
0003-riscv-qemu-Explain-how-to-extract-the-generate-devic.patch
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bin Meng <bin.meng@windriver.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Rick Chen <rick@andestech.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: qemu-devel@nongnu.org
0004-arm-qemu-Add-a-devicetree-file-for-qemu_arm.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: qemu-devel@nongnu.org
0005-arm-qemu-Add-a-devicetree-file-for-qemu_arm64.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: qemu-devel@nongnu.org
0006-riscv-qemu-Add-devicetree-files-for-qemu_riscv32-64.patch
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Cc: Green Wan <green.wan@sifive.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Jonathan Balkind <jbalkind@ucsb.edu>
Cc: Leo <ycliang@andestech.com>
Cc: Padmarao Begari <padmarao.begari@microchip.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tianrui Wei <tianrui-wei@outlook.com>
Cc: Zong Li <zong.li@sifive.com>
Cc: qemu-devel@nongnu.org
0007-arm-rpi-Add-a-devicetree-file-for-rpi_4.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0008-arm-vexpress-Add-a-devicetree-file-for-juno.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Bin Meng <bin.meng@windriver.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0009-arm-xenguest_arm64-Add-a-fake-devicetree-file.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Bin Meng <bin.meng@windriver.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0010-arm-octeontx-Add-a-fake-devicetree-file.patch
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Cc: Tero Kristo <kristo@kernel.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0011-arm-xilinx_versal_virt-Add-a-devicetree-file.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Cc: Tim Harvey <tharvey@gateworks.com>
0012-arm-bcm7xxx-Add-a-devicetree-file.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0013-arm-qemu-ppce500-Add-a-devicetree-file.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Alexander Graf <agraf@csgraf.de>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Niel Fourie <lusus@denx.de>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Sinan Akman <sinan@writeme.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Wolfgang Denk <wd@denx.de>
0014-arm-highbank-Add-a-fake-devicetree-file.patch
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tim Harvey <tharvey@gateworks.com>
0015-fdt-Make-OF_BOARD-a-bool-option.patch
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Jerry Van Baren <vanbaren@cideas.com>
Cc: Leo Yu-Chi Liang <ycliang@andestech.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
0016-Drop-CONFIG_BINMAN_STANDALONE_FDT.patch
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Pali Rohár <pali@kernel.org>
Cc: Simon Glass <sjg@chromium.org>
To: U-Boot Mailing List <u-boot@lists.denx.de>
To: u-boot@lists.denx.de
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: Tom Rini <trini@konsulko.com>
Version: None
Prefix: None
Cover: 36 lines
Cc: Aaron Williams <awilliams@marvell.com>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Alexander Graf <agraf@csgraf.de>
Cc: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
Cc: Atish Patra <atish.patra@wdc.com>
Cc: Bin Meng <bin.meng@windriver.com>
Cc: Bin Meng <bmeng.cn@gmail.com>
Cc: Christian Hewitt <christianshewitt@gmail.com>
Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Green Wan <green.wan@sifive.com>
Cc: Heiko Schocher <hs@denx.de>
Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
Cc: Jagan Teki <jagan@amarulasolutions.com>
Cc: Jerry Van Baren <vanbaren@cideas.com>
Cc: Jonathan Balkind <jbalkind@ucsb.edu>
Cc: Kever Yang <kever.yang@rock-chips.com>
Cc: Leo <ycliang@andestech.com>
Cc: Leo Yu-Chi Liang <ycliang@andestech.com>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
Cc: Marek Behún <marek.behun@nic.cz>
Cc: Matthias Brugger <mbrugger@suse.com>
Cc: Michal Simek <michal.simek@xilinx.com>
Cc: Michal Simek <monstr@monstr.eu>
Cc: Neil Armstrong <narmstrong@baylibre.com>
Cc: Niel Fourie <lusus@denx.de>
Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
Cc: Padmarao Begari <padmarao.begari@microchip.com>
Cc: Pali Rohár <pali@kernel.org>
Cc: Peter Robinson <pbrobinson@gmail.com>
Cc: Priyanka Jain <priyanka.jain@nxp.com>
Cc: Ramon Fried <rfried.dev@gmail.com>
Cc: Rick Chen <rick@andestech.com>
Cc: Sean Anderson <seanga2@gmail.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Sinan Akman <sinan@writeme.com>
Cc: Stefan Roese <sr@denx.de>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: T Karthik Reddy <t.karthik.reddy@xilinx.com>
Cc: Tero Kristo <kristo@kernel.org>
Cc: Thomas Fitzsimmons <fitzsim@fitzsim.org>
Cc: Tianrui Wei <tianrui-wei@outlook.com>
Cc: Tim Harvey <tharvey@gateworks.com>
Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
Cc: Wolfgang Denk <wd@denx.de>
Cc: Zong Li <zong.li@sifive.com>
Cc: qemu-devel@nongnu.org
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 15/16] fdt: Make OF_BOARD a bool option
2021-10-13 16:58 ` Simon Glass
@ 2021-10-13 17:30 ` Sean Anderson
2021-10-24 19:53 ` Simon Glass
0 siblings, 1 reply; 164+ messages in thread
From: Sean Anderson @ 2021-10-13 17:30 UTC (permalink / raw)
To: Simon Glass, Heinrich Schuchardt
Cc: Tom Rini, Ilias Apalodimas, Bin Meng, Jerry Van Baren,
Leo Yu-Chi Liang, Priyanka Jain, Rick Chen, Vladimir Oltean,
U-Boot Mailing List
On 10/13/21 12:58 PM, Simon Glass wrote:
> Hi Heinrich,
>
> On Tue, 12 Oct 2021 at 22:22, Heinrich Schuchardt
> <heinrich.schuchardt@canonical.com> wrote:
>>
>>
>>
>> On 10/13/21 03:01, Simon Glass wrote:
>>> 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.
>>
>> You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
>> complete patch sets instead of selected patches which cannot be reviewed
>> without the context.
>
> I actually only explicitly cc'd Ilias (who has been working on similar
> things) and Tom. Everyone else came in via maintainer files. Can you
> see the rest in the mailing list, assuming you are subscribed? I can
> add you to the next version.
>
> For the record, here is what patman produced:
FWIW I have always thought that patman CCs too many people by default.
It is only partially based on MAINTAINERS; the rest of the CCs are from
people who have touched the file recently. This results in many people
being CC'd who have made only minor or unrelated changes to the code
(especially from treewide changes). For this reason, I curate my CCs
manually to hopefully CC only those people who are actually interested
in my patches.
--Sean
> $ patman -n
> Cleaned 16 patches
> ...
> checkpatch.pl found 0 error(s), 14 warning(s), 0 checks(s)
> Not sending emails due to errors/warnings
> Dry run, so not doing much. But I would do this:
>
> Send a total of 16 patches with a cover letter.
> 0001-arm-qemu-Mention-nographic-in-the-docs.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: qemu-devel@nongnu.org
> 0002-arm-qemu-Explain-how-to-extract-the-generate-devicet.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: qemu-devel@nongnu.org
> 0003-riscv-qemu-Explain-how-to-extract-the-generate-devic.patch
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bin Meng <bin.meng@windriver.com>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: qemu-devel@nongnu.org
> 0004-arm-qemu-Add-a-devicetree-file-for-qemu_arm.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> Cc: qemu-devel@nongnu.org
> 0005-arm-qemu-Add-a-devicetree-file-for-qemu_arm64.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> Cc: qemu-devel@nongnu.org
> 0006-riscv-qemu-Add-devicetree-files-for-qemu_riscv32-64.patch
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
> Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
> Cc: Green Wan <green.wan@sifive.com>
> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Cc: Jonathan Balkind <jbalkind@ucsb.edu>
> Cc: Leo <ycliang@andestech.com>
> Cc: Padmarao Begari <padmarao.begari@microchip.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tianrui Wei <tianrui-wei@outlook.com>
> Cc: Zong Li <zong.li@sifive.com>
> Cc: qemu-devel@nongnu.org
> 0007-arm-rpi-Add-a-devicetree-file-for-rpi_4.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Matthias Brugger <mbrugger@suse.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0008-arm-vexpress-Add-a-devicetree-file-for-juno.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Bin Meng <bin.meng@windriver.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0009-arm-xenguest_arm64-Add-a-fake-devicetree-file.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Bin Meng <bin.meng@windriver.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0010-arm-octeontx-Add-a-fake-devicetree-file.patch
> Cc: Aaron Williams <awilliams@marvell.com>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Tero Kristo <kristo@kernel.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0011-arm-xilinx_versal_virt-Add-a-devicetree-file.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: T Karthik Reddy <t.karthik.reddy@xilinx.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0012-arm-bcm7xxx-Add-a-devicetree-file.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0013-arm-qemu-ppce500-Add-a-devicetree-file.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Alexander Graf <agraf@csgraf.de>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Niel Fourie <lusus@denx.de>
> Cc: Priyanka Jain <priyanka.jain@nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Sinan Akman <sinan@writeme.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: Wolfgang Denk <wd@denx.de>
> 0014-arm-highbank-Add-a-fake-devicetree-file.patch
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Ramon Fried <rfried.dev@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Tim Harvey <tharvey@gateworks.com>
> 0015-fdt-Make-OF_BOARD-a-bool-option.patch
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Cc: Jerry Van Baren <vanbaren@cideas.com>
> Cc: Leo Yu-Chi Liang <ycliang@andestech.com>
> Cc: Priyanka Jain <priyanka.jain@nxp.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> 0016-Drop-CONFIG_BINMAN_STANDALONE_FDT.patch
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Marek Behún <marek.behun@nic.cz>
> Cc: Pali Rohár <pali@kernel.org>
> Cc: Simon Glass <sjg@chromium.org>
> To: U-Boot Mailing List <u-boot@lists.denx.de>
> To: u-boot@lists.denx.de
> Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
> Cc: Tom Rini <trini@konsulko.com>
> Version: None
> Prefix: None
> Cover: 36 lines
> Cc: Aaron Williams <awilliams@marvell.com>
> Cc: Albert Aribaud <albert.u.boot@aribaud.net>
> Cc: Alexander Graf <agraf@csgraf.de>
> Cc: Anastasiia Lukianenko <anastasiia_lukianenko@epam.com>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com>
> Cc: Atish Patra <atish.patra@wdc.com>
> Cc: Bin Meng <bin.meng@windriver.com>
> Cc: Bin Meng <bmeng.cn@gmail.com>
> Cc: Christian Hewitt <christianshewitt@gmail.com>
> Cc: David Abdurachmanov <david.abdurachmanov@sifive.com>
> Cc: Dimitri John Ledkov <dimitri.ledkov@canonical.com>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Green Wan <green.wan@sifive.com>
> Cc: Heiko Schocher <hs@denx.de>
> Cc: Heinrich Schuchardt <heinrich.schuchardt@canonical.com>
> Cc: Heinrich Schuchardt <xypron.glpk@gmx.de>
> Cc: Jagan Teki <jagan@amarulasolutions.com>
> Cc: Jerry Van Baren <vanbaren@cideas.com>
> Cc: Jonathan Balkind <jbalkind@ucsb.edu>
> Cc: Kever Yang <kever.yang@rock-chips.com>
> Cc: Leo <ycliang@andestech.com>
> Cc: Leo Yu-Chi Liang <ycliang@andestech.com>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Cc: Liviu Dudau <liviu.dudau@foss.arm.com>
> Cc: Marek Behún <marek.behun@nic.cz>
> Cc: Matthias Brugger <mbrugger@suse.com>
> Cc: Michal Simek <michal.simek@xilinx.com>
> Cc: Michal Simek <monstr@monstr.eu>
> Cc: Neil Armstrong <narmstrong@baylibre.com>
> Cc: Niel Fourie <lusus@denx.de>
> Cc: Oleksandr Andrushchenko <oleksandr_andrushchenko@epam.com>
> Cc: Padmarao Begari <padmarao.begari@microchip.com>
> Cc: Pali Rohár <pali@kernel.org>
> Cc: Peter Robinson <pbrobinson@gmail.com>
> Cc: Priyanka Jain <priyanka.jain@nxp.com>
> Cc: Ramon Fried <rfried.dev@gmail.com>
> Cc: Rick Chen <rick@andestech.com>
> Cc: Sean Anderson <seanga2@gmail.com>
> Cc: Simon Glass <sjg@chromium.org>
> Cc: Sinan Akman <sinan@writeme.com>
> Cc: Stefan Roese <sr@denx.de>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Cc: T Karthik Reddy <t.karthik.reddy@xilinx.com>
> Cc: Tero Kristo <kristo@kernel.org>
> Cc: Thomas Fitzsimmons <fitzsim@fitzsim.org>
> Cc: Tianrui Wei <tianrui-wei@outlook.com>
> Cc: Tim Harvey <tharvey@gateworks.com>
> Cc: Tuomas Tynkkynen <tuomas.tynkkynen@iki.fi>
> Cc: Valentin Longchamp <valentin.longchamp@hitachi-powergrids.com>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Zong Li <zong.li@sifive.com>
> Cc: qemu-devel@nongnu.org
>
> Regards,
> Simon
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 15/16] fdt: Make OF_BOARD a bool option
2021-10-13 17:30 ` Sean Anderson
@ 2021-10-24 19:53 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-24 19:53 UTC (permalink / raw)
To: Sean Anderson
Cc: Heinrich Schuchardt, Tom Rini, Ilias Apalodimas, Bin Meng,
Jerry Van Baren, Leo Yu-Chi Liang, Priyanka Jain, Rick Chen,
Vladimir Oltean, U-Boot Mailing List
Hi Sean,
On Wed, 13 Oct 2021 at 11:30, Sean Anderson <seanga2@gmail.com> wrote:
>
> On 10/13/21 12:58 PM, Simon Glass wrote:
> > Hi Heinrich,
> >
> > On Tue, 12 Oct 2021 at 22:22, Heinrich Schuchardt
> > <heinrich.schuchardt@canonical.com> wrote:
> >>
> >>
> >>
> >> On 10/13/21 03:01, Simon Glass wrote:
> >>> 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.
> >>
> >> You only sent patch 6/16 and 15/16 to me. No clue why. Please, send
> >> complete patch sets instead of selected patches which cannot be reviewed
> >> without the context.
> >
> > I actually only explicitly cc'd Ilias (who has been working on similar
> > things) and Tom. Everyone else came in via maintainer files. Can you
> > see the rest in the mailing list, assuming you are subscribed? I can
> > add you to the next version.
> >
> > For the record, here is what patman produced:
>
> FWIW I have always thought that patman CCs too many people by default.
> It is only partially based on MAINTAINERS; the rest of the CCs are from
> people who have touched the file recently. This results in many people
> being CC'd who have made only minor or unrelated changes to the code
> (especially from treewide changes). For this reason, I curate my CCs
> manually to hopefully CC only those people who are actually interested
> in my patches.
Patman uses only the commit tags and get_maintainers, so the fault may
live with the latter?
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* [PATCH 16/16] Drop CONFIG_BINMAN_STANDALONE_FDT
2021-10-13 1:01 ` Simon Glass
` (15 preceding siblings ...)
(?)
@ 2021-10-13 1:01 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 1:01 UTC (permalink / raw)
To: U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Simon Glass, Bin Meng,
Marek Behún, Pali Rohár
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 <sjg@chromium.org>
---
Makefile | 3 +--
dts/Kconfig | 18 ------------------
tools/binman/binman.rst | 20 --------------------
3 files changed, 1 insertion(+), 40 deletions(-)
diff --git a/Makefile b/Makefile
index 94c4fd548b4..c20aaf73710 100644
--- a/Makefile
+++ b/Makefile
@@ -939,7 +939,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
@@ -1406,7 +1405,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 6be5710df7d..58356b45e46 100644
--- a/dts/Kconfig
+++ b/dts/Kconfig
@@ -19,24 +19,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/<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 614df541c5a..f90dd3a5e5d 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/<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.33.0.882.g93a45727a2-goog
^ permalink raw reply related [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 1:29 ` Bin Meng
-1 siblings, 0 replies; 164+ messages in thread
From: Bin Meng @ 2021-10-13 1:29 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List,
Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
Atish Patra, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi Simon,
On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>
> 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 at [1].
>
> 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.
Adding device trees that are never used sounds like a hack to me.
For QEMU, device tree is dynamically generated on the fly based on
command line parameters, and the device tree you put in this series
has various hardcoded <phandle> values which normally do not show up
in hand-written dts files.
I am not sure I understand the whole point of this.
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
Regards,
Bin
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 1:29 ` Bin Meng
0 siblings, 0 replies; 164+ messages in thread
From: Bin Meng @ 2021-10-13 1:29 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Tom Rini, Ilias Apalodimas, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Ashok Reddy Soma, Atish Patra, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon,
On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>
> 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 at [1].
>
> 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.
Adding device trees that are never used sounds like a hack to me.
For QEMU, device tree is dynamically generated on the fly based on
command line parameters, and the device tree you put in this series
has various hardcoded <phandle> values which normally do not show up
in hand-written dts files.
I am not sure I understand the whole point of this.
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
Regards,
Bin
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:29 ` Bin Meng
@ 2021-10-13 1:34 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-13 1:34 UTC (permalink / raw)
To: Bin Meng
Cc: Simon Glass, U-Boot Mailing List, Ilias Apalodimas,
Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Christian Hewitt, David Abdurachmanov,
Dimitri John Ledkov, Fabio Estevam, Green Wan, Heiko Schocher,
Heinrich Schuchardt, Heinrich Schuchardt, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, Valentin Longchamp,
Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > 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 at [1].
> >
> > 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.
>
> Adding device trees that are never used sounds like a hack to me.
>
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded <phandle> values which normally do not show up
> in hand-written dts files.
>
> I am not sure I understand the whole point of this.
I am also confused and do not like the idea of adding device trees for
platforms that are capable of and can / do have a device tree to give us
at run time.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 1:34 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-13 1:34 UTC (permalink / raw)
To: Bin Meng
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 2058 bytes --]
On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> Hi Simon,
>
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >
> > 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 at [1].
> >
> > 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.
>
> Adding device trees that are never used sounds like a hack to me.
>
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded <phandle> values which normally do not show up
> in hand-written dts files.
>
> I am not sure I understand the whole point of this.
I am also confused and do not like the idea of adding device trees for
platforms that are capable of and can / do have a device tree to give us
at run time.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:34 ` Tom Rini
@ 2021-10-13 8:02 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 8:02 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 2948 bytes --]
Hi Simon
Le mer. 13 oct. 2021 à 03:35, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.
>
> --
> Tom
+1
While the cleanup go get three options, including OF_BOARD is nice, the
build solution you propose does not sound the right approach: U-Boot should
be buildable without any DT.
Getting the DT you produced as sample information can be useful and kept
out of build path in documentation with ad-hoc warnings though as I
explained in other mails of the series.
OF_BOARD is a choice to say “I don’t override the legitimate DT with either
OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for
U-Boot maintainer of the platform).
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 5627 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 8:02 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 8:02 UTC (permalink / raw)
To: Tom Rini
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Simon Glass, Sinan Akman, Stefan Roese, Stephen Warren,
Stephen Warren, T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons,
Tianrui Wei, Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon
Le mer. 13 oct. 2021 à 03:35, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.
>
> --
> Tom
+1
While the cleanup go get three options, including OF_BOARD is nice, the
build solution you propose does not sound the right approach: U-Boot should
be buildable without any DT.
Getting the DT you produced as sample information can be useful and kept
out of build path in documentation with ad-hoc warnings though as I
explained in other mails of the series.
OF_BOARD is a choice to say “I don’t override the legitimate DT with either
OF_SEPARATE or OF_EMBED” (which I see in this case as debug facility for
U-Boot maintainer of the platform).
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:34 ` Tom Rini
@ 2021-10-13 14:47 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 14:47 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi Tom, Bin,François,
On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.
(I'll just reply to this one email, since the same points applies to
all replies I think)
I have been thinking about this and discussing it with people for a
few months now. I've been signalling a change like this for over a
month now, on U-Boot contributor calls and in discussions with Linaro
people. I sent a patch (below) to try to explain things. I hope it is
not a surprise!
The issue here is that we need a devicetree in-tree in U-Boot, to
avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
Ilias' series and this one we can get ourselves on a stronger footing.
There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
For more context:
http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
BTW I did suggest to QEMU ARM that they support a way of adding the
u-boot.dtsi but there was not much interest there (in fact the
maintainer would prefer there was no special support even for booting
Linux directly!) But in any case it doesn't really help U-Boot. I
think the path forward might be to run QEMU twice, once to get its
generated tree and once to give the 'merged' tree with the U-Boot
properties in it, if people want to use U-Boot features.
I do strongly believe that OF_BOARD must be a run-time option, not a
build-time one. It creates all sorts of problems and obscurity which
have taken months to unpick. See the above patch for the rationale.
To add to that rationale, OF_BOARD needs to be an option available to
any board. At some point in the future it may become a common way
things are done, e.g. TF-A calling U-Boot and providing a devicetree
to it. It doesn't make any sense to have people decide whether or not
to set OF_BOARD at build time, thus affecting how the image is put
together. We'll end up with different U-Boot build targets like
capricorn, capricorn_of_board and the like. It should be obvious where
that will lead. Instead, OF_BOARD needs to become a commonly used
option, perhaps enabled by most/all boards, so that this sort of build
explosion is not needed. U-Boot needs to be flexible enough to
function correctly in whatever runtime environment in which it finds
itself.
Also as binman is pressed into service more and more to build the
complex firmware images that are becoming fashionable, it needs a
definition (in the devicetree) that describes how to create the image.
We can't support that unless we are building a devicetree, nor can the
running program access the image layout without that information.
François's point about 'don't use this with any kernel' is
germane...but of course I am not suggesting doing that, since OF_BOARD
is, still, enabled. We already use OF_BOARD for various boards that
include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
(as I said in the cover letter "Most boards do provide one, but some
don't."). So this series is just completing the picture by enforcing
that *some sort* of devicetree is always present.
I can't quite pinpoint the patch where U-Boot started allowing the
devicetree to be omitted, but if people are interested I could try a
little harder. It was certainly not my intention (putting on my
device-tree-maintainer hat) to go down that path and it slipped in
somehow in all the confusion. I'm not sure anyone could tell you that
rpi_3 has an in-tree devicetree but rpi_4 does not...
Anyway this series is very modest. It just adds the requirement that
all in-tree boards have some sort of sample devicetree and preferably
some documentation as to where it might come from at runtime. That
should not be a tough call IMO. Assuming we can get the validation in
place (mentioned by Rob Herring recently) it will be quite natural to
sync them between (presumably) Linux and U-Boot.
I am also quite happy to discuss what should actually be in these
devicetree files and whether some of them should be essentially empty.
As you probably noticed, some of them are empty since I literally
could not figure out where they come from! But there needs to be at
least some skeleton for U-Boot to progress, since devicetree is
critical to its feature set.
It is high time we tidied all this up. I predict it will be much
harder, and much more confusing, in 6 months.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 14:47 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 14:47 UTC (permalink / raw)
To: Tom Rini
Cc: Bin Meng, U-Boot Mailing List, Ilias Apalodimas, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Andre Przywara, Ashok Reddy Soma, Atish Patra, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Tom, Bin,François,
On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > Hi Simon,
> >
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >
> > > 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 at [1].
> > >
> > > 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
> >
> > I am not sure I understand the whole point of this.
>
> I am also confused and do not like the idea of adding device trees for
> platforms that are capable of and can / do have a device tree to give us
> at run time.
(I'll just reply to this one email, since the same points applies to
all replies I think)
I have been thinking about this and discussing it with people for a
few months now. I've been signalling a change like this for over a
month now, on U-Boot contributor calls and in discussions with Linaro
people. I sent a patch (below) to try to explain things. I hope it is
not a surprise!
The issue here is that we need a devicetree in-tree in U-Boot, to
avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
Ilias' series and this one we can get ourselves on a stronger footing.
There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
For more context:
http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
BTW I did suggest to QEMU ARM that they support a way of adding the
u-boot.dtsi but there was not much interest there (in fact the
maintainer would prefer there was no special support even for booting
Linux directly!) But in any case it doesn't really help U-Boot. I
think the path forward might be to run QEMU twice, once to get its
generated tree and once to give the 'merged' tree with the U-Boot
properties in it, if people want to use U-Boot features.
I do strongly believe that OF_BOARD must be a run-time option, not a
build-time one. It creates all sorts of problems and obscurity which
have taken months to unpick. See the above patch for the rationale.
To add to that rationale, OF_BOARD needs to be an option available to
any board. At some point in the future it may become a common way
things are done, e.g. TF-A calling U-Boot and providing a devicetree
to it. It doesn't make any sense to have people decide whether or not
to set OF_BOARD at build time, thus affecting how the image is put
together. We'll end up with different U-Boot build targets like
capricorn, capricorn_of_board and the like. It should be obvious where
that will lead. Instead, OF_BOARD needs to become a commonly used
option, perhaps enabled by most/all boards, so that this sort of build
explosion is not needed. U-Boot needs to be flexible enough to
function correctly in whatever runtime environment in which it finds
itself.
Also as binman is pressed into service more and more to build the
complex firmware images that are becoming fashionable, it needs a
definition (in the devicetree) that describes how to create the image.
We can't support that unless we are building a devicetree, nor can the
running program access the image layout without that information.
François's point about 'don't use this with any kernel' is
germane...but of course I am not suggesting doing that, since OF_BOARD
is, still, enabled. We already use OF_BOARD for various boards that
include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
(as I said in the cover letter "Most boards do provide one, but some
don't."). So this series is just completing the picture by enforcing
that *some sort* of devicetree is always present.
I can't quite pinpoint the patch where U-Boot started allowing the
devicetree to be omitted, but if people are interested I could try a
little harder. It was certainly not my intention (putting on my
device-tree-maintainer hat) to go down that path and it slipped in
somehow in all the confusion. I'm not sure anyone could tell you that
rpi_3 has an in-tree devicetree but rpi_4 does not...
Anyway this series is very modest. It just adds the requirement that
all in-tree boards have some sort of sample devicetree and preferably
some documentation as to where it might come from at runtime. That
should not be a tough call IMO. Assuming we can get the validation in
place (mentioned by Rob Herring recently) it will be quite natural to
sync them between (presumably) Linux and U-Boot.
I am also quite happy to discuss what should actually be in these
devicetree files and whether some of them should be essentially empty.
As you probably noticed, some of them are empty since I literally
could not figure out where they come from! But there needs to be at
least some skeleton for U-Boot to progress, since devicetree is
critical to its feature set.
It is high time we tidied all this up. I predict it will be much
harder, and much more confusing, in 6 months.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 14:47 ` Simon Glass
@ 2021-10-13 17:34 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 17:34 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 8047 bytes --]
Hi Simon
Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> Hi Tom, Bin,François,
>
> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > 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 at [1].
> > > >
> > > > 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.
> > >
> > > Adding device trees that are never used sounds like a hack to me.
> > >
> > > For QEMU, device tree is dynamically generated on the fly based on
> > > command line parameters, and the device tree you put in this series
> > > has various hardcoded <phandle> values which normally do not show up
> > > in hand-written dts files.
> > >
> > > I am not sure I understand the whole point of this.
> >
> > I am also confused and do not like the idea of adding device trees for
> > platforms that are capable of and can / do have a device tree to give us
> > at run time.
>
> (I'll just reply to this one email, since the same points applies to
> all replies I think)
>
> I have been thinking about this and discussing it with people for a
> few months now. I've been signalling a change like this for over a
> month now, on U-Boot contributor calls and in discussions with Linaro
> people. I sent a patch (below) to try to explain things. I hope it is
> not a surprise!
>
> The issue here is that we need a devicetree in-tree in U-Boot, to
> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> Ilias' series and this one we can get ourselves on a stronger footing.
> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> For more context:
>
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> BTW I did suggest to QEMU ARM that they support a way of adding the
> u-boot.dtsi but there was not much interest there (in fact the
> maintainer would prefer there was no special support even for booting
> Linux directly!)
i understand their point of view and agree with it.
> But in any case it doesn't really help U-Boot. I
> think the path forward might be to run QEMU twice, once to get its
> generated tree and once to give the 'merged' tree with the U-Boot
> properties in it, if people want to use U-Boot features.
>
> I do strongly believe that OF_BOARD must be a run-time option, not a
> build-time one. It creates all sorts of problems and obscurity which
> have taken months to unpick. See the above patch for the rationale.
>
> To add to that rationale, OF_BOARD needs to be an option available to
> any board. At some point in the future it may become a common way
> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> to it. It doesn't make any sense to have people decide whether or not
> to set OF_BOARD at build time, thus affecting how the image is put
> together. We'll end up with different U-Boot build targets like
> capricorn, capricorn_of_board and the like. It should be obvious where
> that will lead. Instead, OF_BOARD needs to become a commonly used
> option, perhaps enabled by most/all boards, so that this sort of build
> explosion is not needed.
If you mean that when boards are by construction providing a DTB to U-Boot
then I agree very much. But I don’t understand how the patch set supports
it as it puts dts files for those boards to be built.
> U-Boot needs to be flexible enough to
> function correctly in whatever runtime environment in which it finds
> itself.
>
> Also as binman is pressed into service more and more to build the
> complex firmware images that are becoming fashionable, it needs a
> definition (in the devicetree) that describes how to create the image.
> We can't support that unless we are building a devicetree, nor can the
> running program access the image layout without that information.
>
> François's point about 'don't use this with any kernel' is
> germane...but of course I am not suggesting doing that, since OF_BOARD
> is, still, enabled. We already use OF_BOARD for various boards that
> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> (as I said in the cover letter "Most boards do provide one, but some
> don't."). So this series is just completing the picture by enforcing
> that *some sort* of devicetree is always present.
>
That seems inconsistent with the OF_BOARD becomes the default.
>
> I can't quite pinpoint the patch where U-Boot started allowing the
> devicetree to be omitted, but if people are interested I could try a
> little harder. It was certainly not my intention (putting on my
> device-tree-maintainer hat) to go down that path and it slipped in
> somehow in all the confusion. I'm not sure anyone could tell you that
> rpi_3 has an in-tree devicetree but rpi_4 does not...
>
> Anyway this series is very modest. It just adds the requirement that
> all in-tree boards have some sort of sample devicetree and preferably
> some documentation as to where it might come from at runtime.
That’s a very good goal. But adding files in dts make them not samples but
templates to be used and replace board provided DTB.
If you push all your DTS files in documentation, you do what you say:
adding sample files.
> That
> should not be a tough call IMO. Assuming we can get the validation in
> place (mentioned by Rob Herring recently) it will be quite natural to
> sync them between (presumably) Linux and U-Boot.
>
> I am also quite happy to discuss what should actually be in these
> devicetree files and whether some of them should be essentially empty.
> As you probably noticed, some of them are empty since I literally
> could not figure out where they come from! But there needs to be at
> least some skeleton for U-Boot to progress, since devicetree is
> critical to its feature set.
absolutely. And thank you for your efforts to make that center stage. This
is also Linaro Edge group mist challenging task on the next 6 moths.
Knowing that we have lived in a floating situation for over 10 years, I
just hope we get consensus across projects and distro providers about the
right end goal and migration strategy.
>
>
> It is high time we tidied all this up. I predict it will be much
> harder, and much more confusing, in 6 months.
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 11368 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 17:34 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 17:34 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon
Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> Hi Tom, Bin,François,
>
> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > Hi Simon,
> > >
> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >
> > > > 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 at [1].
> > > >
> > > > 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.
> > >
> > > Adding device trees that are never used sounds like a hack to me.
> > >
> > > For QEMU, device tree is dynamically generated on the fly based on
> > > command line parameters, and the device tree you put in this series
> > > has various hardcoded <phandle> values which normally do not show up
> > > in hand-written dts files.
> > >
> > > I am not sure I understand the whole point of this.
> >
> > I am also confused and do not like the idea of adding device trees for
> > platforms that are capable of and can / do have a device tree to give us
> > at run time.
>
> (I'll just reply to this one email, since the same points applies to
> all replies I think)
>
> I have been thinking about this and discussing it with people for a
> few months now. I've been signalling a change like this for over a
> month now, on U-Boot contributor calls and in discussions with Linaro
> people. I sent a patch (below) to try to explain things. I hope it is
> not a surprise!
>
> The issue here is that we need a devicetree in-tree in U-Boot, to
> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> Ilias' series and this one we can get ourselves on a stronger footing.
> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> For more context:
>
>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
> BTW I did suggest to QEMU ARM that they support a way of adding the
> u-boot.dtsi but there was not much interest there (in fact the
> maintainer would prefer there was no special support even for booting
> Linux directly!)
i understand their point of view and agree with it.
> But in any case it doesn't really help U-Boot. I
> think the path forward might be to run QEMU twice, once to get its
> generated tree and once to give the 'merged' tree with the U-Boot
> properties in it, if people want to use U-Boot features.
>
> I do strongly believe that OF_BOARD must be a run-time option, not a
> build-time one. It creates all sorts of problems and obscurity which
> have taken months to unpick. See the above patch for the rationale.
>
> To add to that rationale, OF_BOARD needs to be an option available to
> any board. At some point in the future it may become a common way
> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> to it. It doesn't make any sense to have people decide whether or not
> to set OF_BOARD at build time, thus affecting how the image is put
> together. We'll end up with different U-Boot build targets like
> capricorn, capricorn_of_board and the like. It should be obvious where
> that will lead. Instead, OF_BOARD needs to become a commonly used
> option, perhaps enabled by most/all boards, so that this sort of build
> explosion is not needed.
If you mean that when boards are by construction providing a DTB to U-Boot
then I agree very much. But I don’t understand how the patch set supports
it as it puts dts files for those boards to be built.
> U-Boot needs to be flexible enough to
> function correctly in whatever runtime environment in which it finds
> itself.
>
> Also as binman is pressed into service more and more to build the
> complex firmware images that are becoming fashionable, it needs a
> definition (in the devicetree) that describes how to create the image.
> We can't support that unless we are building a devicetree, nor can the
> running program access the image layout without that information.
>
> François's point about 'don't use this with any kernel' is
> germane...but of course I am not suggesting doing that, since OF_BOARD
> is, still, enabled. We already use OF_BOARD for various boards that
> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> (as I said in the cover letter "Most boards do provide one, but some
> don't."). So this series is just completing the picture by enforcing
> that *some sort* of devicetree is always present.
>
That seems inconsistent with the OF_BOARD becomes the default.
>
> I can't quite pinpoint the patch where U-Boot started allowing the
> devicetree to be omitted, but if people are interested I could try a
> little harder. It was certainly not my intention (putting on my
> device-tree-maintainer hat) to go down that path and it slipped in
> somehow in all the confusion. I'm not sure anyone could tell you that
> rpi_3 has an in-tree devicetree but rpi_4 does not...
>
> Anyway this series is very modest. It just adds the requirement that
> all in-tree boards have some sort of sample devicetree and preferably
> some documentation as to where it might come from at runtime.
That’s a very good goal. But adding files in dts make them not samples but
templates to be used and replace board provided DTB.
If you push all your DTS files in documentation, you do what you say:
adding sample files.
> That
> should not be a tough call IMO. Assuming we can get the validation in
> place (mentioned by Rob Herring recently) it will be quite natural to
> sync them between (presumably) Linux and U-Boot.
>
> I am also quite happy to discuss what should actually be in these
> devicetree files and whether some of them should be essentially empty.
> As you probably noticed, some of them are empty since I literally
> could not figure out where they come from! But there needs to be at
> least some skeleton for U-Boot to progress, since devicetree is
> critical to its feature set.
absolutely. And thank you for your efforts to make that center stage. This
is also Linaro Edge group mist challenging task on the next 6 moths.
Knowing that we have lived in a floating situation for over 10 years, I
just hope we get consensus across projects and distro providers about the
right end goal and migration strategy.
>
>
> It is high time we tidied all this up. I predict it will be much
> harder, and much more confusing, in 6 months.
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 17:34 ` François Ozog
@ 2021-10-13 18:06 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 18:06 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi François,
On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Tom, Bin,François,
>>
>> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> > > Hi Simon,
>> > >
>> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>> > > >
>> > > > 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 at [1].
>> > > >
>> > > > 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.
>> > >
>> > > Adding device trees that are never used sounds like a hack to me.
>> > >
>> > > For QEMU, device tree is dynamically generated on the fly based on
>> > > command line parameters, and the device tree you put in this series
>> > > has various hardcoded <phandle> values which normally do not show up
>> > > in hand-written dts files.
>> > >
>> > > I am not sure I understand the whole point of this.
>> >
>> > I am also confused and do not like the idea of adding device trees for
>> > platforms that are capable of and can / do have a device tree to give us
>> > at run time.
>>
>> (I'll just reply to this one email, since the same points applies to
>> all replies I think)
>>
>> I have been thinking about this and discussing it with people for a
>> few months now. I've been signalling a change like this for over a
>> month now, on U-Boot contributor calls and in discussions with Linaro
>> people. I sent a patch (below) to try to explain things. I hope it is
>> not a surprise!
>>
>> The issue here is that we need a devicetree in-tree in U-Boot, to
>> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> Ilias' series and this one we can get ourselves on a stronger footing.
>> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> For more context:
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>>
>> BTW I did suggest to QEMU ARM that they support a way of adding the
>> u-boot.dtsi but there was not much interest there (in fact the
>> maintainer would prefer there was no special support even for booting
>> Linux directly!)
>
> i understand their point of view and agree with it.
>>
>> But in any case it doesn't really help U-Boot. I
>> think the path forward might be to run QEMU twice, once to get its
>> generated tree and once to give the 'merged' tree with the U-Boot
>> properties in it, if people want to use U-Boot features.
>>
>> I do strongly believe that OF_BOARD must be a run-time option, not a
>> build-time one. It creates all sorts of problems and obscurity which
>> have taken months to unpick. See the above patch for the rationale.
>>
>> To add to that rationale, OF_BOARD needs to be an option available to
>> any board. At some point in the future it may become a common way
>> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> to it. It doesn't make any sense to have people decide whether or not
>> to set OF_BOARD at build time, thus affecting how the image is put
>> together. We'll end up with different U-Boot build targets like
>> capricorn, capricorn_of_board and the like. It should be obvious where
>> that will lead. Instead, OF_BOARD needs to become a commonly used
>> option, perhaps enabled by most/all boards, so that this sort of build
>> explosion is not needed.
>
> If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
>>
>> U-Boot needs to be flexible enough to
>> function correctly in whatever runtime environment in which it finds
>> itself.
>>
>> Also as binman is pressed into service more and more to build the
>> complex firmware images that are becoming fashionable, it needs a
>> definition (in the devicetree) that describes how to create the image.
>> We can't support that unless we are building a devicetree, nor can the
>> running program access the image layout without that information.
>>
>> François's point about 'don't use this with any kernel' is
>> germane...but of course I am not suggesting doing that, since OF_BOARD
>> is, still, enabled. We already use OF_BOARD for various boards that
>> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
>> (as I said in the cover letter "Most boards do provide one, but some
>> don't."). So this series is just completing the picture by enforcing
>> that *some sort* of devicetree is always present.
>
> That seems inconsistent with the OF_BOARD becomes the default.
I think the key point that will get you closer to where I am on this
issue, is that OF_BOARD needs to be a run-time option. At present it
has build-time effects and this is quite wrong. If you go through all
the material I have written on this I think I have motivated that very
clearly.
Another big issue is that I believe we need ONE devicetree for U-Boot,
not two that get merged by U-Boot. Again I have gone through that in a
lot of detail.
>>
>>
>> I can't quite pinpoint the patch where U-Boot started allowing the
>> devicetree to be omitted, but if people are interested I could try a
>> little harder. It was certainly not my intention (putting on my
>> device-tree-maintainer hat) to go down that path and it slipped in
>> somehow in all the confusion. I'm not sure anyone could tell you that
>> rpi_3 has an in-tree devicetree but rpi_4 does not...
>>
>> Anyway this series is very modest. It just adds the requirement that
>> all in-tree boards have some sort of sample devicetree and preferably
>> some documentation as to where it might come from at runtime.
>
> That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB.
> If you push all your DTS files in documentation, you do what you say: adding sample files.
>>
>> That
>> should not be a tough call IMO. Assuming we can get the validation in
>> place (mentioned by Rob Herring recently) it will be quite natural to
>> sync them between (presumably) Linux and U-Boot.
>>
>> I am also quite happy to discuss what should actually be in these
>> devicetree files and whether some of them should be essentially empty.
>> As you probably noticed, some of them are empty since I literally
>> could not figure out where they come from! But there needs to be at
>> least some skeleton for U-Boot to progress, since devicetree is
>> critical to its feature set.
>
> absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy.
>>
Thank you.
>>
>>
>> It is high time we tidied all this up. I predict it will be much
>> harder, and much more confusing, in 6 months.
Just to set a road map here in case you can help unblock anything,
here are the things I am aware of, excluding the things I have
forgotten:
- Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
- this series
- the devicetree docs patch
- devicetree bindings upstream for U-Boot (first patch under discussion)
- bloblist as a means of passing devicetree, ACPI, tiny config info as
C structs to U-Boot (needs to be written)
- VPL so we can handle verification (patches pending)
- bootflow / VBE v2 series (coming next week)
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 18:06 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-13 18:06 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi François,
On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Tom, Bin,François,
>>
>> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>> >
>> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> > > Hi Simon,
>> > >
>> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>> > > >
>> > > > 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 at [1].
>> > > >
>> > > > 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.
>> > >
>> > > Adding device trees that are never used sounds like a hack to me.
>> > >
>> > > For QEMU, device tree is dynamically generated on the fly based on
>> > > command line parameters, and the device tree you put in this series
>> > > has various hardcoded <phandle> values which normally do not show up
>> > > in hand-written dts files.
>> > >
>> > > I am not sure I understand the whole point of this.
>> >
>> > I am also confused and do not like the idea of adding device trees for
>> > platforms that are capable of and can / do have a device tree to give us
>> > at run time.
>>
>> (I'll just reply to this one email, since the same points applies to
>> all replies I think)
>>
>> I have been thinking about this and discussing it with people for a
>> few months now. I've been signalling a change like this for over a
>> month now, on U-Boot contributor calls and in discussions with Linaro
>> people. I sent a patch (below) to try to explain things. I hope it is
>> not a surprise!
>>
>> The issue here is that we need a devicetree in-tree in U-Boot, to
>> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> Ilias' series and this one we can get ourselves on a stronger footing.
>> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> For more context:
>>
>> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>>
>> BTW I did suggest to QEMU ARM that they support a way of adding the
>> u-boot.dtsi but there was not much interest there (in fact the
>> maintainer would prefer there was no special support even for booting
>> Linux directly!)
>
> i understand their point of view and agree with it.
>>
>> But in any case it doesn't really help U-Boot. I
>> think the path forward might be to run QEMU twice, once to get its
>> generated tree and once to give the 'merged' tree with the U-Boot
>> properties in it, if people want to use U-Boot features.
>>
>> I do strongly believe that OF_BOARD must be a run-time option, not a
>> build-time one. It creates all sorts of problems and obscurity which
>> have taken months to unpick. See the above patch for the rationale.
>>
>> To add to that rationale, OF_BOARD needs to be an option available to
>> any board. At some point in the future it may become a common way
>> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> to it. It doesn't make any sense to have people decide whether or not
>> to set OF_BOARD at build time, thus affecting how the image is put
>> together. We'll end up with different U-Boot build targets like
>> capricorn, capricorn_of_board and the like. It should be obvious where
>> that will lead. Instead, OF_BOARD needs to become a commonly used
>> option, perhaps enabled by most/all boards, so that this sort of build
>> explosion is not needed.
>
> If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
>>
>> U-Boot needs to be flexible enough to
>> function correctly in whatever runtime environment in which it finds
>> itself.
>>
>> Also as binman is pressed into service more and more to build the
>> complex firmware images that are becoming fashionable, it needs a
>> definition (in the devicetree) that describes how to create the image.
>> We can't support that unless we are building a devicetree, nor can the
>> running program access the image layout without that information.
>>
>> François's point about 'don't use this with any kernel' is
>> germane...but of course I am not suggesting doing that, since OF_BOARD
>> is, still, enabled. We already use OF_BOARD for various boards that
>> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
>> (as I said in the cover letter "Most boards do provide one, but some
>> don't."). So this series is just completing the picture by enforcing
>> that *some sort* of devicetree is always present.
>
> That seems inconsistent with the OF_BOARD becomes the default.
I think the key point that will get you closer to where I am on this
issue, is that OF_BOARD needs to be a run-time option. At present it
has build-time effects and this is quite wrong. If you go through all
the material I have written on this I think I have motivated that very
clearly.
Another big issue is that I believe we need ONE devicetree for U-Boot,
not two that get merged by U-Boot. Again I have gone through that in a
lot of detail.
>>
>>
>> I can't quite pinpoint the patch where U-Boot started allowing the
>> devicetree to be omitted, but if people are interested I could try a
>> little harder. It was certainly not my intention (putting on my
>> device-tree-maintainer hat) to go down that path and it slipped in
>> somehow in all the confusion. I'm not sure anyone could tell you that
>> rpi_3 has an in-tree devicetree but rpi_4 does not...
>>
>> Anyway this series is very modest. It just adds the requirement that
>> all in-tree boards have some sort of sample devicetree and preferably
>> some documentation as to where it might come from at runtime.
>
> That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB.
> If you push all your DTS files in documentation, you do what you say: adding sample files.
>>
>> That
>> should not be a tough call IMO. Assuming we can get the validation in
>> place (mentioned by Rob Herring recently) it will be quite natural to
>> sync them between (presumably) Linux and U-Boot.
>>
>> I am also quite happy to discuss what should actually be in these
>> devicetree files and whether some of them should be essentially empty.
>> As you probably noticed, some of them are empty since I literally
>> could not figure out where they come from! But there needs to be at
>> least some skeleton for U-Boot to progress, since devicetree is
>> critical to its feature set.
>
> absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy.
>>
Thank you.
>>
>>
>> It is high time we tidied all this up. I predict it will be much
>> harder, and much more confusing, in 6 months.
Just to set a road map here in case you can help unblock anything,
here are the things I am aware of, excluding the things I have
forgotten:
- Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
- this series
- the devicetree docs patch
- devicetree bindings upstream for U-Boot (first patch under discussion)
- bloblist as a means of passing devicetree, ACPI, tiny config info as
C structs to U-Boot (needs to be written)
- VPL so we can handle verification (patches pending)
- bootflow / VBE v2 series (coming next week)
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 18:06 ` Simon Glass
@ 2021-10-14 14:56 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-14 14:56 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 7518 bytes --]
On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded <phandle> values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is not needed.
> >
> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> >>
> >> U-Boot needs to be flexible enough to
> >> function correctly in whatever runtime environment in which it finds
> >> itself.
> >>
> >> Also as binman is pressed into service more and more to build the
> >> complex firmware images that are becoming fashionable, it needs a
> >> definition (in the devicetree) that describes how to create the image.
> >> We can't support that unless we are building a devicetree, nor can the
> >> running program access the image layout without that information.
> >>
> >> François's point about 'don't use this with any kernel' is
> >> germane...but of course I am not suggesting doing that, since OF_BOARD
> >> is, still, enabled. We already use OF_BOARD for various boards that
> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> >> (as I said in the cover letter "Most boards do provide one, but some
> >> don't."). So this series is just completing the picture by enforcing
> >> that *some sort* of devicetree is always present.
> >
> > That seems inconsistent with the OF_BOARD becomes the default.
>
> I think the key point that will get you closer to where I am on this
> issue, is that OF_BOARD needs to be a run-time option. At present it
> has build-time effects and this is quite wrong. If you go through all
> the material I have written on this I think I have motivated that very
> clearly.
>
> Another big issue is that I believe we need ONE devicetree for U-Boot,
> not two that get merged by U-Boot. Again I have gone through that in a
> lot of detail.
I have a long long reply to your first reply here saved, but, maybe
here's the biggest sticking point. To be clear, you agree that U-Boot
needs to support being passed a device tree to use, at run time, yes?
And in that case, would not be using the "fake" tree we built in?
So is the sticking point here that we really have two classes of
devices, one class where we will never ever be given the device tree at
run time (think BeagleBone Black) and one where we will always be given
one at run time (think Raspberry Pi) ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 14:56 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-14 14:56 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 7518 bytes --]
On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded <phandle> values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is not needed.
> >
> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> >>
> >> U-Boot needs to be flexible enough to
> >> function correctly in whatever runtime environment in which it finds
> >> itself.
> >>
> >> Also as binman is pressed into service more and more to build the
> >> complex firmware images that are becoming fashionable, it needs a
> >> definition (in the devicetree) that describes how to create the image.
> >> We can't support that unless we are building a devicetree, nor can the
> >> running program access the image layout without that information.
> >>
> >> François's point about 'don't use this with any kernel' is
> >> germane...but of course I am not suggesting doing that, since OF_BOARD
> >> is, still, enabled. We already use OF_BOARD for various boards that
> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> >> (as I said in the cover letter "Most boards do provide one, but some
> >> don't."). So this series is just completing the picture by enforcing
> >> that *some sort* of devicetree is always present.
> >
> > That seems inconsistent with the OF_BOARD becomes the default.
>
> I think the key point that will get you closer to where I am on this
> issue, is that OF_BOARD needs to be a run-time option. At present it
> has build-time effects and this is quite wrong. If you go through all
> the material I have written on this I think I have motivated that very
> clearly.
>
> Another big issue is that I believe we need ONE devicetree for U-Boot,
> not two that get merged by U-Boot. Again I have gone through that in a
> lot of detail.
I have a long long reply to your first reply here saved, but, maybe
here's the biggest sticking point. To be clear, you agree that U-Boot
needs to support being passed a device tree to use, at run time, yes?
And in that case, would not be using the "fake" tree we built in?
So is the sticking point here that we really have two classes of
devices, one class where we will never ever be given the device tree at
run time (think BeagleBone Black) and one where we will always be given
one at run time (think Raspberry Pi) ?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 14:56 ` Tom Rini
@ 2021-10-14 15:17 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-14 15:17 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Tom,
On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > Hi François,
> >
> > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > >
> > > Hi Simon
> > >
> > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > >>
> > >> Hi Tom, Bin,François,
> > >>
> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > >> >
> > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > >> > > Hi Simon,
> > >> > >
> > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >> > > >
> > >> > > > 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 at [1].
> > >> > > >
> > >> > > > 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.
> > >> > >
> > >> > > Adding device trees that are never used sounds like a hack to me.
> > >> > >
> > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > >> > > command line parameters, and the device tree you put in this series
> > >> > > has various hardcoded <phandle> values which normally do not show up
> > >> > > in hand-written dts files.
> > >> > >
> > >> > > I am not sure I understand the whole point of this.
> > >> >
> > >> > I am also confused and do not like the idea of adding device trees for
> > >> > platforms that are capable of and can / do have a device tree to give us
> > >> > at run time.
> > >>
> > >> (I'll just reply to this one email, since the same points applies to
> > >> all replies I think)
> > >>
> > >> I have been thinking about this and discussing it with people for a
> > >> few months now. I've been signalling a change like this for over a
> > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > >> people. I sent a patch (below) to try to explain things. I hope it is
> > >> not a surprise!
> > >>
> > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > >> For more context:
> > >>
> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > >>
> > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > >> u-boot.dtsi but there was not much interest there (in fact the
> > >> maintainer would prefer there was no special support even for booting
> > >> Linux directly!)
> > >
> > > i understand their point of view and agree with it.
> > >>
> > >> But in any case it doesn't really help U-Boot. I
> > >> think the path forward might be to run QEMU twice, once to get its
> > >> generated tree and once to give the 'merged' tree with the U-Boot
> > >> properties in it, if people want to use U-Boot features.
> > >>
> > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > >> build-time one. It creates all sorts of problems and obscurity which
> > >> have taken months to unpick. See the above patch for the rationale.
> > >>
> > >> To add to that rationale, OF_BOARD needs to be an option available to
> > >> any board. At some point in the future it may become a common way
> > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > >> to it. It doesn't make any sense to have people decide whether or not
> > >> to set OF_BOARD at build time, thus affecting how the image is put
> > >> together. We'll end up with different U-Boot build targets like
> > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > >> option, perhaps enabled by most/all boards, so that this sort of build
> > >> explosion is not needed.
> > >
> > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > >>
> > >> U-Boot needs to be flexible enough to
> > >> function correctly in whatever runtime environment in which it finds
> > >> itself.
> > >>
> > >> Also as binman is pressed into service more and more to build the
> > >> complex firmware images that are becoming fashionable, it needs a
> > >> definition (in the devicetree) that describes how to create the image.
> > >> We can't support that unless we are building a devicetree, nor can the
> > >> running program access the image layout without that information.
> > >>
> > >> François's point about 'don't use this with any kernel' is
> > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > >> is, still, enabled. We already use OF_BOARD for various boards that
> > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > >> (as I said in the cover letter "Most boards do provide one, but some
> > >> don't."). So this series is just completing the picture by enforcing
> > >> that *some sort* of devicetree is always present.
> > >
> > > That seems inconsistent with the OF_BOARD becomes the default.
> >
> > I think the key point that will get you closer to where I am on this
> > issue, is that OF_BOARD needs to be a run-time option. At present it
> > has build-time effects and this is quite wrong. If you go through all
> > the material I have written on this I think I have motivated that very
> > clearly.
> >
> > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > not two that get merged by U-Boot. Again I have gone through that in a
> > lot of detail.
>
> I have a long long reply to your first reply here saved, but, maybe
> here's the biggest sticking point. To be clear, you agree that U-Boot
> needs to support being passed a device tree to use, at run time, yes?
Yes. The OF_BOARD feature provides this.
>
> And in that case, would not be using the "fake" tree we built in?
Not at runtime.
>
> So is the sticking point here that we really have two classes of
> devices, one class where we will never ever be given the device tree at
> run time (think BeagleBone Black) and one where we will always be given
> one at run time (think Raspberry Pi) ?
I'm not sure it will be that black and white. I suspect there will be
(many) boards which can boot happily with the U-Boot devicetree but
can also accept one at runtime, if provided. For example, you may want
to boot with or without TF-A or some other, earlier stage.
I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
provided a way to entirely omit a devicetree from U-Boot, thus making
things like binman and U-Boot /config impossible, for example. So I
want to claw that back, so there is always some sort of devicetree in
U-Boot, as we have for rpi_3, etc.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 15:17 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-14 15:17 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi Tom,
On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > Hi François,
> >
> > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > >
> > > Hi Simon
> > >
> > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > >>
> > >> Hi Tom, Bin,François,
> > >>
> > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > >> >
> > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > >> > > Hi Simon,
> > >> > >
> > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > >> > > >
> > >> > > > 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 at [1].
> > >> > > >
> > >> > > > 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.
> > >> > >
> > >> > > Adding device trees that are never used sounds like a hack to me.
> > >> > >
> > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > >> > > command line parameters, and the device tree you put in this series
> > >> > > has various hardcoded <phandle> values which normally do not show up
> > >> > > in hand-written dts files.
> > >> > >
> > >> > > I am not sure I understand the whole point of this.
> > >> >
> > >> > I am also confused and do not like the idea of adding device trees for
> > >> > platforms that are capable of and can / do have a device tree to give us
> > >> > at run time.
> > >>
> > >> (I'll just reply to this one email, since the same points applies to
> > >> all replies I think)
> > >>
> > >> I have been thinking about this and discussing it with people for a
> > >> few months now. I've been signalling a change like this for over a
> > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > >> people. I sent a patch (below) to try to explain things. I hope it is
> > >> not a surprise!
> > >>
> > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > >> For more context:
> > >>
> > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > >>
> > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > >> u-boot.dtsi but there was not much interest there (in fact the
> > >> maintainer would prefer there was no special support even for booting
> > >> Linux directly!)
> > >
> > > i understand their point of view and agree with it.
> > >>
> > >> But in any case it doesn't really help U-Boot. I
> > >> think the path forward might be to run QEMU twice, once to get its
> > >> generated tree and once to give the 'merged' tree with the U-Boot
> > >> properties in it, if people want to use U-Boot features.
> > >>
> > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > >> build-time one. It creates all sorts of problems and obscurity which
> > >> have taken months to unpick. See the above patch for the rationale.
> > >>
> > >> To add to that rationale, OF_BOARD needs to be an option available to
> > >> any board. At some point in the future it may become a common way
> > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > >> to it. It doesn't make any sense to have people decide whether or not
> > >> to set OF_BOARD at build time, thus affecting how the image is put
> > >> together. We'll end up with different U-Boot build targets like
> > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > >> option, perhaps enabled by most/all boards, so that this sort of build
> > >> explosion is not needed.
> > >
> > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > >>
> > >> U-Boot needs to be flexible enough to
> > >> function correctly in whatever runtime environment in which it finds
> > >> itself.
> > >>
> > >> Also as binman is pressed into service more and more to build the
> > >> complex firmware images that are becoming fashionable, it needs a
> > >> definition (in the devicetree) that describes how to create the image.
> > >> We can't support that unless we are building a devicetree, nor can the
> > >> running program access the image layout without that information.
> > >>
> > >> François's point about 'don't use this with any kernel' is
> > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > >> is, still, enabled. We already use OF_BOARD for various boards that
> > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > >> (as I said in the cover letter "Most boards do provide one, but some
> > >> don't."). So this series is just completing the picture by enforcing
> > >> that *some sort* of devicetree is always present.
> > >
> > > That seems inconsistent with the OF_BOARD becomes the default.
> >
> > I think the key point that will get you closer to where I am on this
> > issue, is that OF_BOARD needs to be a run-time option. At present it
> > has build-time effects and this is quite wrong. If you go through all
> > the material I have written on this I think I have motivated that very
> > clearly.
> >
> > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > not two that get merged by U-Boot. Again I have gone through that in a
> > lot of detail.
>
> I have a long long reply to your first reply here saved, but, maybe
> here's the biggest sticking point. To be clear, you agree that U-Boot
> needs to support being passed a device tree to use, at run time, yes?
Yes. The OF_BOARD feature provides this.
>
> And in that case, would not be using the "fake" tree we built in?
Not at runtime.
>
> So is the sticking point here that we really have two classes of
> devices, one class where we will never ever be given the device tree at
> run time (think BeagleBone Black) and one where we will always be given
> one at run time (think Raspberry Pi) ?
I'm not sure it will be that black and white. I suspect there will be
(many) boards which can boot happily with the U-Boot devicetree but
can also accept one at runtime, if provided. For example, you may want
to boot with or without TF-A or some other, earlier stage.
I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
provided a way to entirely omit a devicetree from U-Boot, thus making
things like binman and U-Boot /config impossible, for example. So I
want to claw that back, so there is always some sort of devicetree in
U-Boot, as we have for rpi_3, etc.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 15:17 ` Simon Glass
@ 2021-10-14 15:28 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-14 15:28 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 10110 bytes --]
On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees for
> > > >> > platforms that are capable of and can / do have a device tree to give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)
> > > >
> > > > i understand their point of view and agree with it.
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to unpick. See the above patch for the rationale.
> > > >>
> > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > >> any board. At some point in the future it may become a common way
> > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > >> to it. It doesn't make any sense to have people decide whether or not
> > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > >> together. We'll end up with different U-Boot build targets like
> > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > >> explosion is not needed.
> > > >
> > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > >>
> > > >> U-Boot needs to be flexible enough to
> > > >> function correctly in whatever runtime environment in which it finds
> > > >> itself.
> > > >>
> > > >> Also as binman is pressed into service more and more to build the
> > > >> complex firmware images that are becoming fashionable, it needs a
> > > >> definition (in the devicetree) that describes how to create the image.
> > > >> We can't support that unless we are building a devicetree, nor can the
> > > >> running program access the image layout without that information.
> > > >>
> > > >> François's point about 'don't use this with any kernel' is
> > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > >> don't."). So this series is just completing the picture by enforcing
> > > >> that *some sort* of devicetree is always present.
> > > >
> > > > That seems inconsistent with the OF_BOARD becomes the default.
> > >
> > > I think the key point that will get you closer to where I am on this
> > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > has build-time effects and this is quite wrong. If you go through all
> > > the material I have written on this I think I have motivated that very
> > > clearly.
> > >
> > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > not two that get merged by U-Boot. Again I have gone through that in a
> > > lot of detail.
> >
> > I have a long long reply to your first reply here saved, but, maybe
> > here's the biggest sticking point. To be clear, you agree that U-Boot
> > needs to support being passed a device tree to use, at run time, yes?
>
> Yes. The OF_BOARD feature provides this.
>
> >
> > And in that case, would not be using the "fake" tree we built in?
>
> Not at runtime.
OK.
> > So is the sticking point here that we really have two classes of
> > devices, one class where we will never ever be given the device tree at
> > run time (think BeagleBone Black) and one where we will always be given
> > one at run time (think Raspberry Pi) ?
>
> I'm not sure it will be that black and white. I suspect there will be
> (many) boards which can boot happily with the U-Boot devicetree but
> can also accept one at runtime, if provided. For example, you may want
> to boot with or without TF-A or some other, earlier stage.
I'm not sure I see the value in making this a gray area. There's very
much a class of "never" boards. There's also the class of "can" today.
Maybe as part of a developer iterative flow it would be nice to not have
to re-flash the prior stage to change a DT, and just do it in U-Boot
until things are happy, but I'm not sure what the use case is for
overriding the previous stage.
Especially since the pushback on this series I think has all been "why
are we copying in a tree to build with? We don't want to use it at run
time!". And then softer push back like "Well, U-Boot says we have to
include the device tree file here, but we won't use it...".
> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> provided a way to entirely omit a devicetree from U-Boot, thus making
> things like binman and U-Boot /config impossible, for example. So I
> want to claw that back, so there is always some sort of devicetree in
> U-Boot, as we have for rpi_3, etc.
I really want to see what the binary case looks like since we could then
kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
then also do a rpi_arm32_defconfig too.
I want to see less device trees in U-Boot sources, if they can come
functionally correct from the hardware/our caller.
And I'm not seeing how we make use of "U-Boot /config" if we also don't
use the device tree from build time at run time, ignoring the device
tree provided to us at run time by the caller.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 15:28 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-14 15:28 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 10110 bytes --]
On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> Hi Tom,
>
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees for
> > > >> > platforms that are capable of and can / do have a device tree to give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)
> > > >
> > > > i understand their point of view and agree with it.
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to unpick. See the above patch for the rationale.
> > > >>
> > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > >> any board. At some point in the future it may become a common way
> > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > >> to it. It doesn't make any sense to have people decide whether or not
> > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > >> together. We'll end up with different U-Boot build targets like
> > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > >> explosion is not needed.
> > > >
> > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > >>
> > > >> U-Boot needs to be flexible enough to
> > > >> function correctly in whatever runtime environment in which it finds
> > > >> itself.
> > > >>
> > > >> Also as binman is pressed into service more and more to build the
> > > >> complex firmware images that are becoming fashionable, it needs a
> > > >> definition (in the devicetree) that describes how to create the image.
> > > >> We can't support that unless we are building a devicetree, nor can the
> > > >> running program access the image layout without that information.
> > > >>
> > > >> François's point about 'don't use this with any kernel' is
> > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > >> don't."). So this series is just completing the picture by enforcing
> > > >> that *some sort* of devicetree is always present.
> > > >
> > > > That seems inconsistent with the OF_BOARD becomes the default.
> > >
> > > I think the key point that will get you closer to where I am on this
> > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > has build-time effects and this is quite wrong. If you go through all
> > > the material I have written on this I think I have motivated that very
> > > clearly.
> > >
> > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > not two that get merged by U-Boot. Again I have gone through that in a
> > > lot of detail.
> >
> > I have a long long reply to your first reply here saved, but, maybe
> > here's the biggest sticking point. To be clear, you agree that U-Boot
> > needs to support being passed a device tree to use, at run time, yes?
>
> Yes. The OF_BOARD feature provides this.
>
> >
> > And in that case, would not be using the "fake" tree we built in?
>
> Not at runtime.
OK.
> > So is the sticking point here that we really have two classes of
> > devices, one class where we will never ever be given the device tree at
> > run time (think BeagleBone Black) and one where we will always be given
> > one at run time (think Raspberry Pi) ?
>
> I'm not sure it will be that black and white. I suspect there will be
> (many) boards which can boot happily with the U-Boot devicetree but
> can also accept one at runtime, if provided. For example, you may want
> to boot with or without TF-A or some other, earlier stage.
I'm not sure I see the value in making this a gray area. There's very
much a class of "never" boards. There's also the class of "can" today.
Maybe as part of a developer iterative flow it would be nice to not have
to re-flash the prior stage to change a DT, and just do it in U-Boot
until things are happy, but I'm not sure what the use case is for
overriding the previous stage.
Especially since the pushback on this series I think has all been "why
are we copying in a tree to build with? We don't want to use it at run
time!". And then softer push back like "Well, U-Boot says we have to
include the device tree file here, but we won't use it...".
> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> provided a way to entirely omit a devicetree from U-Boot, thus making
> things like binman and U-Boot /config impossible, for example. So I
> want to claw that back, so there is always some sort of devicetree in
> U-Boot, as we have for rpi_3, etc.
I really want to see what the binary case looks like since we could then
kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
then also do a rpi_arm32_defconfig too.
I want to see less device trees in U-Boot sources, if they can come
functionally correct from the hardware/our caller.
And I'm not seeing how we make use of "U-Boot /config" if we also don't
use the device tree from build time at run time, ignoring the device
tree provided to us at run time by the caller.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 15:28 ` Tom Rini
@ 2021-10-14 17:58 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 17:58 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 11217 bytes --]
Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit :
> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded <phandle> values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all sorts of problems and obscurity
> which
> > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or
> not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious
> where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of
> build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB
> to U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it
> finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the
> image.
> > > > >> We can't support that unless we are building a devicetree, nor
> can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards
> that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > >> (as I said in the cover letter "Most boards do provide one, but
> some
> > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that
> very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in
> a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
>
> OK.
>
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I'm not sure I see the value in making this a gray area. There's very
> much a class of "never" boards. There's also the class of "can" today.
> Maybe as part of a developer iterative flow it would be nice to not have
> to re-flash the prior stage to change a DT, and just do it in U-Boot
> until things are happy, but I'm not sure what the use case is for
> overriding the previous stage.
>
> Especially since the pushback on this series I think has all been "why
> are we copying in a tree to build with? We don't want to use it at run
> time!". And then softer push back like "Well, U-Boot says we have to
> include the device tree file here, but we won't use it...".
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example. So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
>
> I really want to see what the binary case looks like since we could then
> kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> then also do a rpi_arm32_defconfig too.
>
> I want to see less device trees in U-Boot sources, if they can come
> functionally correct from the hardware/our caller.
>
> And I'm not seeing how we make use of "U-Boot /config" if we also don't
> use the device tree from build time at run time, ignoring the device
> tree provided to us at run time by the caller.
+1
if there is a complex build problem to solve when no DT is needed when
OF_BOARD is needed i could agree to temporarily have a void.dts like
/dts-v1/;
/ {
/* required to pass build until proper makefike for OF_BOARD */
};
But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts
are good for reference in the documentation part of the tree.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 17988 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 17:58 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 17:58 UTC (permalink / raw)
To: Tom Rini
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Simon Glass, Sinan Akman, Stefan Roese, Stephen Warren,
Stephen Warren, T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons,
Tianrui Wei, Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Le jeu. 14 oct. 2021 à 17:28, Tom Rini <trini@konsulko.com> a écrit :
> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded <phandle> values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all sorts of problems and obscurity
> which
> > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or
> not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious
> where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of
> build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB
> to U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it
> finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the
> image.
> > > > >> We can't support that unless we are building a devicetree, nor
> can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards
> that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > >> (as I said in the cover letter "Most boards do provide one, but
> some
> > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that
> very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in
> a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
>
> OK.
>
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I'm not sure I see the value in making this a gray area. There's very
> much a class of "never" boards. There's also the class of "can" today.
> Maybe as part of a developer iterative flow it would be nice to not have
> to re-flash the prior stage to change a DT, and just do it in U-Boot
> until things are happy, but I'm not sure what the use case is for
> overriding the previous stage.
>
> Especially since the pushback on this series I think has all been "why
> are we copying in a tree to build with? We don't want to use it at run
> time!". And then softer push back like "Well, U-Boot says we have to
> include the device tree file here, but we won't use it...".
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example. So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
>
> I really want to see what the binary case looks like since we could then
> kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> then also do a rpi_arm32_defconfig too.
>
> I want to see less device trees in U-Boot sources, if they can come
> functionally correct from the hardware/our caller.
>
> And I'm not seeing how we make use of "U-Boot /config" if we also don't
> use the device tree from build time at run time, ignoring the device
> tree provided to us at run time by the caller.
+1
if there is a complex build problem to solve when no DT is needed when
OF_BOARD is needed i could agree to temporarily have a void.dts like
/dts-v1/;
/ {
/* required to pass build until proper makefike for OF_BOARD */
};
But not pseudo dts for boards that provide a DT to U-Boot. The pseudo dts
are good for reference in the documentation part of the tree.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 15:28 ` Tom Rini
@ 2021-10-15 18:03 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-15 18:03 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi all,
On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > > >> > > command line parameters, and the device tree you put in this series
> > > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device trees for
> > > > >> > platforms that are capable of and can / do have a device tree to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > > >> build-time one. It creates all sorts of problems and obscurity which
> > > > >> have taken months to unpick. See the above patch for the rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the image.
> > > > >> We can't support that unless we are building a devicetree, nor can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > > >> don't."). So this series is just completing the picture by enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
>
> OK.
>
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I'm not sure I see the value in making this a gray area. There's very
> much a class of "never" boards. There's also the class of "can" today.
> Maybe as part of a developer iterative flow it would be nice to not have
> to re-flash the prior stage to change a DT, and just do it in U-Boot
> until things are happy, but I'm not sure what the use case is for
> overriding the previous stage.
>
> Especially since the pushback on this series I think has all been "why
> are we copying in a tree to build with? We don't want to use it at run
> time!". And then softer push back like "Well, U-Boot says we have to
> include the device tree file here, but we won't use it...".
See below.
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example. So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
>
> I really want to see what the binary case looks like since we could then
> kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> then also do a rpi_arm32_defconfig too.
>
> I want to see less device trees in U-Boot sources, if they can come
> functionally correct from the hardware/our caller.
>
> And I'm not seeing how we make use of "U-Boot /config" if we also don't
> use the device tree from build time at run time, ignoring the device
> tree provided to us at run time by the caller.
Firstly I should say that I find building firmware very messy and
confusing these days. Lots of things to build and it's hard to find
the instructions. It doesn't have to be that way, but if we carry on
as we are, it will continue to be messy and in five years you will
need a Ph.D and a lucky charm to boot on any modern board. My
objective here is to simplify things, bringing some consistency to the
different components. Binman was one effort there. I feel that putting
at least the U-Boot house in order, in my role as devicetree
maintainer (and as author of devicetree support in U-Boot back in
2011), is the next step.
If we set things up correctly and agree on the bindings, devicetree
can be the unifying configuration mechanism through the whole of
firmware (except for very early bits) and into the OS, this will set
us up very well to deal with the complexity that is coming.
Anyway, here are the mental steps that I've gone through over the past
two months:
Step 1: At present, some people think U-Boot is not even allowed to
have its own nodes/properties in the DT. It is an abuse of the
devicetree standard, like the /chosen node but with less history. We
should sacrifice efficiency, expedience and expandability on the altar
of 'devicetree is a hardware description'. How do we get over that
one? Wel, I just think we need to accept that U-Boot uses devicetree
for its own purposes, as well as for booting the OS. I am not saying
it always has to have those properties, but with existing features
like verified boot, SPL as well as complex firmware images where
U-Boot needs to be able to find things in the image, it is essential.
So let's just assume that we need this everywhere, since we certainly
need it in at least some places.
(stop reading here if you disagree, because nothing below will make
any sense...you can still use U-Boot v2011.06 which doesn't have
OF_CONTROL :-)
Step 2: Assume U-Boot has its own nodes/properties. How do they get
there? Well, we have u-boot.dtsi files for that (the 2016 patch
"6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
have binman definitions, etc. So we need a way to overlay those things
into the DT. We already support this for in-tree DTs, so IMO this is
easy. Just require every board to have an in-tree DT. It helps with
discoverability and documentation, anyway. That is this series.
(I think most of us are at the beginning of step 2, unsure about it
and worried about step 3)
Step 3: Ah, but there are flows (i.e. boards that use a particular
flow only, or boards that sometimes use a flow) which need the DT to
come from a prior stage. How to handle that? IMO that is only going to
grow as every man and his dog get into the write-a-bootloader
business. We need a way to provide the U-Boot nodes/properties in a
form that the prior stage can consume and integrate with its build
system. Is TF-A the only thing being discussed here? If so, let's just
do it. We have the u-boot.dtsi and we can use binman to put the image
together, for example. Or we can get clever and create some sort of
overlay dtb.
Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
then it will need to build it in and use two devicetrees, one internal
and one from the prior stage....well that is not very efficient and it
is going to be confusing for people to figure out what U-Boot is
actually doing. But we actually already do that in a lot of cases
where U-Boot passes a DT to the kernel which is different to the one
it uses. So perhaps we have three devicetrees? OMG. b) Well then
U-Boot can have its own small devicetree with its bits and then U-Boot
can merge the two when it starts. Again that is not very efficient. It
means that U-Boot cannot be controlled by the prior stage (e.g. to get
its public key from there or to enable/disable the console), so
unified firmware config is not possible. It will get very confusing,
particularly for debugging U-Boot. c) Some other scheme to avoid
accepting step 3...please stop!
Step 4: Yes, but there is QEMU, which makes the devicetree up out of
whole cloth. What about that? Well, we are just going to have to deal
with that. We can easily merge in the U-Boot nodes/properties and
update the U-Boot CI scripts to do this, as needed, e.g. with
qemu-riscv64_spl. It's only one use case, although Xen might do
something similar.
To my mind, that deals with both the build-time and run-time issues.
We have a discoverable DT in U-Boot, which should be considered the
source of truth for most boards. We can sync it with Linux
automatically with the tooling that I hope Rob Herring will come up
with. We can use an empty one where there really is no default,
although I'd argue that is making perfect an enemy of the good.
Step 5: If we get clever and want to remove them from the U-Boot tree
and pick them up from somewhere else, we can do that with sufficient
tooling. Perhaps we should set a timeline for that? A year? Two? Six?
To repeat, if we set things up correctly and agree on the bindings,
devicetree can be the unifying configuration mechanism through the
whole of firmware (except for very early bits) and into the OS. I feel
this will set us up very well to deal with the complexity that is
coming.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-15 18:03 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-15 18:03 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi all,
On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
>
> On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > > >> > > command line parameters, and the device tree you put in this series
> > > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device trees for
> > > > >> > platforms that are capable of and can / do have a device tree to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > > >> build-time one. It creates all sorts of problems and obscurity which
> > > > >> have taken months to unpick. See the above patch for the rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the image.
> > > > >> We can't support that unless we are building a devicetree, nor can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > > >> don't."). So this series is just completing the picture by enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
>
> OK.
>
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I'm not sure I see the value in making this a gray area. There's very
> much a class of "never" boards. There's also the class of "can" today.
> Maybe as part of a developer iterative flow it would be nice to not have
> to re-flash the prior stage to change a DT, and just do it in U-Boot
> until things are happy, but I'm not sure what the use case is for
> overriding the previous stage.
>
> Especially since the pushback on this series I think has all been "why
> are we copying in a tree to build with? We don't want to use it at run
> time!". And then softer push back like "Well, U-Boot says we have to
> include the device tree file here, but we won't use it...".
See below.
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example. So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
>
> I really want to see what the binary case looks like since we could then
> kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> then also do a rpi_arm32_defconfig too.
>
> I want to see less device trees in U-Boot sources, if they can come
> functionally correct from the hardware/our caller.
>
> And I'm not seeing how we make use of "U-Boot /config" if we also don't
> use the device tree from build time at run time, ignoring the device
> tree provided to us at run time by the caller.
Firstly I should say that I find building firmware very messy and
confusing these days. Lots of things to build and it's hard to find
the instructions. It doesn't have to be that way, but if we carry on
as we are, it will continue to be messy and in five years you will
need a Ph.D and a lucky charm to boot on any modern board. My
objective here is to simplify things, bringing some consistency to the
different components. Binman was one effort there. I feel that putting
at least the U-Boot house in order, in my role as devicetree
maintainer (and as author of devicetree support in U-Boot back in
2011), is the next step.
If we set things up correctly and agree on the bindings, devicetree
can be the unifying configuration mechanism through the whole of
firmware (except for very early bits) and into the OS, this will set
us up very well to deal with the complexity that is coming.
Anyway, here are the mental steps that I've gone through over the past
two months:
Step 1: At present, some people think U-Boot is not even allowed to
have its own nodes/properties in the DT. It is an abuse of the
devicetree standard, like the /chosen node but with less history. We
should sacrifice efficiency, expedience and expandability on the altar
of 'devicetree is a hardware description'. How do we get over that
one? Wel, I just think we need to accept that U-Boot uses devicetree
for its own purposes, as well as for booting the OS. I am not saying
it always has to have those properties, but with existing features
like verified boot, SPL as well as complex firmware images where
U-Boot needs to be able to find things in the image, it is essential.
So let's just assume that we need this everywhere, since we certainly
need it in at least some places.
(stop reading here if you disagree, because nothing below will make
any sense...you can still use U-Boot v2011.06 which doesn't have
OF_CONTROL :-)
Step 2: Assume U-Boot has its own nodes/properties. How do they get
there? Well, we have u-boot.dtsi files for that (the 2016 patch
"6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
have binman definitions, etc. So we need a way to overlay those things
into the DT. We already support this for in-tree DTs, so IMO this is
easy. Just require every board to have an in-tree DT. It helps with
discoverability and documentation, anyway. That is this series.
(I think most of us are at the beginning of step 2, unsure about it
and worried about step 3)
Step 3: Ah, but there are flows (i.e. boards that use a particular
flow only, or boards that sometimes use a flow) which need the DT to
come from a prior stage. How to handle that? IMO that is only going to
grow as every man and his dog get into the write-a-bootloader
business. We need a way to provide the U-Boot nodes/properties in a
form that the prior stage can consume and integrate with its build
system. Is TF-A the only thing being discussed here? If so, let's just
do it. We have the u-boot.dtsi and we can use binman to put the image
together, for example. Or we can get clever and create some sort of
overlay dtb.
Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
then it will need to build it in and use two devicetrees, one internal
and one from the prior stage....well that is not very efficient and it
is going to be confusing for people to figure out what U-Boot is
actually doing. But we actually already do that in a lot of cases
where U-Boot passes a DT to the kernel which is different to the one
it uses. So perhaps we have three devicetrees? OMG. b) Well then
U-Boot can have its own small devicetree with its bits and then U-Boot
can merge the two when it starts. Again that is not very efficient. It
means that U-Boot cannot be controlled by the prior stage (e.g. to get
its public key from there or to enable/disable the console), so
unified firmware config is not possible. It will get very confusing,
particularly for debugging U-Boot. c) Some other scheme to avoid
accepting step 3...please stop!
Step 4: Yes, but there is QEMU, which makes the devicetree up out of
whole cloth. What about that? Well, we are just going to have to deal
with that. We can easily merge in the U-Boot nodes/properties and
update the U-Boot CI scripts to do this, as needed, e.g. with
qemu-riscv64_spl. It's only one use case, although Xen might do
something similar.
To my mind, that deals with both the build-time and run-time issues.
We have a discoverable DT in U-Boot, which should be considered the
source of truth for most boards. We can sync it with Linux
automatically with the tooling that I hope Rob Herring will come up
with. We can use an empty one where there really is no default,
although I'd argue that is making perfect an enemy of the good.
Step 5: If we get clever and want to remove them from the U-Boot tree
and pick them up from somewhere else, we can do that with sufficient
tooling. Perhaps we should set a timeline for that? A year? Two? Six?
To repeat, if we set things up correctly and agree on the bindings,
devicetree can be the unifying configuration mechanism through the
whole of firmware (except for very early bits) and into the OS. I feel
this will set us up very well to deal with the complexity that is
coming.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-15 18:03 ` Simon Glass
@ 2021-10-26 6:46 ` Ilias Apalodimas
-1 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-10-26 6:46 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi Simon,
A bit late to the party, sorry!
[...]
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
>
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.
>
> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
>
> Anyway, here are the mental steps that I've gone through over the past
> two months:
>
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying
> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.
>
> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
Having U-Boot keep it's *internal* config state in DTs is fine. Adding
that to the DTs that are copied over from linux isn't imho. There are
various reasons for that. First of all syncing device trees is a huge pain
and that's probably one of the main reasons our DTs are out of sync for a
large number of boards.
The point is this was fine in 2011 were we had SPL only, but the reality
today is completely different. There's previous stage boot loaders (and
enough cases were vendors prefer those over SPL). If that bootloader needs
to use it's own device tree for whatever reason, imposing restrictions on
it wrt to the device tree it has to include, and require them to have
knowledge of U-Boot and it's internal config mechanism makes no sense not
to mention it doesn't scale at all.
>
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
Again, the board might decide for it's own reason to provide it's own DT.
IMHO U-Boot must be able to cope with that and asking DTs to be included in
U-Boot source is not the right way to do that, not to mention cases were
that's completely unrealistic (e.g QEMU or a board that reads the DTB from
it's flash).
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
>
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business.
And that's exactly why we have to come up with something that scales, without
having to add a bunch of unusable DTs in U-Boot.
> We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can get clever and create some sort of
> overlay dtb.
>
> Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> then it will need to build it in and use two devicetrees, one internal
> and one from the prior stage....well that is not very efficient and it
> is going to be confusing for people to figure out what U-Boot is
> actually doing. But we actually already do that in a lot of cases
> where U-Boot passes a DT to the kernel which is different to the one
> it uses. So perhaps we have three devicetrees? OMG.
No we don't. That's a moot point. If you separate the DTs U-Boot
provides the internal one and inherits one 'generic'. Linux will be able to use
that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
DT across kernel versions, In which case there's not much you can do to
begin with and that's already a case we have to deal with.
> b) Well then
> U-Boot can have its own small devicetree with its bits and then U-Boot
> can merge the two when it starts. Again that is not very efficient. It
> means that U-Boot cannot be controlled by the prior stage (e.g. to get
> its public key from there or to enable/disable the console), so
> unified firmware config is not possible. It will get very confusing,
> particularly for debugging U-Boot. c) Some other scheme to avoid
> accepting step 3...please stop!
>
> Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> whole cloth. What about that? Well, we are just going to have to deal
> with that. We can easily merge in the U-Boot nodes/properties and
> update the U-Boot CI scripts to do this, as needed, e.g. with
> qemu-riscv64_spl. It's only one use case, although Xen might do
> something similar.
>
> To my mind, that deals with both the build-time and run-time issues.
> We have a discoverable DT in U-Boot, which should be considered the
> source of truth for most boards. We can sync it with Linux
> automatically with the tooling that I hope Rob Herring will come up
> with. We can use an empty one where there really is no default,
> although I'd argue that is making perfect an enemy of the good.
>
> Step 5: If we get clever and want to remove them from the U-Boot tree
> and pick them up from somewhere else, we can do that with sufficient
> tooling. Perhaps we should set a timeline for that? A year? Two? Six?
We can start slowly migrating boards and see how that works out.
We could either use 2 device trees as you proposed, or have u-boot merge
the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
if linux gets handed a clean device tree without the u-boot internals in
it, so I think 2 discrete DTs is cleaner overall.
Regards
/Ilias
>
> To repeat, if we set things up correctly and agree on the bindings,
> devicetree can be the unifying configuration mechanism through the
> whole of firmware (except for very early bits) and into the OS. I feel
> this will set us up very well to deal with the complexity that is
> coming.
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-26 6:46 ` Ilias Apalodimas
0 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-10-26 6:46 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung,
Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún,
Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp,
Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, François Ozog,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi Simon,
A bit late to the party, sorry!
[...]
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
>
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.
>
> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
>
> Anyway, here are the mental steps that I've gone through over the past
> two months:
>
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying
> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.
>
> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
Having U-Boot keep it's *internal* config state in DTs is fine. Adding
that to the DTs that are copied over from linux isn't imho. There are
various reasons for that. First of all syncing device trees is a huge pain
and that's probably one of the main reasons our DTs are out of sync for a
large number of boards.
The point is this was fine in 2011 were we had SPL only, but the reality
today is completely different. There's previous stage boot loaders (and
enough cases were vendors prefer those over SPL). If that bootloader needs
to use it's own device tree for whatever reason, imposing restrictions on
it wrt to the device tree it has to include, and require them to have
knowledge of U-Boot and it's internal config mechanism makes no sense not
to mention it doesn't scale at all.
>
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
Again, the board might decide for it's own reason to provide it's own DT.
IMHO U-Boot must be able to cope with that and asking DTs to be included in
U-Boot source is not the right way to do that, not to mention cases were
that's completely unrealistic (e.g QEMU or a board that reads the DTB from
it's flash).
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
>
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business.
And that's exactly why we have to come up with something that scales, without
having to add a bunch of unusable DTs in U-Boot.
> We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can get clever and create some sort of
> overlay dtb.
>
> Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> then it will need to build it in and use two devicetrees, one internal
> and one from the prior stage....well that is not very efficient and it
> is going to be confusing for people to figure out what U-Boot is
> actually doing. But we actually already do that in a lot of cases
> where U-Boot passes a DT to the kernel which is different to the one
> it uses. So perhaps we have three devicetrees? OMG.
No we don't. That's a moot point. If you separate the DTs U-Boot
provides the internal one and inherits one 'generic'. Linux will be able to use
that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
DT across kernel versions, In which case there's not much you can do to
begin with and that's already a case we have to deal with.
> b) Well then
> U-Boot can have its own small devicetree with its bits and then U-Boot
> can merge the two when it starts. Again that is not very efficient. It
> means that U-Boot cannot be controlled by the prior stage (e.g. to get
> its public key from there or to enable/disable the console), so
> unified firmware config is not possible. It will get very confusing,
> particularly for debugging U-Boot. c) Some other scheme to avoid
> accepting step 3...please stop!
>
> Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> whole cloth. What about that? Well, we are just going to have to deal
> with that. We can easily merge in the U-Boot nodes/properties and
> update the U-Boot CI scripts to do this, as needed, e.g. with
> qemu-riscv64_spl. It's only one use case, although Xen might do
> something similar.
>
> To my mind, that deals with both the build-time and run-time issues.
> We have a discoverable DT in U-Boot, which should be considered the
> source of truth for most boards. We can sync it with Linux
> automatically with the tooling that I hope Rob Herring will come up
> with. We can use an empty one where there really is no default,
> although I'd argue that is making perfect an enemy of the good.
>
> Step 5: If we get clever and want to remove them from the U-Boot tree
> and pick them up from somewhere else, we can do that with sufficient
> tooling. Perhaps we should set a timeline for that? A year? Two? Six?
We can start slowly migrating boards and see how that works out.
We could either use 2 device trees as you proposed, or have u-boot merge
the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
if linux gets handed a clean device tree without the u-boot internals in
it, so I think 2 discrete DTs is cleaner overall.
Regards
/Ilias
>
> To repeat, if we set things up correctly and agree on the bindings,
> devicetree can be the unifying configuration mechanism through the
> whole of firmware (except for very early bits) and into the OS. I feel
> this will set us up very well to deal with the complexity that is
> coming.
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-26 6:46 ` Ilias Apalodimas
@ 2021-10-27 12:59 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 12:59 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Simon Glass, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 9458 bytes --]
On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> Hi Simon,
>
> A bit late to the party, sorry!
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since we could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
> >
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT. It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> that to the DTs that are copied over from linux isn't imho. There are
> various reasons for that. First of all syncing device trees is a huge pain
> and that's probably one of the main reasons our DTs are out of sync for a
> large number of boards.
This re-sync is only a pain because:
1. Some platforms have been modifying the core dts files LIKE THEY ARE
NOT SUPPOSED TO.
2. DTS files are getting closer to being the super stable API that has
been promised now that there's validation tools.
Some SoCs, like stm32 are doing an amazing job and keeping things in
sync, every release. Others like NXP are violating rule #1. Still
others like some TI platforms get bit by #2 (I solved one of these, and
need to cycle back to the one you and I talked about on IRC a while
back, I bet it's another node name dash changed to underbar).
> The point is this was fine in 2011 were we had SPL only, but the reality
> today is completely different. There's previous stage boot loaders (and
> enough cases were vendors prefer those over SPL). If that bootloader needs
> to use it's own device tree for whatever reason, imposing restrictions on
> it wrt to the device tree it has to include, and require them to have
> knowledge of U-Boot and it's internal config mechanism makes no sense not
> to mention it doesn't scale at all.
If you are passing the full device tree around, a few more
nodes/properties aren't going to make the situation worse. If we're
talking about a 60 kilobyte blob one more kilobyte isn't where we call
the line, especially since if we wait another 6 months it'll be a 62
kilobyte file coming in from Linux instead.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
>
> Again, the board might decide for it's own reason to provide it's own DT.
> IMHO U-Boot must be able to cope with that and asking DTs to be included in
> U-Boot source is not the right way to do that, not to mention cases were
> that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> it's flash).
>
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business.
>
> And that's exactly why we have to come up with something that scales, without
> having to add a bunch of unusable DTs in U-Boot.
Both of these are solved by having our bindings reviewed and upstreamed
and then what we need included in the authoritative dts files.
> > We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG.
>
> No we don't. That's a moot point. If you separate the DTs U-Boot
> provides the internal one and inherits one 'generic'. Linux will be able to use
> that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> DT across kernel versions, In which case there's not much you can do to
> begin with and that's already a case we have to deal with.
>
> > b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient. It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
> >
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> We can start slowly migrating boards and see how that works out.
> We could either use 2 device trees as you proposed, or have u-boot merge
> the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> if linux gets handed a clean device tree without the u-boot internals in
> it, so I think 2 discrete DTs is cleaner overall.
Why does it matter if Linux sees some u-boot, properties? If some huge
stink is going to be thrown, we could probably prune them out at run
time but it's already being passed N disabled nodes, yes?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 12:59 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 12:59 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 9458 bytes --]
On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> Hi Simon,
>
> A bit late to the party, sorry!
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since we could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
> >
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT. It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> that to the DTs that are copied over from linux isn't imho. There are
> various reasons for that. First of all syncing device trees is a huge pain
> and that's probably one of the main reasons our DTs are out of sync for a
> large number of boards.
This re-sync is only a pain because:
1. Some platforms have been modifying the core dts files LIKE THEY ARE
NOT SUPPOSED TO.
2. DTS files are getting closer to being the super stable API that has
been promised now that there's validation tools.
Some SoCs, like stm32 are doing an amazing job and keeping things in
sync, every release. Others like NXP are violating rule #1. Still
others like some TI platforms get bit by #2 (I solved one of these, and
need to cycle back to the one you and I talked about on IRC a while
back, I bet it's another node name dash changed to underbar).
> The point is this was fine in 2011 were we had SPL only, but the reality
> today is completely different. There's previous stage boot loaders (and
> enough cases were vendors prefer those over SPL). If that bootloader needs
> to use it's own device tree for whatever reason, imposing restrictions on
> it wrt to the device tree it has to include, and require them to have
> knowledge of U-Boot and it's internal config mechanism makes no sense not
> to mention it doesn't scale at all.
If you are passing the full device tree around, a few more
nodes/properties aren't going to make the situation worse. If we're
talking about a 60 kilobyte blob one more kilobyte isn't where we call
the line, especially since if we wait another 6 months it'll be a 62
kilobyte file coming in from Linux instead.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
>
> Again, the board might decide for it's own reason to provide it's own DT.
> IMHO U-Boot must be able to cope with that and asking DTs to be included in
> U-Boot source is not the right way to do that, not to mention cases were
> that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> it's flash).
>
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business.
>
> And that's exactly why we have to come up with something that scales, without
> having to add a bunch of unusable DTs in U-Boot.
Both of these are solved by having our bindings reviewed and upstreamed
and then what we need included in the authoritative dts files.
> > We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG.
>
> No we don't. That's a moot point. If you separate the DTs U-Boot
> provides the internal one and inherits one 'generic'. Linux will be able to use
> that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> DT across kernel versions, In which case there's not much you can do to
> begin with and that's already a case we have to deal with.
>
> > b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient. It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
> >
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> We can start slowly migrating boards and see how that works out.
> We could either use 2 device trees as you proposed, or have u-boot merge
> the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> if linux gets handed a clean device tree without the u-boot internals in
> it, so I think 2 discrete DTs is cleaner overall.
Why does it matter if Linux sees some u-boot, properties? If some huge
stink is going to be thrown, we could probably prune them out at run
time but it's already being passed N disabled nodes, yes?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 12:59 ` Tom Rini
@ 2021-10-27 13:30 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:30 UTC (permalink / raw)
To: Tom Rini
Cc: Ilias Apalodimas, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi Tom,
On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > A bit late to the party, sorry!
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
>
> This re-sync is only a pain because:
> 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> NOT SUPPOSED TO.
> 2. DTS files are getting closer to being the super stable API that has
> been promised now that there's validation tools.
>
> Some SoCs, like stm32 are doing an amazing job and keeping things in
> sync, every release. Others like NXP are violating rule #1.
With NXP commitment to SystemReady on some IMX8 boards, I think this is
changing,
at least for the SystemReady boards.
> Still
> others like some TI platforms get bit by #2 (I solved one of these, and
> need to cycle back to the one you and I talked about on IRC a while
> back, I bet it's another node name dash changed to underbar).
>
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> If you are passing the full device tree around, a few more
> nodes/properties aren't going to make the situation worse. If we're
> talking about a 60 kilobyte blob one more kilobyte isn't where we call
> the line, especially since if we wait another 6 months it'll be a 62
> kilobyte file coming in from Linux instead.
>
This is not about size but about firmware supply chain organization.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> >
> > Again, the board might decide for it's own reason to provide it's own
> DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included
> in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> > it's flash).
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales,
> without
> > having to add a bunch of unusable DTs in U-Boot.
>
> Both of these are solved by having our bindings reviewed and upstreamed
> and then what we need included in the authoritative dts files.
>
There shall be authoritative System Device Trees as vendors are working on.
Those System Device Trees cover all aspects of a board, not just the
Cortex-A part that U-Boot cares about.
Out of those system device trees, a tool (lopper) is going to carve out the
"authoritative dts for the cortex-A".
Essentially, that carve out will correspond to what would come out of Linux.
This scheme will not be generalized, just adopted by vendors on some
boards.
DT for those board become part of the OS ABI (meaning, the driver
developper is constrained).
>
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks
> the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> Why does it matter if Linux sees some u-boot, properties? If some huge
> stink is going to be thrown, we could probably prune them out at run
> time but it's already being passed N disabled nodes, yes?
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:30 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:30 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 10787 bytes --]
Hi Tom,
On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > Hi Simon,
> >
> > A bit late to the party, sorry!
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
>
> This re-sync is only a pain because:
> 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> NOT SUPPOSED TO.
> 2. DTS files are getting closer to being the super stable API that has
> been promised now that there's validation tools.
>
> Some SoCs, like stm32 are doing an amazing job and keeping things in
> sync, every release. Others like NXP are violating rule #1.
With NXP commitment to SystemReady on some IMX8 boards, I think this is
changing,
at least for the SystemReady boards.
> Still
> others like some TI platforms get bit by #2 (I solved one of these, and
> need to cycle back to the one you and I talked about on IRC a while
> back, I bet it's another node name dash changed to underbar).
>
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> If you are passing the full device tree around, a few more
> nodes/properties aren't going to make the situation worse. If we're
> talking about a 60 kilobyte blob one more kilobyte isn't where we call
> the line, especially since if we wait another 6 months it'll be a 62
> kilobyte file coming in from Linux instead.
>
This is not about size but about firmware supply chain organization.
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> >
> > Again, the board might decide for it's own reason to provide it's own
> DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included
> in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> > it's flash).
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales,
> without
> > having to add a bunch of unusable DTs in U-Boot.
>
> Both of these are solved by having our bindings reviewed and upstreamed
> and then what we need included in the authoritative dts files.
>
There shall be authoritative System Device Trees as vendors are working on.
Those System Device Trees cover all aspects of a board, not just the
Cortex-A part that U-Boot cares about.
Out of those system device trees, a tool (lopper) is going to carve out the
"authoritative dts for the cortex-A".
Essentially, that carve out will correspond to what would come out of Linux.
This scheme will not be generalized, just adopted by vendors on some
boards.
DT for those board become part of the OS ABI (meaning, the driver
developper is constrained).
>
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks
> the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> Why does it matter if Linux sees some u-boot, properties? If some huge
> stink is going to be thrown, we could probably prune them out at run
> time but it's already being passed N disabled nodes, yes?
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 14433 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:30 ` François Ozog
@ 2021-10-27 13:38 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 13:38 UTC (permalink / raw)
To: François Ozog
Cc: Ilias Apalodimas, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 8011 bytes --]
On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> Hi Tom,
>
> On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
>
> > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> > >
> > > [...]
> > >
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > devicetree standard, like the /chosen node but with less history. We
> > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > of 'devicetree is a hardware description'. How do we get over that
> > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > it always has to have those properties, but with existing features
> > > > like verified boot, SPL as well as complex firmware images where
> > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > So let's just assume that we need this everywhere, since we certainly
> > > > need it in at least some places.
> > > >
> > > > (stop reading here if you disagree, because nothing below will make
> > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > OF_CONTROL :-)
> > >
> > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > that to the DTs that are copied over from linux isn't imho. There are
> > > various reasons for that. First of all syncing device trees is a huge
> > pain
> > > and that's probably one of the main reasons our DTs are out of sync for a
> > > large number of boards.
> >
> > This re-sync is only a pain because:
> > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > NOT SUPPOSED TO.
> > 2. DTS files are getting closer to being the super stable API that has
> > been promised now that there's validation tools.
> >
> > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > sync, every release. Others like NXP are violating rule #1.
>
> With NXP commitment to SystemReady on some IMX8 boards, I think this is
> changing,
> at least for the SystemReady boards.
I'd really like to see some progress (as would the other non-NXP folks
working on NXP SoCs) in that regard.
> > Still
> > others like some TI platforms get bit by #2 (I solved one of these, and
> > need to cycle back to the one you and I talked about on IRC a while
> > back, I bet it's another node name dash changed to underbar).
> >
> > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > today is completely different. There's previous stage boot loaders (and
> > > enough cases were vendors prefer those over SPL). If that bootloader
> > needs
> > > to use it's own device tree for whatever reason, imposing restrictions
> > on
> > > it wrt to the device tree it has to include, and require them to have
> > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > to mention it doesn't scale at all.
> >
> > If you are passing the full device tree around, a few more
> > nodes/properties aren't going to make the situation worse. If we're
> > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > the line, especially since if we wait another 6 months it'll be a 62
> > kilobyte file coming in from Linux instead.
>
> This is not about size but about firmware supply chain organization.
That's great since it means we just need the bindings reviewed then
everyone can pass whatever everyone else needs.
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > have binman definitions, etc. So we need a way to overlay those things
> > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > discoverability and documentation, anyway. That is this series.
> > >
> > > Again, the board might decide for it's own reason to provide it's own
> > DT.
> > > IMHO U-Boot must be able to cope with that and asking DTs to be included
> > in
> > > U-Boot source is not the right way to do that, not to mention cases were
> > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > from
> > > it's flash).
> > >
> > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > and worried about step 3)
> > > >
> > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > grow as every man and his dog get into the write-a-bootloader
> > > > business.
> > >
> > > And that's exactly why we have to come up with something that scales,
> > without
> > > having to add a bunch of unusable DTs in U-Boot.
> >
> > Both of these are solved by having our bindings reviewed and upstreamed
> > and then what we need included in the authoritative dts files.
> >
> There shall be authoritative System Device Trees as vendors are working on.
> Those System Device Trees cover all aspects of a board, not just the
> Cortex-A part that U-Boot cares about.
> Out of those system device trees, a tool (lopper) is going to carve out the
> "authoritative dts for the cortex-A".
> Essentially, that carve out will correspond to what would come out of Linux.
s/Linux/software/
> This scheme will not be generalized, just adopted by vendors on some
> boards.
> DT for those board become part of the OS ABI (meaning, the driver
> developper is constrained).
OK? And is going to pick and choose which valid bindings to implement?
Or is it going to provide half a node for Linux? No? I assume no. So
it will also provide whatever bindings we've upstreamed and say need to
be passed.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:38 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 13:38 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 8011 bytes --]
On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> Hi Tom,
>
> On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
>
> > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> > >
> > > [...]
> > >
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > devicetree standard, like the /chosen node but with less history. We
> > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > of 'devicetree is a hardware description'. How do we get over that
> > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > it always has to have those properties, but with existing features
> > > > like verified boot, SPL as well as complex firmware images where
> > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > So let's just assume that we need this everywhere, since we certainly
> > > > need it in at least some places.
> > > >
> > > > (stop reading here if you disagree, because nothing below will make
> > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > OF_CONTROL :-)
> > >
> > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > that to the DTs that are copied over from linux isn't imho. There are
> > > various reasons for that. First of all syncing device trees is a huge
> > pain
> > > and that's probably one of the main reasons our DTs are out of sync for a
> > > large number of boards.
> >
> > This re-sync is only a pain because:
> > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > NOT SUPPOSED TO.
> > 2. DTS files are getting closer to being the super stable API that has
> > been promised now that there's validation tools.
> >
> > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > sync, every release. Others like NXP are violating rule #1.
>
> With NXP commitment to SystemReady on some IMX8 boards, I think this is
> changing,
> at least for the SystemReady boards.
I'd really like to see some progress (as would the other non-NXP folks
working on NXP SoCs) in that regard.
> > Still
> > others like some TI platforms get bit by #2 (I solved one of these, and
> > need to cycle back to the one you and I talked about on IRC a while
> > back, I bet it's another node name dash changed to underbar).
> >
> > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > today is completely different. There's previous stage boot loaders (and
> > > enough cases were vendors prefer those over SPL). If that bootloader
> > needs
> > > to use it's own device tree for whatever reason, imposing restrictions
> > on
> > > it wrt to the device tree it has to include, and require them to have
> > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > to mention it doesn't scale at all.
> >
> > If you are passing the full device tree around, a few more
> > nodes/properties aren't going to make the situation worse. If we're
> > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > the line, especially since if we wait another 6 months it'll be a 62
> > kilobyte file coming in from Linux instead.
>
> This is not about size but about firmware supply chain organization.
That's great since it means we just need the bindings reviewed then
everyone can pass whatever everyone else needs.
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > have binman definitions, etc. So we need a way to overlay those things
> > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > discoverability and documentation, anyway. That is this series.
> > >
> > > Again, the board might decide for it's own reason to provide it's own
> > DT.
> > > IMHO U-Boot must be able to cope with that and asking DTs to be included
> > in
> > > U-Boot source is not the right way to do that, not to mention cases were
> > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > from
> > > it's flash).
> > >
> > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > and worried about step 3)
> > > >
> > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > grow as every man and his dog get into the write-a-bootloader
> > > > business.
> > >
> > > And that's exactly why we have to come up with something that scales,
> > without
> > > having to add a bunch of unusable DTs in U-Boot.
> >
> > Both of these are solved by having our bindings reviewed and upstreamed
> > and then what we need included in the authoritative dts files.
> >
> There shall be authoritative System Device Trees as vendors are working on.
> Those System Device Trees cover all aspects of a board, not just the
> Cortex-A part that U-Boot cares about.
> Out of those system device trees, a tool (lopper) is going to carve out the
> "authoritative dts for the cortex-A".
> Essentially, that carve out will correspond to what would come out of Linux.
s/Linux/software/
> This scheme will not be generalized, just adopted by vendors on some
> boards.
> DT for those board become part of the OS ABI (meaning, the driver
> developper is constrained).
OK? And is going to pick and choose which valid bindings to implement?
Or is it going to provide half a node for Linux? No? I assume no. So
it will also provide whatever bindings we've upstreamed and say need to
be passed.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:38 ` Tom Rini
@ 2021-10-27 13:47 ` Ilias Apalodimas
-1 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-10-27 13:47 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi trying to reply to all at the same time!
On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to the
> > > > > different components. Binman was one effort there. I feel that putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > > So let's just assume that we need this everywhere, since we certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > > that to the DTs that are copied over from linux isn't imho. There are
> > > > various reasons for that. First of all syncing device trees is a huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > > been promised now that there's validation tools.
Agree on both, but still this is the reality we have to deal with right now
> > >
> > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > sync, every release. Others like NXP are violating rule #1.
> >
> > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > changing,
> > at least for the SystemReady boards.
>
> I'd really like to see some progress (as would the other non-NXP folks
> working on NXP SoCs) in that regard.
>
> > > Still
> > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > need to cycle back to the one you and I talked about on IRC a while
> > > back, I bet it's another node name dash changed to underbar).
> > >
> > > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > > today is completely different. There's previous stage boot loaders (and
> > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > needs
> > > > to use it's own device tree for whatever reason, imposing restrictions
> > > on
> > > > it wrt to the device tree it has to include, and require them to have
> > > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > > to mention it doesn't scale at all.
> > >
> > > If you are passing the full device tree around, a few more
> > > nodes/properties aren't going to make the situation worse. If we're
> > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > the line, especially since if we wait another 6 months it'll be a 62
> > > kilobyte file coming in from Linux instead.
> >
> > This is not about size but about firmware supply chain organization.
>
> That's great since it means we just need the bindings reviewed then
> everyone can pass whatever everyone else needs.
>
Size here is not my concern. If the bindings u-boot expects gets
upstreamed I am obviously fine with the previous stage bootloader passing
them over. What I strongly disagree, is *demand* the previous stage boot
loader have knowledge about them if they are not in upstream.
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > > have binman definitions, etc. So we need a way to overlay those things
> > > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > discoverability and documentation, anyway. That is this series.
> > > >
> > > > Again, the board might decide for it's own reason to provide it's own
> > > DT.
> > > > IMHO U-Boot must be able to cope with that and asking DTs to be included
> > > in
> > > > U-Boot source is not the right way to do that, not to mention cases were
> > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > from
> > > > it's flash).
> > > >
> > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > and worried about step 3)
> > > > >
> > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > business.
> > > >
> > > > And that's exactly why we have to come up with something that scales,
> > > without
> > > > having to add a bunch of unusable DTs in U-Boot.
> > >
> > > Both of these are solved by having our bindings reviewed and upstreamed
> > > and then what we need included in the authoritative dts files.
> > >
yes
> > There shall be authoritative System Device Trees as vendors are working on.
> > Those System Device Trees cover all aspects of a board, not just the
> > Cortex-A part that U-Boot cares about.
> > Out of those system device trees, a tool (lopper) is going to carve out the
> > "authoritative dts for the cortex-A".
> > Essentially, that carve out will correspond to what would come out of Linux.
>
> s/Linux/software/
>
> > This scheme will not be generalized, just adopted by vendors on some
> > boards.
> > DT for those board become part of the OS ABI (meaning, the driver
> > developper is constrained).
>
> OK? And is going to pick and choose which valid bindings to implement?
> Or is it going to provide half a node for Linux? No? I assume no. So
> it will also provide whatever bindings we've upstreamed and say need to
> be passed.
>
> --
> Tom
Regards
/Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:47 ` Ilias Apalodimas
0 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-10-27 13:47 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi trying to reply to all at the same time!
On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to the
> > > > > different components. Binman was one effort there. I feel that putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > > So let's just assume that we need this everywhere, since we certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > > that to the DTs that are copied over from linux isn't imho. There are
> > > > various reasons for that. First of all syncing device trees is a huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > > been promised now that there's validation tools.
Agree on both, but still this is the reality we have to deal with right now
> > >
> > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > sync, every release. Others like NXP are violating rule #1.
> >
> > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > changing,
> > at least for the SystemReady boards.
>
> I'd really like to see some progress (as would the other non-NXP folks
> working on NXP SoCs) in that regard.
>
> > > Still
> > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > need to cycle back to the one you and I talked about on IRC a while
> > > back, I bet it's another node name dash changed to underbar).
> > >
> > > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > > today is completely different. There's previous stage boot loaders (and
> > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > needs
> > > > to use it's own device tree for whatever reason, imposing restrictions
> > > on
> > > > it wrt to the device tree it has to include, and require them to have
> > > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > > to mention it doesn't scale at all.
> > >
> > > If you are passing the full device tree around, a few more
> > > nodes/properties aren't going to make the situation worse. If we're
> > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > the line, especially since if we wait another 6 months it'll be a 62
> > > kilobyte file coming in from Linux instead.
> >
> > This is not about size but about firmware supply chain organization.
>
> That's great since it means we just need the bindings reviewed then
> everyone can pass whatever everyone else needs.
>
Size here is not my concern. If the bindings u-boot expects gets
upstreamed I am obviously fine with the previous stage bootloader passing
them over. What I strongly disagree, is *demand* the previous stage boot
loader have knowledge about them if they are not in upstream.
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > > have binman definitions, etc. So we need a way to overlay those things
> > > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > discoverability and documentation, anyway. That is this series.
> > > >
> > > > Again, the board might decide for it's own reason to provide it's own
> > > DT.
> > > > IMHO U-Boot must be able to cope with that and asking DTs to be included
> > > in
> > > > U-Boot source is not the right way to do that, not to mention cases were
> > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > from
> > > > it's flash).
> > > >
> > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > and worried about step 3)
> > > > >
> > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > business.
> > > >
> > > > And that's exactly why we have to come up with something that scales,
> > > without
> > > > having to add a bunch of unusable DTs in U-Boot.
> > >
> > > Both of these are solved by having our bindings reviewed and upstreamed
> > > and then what we need included in the authoritative dts files.
> > >
yes
> > There shall be authoritative System Device Trees as vendors are working on.
> > Those System Device Trees cover all aspects of a board, not just the
> > Cortex-A part that U-Boot cares about.
> > Out of those system device trees, a tool (lopper) is going to carve out the
> > "authoritative dts for the cortex-A".
> > Essentially, that carve out will correspond to what would come out of Linux.
>
> s/Linux/software/
>
> > This scheme will not be generalized, just adopted by vendors on some
> > boards.
> > DT for those board become part of the OS ABI (meaning, the driver
> > developper is constrained).
>
> OK? And is going to pick and choose which valid bindings to implement?
> Or is it going to provide half a node for Linux? No? I assume no. So
> it will also provide whatever bindings we've upstreamed and say need to
> be passed.
>
> --
> Tom
Regards
/Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:47 ` Ilias Apalodimas
@ 2021-10-27 14:26 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:26 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 6954 bytes --]
On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote:
> Hi trying to reply to all at the same time!
>
> On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to the
> > > > > > different components. Binman was one effort there. I feel that putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > > > So let's just assume that we need this everywhere, since we certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > > > that to the DTs that are copied over from linux isn't imho. There are
> > > > > various reasons for that. First of all syncing device trees is a huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > > NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > > been promised now that there's validation tools.
>
> Agree on both, but still this is the reality we have to deal with right now
>
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release. Others like NXP are violating rule #1.
> > >
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> >
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> >
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > > > today is completely different. There's previous stage boot loaders (and
> > > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason, imposing restrictions
> > > > on
> > > > > it wrt to the device tree it has to include, and require them to have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse. If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> >
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> >
>
> Size here is not my concern. If the bindings u-boot expects gets
> upstreamed I am obviously fine with the previous stage bootloader passing
> them over. What I strongly disagree, is *demand* the previous stage boot
> loader have knowledge about them if they are not in upstream.
I also agree that bindings MUST be upstreamed for there to be a
reasonable expectation that any other project (or human creating a dts)
be adding them, either statically or any sort of run-time modification
(think memory information, this gets fixed up at run-time often still).
And it may end up being zero "u-boot,FOO" bindings where this is the
case. Or it may end up being related to secure / verified boot stuff
only.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 14:26 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:26 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 6954 bytes --]
On Wed, Oct 27, 2021 at 04:47:55PM +0300, Ilias Apalodimas wrote:
> Hi trying to reply to all at the same time!
>
> On Wed, Oct 27, 2021 at 09:38:40AM -0400, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to the
> > > > > > different components. Binman was one effort there. I feel that putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history. We
> > > > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > > > So let's just assume that we need this everywhere, since we certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > > > that to the DTs that are copied over from linux isn't imho. There are
> > > > > various reasons for that. First of all syncing device trees is a huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > > NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > > been promised now that there's validation tools.
>
> Agree on both, but still this is the reality we have to deal with right now
>
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release. Others like NXP are violating rule #1.
> > >
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> >
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> >
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > > > today is completely different. There's previous stage boot loaders (and
> > > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason, imposing restrictions
> > > > on
> > > > > it wrt to the device tree it has to include, and require them to have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse. If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> >
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> >
>
> Size here is not my concern. If the bindings u-boot expects gets
> upstreamed I am obviously fine with the previous stage bootloader passing
> them over. What I strongly disagree, is *demand* the previous stage boot
> loader have knowledge about them if they are not in upstream.
I also agree that bindings MUST be upstreamed for there to be a
reasonable expectation that any other project (or human creating a dts)
be adding them, either statically or any sort of run-time modification
(think memory information, this gets fixed up at run-time often still).
And it may end up being zero "u-boot,FOO" bindings where this is the
case. Or it may end up being related to secure / verified boot stuff
only.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:38 ` Tom Rini
@ 2021-10-27 13:48 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:48 UTC (permalink / raw)
To: Tom Rini
Cc: Ilias Apalodimas, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we
> could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry
> on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> the
> > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history.
> We
> > > > > should sacrifice efficiency, expedience and expandability on the
> altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not
> saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is
> essential.
> > > > > So let's just assume that we need this everywhere, since we
> certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> > > > that to the DTs that are copied over from linux isn't imho. There
> are
> > > > various reasons for that. First of all syncing device trees is a
> huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync
> for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > > been promised now that there's validation tools.
> > >
> > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > sync, every release. Others like NXP are violating rule #1.
> >
> > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > changing,
> > at least for the SystemReady boards.
>
> I'd really like to see some progress (as would the other non-NXP folks
> working on NXP SoCs) in that regard.
>
> > > Still
> > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > need to cycle back to the one you and I talked about on IRC a while
> > > back, I bet it's another node name dash changed to underbar).
> > >
> > > > The point is this was fine in 2011 were we had SPL only, but the
> reality
> > > > today is completely different. There's previous stage boot loaders
> (and
> > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > needs
> > > > to use it's own device tree for whatever reason, imposing
> restrictions
> > > on
> > > > it wrt to the device tree it has to include, and require them to
> have
> > > > knowledge of U-Boot and it's internal config mechanism makes no
> sense not
> > > > to mention it doesn't scale at all.
> > >
> > > If you are passing the full device tree around, a few more
> > > nodes/properties aren't going to make the situation worse. If we're
> > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > the line, especially since if we wait another 6 months it'll be a 62
> > > kilobyte file coming in from Linux instead.
> >
> > This is not about size but about firmware supply chain organization.
>
> That's great since it means we just need the bindings reviewed then
> everyone can pass whatever everyone else needs.
>
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> we
> > > > > have binman definitions, etc. So we need a way to overlay those
> things
> > > > > into the DT. We already support this for in-tree DTs, so IMO this
> is
> > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > discoverability and documentation, anyway. That is this series.
> > > >
> > > > Again, the board might decide for it's own reason to provide it's own
> > > DT.
> > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> included
> > > in
> > > > U-Boot source is not the right way to do that, not to mention cases
> were
> > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > from
> > > > it's flash).
> > > >
> > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > and worried about step 3)
> > > > >
> > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > flow only, or boards that sometimes use a flow) which need the DT
> to
> > > > > come from a prior stage. How to handle that? IMO that is only
> going to
> > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > business.
> > > >
> > > > And that's exactly why we have to come up with something that scales,
> > > without
> > > > having to add a bunch of unusable DTs in U-Boot.
> > >
> > > Both of these are solved by having our bindings reviewed and upstreamed
> > > and then what we need included in the authoritative dts files.
> > >
> > There shall be authoritative System Device Trees as vendors are working
> on.
> > Those System Device Trees cover all aspects of a board, not just the
> > Cortex-A part that U-Boot cares about.
> > Out of those system device trees, a tool (lopper) is going to carve out
> the
> > "authoritative dts for the cortex-A".
> > Essentially, that carve out will correspond to what would come out of
> Linux.
>
> s/Linux/software/
>
> > This scheme will not be generalized, just adopted by vendors on some
> > boards.
> > DT for those board become part of the OS ABI (meaning, the driver
> > developper is constrained).
>
> OK? And is going to pick and choose which valid bindings to implement?
> Or is it going to provide half a node for Linux? No? I assume no. So
> it will also provide whatever bindings we've upstreamed and say need to
> be passed.
>
Until we can agree on a better scheme, Linux will server as the basis for
most of the bindings.
Some projects, like TF-A maintain their own bindings specifications. I
guess U-Boot shall do the same.
The U-Boot DT (for properties or whatever purpose) can be stored in a
various of U-Boot decided ways and as part of the TF-A FIP image in the
ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
the NF_FW_CONFIG should be part of the blob_list discussion that started a
while ago.
For System Device Tree, the bindings and the master repo will be maintained
in devicetree.org (AFAIK).
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:48 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:48 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 9257 bytes --]
On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote:
> On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > Hi Tom,
> >
> > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > Hi Simon,
> > > >
> > > > A bit late to the party, sorry!
> > > >
> > > > [...]
> > > >
> > > > > >
> > > > > > I really want to see what the binary case looks like since we
> could
> > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > don't
> > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry
> on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> the
> > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > devicetree standard, like the /chosen node but with less history.
> We
> > > > > should sacrifice efficiency, expedience and expandability on the
> altar
> > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> > > > > for its own purposes, as well as for booting the OS. I am not
> saying
> > > > > it always has to have those properties, but with existing features
> > > > > like verified boot, SPL as well as complex firmware images where
> > > > > U-Boot needs to be able to find things in the image, it is
> essential.
> > > > > So let's just assume that we need this everywhere, since we
> certainly
> > > > > need it in at least some places.
> > > > >
> > > > > (stop reading here if you disagree, because nothing below will make
> > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > OF_CONTROL :-)
> > > >
> > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> > > > that to the DTs that are copied over from linux isn't imho. There
> are
> > > > various reasons for that. First of all syncing device trees is a
> huge
> > > pain
> > > > and that's probably one of the main reasons our DTs are out of sync
> for a
> > > > large number of boards.
> > >
> > > This re-sync is only a pain because:
> > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > NOT SUPPOSED TO.
> > > 2. DTS files are getting closer to being the super stable API that has
> > > been promised now that there's validation tools.
> > >
> > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > sync, every release. Others like NXP are violating rule #1.
> >
> > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > changing,
> > at least for the SystemReady boards.
>
> I'd really like to see some progress (as would the other non-NXP folks
> working on NXP SoCs) in that regard.
>
> > > Still
> > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > need to cycle back to the one you and I talked about on IRC a while
> > > back, I bet it's another node name dash changed to underbar).
> > >
> > > > The point is this was fine in 2011 were we had SPL only, but the
> reality
> > > > today is completely different. There's previous stage boot loaders
> (and
> > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > needs
> > > > to use it's own device tree for whatever reason, imposing
> restrictions
> > > on
> > > > it wrt to the device tree it has to include, and require them to
> have
> > > > knowledge of U-Boot and it's internal config mechanism makes no
> sense not
> > > > to mention it doesn't scale at all.
> > >
> > > If you are passing the full device tree around, a few more
> > > nodes/properties aren't going to make the situation worse. If we're
> > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > the line, especially since if we wait another 6 months it'll be a 62
> > > kilobyte file coming in from Linux instead.
> >
> > This is not about size but about firmware supply chain organization.
>
> That's great since it means we just need the bindings reviewed then
> everyone can pass whatever everyone else needs.
>
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> we
> > > > > have binman definitions, etc. So we need a way to overlay those
> things
> > > > > into the DT. We already support this for in-tree DTs, so IMO this
> is
> > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > discoverability and documentation, anyway. That is this series.
> > > >
> > > > Again, the board might decide for it's own reason to provide it's own
> > > DT.
> > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> included
> > > in
> > > > U-Boot source is not the right way to do that, not to mention cases
> were
> > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > from
> > > > it's flash).
> > > >
> > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > and worried about step 3)
> > > > >
> > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > flow only, or boards that sometimes use a flow) which need the DT
> to
> > > > > come from a prior stage. How to handle that? IMO that is only
> going to
> > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > business.
> > > >
> > > > And that's exactly why we have to come up with something that scales,
> > > without
> > > > having to add a bunch of unusable DTs in U-Boot.
> > >
> > > Both of these are solved by having our bindings reviewed and upstreamed
> > > and then what we need included in the authoritative dts files.
> > >
> > There shall be authoritative System Device Trees as vendors are working
> on.
> > Those System Device Trees cover all aspects of a board, not just the
> > Cortex-A part that U-Boot cares about.
> > Out of those system device trees, a tool (lopper) is going to carve out
> the
> > "authoritative dts for the cortex-A".
> > Essentially, that carve out will correspond to what would come out of
> Linux.
>
> s/Linux/software/
>
> > This scheme will not be generalized, just adopted by vendors on some
> > boards.
> > DT for those board become part of the OS ABI (meaning, the driver
> > developper is constrained).
>
> OK? And is going to pick and choose which valid bindings to implement?
> Or is it going to provide half a node for Linux? No? I assume no. So
> it will also provide whatever bindings we've upstreamed and say need to
> be passed.
>
Until we can agree on a better scheme, Linux will server as the basis for
most of the bindings.
Some projects, like TF-A maintain their own bindings specifications. I
guess U-Boot shall do the same.
The U-Boot DT (for properties or whatever purpose) can be stored in a
various of U-Boot decided ways and as part of the TF-A FIP image in the
ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
the NF_FW_CONFIG should be part of the blob_list discussion that started a
while ago.
For System Device Tree, the bindings and the master repo will be maintained
in devicetree.org (AFAIK).
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 12982 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:48 ` François Ozog
@ 2021-10-27 14:30 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:30 UTC (permalink / raw)
To: François Ozog
Cc: Ilias Apalodimas, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 10081 bytes --]
On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote:
>
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry
> > on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history.
> > We
> > > > > > should sacrifice efficiency, expedience and expandability on the
> > altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses
> > devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not
> > saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is
> > essential.
> > > > > > So let's just assume that we need this everywhere, since we
> > certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> > Adding
> > > > > that to the DTs that are copied over from linux isn't imho. There
> > are
> > > > > various reasons for that. First of all syncing device trees is a
> > huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync
> > for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > > NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > > been promised now that there's validation tools.
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release. Others like NXP are violating rule #1.
> > >
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> >
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> >
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only, but the
> > reality
> > > > > today is completely different. There's previous stage boot loaders
> > (and
> > > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason, imposing
> > restrictions
> > > > on
> > > > > it wrt to the device tree it has to include, and require them to
> > have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no
> > sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse. If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> >
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> >
> > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> > we
> > > > > > have binman definitions, etc. So we need a way to overlay those
> > things
> > > > > > into the DT. We already support this for in-tree DTs, so IMO this
> > is
> > > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > > discoverability and documentation, anyway. That is this series.
> > > > >
> > > > > Again, the board might decide for it's own reason to provide it's own
> > > > DT.
> > > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> > included
> > > > in
> > > > > U-Boot source is not the right way to do that, not to mention cases
> > were
> > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > > from
> > > > > it's flash).
> > > > >
> > > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > > and worried about step 3)
> > > > > >
> > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > > flow only, or boards that sometimes use a flow) which need the DT
> > to
> > > > > > come from a prior stage. How to handle that? IMO that is only
> > going to
> > > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > > business.
> > > > >
> > > > > And that's exactly why we have to come up with something that scales,
> > > > without
> > > > > having to add a bunch of unusable DTs in U-Boot.
> > > >
> > > > Both of these are solved by having our bindings reviewed and upstreamed
> > > > and then what we need included in the authoritative dts files.
> > > >
> > > There shall be authoritative System Device Trees as vendors are working
> > on.
> > > Those System Device Trees cover all aspects of a board, not just the
> > > Cortex-A part that U-Boot cares about.
> > > Out of those system device trees, a tool (lopper) is going to carve out
> > the
> > > "authoritative dts for the cortex-A".
> > > Essentially, that carve out will correspond to what would come out of
> > Linux.
> >
> > s/Linux/software/
> >
> > > This scheme will not be generalized, just adopted by vendors on some
> > > boards.
> > > DT for those board become part of the OS ABI (meaning, the driver
> > > developper is constrained).
> >
> > OK? And is going to pick and choose which valid bindings to implement?
> > Or is it going to provide half a node for Linux? No? I assume no. So
> > it will also provide whatever bindings we've upstreamed and say need to
> > be passed.
> >
> Until we can agree on a better scheme, Linux will server as the basis for
> most of the bindings.
Yes, this is the de-facto standard since the beginning.
> Some projects, like TF-A maintain their own bindings specifications. I
And as I keep saying I believe this to be totally wrong. Unless and
only unless the TF-A bindings are for TF-A only to care about, and then
it's just one-off do what you guys want non-standard stuff.
> guess U-Boot shall do the same.
No, U-Boot is going to upstream the bindings that we want to have be
considered official.
> The U-Boot DT (for properties or whatever purpose) can be stored in a
> various of U-Boot decided ways and as part of the TF-A FIP image in the
> ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
> the NF_FW_CONFIG should be part of the blob_list discussion that started a
> while ago.
Yes, we'll have to see where things progress about what bindings are
needed, and where.
> For System Device Tree, the bindings and the master repo will be maintained
> in devicetree.org (AFAIK).
Interesting, okay.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 14:30 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:30 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 10081 bytes --]
On Wed, Oct 27, 2021 at 03:48:48PM +0200, François Ozog wrote:
> On Wed, 27 Oct 2021 at 15:38, Tom Rini <trini@konsulko.com> wrote:
>
> > On Wed, Oct 27, 2021 at 03:30:18PM +0200, François Ozog wrote:
> > > Hi Tom,
> > >
> > > On Wed, 27 Oct 2021 at 14:59, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Tue, Oct 26, 2021 at 09:46:38AM +0300, Ilias Apalodimas wrote:
> > > > > Hi Simon,
> > > > >
> > > > > A bit late to the party, sorry!
> > > > >
> > > > > [...]
> > > > >
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > > the instructions. It doesn't have to be that way, but if we carry
> > on
> > > > > > as we are, it will continue to be messy and in five years you will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > > >
> > > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > > > devicetree standard, like the /chosen node but with less history.
> > We
> > > > > > should sacrifice efficiency, expedience and expandability on the
> > altar
> > > > > > of 'devicetree is a hardware description'. How do we get over that
> > > > > > one? Wel, I just think we need to accept that U-Boot uses
> > devicetree
> > > > > > for its own purposes, as well as for booting the OS. I am not
> > saying
> > > > > > it always has to have those properties, but with existing features
> > > > > > like verified boot, SPL as well as complex firmware images where
> > > > > > U-Boot needs to be able to find things in the image, it is
> > essential.
> > > > > > So let's just assume that we need this everywhere, since we
> > certainly
> > > > > > need it in at least some places.
> > > > > >
> > > > > > (stop reading here if you disagree, because nothing below will make
> > > > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > > > OF_CONTROL :-)
> > > > >
> > > > > Having U-Boot keep it's *internal* config state in DTs is fine.
> > Adding
> > > > > that to the DTs that are copied over from linux isn't imho. There
> > are
> > > > > various reasons for that. First of all syncing device trees is a
> > huge
> > > > pain
> > > > > and that's probably one of the main reasons our DTs are out of sync
> > for a
> > > > > large number of boards.
> > > >
> > > > This re-sync is only a pain because:
> > > > 1. Some platforms have been modifying the core dts files LIKE THEY ARE
> > > > NOT SUPPOSED TO.
> > > > 2. DTS files are getting closer to being the super stable API that has
> > > > been promised now that there's validation tools.
> > > >
> > > > Some SoCs, like stm32 are doing an amazing job and keeping things in
> > > > sync, every release. Others like NXP are violating rule #1.
> > >
> > > With NXP commitment to SystemReady on some IMX8 boards, I think this is
> > > changing,
> > > at least for the SystemReady boards.
> >
> > I'd really like to see some progress (as would the other non-NXP folks
> > working on NXP SoCs) in that regard.
> >
> > > > Still
> > > > others like some TI platforms get bit by #2 (I solved one of these, and
> > > > need to cycle back to the one you and I talked about on IRC a while
> > > > back, I bet it's another node name dash changed to underbar).
> > > >
> > > > > The point is this was fine in 2011 were we had SPL only, but the
> > reality
> > > > > today is completely different. There's previous stage boot loaders
> > (and
> > > > > enough cases were vendors prefer those over SPL). If that bootloader
> > > > needs
> > > > > to use it's own device tree for whatever reason, imposing
> > restrictions
> > > > on
> > > > > it wrt to the device tree it has to include, and require them to
> > have
> > > > > knowledge of U-Boot and it's internal config mechanism makes no
> > sense not
> > > > > to mention it doesn't scale at all.
> > > >
> > > > If you are passing the full device tree around, a few more
> > > > nodes/properties aren't going to make the situation worse. If we're
> > > > talking about a 60 kilobyte blob one more kilobyte isn't where we call
> > > > the line, especially since if we wait another 6 months it'll be a 62
> > > > kilobyte file coming in from Linux instead.
> > >
> > > This is not about size but about firmware supply chain organization.
> >
> > That's great since it means we just need the bindings reviewed then
> > everyone can pass whatever everyone else needs.
> >
> > > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"),
> > we
> > > > > > have binman definitions, etc. So we need a way to overlay those
> > things
> > > > > > into the DT. We already support this for in-tree DTs, so IMO this
> > is
> > > > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > > > discoverability and documentation, anyway. That is this series.
> > > > >
> > > > > Again, the board might decide for it's own reason to provide it's own
> > > > DT.
> > > > > IMHO U-Boot must be able to cope with that and asking DTs to be
> > included
> > > > in
> > > > > U-Boot source is not the right way to do that, not to mention cases
> > were
> > > > > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> > > > from
> > > > > it's flash).
> > > > >
> > > > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > > > and worried about step 3)
> > > > > >
> > > > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > > > flow only, or boards that sometimes use a flow) which need the DT
> > to
> > > > > > come from a prior stage. How to handle that? IMO that is only
> > going to
> > > > > > grow as every man and his dog get into the write-a-bootloader
> > > > > > business.
> > > > >
> > > > > And that's exactly why we have to come up with something that scales,
> > > > without
> > > > > having to add a bunch of unusable DTs in U-Boot.
> > > >
> > > > Both of these are solved by having our bindings reviewed and upstreamed
> > > > and then what we need included in the authoritative dts files.
> > > >
> > > There shall be authoritative System Device Trees as vendors are working
> > on.
> > > Those System Device Trees cover all aspects of a board, not just the
> > > Cortex-A part that U-Boot cares about.
> > > Out of those system device trees, a tool (lopper) is going to carve out
> > the
> > > "authoritative dts for the cortex-A".
> > > Essentially, that carve out will correspond to what would come out of
> > Linux.
> >
> > s/Linux/software/
> >
> > > This scheme will not be generalized, just adopted by vendors on some
> > > boards.
> > > DT for those board become part of the OS ABI (meaning, the driver
> > > developper is constrained).
> >
> > OK? And is going to pick and choose which valid bindings to implement?
> > Or is it going to provide half a node for Linux? No? I assume no. So
> > it will also provide whatever bindings we've upstreamed and say need to
> > be passed.
> >
> Until we can agree on a better scheme, Linux will server as the basis for
> most of the bindings.
Yes, this is the de-facto standard since the beginning.
> Some projects, like TF-A maintain their own bindings specifications. I
And as I keep saying I believe this to be totally wrong. Unless and
only unless the TF-A bindings are for TF-A only to care about, and then
it's just one-off do what you guys want non-standard stuff.
> guess U-Boot shall do the same.
No, U-Boot is going to upstream the bindings that we want to have be
considered official.
> The U-Boot DT (for properties or whatever purpose) can be stored in a
> various of U-Boot decided ways and as part of the TF-A FIP image in the
> ad-hoc section: NT_FW_CONFIG. Passing FIP information to U-Boot to retrieve
> the NF_FW_CONFIG should be part of the blob_list discussion that started a
> while ago.
Yes, we'll have to see where things progress about what bindings are
needed, and where.
> For System Device Tree, the bindings and the master repo will be maintained
> in devicetree.org (AFAIK).
Interesting, okay.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-26 6:46 ` Ilias Apalodimas
@ 2021-10-28 2:50 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 2:50 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung,
Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún,
Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp,
Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, François Ozog,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi Ilias,
On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> A bit late to the party, sorry!
(Did you remember the beer? I am replying to this but I don't think it
is all that helpful for me to reply to a lot of things on this thread,
since I would not be adding much to my cover letter and patches)
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since we could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
> >
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT. It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> that to the DTs that are copied over from linux isn't imho. There are
> various reasons for that. First of all syncing device trees is a huge pain
> and that's probably one of the main reasons our DTs are out of sync for a
> large number of boards.
> The point is this was fine in 2011 were we had SPL only, but the reality
> today is completely different. There's previous stage boot loaders (and
> enough cases were vendors prefer those over SPL). If that bootloader needs
> to use it's own device tree for whatever reason, imposing restrictions on
> it wrt to the device tree it has to include, and require them to have
> knowledge of U-Boot and it's internal config mechanism makes no sense not
> to mention it doesn't scale at all.
I think the solution here may be the binman image packer. It works
from a description of the image (i.e. is data-driver) and can collect
all the pieces together. The U-Boot properties (and the ones required
by TF-A, etc.) can be added at package time.
If you think about it, it doesn't matter what properties are in the DT
that is put into the firmware image. TF-A, for example, is presumably
reading a devicetree from flash, so what does it care if it has some
U-Boot properties in it?
As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
so I think this can be dealt with.
>
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
>
> Again, the board might decide for it's own reason to provide it's own DT.
> IMHO U-Boot must be able to cope with that and asking DTs to be included in
> U-Boot source is not the right way to do that, not to mention cases were
> that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> it's flash).
I think you are at step 2. See above for my response.
>
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business.
>
> And that's exactly why we have to come up with something that scales, without
> having to add a bunch of unusable DTs in U-Boot.
In what way does this not scale? How are the DTs unusable? If there is
a standard binding, we should be fine.
>
> > We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG.
>
> No we don't. That's a moot point. If you separate the DTs U-Boot
> provides the internal one and inherits one 'generic'. Linux will be able to use
> that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> DT across kernel versions, In which case there's not much you can do to
> begin with and that's already a case we have to deal with.
Linux actually doesn't care if the U-Boot properties are in the tree,
so long as we have proper bindings. My point here is we only need
either:
a. one devicetree, shared with Linux and U-Boot (and TF-A?)
b. two devicetrees, one for use in firmware and one for passing to Linux
We don't need to separate out the U-Boot properties into a second (or
third) devicetree. There just isn't any point.
>
> > b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient. It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
> >
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> We can start slowly migrating boards and see how that works out.
> We could either use 2 device trees as you proposed, or have u-boot merge
> the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> if linux gets handed a clean device tree without the u-boot internals in
> it, so I think 2 discrete DTs is cleaner overall.
I know you would prefer that, but does it really matter in practice?
What is the objection, actually?
As I mentioned on the call, I think the prior stage should do any
merging or fixing up. Trying to do that sort of thing in 'early' code
in U-Boot (or any other program, including Linux) is such a pain. With
U-Boot, for example, we don't even have any RAM available to do it
with half the time and it would dramatically increase the amount of
memory needed prior to relocation. It just isn't a very good idea to
try to do this in early code. It is also completely unnecessary, once
you get past the philosophical objections.
If TF-A wants to be in the picture, let it deal with the implications
and responsibility thus incurred. TF-A has no right to tell U-Boot how
to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
of the size of U-Boot. It duplicates loads of things in there. No one
will even *notice* an FDT merge function, which is actually only 70
LOC:
/**
* overlay_apply_node - Merges a node into the base device tree
* @fdt: Base Device Tree blob
* @target: Node offset in the base device tree to apply the fragment to
* @fdto: Device tree overlay blob
* @node: Node offset in the overlay holding the changes to merge
*
* overlay_apply_node() merges a node into a target base device tree
* node pointed.
*
* This is part of the final step in the device tree overlay
* application process, when all the phandles have been adjusted and
* resolved and you just have to merge overlay into the base device
* tree.
*
* returns:
* 0 on success
* Negative error code on failure
*/
static int overlay_apply_node(void *fdt, int target,
void *fdto, int node)
{
int property;
int subnode;
fdt_for_each_property_offset(property, fdto, node) {
const char *name;
const void *prop;
int prop_len;
int ret;
prop = fdt_getprop_by_offset(fdto, property, &name,
&prop_len);
if (prop_len == -FDT_ERR_NOTFOUND)
return -FDT_ERR_INTERNAL;
if (prop_len < 0)
return prop_len;
ret = fdt_setprop(fdt, target, name, prop, prop_len);
if (ret)
return ret;
}
fdt_for_each_subnode(subnode, fdto, node) {
const char *name = fdt_get_name(fdto, subnode, NULL);
int nnode;
int ret;
nnode = fdt_add_subnode(fdt, target, name);
if (nnode == -FDT_ERR_EXISTS) {
nnode = fdt_subnode_offset(fdt, target, name);
if (nnode == -FDT_ERR_NOTFOUND)
return -FDT_ERR_INTERNAL;
}
if (nnode < 0)
return nnode;
ret = overlay_apply_node(fdt, nnode, fdto, subnode);
if (ret)
return ret;
}
return 0;
}
>
> Regards
> /Ilias
> >
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I feel
> > this will set us up very well to deal with the complexity that is
> > coming.
> >
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 2:50 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 2:50 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi Ilias,
On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> A bit late to the party, sorry!
(Did you remember the beer? I am replying to this but I don't think it
is all that helpful for me to reply to a lot of things on this thread,
since I would not be adding much to my cover letter and patches)
>
> [...]
>
> > >
> > > I really want to see what the binary case looks like since we could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
> >
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT. It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
> >
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
>
> Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> that to the DTs that are copied over from linux isn't imho. There are
> various reasons for that. First of all syncing device trees is a huge pain
> and that's probably one of the main reasons our DTs are out of sync for a
> large number of boards.
> The point is this was fine in 2011 were we had SPL only, but the reality
> today is completely different. There's previous stage boot loaders (and
> enough cases were vendors prefer those over SPL). If that bootloader needs
> to use it's own device tree for whatever reason, imposing restrictions on
> it wrt to the device tree it has to include, and require them to have
> knowledge of U-Boot and it's internal config mechanism makes no sense not
> to mention it doesn't scale at all.
I think the solution here may be the binman image packer. It works
from a description of the image (i.e. is data-driver) and can collect
all the pieces together. The U-Boot properties (and the ones required
by TF-A, etc.) can be added at package time.
If you think about it, it doesn't matter what properties are in the DT
that is put into the firmware image. TF-A, for example, is presumably
reading a devicetree from flash, so what does it care if it has some
U-Boot properties in it?
As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
so I think this can be dealt with.
>
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
>
> Again, the board might decide for it's own reason to provide it's own DT.
> IMHO U-Boot must be able to cope with that and asking DTs to be included in
> U-Boot source is not the right way to do that, not to mention cases were
> that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> it's flash).
I think you are at step 2. See above for my response.
>
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business.
>
> And that's exactly why we have to come up with something that scales, without
> having to add a bunch of unusable DTs in U-Boot.
In what way does this not scale? How are the DTs unusable? If there is
a standard binding, we should be fine.
>
> > We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG.
>
> No we don't. That's a moot point. If you separate the DTs U-Boot
> provides the internal one and inherits one 'generic'. Linux will be able to use
> that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> DT across kernel versions, In which case there's not much you can do to
> begin with and that's already a case we have to deal with.
Linux actually doesn't care if the U-Boot properties are in the tree,
so long as we have proper bindings. My point here is we only need
either:
a. one devicetree, shared with Linux and U-Boot (and TF-A?)
b. two devicetrees, one for use in firmware and one for passing to Linux
We don't need to separate out the U-Boot properties into a second (or
third) devicetree. There just isn't any point.
>
> > b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient. It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
> >
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> We can start slowly migrating boards and see how that works out.
> We could either use 2 device trees as you proposed, or have u-boot merge
> the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> if linux gets handed a clean device tree without the u-boot internals in
> it, so I think 2 discrete DTs is cleaner overall.
I know you would prefer that, but does it really matter in practice?
What is the objection, actually?
As I mentioned on the call, I think the prior stage should do any
merging or fixing up. Trying to do that sort of thing in 'early' code
in U-Boot (or any other program, including Linux) is such a pain. With
U-Boot, for example, we don't even have any RAM available to do it
with half the time and it would dramatically increase the amount of
memory needed prior to relocation. It just isn't a very good idea to
try to do this in early code. It is also completely unnecessary, once
you get past the philosophical objections.
If TF-A wants to be in the picture, let it deal with the implications
and responsibility thus incurred. TF-A has no right to tell U-Boot how
to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
of the size of U-Boot. It duplicates loads of things in there. No one
will even *notice* an FDT merge function, which is actually only 70
LOC:
/**
* overlay_apply_node - Merges a node into the base device tree
* @fdt: Base Device Tree blob
* @target: Node offset in the base device tree to apply the fragment to
* @fdto: Device tree overlay blob
* @node: Node offset in the overlay holding the changes to merge
*
* overlay_apply_node() merges a node into a target base device tree
* node pointed.
*
* This is part of the final step in the device tree overlay
* application process, when all the phandles have been adjusted and
* resolved and you just have to merge overlay into the base device
* tree.
*
* returns:
* 0 on success
* Negative error code on failure
*/
static int overlay_apply_node(void *fdt, int target,
void *fdto, int node)
{
int property;
int subnode;
fdt_for_each_property_offset(property, fdto, node) {
const char *name;
const void *prop;
int prop_len;
int ret;
prop = fdt_getprop_by_offset(fdto, property, &name,
&prop_len);
if (prop_len == -FDT_ERR_NOTFOUND)
return -FDT_ERR_INTERNAL;
if (prop_len < 0)
return prop_len;
ret = fdt_setprop(fdt, target, name, prop, prop_len);
if (ret)
return ret;
}
fdt_for_each_subnode(subnode, fdto, node) {
const char *name = fdt_get_name(fdto, subnode, NULL);
int nnode;
int ret;
nnode = fdt_add_subnode(fdt, target, name);
if (nnode == -FDT_ERR_EXISTS) {
nnode = fdt_subnode_offset(fdt, target, name);
if (nnode == -FDT_ERR_NOTFOUND)
return -FDT_ERR_INTERNAL;
}
if (nnode < 0)
return nnode;
ret = overlay_apply_node(fdt, nnode, fdto, subnode);
if (ret)
return ret;
}
return 0;
}
>
> Regards
> /Ilias
> >
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I feel
> > this will set us up very well to deal with the complexity that is
> > coming.
> >
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 2:50 ` Simon Glass
@ 2021-10-28 8:21 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 8:21 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 14640 bytes --]
Hi Simon,
Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer? I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?
I am going to change my position in all mail threads I participate.
I was trying to make patches relevant in the future and conceptually clean.
That may not be the most effective position: I should just care about
Linaro and its members being able to implement SystemReady concepts.
If you mandate U-Boot has nodes in the device tree passed to the OS, we can
put DT fragment in the nt_fw_config section of the fip and merge it at
boot time. So there is a solution compatible with SystemReady.
If you want to put fake, non future proof, DT sources in the dts for
platforms that are organized to provide the authoritative DT to U-Boot at
runtime, that's kind of your choice (hopefully representing the rest of
U-Boot community). There will be quirk code in U-Boot to redo the
adaptations on its non authoritative DT that the platform previous stage
firmware does (already saw one in the past month); as Mark said there will
be issues over time; and it will confuse people about the role of the DT.
But I am fine with it as it does not impair Linaro and its members ability
to implement SystemReady way of handling DT.
>
> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> so I think this can be dealt with.
>
> >
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> >
> > Again, the board might decide for it's own reason to provide it's own DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included
> in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> > it's flash).
>
> I think you are at step 2. See above for my response.
>
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales,
> without
> > having to add a bunch of unusable DTs in U-Boot.
>
> In what way does this not scale? How are the DTs unusable? If there is
> a standard binding, we should be fine.
>
> >
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks
> the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
>
> Linux actually doesn't care if the U-Boot properties are in the tree,
> so long as we have proper bindings. My point here is we only need
> either:
>
> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> b. two devicetrees, one for use in firmware and one for passing to Linux
>
> We don't need to separate out the U-Boot properties into a second (or
> third) devicetree. There just isn't any point.
>
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> I know you would prefer that, but does it really matter in practice?
> What is the objection, actually?
>
> As I mentioned on the call, I think the prior stage should do any
> merging or fixing up. Trying to do that sort of thing in 'early' code
> in U-Boot (or any other program, including Linux) is such a pain. With
> U-Boot, for example, we don't even have any RAM available to do it
> with half the time and it would dramatically increase the amount of
> memory needed prior to relocation. It just isn't a very good idea to
> try to do this in early code. It is also completely unnecessary, once
> you get past the philosophical objections.
>
> If TF-A wants to be in the picture, let it deal with the implications
> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> of the size of U-Boot. It duplicates loads of things in there. No one
> will even *notice* an FDT merge function, which is actually only 70
> LOC:
>
> /**
> * overlay_apply_node - Merges a node into the base device tree
> * @fdt: Base Device Tree blob
> * @target: Node offset in the base device tree to apply the fragment to
> * @fdto: Device tree overlay blob
> * @node: Node offset in the overlay holding the changes to merge
> *
> * overlay_apply_node() merges a node into a target base device tree
> * node pointed.
> *
> * This is part of the final step in the device tree overlay
> * application process, when all the phandles have been adjusted and
> * resolved and you just have to merge overlay into the base device
> * tree.
> *
> * returns:
> * 0 on success
> * Negative error code on failure
> */
> static int overlay_apply_node(void *fdt, int target,
> void *fdto, int node)
> {
> int property;
> int subnode;
>
> fdt_for_each_property_offset(property, fdto, node) {
> const char *name;
> const void *prop;
> int prop_len;
> int ret;
>
> prop = fdt_getprop_by_offset(fdto, property, &name,
> &prop_len);
> if (prop_len == -FDT_ERR_NOTFOUND)
> return -FDT_ERR_INTERNAL;
> if (prop_len < 0)
> return prop_len;
>
> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> if (ret)
> return ret;
> }
>
> fdt_for_each_subnode(subnode, fdto, node) {
> const char *name = fdt_get_name(fdto, subnode, NULL);
> int nnode;
> int ret;
>
> nnode = fdt_add_subnode(fdt, target, name);
> if (nnode == -FDT_ERR_EXISTS) {
> nnode = fdt_subnode_offset(fdt, target, name);
> if (nnode == -FDT_ERR_NOTFOUND)
> return -FDT_ERR_INTERNAL;
> }
>
> if (nnode < 0)
> return nnode;
>
> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> if (ret)
> return ret;
> }
>
> return 0;
>
>
>
> }
>
>
> >
> > Regards
> > /Ilias
> > >
> > > To repeat, if we set things up correctly and agree on the bindings,
> > > devicetree can be the unifying configuration mechanism through the
> > > whole of firmware (except for very early bits) and into the OS. I feel
> > > this will set us up very well to deal with the complexity that is
> > > coming.
> > >
>
> Regards,
> Simon
>
[-- Attachment #2: Type: text/html, Size: 17138 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 8:21 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 8:21 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon,
Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer? I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could
> then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge
> pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> > to use it's own device tree for whatever reason, imposing restrictions
> on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?
I am going to change my position in all mail threads I participate.
I was trying to make patches relevant in the future and conceptually clean.
That may not be the most effective position: I should just care about
Linaro and its members being able to implement SystemReady concepts.
If you mandate U-Boot has nodes in the device tree passed to the OS, we can
put DT fragment in the nt_fw_config section of the fip and merge it at
boot time. So there is a solution compatible with SystemReady.
If you want to put fake, non future proof, DT sources in the dts for
platforms that are organized to provide the authoritative DT to U-Boot at
runtime, that's kind of your choice (hopefully representing the rest of
U-Boot community). There will be quirk code in U-Boot to redo the
adaptations on its non authoritative DT that the platform previous stage
firmware does (already saw one in the past month); as Mark said there will
be issues over time; and it will confuse people about the role of the DT.
But I am fine with it as it does not impair Linaro and its members ability
to implement SystemReady way of handling DT.
>
> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> so I think this can be dealt with.
>
> >
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> >
> > Again, the board might decide for it's own reason to provide it's own DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included
> in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> > it's flash).
>
> I think you are at step 2. See above for my response.
>
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales,
> without
> > having to add a bunch of unusable DTs in U-Boot.
>
> In what way does this not scale? How are the DTs unusable? If there is
> a standard binding, we should be fine.
>
> >
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks
> the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
>
> Linux actually doesn't care if the U-Boot properties are in the tree,
> so long as we have proper bindings. My point here is we only need
> either:
>
> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> b. two devicetrees, one for use in firmware and one for passing to Linux
>
> We don't need to separate out the U-Boot properties into a second (or
> third) devicetree. There just isn't any point.
>
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> I know you would prefer that, but does it really matter in practice?
> What is the objection, actually?
>
> As I mentioned on the call, I think the prior stage should do any
> merging or fixing up. Trying to do that sort of thing in 'early' code
> in U-Boot (or any other program, including Linux) is such a pain. With
> U-Boot, for example, we don't even have any RAM available to do it
> with half the time and it would dramatically increase the amount of
> memory needed prior to relocation. It just isn't a very good idea to
> try to do this in early code. It is also completely unnecessary, once
> you get past the philosophical objections.
>
> If TF-A wants to be in the picture, let it deal with the implications
> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> of the size of U-Boot. It duplicates loads of things in there. No one
> will even *notice* an FDT merge function, which is actually only 70
> LOC:
>
> /**
> * overlay_apply_node - Merges a node into the base device tree
> * @fdt: Base Device Tree blob
> * @target: Node offset in the base device tree to apply the fragment to
> * @fdto: Device tree overlay blob
> * @node: Node offset in the overlay holding the changes to merge
> *
> * overlay_apply_node() merges a node into a target base device tree
> * node pointed.
> *
> * This is part of the final step in the device tree overlay
> * application process, when all the phandles have been adjusted and
> * resolved and you just have to merge overlay into the base device
> * tree.
> *
> * returns:
> * 0 on success
> * Negative error code on failure
> */
> static int overlay_apply_node(void *fdt, int target,
> void *fdto, int node)
> {
> int property;
> int subnode;
>
> fdt_for_each_property_offset(property, fdto, node) {
> const char *name;
> const void *prop;
> int prop_len;
> int ret;
>
> prop = fdt_getprop_by_offset(fdto, property, &name,
> &prop_len);
> if (prop_len == -FDT_ERR_NOTFOUND)
> return -FDT_ERR_INTERNAL;
> if (prop_len < 0)
> return prop_len;
>
> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> if (ret)
> return ret;
> }
>
> fdt_for_each_subnode(subnode, fdto, node) {
> const char *name = fdt_get_name(fdto, subnode, NULL);
> int nnode;
> int ret;
>
> nnode = fdt_add_subnode(fdt, target, name);
> if (nnode == -FDT_ERR_EXISTS) {
> nnode = fdt_subnode_offset(fdt, target, name);
> if (nnode == -FDT_ERR_NOTFOUND)
> return -FDT_ERR_INTERNAL;
> }
>
> if (nnode < 0)
> return nnode;
>
> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> if (ret)
> return ret;
> }
>
> return 0;
>
>
>
> }
>
>
> >
> > Regards
> > /Ilias
> > >
> > > To repeat, if we set things up correctly and agree on the bindings,
> > > devicetree can be the unifying configuration mechanism through the
> > > whole of firmware (except for very early bits) and into the OS. I feel
> > > this will set us up very well to deal with the complexity that is
> > > coming.
> > >
>
> Regards,
> Simon
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 8:21 ` François Ozog
@ 2021-10-28 14:30 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 14:30 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi François,
On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon,
>
> Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Ilias,
>>
>> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> <ilias.apalodimas@linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> > A bit late to the party, sorry!
>>
>> (Did you remember the beer? I am replying to this but I don't think it
>> is all that helpful for me to reply to a lot of things on this thread,
>> since I would not be adding much to my cover letter and patches)
>>
>> >
>> > [...]
>> >
>> > > >
>> > > > I really want to see what the binary case looks like since we could then
>> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> > > > then also do a rpi_arm32_defconfig too.
>> > > >
>> > > > I want to see less device trees in U-Boot sources, if they can come
>> > > > functionally correct from the hardware/our caller.
>> > > >
>> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> > > > use the device tree from build time at run time, ignoring the device
>> > > > tree provided to us at run time by the caller.
>> > >
>> > > Firstly I should say that I find building firmware very messy and
>> > > confusing these days. Lots of things to build and it's hard to find
>> > > the instructions. It doesn't have to be that way, but if we carry on
>> > > as we are, it will continue to be messy and in five years you will
>> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> > > objective here is to simplify things, bringing some consistency to the
>> > > different components. Binman was one effort there. I feel that putting
>> > > at least the U-Boot house in order, in my role as devicetree
>> > > maintainer (and as author of devicetree support in U-Boot back in
>> > > 2011), is the next step.
>> > >
>> > > If we set things up correctly and agree on the bindings, devicetree
>> > > can be the unifying configuration mechanism through the whole of
>> > > firmware (except for very early bits) and into the OS, this will set
>> > > us up very well to deal with the complexity that is coming.
>> > >
>> > > Anyway, here are the mental steps that I've gone through over the past
>> > > two months:
>> > >
>> > > Step 1: At present, some people think U-Boot is not even allowed to
>> > > have its own nodes/properties in the DT. It is an abuse of the
>> > > devicetree standard, like the /chosen node but with less history. We
>> > > should sacrifice efficiency, expedience and expandability on the altar
>> > > of 'devicetree is a hardware description'. How do we get over that
>> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> > > for its own purposes, as well as for booting the OS. I am not saying
>> > > it always has to have those properties, but with existing features
>> > > like verified boot, SPL as well as complex firmware images where
>> > > U-Boot needs to be able to find things in the image, it is essential.
>> > > So let's just assume that we need this everywhere, since we certainly
>> > > need it in at least some places.
>> > >
>> > > (stop reading here if you disagree, because nothing below will make
>> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> > > OF_CONTROL :-)
>> >
>> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> > that to the DTs that are copied over from linux isn't imho. There are
>> > various reasons for that. First of all syncing device trees is a huge pain
>> > and that's probably one of the main reasons our DTs are out of sync for a
>> > large number of boards.
>> > The point is this was fine in 2011 were we had SPL only, but the reality
>> > today is completely different. There's previous stage boot loaders (and
>> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> > to use it's own device tree for whatever reason, imposing restrictions on
>> > it wrt to the device tree it has to include, and require them to have
>> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> > to mention it doesn't scale at all.
>>
>> I think the solution here may be the binman image packer. It works
>> from a description of the image (i.e. is data-driver) and can collect
>> all the pieces together. The U-Boot properties (and the ones required
>> by TF-A, etc.) can be added at package time.
>>
>> If you think about it, it doesn't matter what properties are in the DT
>> that is put into the firmware image. TF-A, for example, is presumably
>> reading a devicetree from flash, so what does it care if it has some
>> U-Boot properties in it?
>
>
> I am going to change my position in all mail threads I participate.
> I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>
>
> If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>
> If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
OK thank you. It doesn't sound like you are very on-board though.
Also, you mischaracterise my intent with in-tree devicetrees.
I would be happy enough for now if you could accept that U-Boot has
nodes/properties of its own in the devicetree. It has been a feature
of U-Boot for 10 years now.
Regards,
Simon
>
>>
>>
>> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> so I think this can be dealt with.
>>
>> >
>> > >
>> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> > > have binman definitions, etc. So we need a way to overlay those things
>> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> > > easy. Just require every board to have an in-tree DT. It helps with
>> > > discoverability and documentation, anyway. That is this series.
>> > >
>> >
>> > Again, the board might decide for it's own reason to provide it's own DT.
>> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> > U-Boot source is not the right way to do that, not to mention cases were
>> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> > it's flash).
>>
>> I think you are at step 2. See above for my response.
>>
>> >
>> > > (I think most of us are at the beginning of step 2, unsure about it
>> > > and worried about step 3)
>> > >
>> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> > > flow only, or boards that sometimes use a flow) which need the DT to
>> > > come from a prior stage. How to handle that? IMO that is only going to
>> > > grow as every man and his dog get into the write-a-bootloader
>> > > business.
>> >
>> > And that's exactly why we have to come up with something that scales, without
>> > having to add a bunch of unusable DTs in U-Boot.
>>
>> In what way does this not scale? How are the DTs unusable? If there is
>> a standard binding, we should be fine.
>>
>> >
>> > > We need a way to provide the U-Boot nodes/properties in a
>> > > form that the prior stage can consume and integrate with its build
>> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> > > together, for example. Or we can get clever and create some sort of
>> > > overlay dtb.
>> > >
>> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> > > then it will need to build it in and use two devicetrees, one internal
>> > > and one from the prior stage....well that is not very efficient and it
>> > > is going to be confusing for people to figure out what U-Boot is
>> > > actually doing. But we actually already do that in a lot of cases
>> > > where U-Boot passes a DT to the kernel which is different to the one
>> > > it uses. So perhaps we have three devicetrees? OMG.
>> >
>> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> > DT across kernel versions, In which case there's not much you can do to
>> > begin with and that's already a case we have to deal with.
>>
>> Linux actually doesn't care if the U-Boot properties are in the tree,
>> so long as we have proper bindings. My point here is we only need
>> either:
>>
>> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> b. two devicetrees, one for use in firmware and one for passing to Linux
>>
>> We don't need to separate out the U-Boot properties into a second (or
>> third) devicetree. There just isn't any point.
>>
>> >
>> > > b) Well then
>> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> > > can merge the two when it starts. Again that is not very efficient. It
>> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> > > its public key from there or to enable/disable the console), so
>> > > unified firmware config is not possible. It will get very confusing,
>> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> > > accepting step 3...please stop!
>> > >
>> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> > > whole cloth. What about that? Well, we are just going to have to deal
>> > > with that. We can easily merge in the U-Boot nodes/properties and
>> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> > > something similar.
>> > >
>> > > To my mind, that deals with both the build-time and run-time issues.
>> > > We have a discoverable DT in U-Boot, which should be considered the
>> > > source of truth for most boards. We can sync it with Linux
>> > > automatically with the tooling that I hope Rob Herring will come up
>> > > with. We can use an empty one where there really is no default,
>> > > although I'd argue that is making perfect an enemy of the good.
>> > >
>> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> > > and pick them up from somewhere else, we can do that with sufficient
>> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >
>> > We can start slowly migrating boards and see how that works out.
>> > We could either use 2 device trees as you proposed, or have u-boot merge
>> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> > if linux gets handed a clean device tree without the u-boot internals in
>> > it, so I think 2 discrete DTs is cleaner overall.
>>
>> I know you would prefer that, but does it really matter in practice?
>> What is the objection, actually?
>>
>> As I mentioned on the call, I think the prior stage should do any
>> merging or fixing up. Trying to do that sort of thing in 'early' code
>> in U-Boot (or any other program, including Linux) is such a pain. With
>> U-Boot, for example, we don't even have any RAM available to do it
>> with half the time and it would dramatically increase the amount of
>> memory needed prior to relocation. It just isn't a very good idea to
>> try to do this in early code. It is also completely unnecessary, once
>> you get past the philosophical objections.
>>
>> If TF-A wants to be in the picture, let it deal with the implications
>> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> of the size of U-Boot. It duplicates loads of things in there. No one
>> will even *notice* an FDT merge function, which is actually only 70
>> LOC:
>>
>> /**
>> * overlay_apply_node - Merges a node into the base device tree
>> * @fdt: Base Device Tree blob
>> * @target: Node offset in the base device tree to apply the fragment to
>> * @fdto: Device tree overlay blob
>> * @node: Node offset in the overlay holding the changes to merge
>> *
>> * overlay_apply_node() merges a node into a target base device tree
>> * node pointed.
>> *
>> * This is part of the final step in the device tree overlay
>> * application process, when all the phandles have been adjusted and
>> * resolved and you just have to merge overlay into the base device
>> * tree.
>> *
>> * returns:
>> * 0 on success
>> * Negative error code on failure
>> */
>> static int overlay_apply_node(void *fdt, int target,
>> void *fdto, int node)
>> {
>> int property;
>> int subnode;
>>
>> fdt_for_each_property_offset(property, fdto, node) {
>> const char *name;
>> const void *prop;
>> int prop_len;
>> int ret;
>>
>> prop = fdt_getprop_by_offset(fdto, property, &name,
>> &prop_len);
>> if (prop_len == -FDT_ERR_NOTFOUND)
>> return -FDT_ERR_INTERNAL;
>> if (prop_len < 0)
>> return prop_len;
>>
>> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> if (ret)
>> return ret;
>> }
>>
>> fdt_for_each_subnode(subnode, fdto, node) {
>> const char *name = fdt_get_name(fdto, subnode, NULL);
>> int nnode;
>> int ret;
>>
>> nnode = fdt_add_subnode(fdt, target, name);
>> if (nnode == -FDT_ERR_EXISTS) {
>> nnode = fdt_subnode_offset(fdt, target, name);
>> if (nnode == -FDT_ERR_NOTFOUND)
>> return -FDT_ERR_INTERNAL;
>> }
>>
>> if (nnode < 0)
>> return nnode;
>>
>> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> if (ret)
>> return ret;
>> }
>>
>> return 0;
>>
>>
>>
>> }
>>
>>
>> >
>> > Regards
>> > /Ilias
>> > >
>> > > To repeat, if we set things up correctly and agree on the bindings,
>> > > devicetree can be the unifying configuration mechanism through the
>> > > whole of firmware (except for very early bits) and into the OS. I feel
>> > > this will set us up very well to deal with the complexity that is
>> > > coming.
>> > >
>>
>> Regards,
>> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 14:30 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 14:30 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi François,
On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon,
>
> Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi Ilias,
>>
>> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> <ilias.apalodimas@linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> > A bit late to the party, sorry!
>>
>> (Did you remember the beer? I am replying to this but I don't think it
>> is all that helpful for me to reply to a lot of things on this thread,
>> since I would not be adding much to my cover letter and patches)
>>
>> >
>> > [...]
>> >
>> > > >
>> > > > I really want to see what the binary case looks like since we could then
>> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> > > > then also do a rpi_arm32_defconfig too.
>> > > >
>> > > > I want to see less device trees in U-Boot sources, if they can come
>> > > > functionally correct from the hardware/our caller.
>> > > >
>> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> > > > use the device tree from build time at run time, ignoring the device
>> > > > tree provided to us at run time by the caller.
>> > >
>> > > Firstly I should say that I find building firmware very messy and
>> > > confusing these days. Lots of things to build and it's hard to find
>> > > the instructions. It doesn't have to be that way, but if we carry on
>> > > as we are, it will continue to be messy and in five years you will
>> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> > > objective here is to simplify things, bringing some consistency to the
>> > > different components. Binman was one effort there. I feel that putting
>> > > at least the U-Boot house in order, in my role as devicetree
>> > > maintainer (and as author of devicetree support in U-Boot back in
>> > > 2011), is the next step.
>> > >
>> > > If we set things up correctly and agree on the bindings, devicetree
>> > > can be the unifying configuration mechanism through the whole of
>> > > firmware (except for very early bits) and into the OS, this will set
>> > > us up very well to deal with the complexity that is coming.
>> > >
>> > > Anyway, here are the mental steps that I've gone through over the past
>> > > two months:
>> > >
>> > > Step 1: At present, some people think U-Boot is not even allowed to
>> > > have its own nodes/properties in the DT. It is an abuse of the
>> > > devicetree standard, like the /chosen node but with less history. We
>> > > should sacrifice efficiency, expedience and expandability on the altar
>> > > of 'devicetree is a hardware description'. How do we get over that
>> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> > > for its own purposes, as well as for booting the OS. I am not saying
>> > > it always has to have those properties, but with existing features
>> > > like verified boot, SPL as well as complex firmware images where
>> > > U-Boot needs to be able to find things in the image, it is essential.
>> > > So let's just assume that we need this everywhere, since we certainly
>> > > need it in at least some places.
>> > >
>> > > (stop reading here if you disagree, because nothing below will make
>> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> > > OF_CONTROL :-)
>> >
>> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> > that to the DTs that are copied over from linux isn't imho. There are
>> > various reasons for that. First of all syncing device trees is a huge pain
>> > and that's probably one of the main reasons our DTs are out of sync for a
>> > large number of boards.
>> > The point is this was fine in 2011 were we had SPL only, but the reality
>> > today is completely different. There's previous stage boot loaders (and
>> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> > to use it's own device tree for whatever reason, imposing restrictions on
>> > it wrt to the device tree it has to include, and require them to have
>> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> > to mention it doesn't scale at all.
>>
>> I think the solution here may be the binman image packer. It works
>> from a description of the image (i.e. is data-driver) and can collect
>> all the pieces together. The U-Boot properties (and the ones required
>> by TF-A, etc.) can be added at package time.
>>
>> If you think about it, it doesn't matter what properties are in the DT
>> that is put into the firmware image. TF-A, for example, is presumably
>> reading a devicetree from flash, so what does it care if it has some
>> U-Boot properties in it?
>
>
> I am going to change my position in all mail threads I participate.
> I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>
>
> If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>
> If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
OK thank you. It doesn't sound like you are very on-board though.
Also, you mischaracterise my intent with in-tree devicetrees.
I would be happy enough for now if you could accept that U-Boot has
nodes/properties of its own in the devicetree. It has been a feature
of U-Boot for 10 years now.
Regards,
Simon
>
>>
>>
>> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> so I think this can be dealt with.
>>
>> >
>> > >
>> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> > > have binman definitions, etc. So we need a way to overlay those things
>> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> > > easy. Just require every board to have an in-tree DT. It helps with
>> > > discoverability and documentation, anyway. That is this series.
>> > >
>> >
>> > Again, the board might decide for it's own reason to provide it's own DT.
>> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> > U-Boot source is not the right way to do that, not to mention cases were
>> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> > it's flash).
>>
>> I think you are at step 2. See above for my response.
>>
>> >
>> > > (I think most of us are at the beginning of step 2, unsure about it
>> > > and worried about step 3)
>> > >
>> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> > > flow only, or boards that sometimes use a flow) which need the DT to
>> > > come from a prior stage. How to handle that? IMO that is only going to
>> > > grow as every man and his dog get into the write-a-bootloader
>> > > business.
>> >
>> > And that's exactly why we have to come up with something that scales, without
>> > having to add a bunch of unusable DTs in U-Boot.
>>
>> In what way does this not scale? How are the DTs unusable? If there is
>> a standard binding, we should be fine.
>>
>> >
>> > > We need a way to provide the U-Boot nodes/properties in a
>> > > form that the prior stage can consume and integrate with its build
>> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> > > together, for example. Or we can get clever and create some sort of
>> > > overlay dtb.
>> > >
>> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> > > then it will need to build it in and use two devicetrees, one internal
>> > > and one from the prior stage....well that is not very efficient and it
>> > > is going to be confusing for people to figure out what U-Boot is
>> > > actually doing. But we actually already do that in a lot of cases
>> > > where U-Boot passes a DT to the kernel which is different to the one
>> > > it uses. So perhaps we have three devicetrees? OMG.
>> >
>> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> > DT across kernel versions, In which case there's not much you can do to
>> > begin with and that's already a case we have to deal with.
>>
>> Linux actually doesn't care if the U-Boot properties are in the tree,
>> so long as we have proper bindings. My point here is we only need
>> either:
>>
>> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> b. two devicetrees, one for use in firmware and one for passing to Linux
>>
>> We don't need to separate out the U-Boot properties into a second (or
>> third) devicetree. There just isn't any point.
>>
>> >
>> > > b) Well then
>> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> > > can merge the two when it starts. Again that is not very efficient. It
>> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> > > its public key from there or to enable/disable the console), so
>> > > unified firmware config is not possible. It will get very confusing,
>> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> > > accepting step 3...please stop!
>> > >
>> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> > > whole cloth. What about that? Well, we are just going to have to deal
>> > > with that. We can easily merge in the U-Boot nodes/properties and
>> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> > > something similar.
>> > >
>> > > To my mind, that deals with both the build-time and run-time issues.
>> > > We have a discoverable DT in U-Boot, which should be considered the
>> > > source of truth for most boards. We can sync it with Linux
>> > > automatically with the tooling that I hope Rob Herring will come up
>> > > with. We can use an empty one where there really is no default,
>> > > although I'd argue that is making perfect an enemy of the good.
>> > >
>> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> > > and pick them up from somewhere else, we can do that with sufficient
>> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >
>> > We can start slowly migrating boards and see how that works out.
>> > We could either use 2 device trees as you proposed, or have u-boot merge
>> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> > if linux gets handed a clean device tree without the u-boot internals in
>> > it, so I think 2 discrete DTs is cleaner overall.
>>
>> I know you would prefer that, but does it really matter in practice?
>> What is the objection, actually?
>>
>> As I mentioned on the call, I think the prior stage should do any
>> merging or fixing up. Trying to do that sort of thing in 'early' code
>> in U-Boot (or any other program, including Linux) is such a pain. With
>> U-Boot, for example, we don't even have any RAM available to do it
>> with half the time and it would dramatically increase the amount of
>> memory needed prior to relocation. It just isn't a very good idea to
>> try to do this in early code. It is also completely unnecessary, once
>> you get past the philosophical objections.
>>
>> If TF-A wants to be in the picture, let it deal with the implications
>> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> of the size of U-Boot. It duplicates loads of things in there. No one
>> will even *notice* an FDT merge function, which is actually only 70
>> LOC:
>>
>> /**
>> * overlay_apply_node - Merges a node into the base device tree
>> * @fdt: Base Device Tree blob
>> * @target: Node offset in the base device tree to apply the fragment to
>> * @fdto: Device tree overlay blob
>> * @node: Node offset in the overlay holding the changes to merge
>> *
>> * overlay_apply_node() merges a node into a target base device tree
>> * node pointed.
>> *
>> * This is part of the final step in the device tree overlay
>> * application process, when all the phandles have been adjusted and
>> * resolved and you just have to merge overlay into the base device
>> * tree.
>> *
>> * returns:
>> * 0 on success
>> * Negative error code on failure
>> */
>> static int overlay_apply_node(void *fdt, int target,
>> void *fdto, int node)
>> {
>> int property;
>> int subnode;
>>
>> fdt_for_each_property_offset(property, fdto, node) {
>> const char *name;
>> const void *prop;
>> int prop_len;
>> int ret;
>>
>> prop = fdt_getprop_by_offset(fdto, property, &name,
>> &prop_len);
>> if (prop_len == -FDT_ERR_NOTFOUND)
>> return -FDT_ERR_INTERNAL;
>> if (prop_len < 0)
>> return prop_len;
>>
>> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> if (ret)
>> return ret;
>> }
>>
>> fdt_for_each_subnode(subnode, fdto, node) {
>> const char *name = fdt_get_name(fdto, subnode, NULL);
>> int nnode;
>> int ret;
>>
>> nnode = fdt_add_subnode(fdt, target, name);
>> if (nnode == -FDT_ERR_EXISTS) {
>> nnode = fdt_subnode_offset(fdt, target, name);
>> if (nnode == -FDT_ERR_NOTFOUND)
>> return -FDT_ERR_INTERNAL;
>> }
>>
>> if (nnode < 0)
>> return nnode;
>>
>> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> if (ret)
>> return ret;
>> }
>>
>> return 0;
>>
>>
>>
>> }
>>
>>
>> >
>> > Regards
>> > /Ilias
>> > >
>> > > To repeat, if we set things up correctly and agree on the bindings,
>> > > devicetree can be the unifying configuration mechanism through the
>> > > whole of firmware (except for very early bits) and into the OS. I feel
>> > > this will set us up very well to deal with the complexity that is
>> > > coming.
>> > >
>>
>> Regards,
>> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 14:30 ` Simon Glass
@ 2021-10-28 14:50 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 14:50 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon
Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Ilias,
> >>
> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > A bit late to the party, sorry!
> >>
> >> (Did you remember the beer? I am replying to this but I don't think it
> >> is all that helpful for me to reply to a lot of things on this thread,
> >> since I would not be adding much to my cover letter and patches)
> >>
> >> >
> >> > [...]
> >> >
> >> > > >
> >> > > > I really want to see what the binary case looks like since we
> could then
> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> > > > then also do a rpi_arm32_defconfig too.
> >> > > >
> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> > > > functionally correct from the hardware/our caller.
> >> > > >
> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> > > > tree provided to us at run time by the caller.
> >> > >
> >> > > Firstly I should say that I find building firmware very messy and
> >> > > confusing these days. Lots of things to build and it's hard to find
> >> > > the instructions. It doesn't have to be that way, but if we carry on
> >> > > as we are, it will continue to be messy and in five years you will
> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> > > objective here is to simplify things, bringing some consistency to
> the
> >> > > different components. Binman was one effort there. I feel that
> putting
> >> > > at least the U-Boot house in order, in my role as devicetree
> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> > > 2011), is the next step.
> >> > >
> >> > > If we set things up correctly and agree on the bindings, devicetree
> >> > > can be the unifying configuration mechanism through the whole of
> >> > > firmware (except for very early bits) and into the OS, this will set
> >> > > us up very well to deal with the complexity that is coming.
> >> > >
> >> > > Anyway, here are the mental steps that I've gone through over the
> past
> >> > > two months:
> >> > >
> >> > > Step 1: At present, some people think U-Boot is not even allowed to
> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> > > devicetree standard, like the /chosen node but with less history. We
> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> > > of 'devicetree is a hardware description'. How do we get over that
> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> >> > > for its own purposes, as well as for booting the OS. I am not saying
> >> > > it always has to have those properties, but with existing features
> >> > > like verified boot, SPL as well as complex firmware images where
> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> > > So let's just assume that we need this everywhere, since we
> certainly
> >> > > need it in at least some places.
> >> > >
> >> > > (stop reading here if you disagree, because nothing below will make
> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> >> > > OF_CONTROL :-)
> >> >
> >> > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> >> > that to the DTs that are copied over from linux isn't imho. There are
> >> > various reasons for that. First of all syncing device trees is a
> huge pain
> >> > and that's probably one of the main reasons our DTs are out of sync
> for a
> >> > large number of boards.
> >> > The point is this was fine in 2011 were we had SPL only, but the
> reality
> >> > today is completely different. There's previous stage boot loaders
> (and
> >> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> >> > to use it's own device tree for whatever reason, imposing
> restrictions on
> >> > it wrt to the device tree it has to include, and require them to have
> >> > knowledge of U-Boot and it's internal config mechanism makes no sense
> not
> >> > to mention it doesn't scale at all.
> >>
> >> I think the solution here may be the binman image packer. It works
> >> from a description of the image (i.e. is data-driver) and can collect
> >> all the pieces together. The U-Boot properties (and the ones required
> >> by TF-A, etc.) can be added at package time.
> >>
> >> If you think about it, it doesn't matter what properties are in the DT
> >> that is put into the firmware image. TF-A, for example, is presumably
> >> reading a devicetree from flash, so what does it care if it has some
> >> U-Boot properties in it?
> >
> >
> > I am going to change my position in all mail threads I participate.
> > I was trying to make patches relevant in the future and conceptually
> clean. That may not be the most effective position: I should just care
> about Linaro and its members being able to implement SystemReady concepts.
> >
> >
> > If you mandate U-Boot has nodes in the device tree passed to the OS, we
> can put DT fragment in the nt_fw_config section of the fip and merge it at
> boot time. So there is a solution compatible with SystemReady.
> >
> > If you want to put fake, non future proof, DT sources in the dts for
> platforms that are organized to provide the authoritative DT to U-Boot at
> runtime, that's kind of your choice (hopefully representing the rest of
> U-Boot community). There will be quirk code in U-Boot to redo the
> adaptations on its non authoritative DT that the platform previous stage
> firmware does (already saw one in the past month); as Mark said there will
> be issues over time; and it will confuse people about the role of the DT.
> But I am fine with it as it does not impair Linaro and its members ability
> to implement SystemReady way of handling DT.
>
> OK thank you. It doesn't sound like you are very on-board though.
> Also, you mischaracterise my intent with in-tree devicetrees.
>
> I would be happy enough for now if you could accept that U-Boot has
> nodes/properties of its own in the devicetree. It has been a feature
> of U-Boot for 10 years now.
On SystemReady systems the DT passed to U-Boot for the OS will be assembled
from the board DT and a U-Boot fragment/overlay. The board DT is free from
any software/firmware aspects, just contains hardware description. The
U-Boot fragment/overlay can contain any nodes it wants. The location of the
bindings specification is essentially irrelevant: it could be devicetree.org,
U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making
their firmware will just put whatever is needed in this “dynamic config”
DT. On SystemReady platforms U-Boot will always be given a DT, like on the
RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a
platform may end-up failing compliance tests.
I think we need to document the above in U-Boot and refer to relevant
specifications. I’ll let Ilias propose something.
>
>
>
> Regards,
> Simon
>
>
> >
> >>
> >>
> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> >> so I think this can be dealt with.
> >>
> >> >
> >> > >
> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> >> > > have binman definitions, etc. So we need a way to overlay those
> things
> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
> >> > > easy. Just require every board to have an in-tree DT. It helps with
> >> > > discoverability and documentation, anyway. That is this series.
> >> > >
> >> >
> >> > Again, the board might decide for it's own reason to provide it's own
> DT.
> >> > IMHO U-Boot must be able to cope with that and asking DTs to be
> included in
> >> > U-Boot source is not the right way to do that, not to mention cases
> were
> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> >> > it's flash).
> >>
> >> I think you are at step 2. See above for my response.
> >>
> >> >
> >> > > (I think most of us are at the beginning of step 2, unsure about it
> >> > > and worried about step 3)
> >> > >
> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> >> > > flow only, or boards that sometimes use a flow) which need the DT to
> >> > > come from a prior stage. How to handle that? IMO that is only going
> to
> >> > > grow as every man and his dog get into the write-a-bootloader
> >> > > business.
> >> >
> >> > And that's exactly why we have to come up with something that
> scales, without
> >> > having to add a bunch of unusable DTs in U-Boot.
> >>
> >> In what way does this not scale? How are the DTs unusable? If there is
> >> a standard binding, we should be fine.
> >>
> >> >
> >> > > We need a way to provide the U-Boot nodes/properties in a
> >> > > form that the prior stage can consume and integrate with its build
> >> > > system. Is TF-A the only thing being discussed here? If so, let's
> just
> >> > > do it. We have the u-boot.dtsi and we can use binman to put the
> image
> >> > > together, for example. Or we can get clever and create some sort of
> >> > > overlay dtb.
> >> > >
> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> >> > > then it will need to build it in and use two devicetrees, one
> internal
> >> > > and one from the prior stage....well that is not very efficient and
> it
> >> > > is going to be confusing for people to figure out what U-Boot is
> >> > > actually doing. But we actually already do that in a lot of cases
> >> > > where U-Boot passes a DT to the kernel which is different to the one
> >> > > it uses. So perhaps we have three devicetrees? OMG.
> >> >
> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
> >> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> >> > that. So the only case were you'll need 3 DTs is if the *vendor*
> breaks the
> >> > DT across kernel versions, In which case there's not much you can do
> to
> >> > begin with and that's already a case we have to deal with.
> >>
> >> Linux actually doesn't care if the U-Boot properties are in the tree,
> >> so long as we have proper bindings. My point here is we only need
> >> either:
> >>
> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> >> b. two devicetrees, one for use in firmware and one for passing to Linux
> >>
> >> We don't need to separate out the U-Boot properties into a second (or
> >> third) devicetree. There just isn't any point.
> >>
> >> >
> >> > > b) Well then
> >> > > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> >> > > can merge the two when it starts. Again that is not very efficient.
> It
> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to
> get
> >> > > its public key from there or to enable/disable the console), so
> >> > > unified firmware config is not possible. It will get very confusing,
> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> >> > > accepting step 3...please stop!
> >> > >
> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> >> > > whole cloth. What about that? Well, we are just going to have to
> deal
> >> > > with that. We can easily merge in the U-Boot nodes/properties and
> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> >> > > something similar.
> >> > >
> >> > > To my mind, that deals with both the build-time and run-time issues.
> >> > > We have a discoverable DT in U-Boot, which should be considered the
> >> > > source of truth for most boards. We can sync it with Linux
> >> > > automatically with the tooling that I hope Rob Herring will come up
> >> > > with. We can use an empty one where there really is no default,
> >> > > although I'd argue that is making perfect an enemy of the good.
> >> > >
> >> > > Step 5: If we get clever and want to remove them from the U-Boot
> tree
> >> > > and pick them up from somewhere else, we can do that with sufficient
> >> > > tooling. Perhaps we should set a timeline for that? A year? Two?
> Six?
> >> >
> >> > We can start slowly migrating boards and see how that works out.
> >> > We could either use 2 device trees as you proposed, or have u-boot
> merge
> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> >> > if linux gets handed a clean device tree without the u-boot internals
> in
> >> > it, so I think 2 discrete DTs is cleaner overall.
> >>
> >> I know you would prefer that, but does it really matter in practice?
> >> What is the objection, actually?
> >>
> >> As I mentioned on the call, I think the prior stage should do any
> >> merging or fixing up. Trying to do that sort of thing in 'early' code
> >> in U-Boot (or any other program, including Linux) is such a pain. With
> >> U-Boot, for example, we don't even have any RAM available to do it
> >> with half the time and it would dramatically increase the amount of
> >> memory needed prior to relocation. It just isn't a very good idea to
> >> try to do this in early code. It is also completely unnecessary, once
> >> you get past the philosophical objections.
> >>
> >> If TF-A wants to be in the picture, let it deal with the implications
> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> >> of the size of U-Boot. It duplicates loads of things in there. No one
> >> will even *notice* an FDT merge function, which is actually only 70
> >> LOC:
> >>
> >> /**
> >> * overlay_apply_node - Merges a node into the base device tree
> >> * @fdt: Base Device Tree blob
> >> * @target: Node offset in the base device tree to apply the fragment to
> >> * @fdto: Device tree overlay blob
> >> * @node: Node offset in the overlay holding the changes to merge
> >> *
> >> * overlay_apply_node() merges a node into a target base device tree
> >> * node pointed.
> >> *
> >> * This is part of the final step in the device tree overlay
> >> * application process, when all the phandles have been adjusted and
> >> * resolved and you just have to merge overlay into the base device
> >> * tree.
> >> *
> >> * returns:
> >> * 0 on success
> >> * Negative error code on failure
> >> */
> >> static int overlay_apply_node(void *fdt, int target,
> >> void *fdto, int node)
> >> {
> >> int property;
> >> int subnode;
> >>
> >> fdt_for_each_property_offset(property, fdto, node) {
> >> const char *name;
> >> const void *prop;
> >> int prop_len;
> >> int ret;
> >>
> >> prop = fdt_getprop_by_offset(fdto, property, &name,
> >> &prop_len);
> >> if (prop_len == -FDT_ERR_NOTFOUND)
> >> return -FDT_ERR_INTERNAL;
> >> if (prop_len < 0)
> >> return prop_len;
> >>
> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> >> if (ret)
> >> return ret;
> >> }
> >>
> >> fdt_for_each_subnode(subnode, fdto, node) {
> >> const char *name = fdt_get_name(fdto, subnode, NULL);
> >> int nnode;
> >> int ret;
> >>
> >> nnode = fdt_add_subnode(fdt, target, name);
> >> if (nnode == -FDT_ERR_EXISTS) {
> >> nnode = fdt_subnode_offset(fdt, target, name);
> >> if (nnode == -FDT_ERR_NOTFOUND)
> >> return -FDT_ERR_INTERNAL;
> >> }
> >>
> >> if (nnode < 0)
> >> return nnode;
> >>
> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> >> if (ret)
> >> return ret;
> >> }
> >>
> >> return 0;
> >>
> >>
> >>
> >> }
> >>
> >>
> >> >
> >> > Regards
> >> > /Ilias
> >> > >
> >> > > To repeat, if we set things up correctly and agree on the bindings,
> >> > > devicetree can be the unifying configuration mechanism through the
> >> > > whole of firmware (except for very early bits) and into the OS. I
> feel
> >> > > this will set us up very well to deal with the complexity that is
> >> > > coming.
> >> > >
> >>
> >> Regards,
> >> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 14:50 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 14:50 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 17228 bytes --]
Hi Simon
Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon,
> >
> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Ilias,
> >>
> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> <ilias.apalodimas@linaro.org> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > A bit late to the party, sorry!
> >>
> >> (Did you remember the beer? I am replying to this but I don't think it
> >> is all that helpful for me to reply to a lot of things on this thread,
> >> since I would not be adding much to my cover letter and patches)
> >>
> >> >
> >> > [...]
> >> >
> >> > > >
> >> > > > I really want to see what the binary case looks like since we
> could then
> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> > > > then also do a rpi_arm32_defconfig too.
> >> > > >
> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> > > > functionally correct from the hardware/our caller.
> >> > > >
> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> > > > tree provided to us at run time by the caller.
> >> > >
> >> > > Firstly I should say that I find building firmware very messy and
> >> > > confusing these days. Lots of things to build and it's hard to find
> >> > > the instructions. It doesn't have to be that way, but if we carry on
> >> > > as we are, it will continue to be messy and in five years you will
> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> > > objective here is to simplify things, bringing some consistency to
> the
> >> > > different components. Binman was one effort there. I feel that
> putting
> >> > > at least the U-Boot house in order, in my role as devicetree
> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> > > 2011), is the next step.
> >> > >
> >> > > If we set things up correctly and agree on the bindings, devicetree
> >> > > can be the unifying configuration mechanism through the whole of
> >> > > firmware (except for very early bits) and into the OS, this will set
> >> > > us up very well to deal with the complexity that is coming.
> >> > >
> >> > > Anyway, here are the mental steps that I've gone through over the
> past
> >> > > two months:
> >> > >
> >> > > Step 1: At present, some people think U-Boot is not even allowed to
> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> > > devicetree standard, like the /chosen node but with less history. We
> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> > > of 'devicetree is a hardware description'. How do we get over that
> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> >> > > for its own purposes, as well as for booting the OS. I am not saying
> >> > > it always has to have those properties, but with existing features
> >> > > like verified boot, SPL as well as complex firmware images where
> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> > > So let's just assume that we need this everywhere, since we
> certainly
> >> > > need it in at least some places.
> >> > >
> >> > > (stop reading here if you disagree, because nothing below will make
> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> >> > > OF_CONTROL :-)
> >> >
> >> > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> >> > that to the DTs that are copied over from linux isn't imho. There are
> >> > various reasons for that. First of all syncing device trees is a
> huge pain
> >> > and that's probably one of the main reasons our DTs are out of sync
> for a
> >> > large number of boards.
> >> > The point is this was fine in 2011 were we had SPL only, but the
> reality
> >> > today is completely different. There's previous stage boot loaders
> (and
> >> > enough cases were vendors prefer those over SPL). If that bootloader
> needs
> >> > to use it's own device tree for whatever reason, imposing
> restrictions on
> >> > it wrt to the device tree it has to include, and require them to have
> >> > knowledge of U-Boot and it's internal config mechanism makes no sense
> not
> >> > to mention it doesn't scale at all.
> >>
> >> I think the solution here may be the binman image packer. It works
> >> from a description of the image (i.e. is data-driver) and can collect
> >> all the pieces together. The U-Boot properties (and the ones required
> >> by TF-A, etc.) can be added at package time.
> >>
> >> If you think about it, it doesn't matter what properties are in the DT
> >> that is put into the firmware image. TF-A, for example, is presumably
> >> reading a devicetree from flash, so what does it care if it has some
> >> U-Boot properties in it?
> >
> >
> > I am going to change my position in all mail threads I participate.
> > I was trying to make patches relevant in the future and conceptually
> clean. That may not be the most effective position: I should just care
> about Linaro and its members being able to implement SystemReady concepts.
> >
> >
> > If you mandate U-Boot has nodes in the device tree passed to the OS, we
> can put DT fragment in the nt_fw_config section of the fip and merge it at
> boot time. So there is a solution compatible with SystemReady.
> >
> > If you want to put fake, non future proof, DT sources in the dts for
> platforms that are organized to provide the authoritative DT to U-Boot at
> runtime, that's kind of your choice (hopefully representing the rest of
> U-Boot community). There will be quirk code in U-Boot to redo the
> adaptations on its non authoritative DT that the platform previous stage
> firmware does (already saw one in the past month); as Mark said there will
> be issues over time; and it will confuse people about the role of the DT.
> But I am fine with it as it does not impair Linaro and its members ability
> to implement SystemReady way of handling DT.
>
> OK thank you. It doesn't sound like you are very on-board though.
> Also, you mischaracterise my intent with in-tree devicetrees.
>
> I would be happy enough for now if you could accept that U-Boot has
> nodes/properties of its own in the devicetree. It has been a feature
> of U-Boot for 10 years now.
On SystemReady systems the DT passed to U-Boot for the OS will be assembled
from the board DT and a U-Boot fragment/overlay. The board DT is free from
any software/firmware aspects, just contains hardware description. The
U-Boot fragment/overlay can contain any nodes it wants. The location of the
bindings specification is essentially irrelevant: it could be devicetree.org,
U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making
their firmware will just put whatever is needed in this “dynamic config”
DT. On SystemReady platforms U-Boot will always be given a DT, like on the
RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a
platform may end-up failing compliance tests.
I think we need to document the above in U-Boot and refer to relevant
specifications. I’ll let Ilias propose something.
>
>
>
> Regards,
> Simon
>
>
> >
> >>
> >>
> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> >> so I think this can be dealt with.
> >>
> >> >
> >> > >
> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> >> > > have binman definitions, etc. So we need a way to overlay those
> things
> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
> >> > > easy. Just require every board to have an in-tree DT. It helps with
> >> > > discoverability and documentation, anyway. That is this series.
> >> > >
> >> >
> >> > Again, the board might decide for it's own reason to provide it's own
> DT.
> >> > IMHO U-Boot must be able to cope with that and asking DTs to be
> included in
> >> > U-Boot source is not the right way to do that, not to mention cases
> were
> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB
> from
> >> > it's flash).
> >>
> >> I think you are at step 2. See above for my response.
> >>
> >> >
> >> > > (I think most of us are at the beginning of step 2, unsure about it
> >> > > and worried about step 3)
> >> > >
> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> >> > > flow only, or boards that sometimes use a flow) which need the DT to
> >> > > come from a prior stage. How to handle that? IMO that is only going
> to
> >> > > grow as every man and his dog get into the write-a-bootloader
> >> > > business.
> >> >
> >> > And that's exactly why we have to come up with something that
> scales, without
> >> > having to add a bunch of unusable DTs in U-Boot.
> >>
> >> In what way does this not scale? How are the DTs unusable? If there is
> >> a standard binding, we should be fine.
> >>
> >> >
> >> > > We need a way to provide the U-Boot nodes/properties in a
> >> > > form that the prior stage can consume and integrate with its build
> >> > > system. Is TF-A the only thing being discussed here? If so, let's
> just
> >> > > do it. We have the u-boot.dtsi and we can use binman to put the
> image
> >> > > together, for example. Or we can get clever and create some sort of
> >> > > overlay dtb.
> >> > >
> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> >> > > then it will need to build it in and use two devicetrees, one
> internal
> >> > > and one from the prior stage....well that is not very efficient and
> it
> >> > > is going to be confusing for people to figure out what U-Boot is
> >> > > actually doing. But we actually already do that in a lot of cases
> >> > > where U-Boot passes a DT to the kernel which is different to the one
> >> > > it uses. So perhaps we have three devicetrees? OMG.
> >> >
> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
> >> > provides the internal one and inherits one 'generic'. Linux will be
> able to use
> >> > that. So the only case were you'll need 3 DTs is if the *vendor*
> breaks the
> >> > DT across kernel versions, In which case there's not much you can do
> to
> >> > begin with and that's already a case we have to deal with.
> >>
> >> Linux actually doesn't care if the U-Boot properties are in the tree,
> >> so long as we have proper bindings. My point here is we only need
> >> either:
> >>
> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> >> b. two devicetrees, one for use in firmware and one for passing to Linux
> >>
> >> We don't need to separate out the U-Boot properties into a second (or
> >> third) devicetree. There just isn't any point.
> >>
> >> >
> >> > > b) Well then
> >> > > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> >> > > can merge the two when it starts. Again that is not very efficient.
> It
> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to
> get
> >> > > its public key from there or to enable/disable the console), so
> >> > > unified firmware config is not possible. It will get very confusing,
> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> >> > > accepting step 3...please stop!
> >> > >
> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> >> > > whole cloth. What about that? Well, we are just going to have to
> deal
> >> > > with that. We can easily merge in the U-Boot nodes/properties and
> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> >> > > something similar.
> >> > >
> >> > > To my mind, that deals with both the build-time and run-time issues.
> >> > > We have a discoverable DT in U-Boot, which should be considered the
> >> > > source of truth for most boards. We can sync it with Linux
> >> > > automatically with the tooling that I hope Rob Herring will come up
> >> > > with. We can use an empty one where there really is no default,
> >> > > although I'd argue that is making perfect an enemy of the good.
> >> > >
> >> > > Step 5: If we get clever and want to remove them from the U-Boot
> tree
> >> > > and pick them up from somewhere else, we can do that with sufficient
> >> > > tooling. Perhaps we should set a timeline for that? A year? Two?
> Six?
> >> >
> >> > We can start slowly migrating boards and see how that works out.
> >> > We could either use 2 device trees as you proposed, or have u-boot
> merge
> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd
> prefer
> >> > if linux gets handed a clean device tree without the u-boot internals
> in
> >> > it, so I think 2 discrete DTs is cleaner overall.
> >>
> >> I know you would prefer that, but does it really matter in practice?
> >> What is the objection, actually?
> >>
> >> As I mentioned on the call, I think the prior stage should do any
> >> merging or fixing up. Trying to do that sort of thing in 'early' code
> >> in U-Boot (or any other program, including Linux) is such a pain. With
> >> U-Boot, for example, we don't even have any RAM available to do it
> >> with half the time and it would dramatically increase the amount of
> >> memory needed prior to relocation. It just isn't a very good idea to
> >> try to do this in early code. It is also completely unnecessary, once
> >> you get past the philosophical objections.
> >>
> >> If TF-A wants to be in the picture, let it deal with the implications
> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> >> of the size of U-Boot. It duplicates loads of things in there. No one
> >> will even *notice* an FDT merge function, which is actually only 70
> >> LOC:
> >>
> >> /**
> >> * overlay_apply_node - Merges a node into the base device tree
> >> * @fdt: Base Device Tree blob
> >> * @target: Node offset in the base device tree to apply the fragment to
> >> * @fdto: Device tree overlay blob
> >> * @node: Node offset in the overlay holding the changes to merge
> >> *
> >> * overlay_apply_node() merges a node into a target base device tree
> >> * node pointed.
> >> *
> >> * This is part of the final step in the device tree overlay
> >> * application process, when all the phandles have been adjusted and
> >> * resolved and you just have to merge overlay into the base device
> >> * tree.
> >> *
> >> * returns:
> >> * 0 on success
> >> * Negative error code on failure
> >> */
> >> static int overlay_apply_node(void *fdt, int target,
> >> void *fdto, int node)
> >> {
> >> int property;
> >> int subnode;
> >>
> >> fdt_for_each_property_offset(property, fdto, node) {
> >> const char *name;
> >> const void *prop;
> >> int prop_len;
> >> int ret;
> >>
> >> prop = fdt_getprop_by_offset(fdto, property, &name,
> >> &prop_len);
> >> if (prop_len == -FDT_ERR_NOTFOUND)
> >> return -FDT_ERR_INTERNAL;
> >> if (prop_len < 0)
> >> return prop_len;
> >>
> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> >> if (ret)
> >> return ret;
> >> }
> >>
> >> fdt_for_each_subnode(subnode, fdto, node) {
> >> const char *name = fdt_get_name(fdto, subnode, NULL);
> >> int nnode;
> >> int ret;
> >>
> >> nnode = fdt_add_subnode(fdt, target, name);
> >> if (nnode == -FDT_ERR_EXISTS) {
> >> nnode = fdt_subnode_offset(fdt, target, name);
> >> if (nnode == -FDT_ERR_NOTFOUND)
> >> return -FDT_ERR_INTERNAL;
> >> }
> >>
> >> if (nnode < 0)
> >> return nnode;
> >>
> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> >> if (ret)
> >> return ret;
> >> }
> >>
> >> return 0;
> >>
> >>
> >>
> >> }
> >>
> >>
> >> >
> >> > Regards
> >> > /Ilias
> >> > >
> >> > > To repeat, if we set things up correctly and agree on the bindings,
> >> > > devicetree can be the unifying configuration mechanism through the
> >> > > whole of firmware (except for very early bits) and into the OS. I
> feel
> >> > > this will set us up very well to deal with the complexity that is
> >> > > coming.
> >> > >
> >>
> >> Regards,
> >> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 22933 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 14:50 ` François Ozog
@ 2021-10-28 15:44 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 15:44 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi François,
On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi Ilias,
>> >>
>> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> <ilias.apalodimas@linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > A bit late to the party, sorry!
>> >>
>> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> since I would not be adding much to my cover letter and patches)
>> >>
>> >> >
>> >> > [...]
>> >> >
>> >> > > >
>> >> > > > I really want to see what the binary case looks like since we could then
>> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> >> > > > then also do a rpi_arm32_defconfig too.
>> >> > > >
>> >> > > > I want to see less device trees in U-Boot sources, if they can come
>> >> > > > functionally correct from the hardware/our caller.
>> >> > > >
>> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> >> > > > use the device tree from build time at run time, ignoring the device
>> >> > > > tree provided to us at run time by the caller.
>> >> > >
>> >> > > Firstly I should say that I find building firmware very messy and
>> >> > > confusing these days. Lots of things to build and it's hard to find
>> >> > > the instructions. It doesn't have to be that way, but if we carry on
>> >> > > as we are, it will continue to be messy and in five years you will
>> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> >> > > objective here is to simplify things, bringing some consistency to the
>> >> > > different components. Binman was one effort there. I feel that putting
>> >> > > at least the U-Boot house in order, in my role as devicetree
>> >> > > maintainer (and as author of devicetree support in U-Boot back in
>> >> > > 2011), is the next step.
>> >> > >
>> >> > > If we set things up correctly and agree on the bindings, devicetree
>> >> > > can be the unifying configuration mechanism through the whole of
>> >> > > firmware (except for very early bits) and into the OS, this will set
>> >> > > us up very well to deal with the complexity that is coming.
>> >> > >
>> >> > > Anyway, here are the mental steps that I've gone through over the past
>> >> > > two months:
>> >> > >
>> >> > > Step 1: At present, some people think U-Boot is not even allowed to
>> >> > > have its own nodes/properties in the DT. It is an abuse of the
>> >> > > devicetree standard, like the /chosen node but with less history. We
>> >> > > should sacrifice efficiency, expedience and expandability on the altar
>> >> > > of 'devicetree is a hardware description'. How do we get over that
>> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> >> > > for its own purposes, as well as for booting the OS. I am not saying
>> >> > > it always has to have those properties, but with existing features
>> >> > > like verified boot, SPL as well as complex firmware images where
>> >> > > U-Boot needs to be able to find things in the image, it is essential.
>> >> > > So let's just assume that we need this everywhere, since we certainly
>> >> > > need it in at least some places.
>> >> > >
>> >> > > (stop reading here if you disagree, because nothing below will make
>> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> >> > > OF_CONTROL :-)
>> >> >
>> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> >> > that to the DTs that are copied over from linux isn't imho. There are
>> >> > various reasons for that. First of all syncing device trees is a huge pain
>> >> > and that's probably one of the main reasons our DTs are out of sync for a
>> >> > large number of boards.
>> >> > The point is this was fine in 2011 were we had SPL only, but the reality
>> >> > today is completely different. There's previous stage boot loaders (and
>> >> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> >> > to use it's own device tree for whatever reason, imposing restrictions on
>> >> > it wrt to the device tree it has to include, and require them to have
>> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> >> > to mention it doesn't scale at all.
>> >>
>> >> I think the solution here may be the binman image packer. It works
>> >> from a description of the image (i.e. is data-driver) and can collect
>> >> all the pieces together. The U-Boot properties (and the ones required
>> >> by TF-A, etc.) can be added at package time.
>> >>
>> >> If you think about it, it doesn't matter what properties are in the DT
>> >> that is put into the firmware image. TF-A, for example, is presumably
>> >> reading a devicetree from flash, so what does it care if it has some
>> >> U-Boot properties in it?
>> >
>> >
>> > I am going to change my position in all mail threads I participate.
>> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>> >
>> >
>> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>> >
>> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
>>
>> OK thank you. It doesn't sound like you are very on-board though.
>> Also, you mischaracterise my intent with in-tree devicetrees.
>>
>> I would be happy enough for now if you could accept that U-Boot has
>> nodes/properties of its own in the devicetree. It has been a feature
>> of U-Boot for 10 years now.
>
> On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests.
> I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something.
Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
Are you talking here about what TF-A will do? I assume so, since you
mention FIP and I believe that is a TF-A invention.
Of course the image is all packaged together in fact, so binman could
presumably merge the DTs at build time, if desired.
Regards,
Simon
>> >>
>> >>
>> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> >> so I think this can be dealt with.
>> >>
>> >> >
>> >> > >
>> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> >> > > have binman definitions, etc. So we need a way to overlay those things
>> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> >> > > easy. Just require every board to have an in-tree DT. It helps with
>> >> > > discoverability and documentation, anyway. That is this series.
>> >> > >
>> >> >
>> >> > Again, the board might decide for it's own reason to provide it's own DT.
>> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> >> > U-Boot source is not the right way to do that, not to mention cases were
>> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> >> > it's flash).
>> >>
>> >> I think you are at step 2. See above for my response.
>> >>
>> >> >
>> >> > > (I think most of us are at the beginning of step 2, unsure about it
>> >> > > and worried about step 3)
>> >> > >
>> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> >> > > flow only, or boards that sometimes use a flow) which need the DT to
>> >> > > come from a prior stage. How to handle that? IMO that is only going to
>> >> > > grow as every man and his dog get into the write-a-bootloader
>> >> > > business.
>> >> >
>> >> > And that's exactly why we have to come up with something that scales, without
>> >> > having to add a bunch of unusable DTs in U-Boot.
>> >>
>> >> In what way does this not scale? How are the DTs unusable? If there is
>> >> a standard binding, we should be fine.
>> >>
>> >> >
>> >> > > We need a way to provide the U-Boot nodes/properties in a
>> >> > > form that the prior stage can consume and integrate with its build
>> >> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> >> > > together, for example. Or we can get clever and create some sort of
>> >> > > overlay dtb.
>> >> > >
>> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> >> > > then it will need to build it in and use two devicetrees, one internal
>> >> > > and one from the prior stage....well that is not very efficient and it
>> >> > > is going to be confusing for people to figure out what U-Boot is
>> >> > > actually doing. But we actually already do that in a lot of cases
>> >> > > where U-Boot passes a DT to the kernel which is different to the one
>> >> > > it uses. So perhaps we have three devicetrees? OMG.
>> >> >
>> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> >> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> >> > DT across kernel versions, In which case there's not much you can do to
>> >> > begin with and that's already a case we have to deal with.
>> >>
>> >> Linux actually doesn't care if the U-Boot properties are in the tree,
>> >> so long as we have proper bindings. My point here is we only need
>> >> either:
>> >>
>> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> >> b. two devicetrees, one for use in firmware and one for passing to Linux
>> >>
>> >> We don't need to separate out the U-Boot properties into a second (or
>> >> third) devicetree. There just isn't any point.
>> >>
>> >> >
>> >> > > b) Well then
>> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> >> > > can merge the two when it starts. Again that is not very efficient. It
>> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> >> > > its public key from there or to enable/disable the console), so
>> >> > > unified firmware config is not possible. It will get very confusing,
>> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> >> > > accepting step 3...please stop!
>> >> > >
>> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> >> > > whole cloth. What about that? Well, we are just going to have to deal
>> >> > > with that. We can easily merge in the U-Boot nodes/properties and
>> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> >> > > something similar.
>> >> > >
>> >> > > To my mind, that deals with both the build-time and run-time issues.
>> >> > > We have a discoverable DT in U-Boot, which should be considered the
>> >> > > source of truth for most boards. We can sync it with Linux
>> >> > > automatically with the tooling that I hope Rob Herring will come up
>> >> > > with. We can use an empty one where there really is no default,
>> >> > > although I'd argue that is making perfect an enemy of the good.
>> >> > >
>> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> >> > > and pick them up from somewhere else, we can do that with sufficient
>> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >> >
>> >> > We can start slowly migrating boards and see how that works out.
>> >> > We could either use 2 device trees as you proposed, or have u-boot merge
>> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> >> > if linux gets handed a clean device tree without the u-boot internals in
>> >> > it, so I think 2 discrete DTs is cleaner overall.
>> >>
>> >> I know you would prefer that, but does it really matter in practice?
>> >> What is the objection, actually?
>> >>
>> >> As I mentioned on the call, I think the prior stage should do any
>> >> merging or fixing up. Trying to do that sort of thing in 'early' code
>> >> in U-Boot (or any other program, including Linux) is such a pain. With
>> >> U-Boot, for example, we don't even have any RAM available to do it
>> >> with half the time and it would dramatically increase the amount of
>> >> memory needed prior to relocation. It just isn't a very good idea to
>> >> try to do this in early code. It is also completely unnecessary, once
>> >> you get past the philosophical objections.
>> >>
>> >> If TF-A wants to be in the picture, let it deal with the implications
>> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> >> of the size of U-Boot. It duplicates loads of things in there. No one
>> >> will even *notice* an FDT merge function, which is actually only 70
>> >> LOC:
>> >>
>> >> /**
>> >> * overlay_apply_node - Merges a node into the base device tree
>> >> * @fdt: Base Device Tree blob
>> >> * @target: Node offset in the base device tree to apply the fragment to
>> >> * @fdto: Device tree overlay blob
>> >> * @node: Node offset in the overlay holding the changes to merge
>> >> *
>> >> * overlay_apply_node() merges a node into a target base device tree
>> >> * node pointed.
>> >> *
>> >> * This is part of the final step in the device tree overlay
>> >> * application process, when all the phandles have been adjusted and
>> >> * resolved and you just have to merge overlay into the base device
>> >> * tree.
>> >> *
>> >> * returns:
>> >> * 0 on success
>> >> * Negative error code on failure
>> >> */
>> >> static int overlay_apply_node(void *fdt, int target,
>> >> void *fdto, int node)
>> >> {
>> >> int property;
>> >> int subnode;
>> >>
>> >> fdt_for_each_property_offset(property, fdto, node) {
>> >> const char *name;
>> >> const void *prop;
>> >> int prop_len;
>> >> int ret;
>> >>
>> >> prop = fdt_getprop_by_offset(fdto, property, &name,
>> >> &prop_len);
>> >> if (prop_len == -FDT_ERR_NOTFOUND)
>> >> return -FDT_ERR_INTERNAL;
>> >> if (prop_len < 0)
>> >> return prop_len;
>> >>
>> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> >> if (ret)
>> >> return ret;
>> >> }
>> >>
>> >> fdt_for_each_subnode(subnode, fdto, node) {
>> >> const char *name = fdt_get_name(fdto, subnode, NULL);
>> >> int nnode;
>> >> int ret;
>> >>
>> >> nnode = fdt_add_subnode(fdt, target, name);
>> >> if (nnode == -FDT_ERR_EXISTS) {
>> >> nnode = fdt_subnode_offset(fdt, target, name);
>> >> if (nnode == -FDT_ERR_NOTFOUND)
>> >> return -FDT_ERR_INTERNAL;
>> >> }
>> >>
>> >> if (nnode < 0)
>> >> return nnode;
>> >>
>> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> >> if (ret)
>> >> return ret;
>> >> }
>> >>
>> >> return 0;
>> >>
>> >>
>> >>
>> >> }
>> >>
>> >>
>> >> >
>> >> > Regards
>> >> > /Ilias
>> >> > >
>> >> > > To repeat, if we set things up correctly and agree on the bindings,
>> >> > > devicetree can be the unifying configuration mechanism through the
>> >> > > whole of firmware (except for very early bits) and into the OS. I feel
>> >> > > this will set us up very well to deal with the complexity that is
>> >> > > coming.
>> >> > >
>> >>
>> >> Regards,
>> >> Simon
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 15:44 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-28 15:44 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi François,
On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon,
>> >
>> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi Ilias,
>> >>
>> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> <ilias.apalodimas@linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > A bit late to the party, sorry!
>> >>
>> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> since I would not be adding much to my cover letter and patches)
>> >>
>> >> >
>> >> > [...]
>> >> >
>> >> > > >
>> >> > > > I really want to see what the binary case looks like since we could then
>> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> >> > > > then also do a rpi_arm32_defconfig too.
>> >> > > >
>> >> > > > I want to see less device trees in U-Boot sources, if they can come
>> >> > > > functionally correct from the hardware/our caller.
>> >> > > >
>> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> >> > > > use the device tree from build time at run time, ignoring the device
>> >> > > > tree provided to us at run time by the caller.
>> >> > >
>> >> > > Firstly I should say that I find building firmware very messy and
>> >> > > confusing these days. Lots of things to build and it's hard to find
>> >> > > the instructions. It doesn't have to be that way, but if we carry on
>> >> > > as we are, it will continue to be messy and in five years you will
>> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> >> > > objective here is to simplify things, bringing some consistency to the
>> >> > > different components. Binman was one effort there. I feel that putting
>> >> > > at least the U-Boot house in order, in my role as devicetree
>> >> > > maintainer (and as author of devicetree support in U-Boot back in
>> >> > > 2011), is the next step.
>> >> > >
>> >> > > If we set things up correctly and agree on the bindings, devicetree
>> >> > > can be the unifying configuration mechanism through the whole of
>> >> > > firmware (except for very early bits) and into the OS, this will set
>> >> > > us up very well to deal with the complexity that is coming.
>> >> > >
>> >> > > Anyway, here are the mental steps that I've gone through over the past
>> >> > > two months:
>> >> > >
>> >> > > Step 1: At present, some people think U-Boot is not even allowed to
>> >> > > have its own nodes/properties in the DT. It is an abuse of the
>> >> > > devicetree standard, like the /chosen node but with less history. We
>> >> > > should sacrifice efficiency, expedience and expandability on the altar
>> >> > > of 'devicetree is a hardware description'. How do we get over that
>> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> >> > > for its own purposes, as well as for booting the OS. I am not saying
>> >> > > it always has to have those properties, but with existing features
>> >> > > like verified boot, SPL as well as complex firmware images where
>> >> > > U-Boot needs to be able to find things in the image, it is essential.
>> >> > > So let's just assume that we need this everywhere, since we certainly
>> >> > > need it in at least some places.
>> >> > >
>> >> > > (stop reading here if you disagree, because nothing below will make
>> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> >> > > OF_CONTROL :-)
>> >> >
>> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> >> > that to the DTs that are copied over from linux isn't imho. There are
>> >> > various reasons for that. First of all syncing device trees is a huge pain
>> >> > and that's probably one of the main reasons our DTs are out of sync for a
>> >> > large number of boards.
>> >> > The point is this was fine in 2011 were we had SPL only, but the reality
>> >> > today is completely different. There's previous stage boot loaders (and
>> >> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> >> > to use it's own device tree for whatever reason, imposing restrictions on
>> >> > it wrt to the device tree it has to include, and require them to have
>> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> >> > to mention it doesn't scale at all.
>> >>
>> >> I think the solution here may be the binman image packer. It works
>> >> from a description of the image (i.e. is data-driver) and can collect
>> >> all the pieces together. The U-Boot properties (and the ones required
>> >> by TF-A, etc.) can be added at package time.
>> >>
>> >> If you think about it, it doesn't matter what properties are in the DT
>> >> that is put into the firmware image. TF-A, for example, is presumably
>> >> reading a devicetree from flash, so what does it care if it has some
>> >> U-Boot properties in it?
>> >
>> >
>> > I am going to change my position in all mail threads I participate.
>> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>> >
>> >
>> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>> >
>> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
>>
>> OK thank you. It doesn't sound like you are very on-board though.
>> Also, you mischaracterise my intent with in-tree devicetrees.
>>
>> I would be happy enough for now if you could accept that U-Boot has
>> nodes/properties of its own in the devicetree. It has been a feature
>> of U-Boot for 10 years now.
>
> On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests.
> I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something.
Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
Are you talking here about what TF-A will do? I assume so, since you
mention FIP and I believe that is a TF-A invention.
Of course the image is all packaged together in fact, so binman could
presumably merge the DTs at build time, if desired.
Regards,
Simon
>> >>
>> >>
>> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> >> so I think this can be dealt with.
>> >>
>> >> >
>> >> > >
>> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> >> > > have binman definitions, etc. So we need a way to overlay those things
>> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> >> > > easy. Just require every board to have an in-tree DT. It helps with
>> >> > > discoverability and documentation, anyway. That is this series.
>> >> > >
>> >> >
>> >> > Again, the board might decide for it's own reason to provide it's own DT.
>> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> >> > U-Boot source is not the right way to do that, not to mention cases were
>> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> >> > it's flash).
>> >>
>> >> I think you are at step 2. See above for my response.
>> >>
>> >> >
>> >> > > (I think most of us are at the beginning of step 2, unsure about it
>> >> > > and worried about step 3)
>> >> > >
>> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> >> > > flow only, or boards that sometimes use a flow) which need the DT to
>> >> > > come from a prior stage. How to handle that? IMO that is only going to
>> >> > > grow as every man and his dog get into the write-a-bootloader
>> >> > > business.
>> >> >
>> >> > And that's exactly why we have to come up with something that scales, without
>> >> > having to add a bunch of unusable DTs in U-Boot.
>> >>
>> >> In what way does this not scale? How are the DTs unusable? If there is
>> >> a standard binding, we should be fine.
>> >>
>> >> >
>> >> > > We need a way to provide the U-Boot nodes/properties in a
>> >> > > form that the prior stage can consume and integrate with its build
>> >> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> >> > > together, for example. Or we can get clever and create some sort of
>> >> > > overlay dtb.
>> >> > >
>> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> >> > > then it will need to build it in and use two devicetrees, one internal
>> >> > > and one from the prior stage....well that is not very efficient and it
>> >> > > is going to be confusing for people to figure out what U-Boot is
>> >> > > actually doing. But we actually already do that in a lot of cases
>> >> > > where U-Boot passes a DT to the kernel which is different to the one
>> >> > > it uses. So perhaps we have three devicetrees? OMG.
>> >> >
>> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> >> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> >> > DT across kernel versions, In which case there's not much you can do to
>> >> > begin with and that's already a case we have to deal with.
>> >>
>> >> Linux actually doesn't care if the U-Boot properties are in the tree,
>> >> so long as we have proper bindings. My point here is we only need
>> >> either:
>> >>
>> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> >> b. two devicetrees, one for use in firmware and one for passing to Linux
>> >>
>> >> We don't need to separate out the U-Boot properties into a second (or
>> >> third) devicetree. There just isn't any point.
>> >>
>> >> >
>> >> > > b) Well then
>> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> >> > > can merge the two when it starts. Again that is not very efficient. It
>> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> >> > > its public key from there or to enable/disable the console), so
>> >> > > unified firmware config is not possible. It will get very confusing,
>> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> >> > > accepting step 3...please stop!
>> >> > >
>> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> >> > > whole cloth. What about that? Well, we are just going to have to deal
>> >> > > with that. We can easily merge in the U-Boot nodes/properties and
>> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> >> > > something similar.
>> >> > >
>> >> > > To my mind, that deals with both the build-time and run-time issues.
>> >> > > We have a discoverable DT in U-Boot, which should be considered the
>> >> > > source of truth for most boards. We can sync it with Linux
>> >> > > automatically with the tooling that I hope Rob Herring will come up
>> >> > > with. We can use an empty one where there really is no default,
>> >> > > although I'd argue that is making perfect an enemy of the good.
>> >> > >
>> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> >> > > and pick them up from somewhere else, we can do that with sufficient
>> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >> >
>> >> > We can start slowly migrating boards and see how that works out.
>> >> > We could either use 2 device trees as you proposed, or have u-boot merge
>> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> >> > if linux gets handed a clean device tree without the u-boot internals in
>> >> > it, so I think 2 discrete DTs is cleaner overall.
>> >>
>> >> I know you would prefer that, but does it really matter in practice?
>> >> What is the objection, actually?
>> >>
>> >> As I mentioned on the call, I think the prior stage should do any
>> >> merging or fixing up. Trying to do that sort of thing in 'early' code
>> >> in U-Boot (or any other program, including Linux) is such a pain. With
>> >> U-Boot, for example, we don't even have any RAM available to do it
>> >> with half the time and it would dramatically increase the amount of
>> >> memory needed prior to relocation. It just isn't a very good idea to
>> >> try to do this in early code. It is also completely unnecessary, once
>> >> you get past the philosophical objections.
>> >>
>> >> If TF-A wants to be in the picture, let it deal with the implications
>> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> >> of the size of U-Boot. It duplicates loads of things in there. No one
>> >> will even *notice* an FDT merge function, which is actually only 70
>> >> LOC:
>> >>
>> >> /**
>> >> * overlay_apply_node - Merges a node into the base device tree
>> >> * @fdt: Base Device Tree blob
>> >> * @target: Node offset in the base device tree to apply the fragment to
>> >> * @fdto: Device tree overlay blob
>> >> * @node: Node offset in the overlay holding the changes to merge
>> >> *
>> >> * overlay_apply_node() merges a node into a target base device tree
>> >> * node pointed.
>> >> *
>> >> * This is part of the final step in the device tree overlay
>> >> * application process, when all the phandles have been adjusted and
>> >> * resolved and you just have to merge overlay into the base device
>> >> * tree.
>> >> *
>> >> * returns:
>> >> * 0 on success
>> >> * Negative error code on failure
>> >> */
>> >> static int overlay_apply_node(void *fdt, int target,
>> >> void *fdto, int node)
>> >> {
>> >> int property;
>> >> int subnode;
>> >>
>> >> fdt_for_each_property_offset(property, fdto, node) {
>> >> const char *name;
>> >> const void *prop;
>> >> int prop_len;
>> >> int ret;
>> >>
>> >> prop = fdt_getprop_by_offset(fdto, property, &name,
>> >> &prop_len);
>> >> if (prop_len == -FDT_ERR_NOTFOUND)
>> >> return -FDT_ERR_INTERNAL;
>> >> if (prop_len < 0)
>> >> return prop_len;
>> >>
>> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> >> if (ret)
>> >> return ret;
>> >> }
>> >>
>> >> fdt_for_each_subnode(subnode, fdto, node) {
>> >> const char *name = fdt_get_name(fdto, subnode, NULL);
>> >> int nnode;
>> >> int ret;
>> >>
>> >> nnode = fdt_add_subnode(fdt, target, name);
>> >> if (nnode == -FDT_ERR_EXISTS) {
>> >> nnode = fdt_subnode_offset(fdt, target, name);
>> >> if (nnode == -FDT_ERR_NOTFOUND)
>> >> return -FDT_ERR_INTERNAL;
>> >> }
>> >>
>> >> if (nnode < 0)
>> >> return nnode;
>> >>
>> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> >> if (ret)
>> >> return ret;
>> >> }
>> >>
>> >> return 0;
>> >>
>> >>
>> >>
>> >> }
>> >>
>> >>
>> >> >
>> >> > Regards
>> >> > /Ilias
>> >> > >
>> >> > > To repeat, if we set things up correctly and agree on the bindings,
>> >> > > devicetree can be the unifying configuration mechanism through the
>> >> > > whole of firmware (except for very early bits) and into the OS. I feel
>> >> > > this will set us up very well to deal with the complexity that is
>> >> > > coming.
>> >> > >
>> >>
>> >> Regards,
>> >> Simon
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 15:44 ` Simon Glass
@ 2021-10-28 16:25 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 16:25 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 19475 bytes --]
Hi Simon
Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi François,
> >>
> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org>
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit
> :
> >> >>
> >> >> Hi Ilias,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> >> <ilias.apalodimas@linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > A bit late to the party, sorry!
> >> >>
> >> >> (Did you remember the beer? I am replying to this but I don't think
> it
> >> >> is all that helpful for me to reply to a lot of things on this
> thread,
> >> >> since I would not be adding much to my cover letter and patches)
> >> >>
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > > >
> >> >> > > > I really want to see what the binary case looks like since we
> could then
> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> >> > > > then also do a rpi_arm32_defconfig too.
> >> >> > > >
> >> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> >> > > > functionally correct from the hardware/our caller.
> >> >> > > >
> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> >> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> >> > > > tree provided to us at run time by the caller.
> >> >> > >
> >> >> > > Firstly I should say that I find building firmware very messy and
> >> >> > > confusing these days. Lots of things to build and it's hard to
> find
> >> >> > > the instructions. It doesn't have to be that way, but if we
> carry on
> >> >> > > as we are, it will continue to be messy and in five years you
> will
> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> >> > > objective here is to simplify things, bringing some consistency
> to the
> >> >> > > different components. Binman was one effort there. I feel that
> putting
> >> >> > > at least the U-Boot house in order, in my role as devicetree
> >> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> >> > > 2011), is the next step.
> >> >> > >
> >> >> > > If we set things up correctly and agree on the bindings,
> devicetree
> >> >> > > can be the unifying configuration mechanism through the whole of
> >> >> > > firmware (except for very early bits) and into the OS, this will
> set
> >> >> > > us up very well to deal with the complexity that is coming.
> >> >> > >
> >> >> > > Anyway, here are the mental steps that I've gone through over
> the past
> >> >> > > two months:
> >> >> > >
> >> >> > > Step 1: At present, some people think U-Boot is not even allowed
> to
> >> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> >> > > devicetree standard, like the /chosen node but with less
> history. We
> >> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> >> > > of 'devicetree is a hardware description'. How do we get over
> that
> >> >> > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> >> >> > > for its own purposes, as well as for booting the OS. I am not
> saying
> >> >> > > it always has to have those properties, but with existing
> features
> >> >> > > like verified boot, SPL as well as complex firmware images where
> >> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> >> > > So let's just assume that we need this everywhere, since we
> certainly
> >> >> > > need it in at least some places.
> >> >> > >
> >> >> > > (stop reading here if you disagree, because nothing below will
> make
> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> >> >> > > OF_CONTROL :-)
> >> >> >
> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> >> >> > that to the DTs that are copied over from linux isn't imho. There
> are
> >> >> > various reasons for that. First of all syncing device trees is a
> huge pain
> >> >> > and that's probably one of the main reasons our DTs are out of
> sync for a
> >> >> > large number of boards.
> >> >> > The point is this was fine in 2011 were we had SPL only, but the
> reality
> >> >> > today is completely different. There's previous stage boot
> loaders (and
> >> >> > enough cases were vendors prefer those over SPL). If that
> bootloader needs
> >> >> > to use it's own device tree for whatever reason, imposing
> restrictions on
> >> >> > it wrt to the device tree it has to include, and require them to
> have
> >> >> > knowledge of U-Boot and it's internal config mechanism makes no
> sense not
> >> >> > to mention it doesn't scale at all.
> >> >>
> >> >> I think the solution here may be the binman image packer. It works
> >> >> from a description of the image (i.e. is data-driver) and can collect
> >> >> all the pieces together. The U-Boot properties (and the ones required
> >> >> by TF-A, etc.) can be added at package time.
> >> >>
> >> >> If you think about it, it doesn't matter what properties are in the
> DT
> >> >> that is put into the firmware image. TF-A, for example, is presumably
> >> >> reading a devicetree from flash, so what does it care if it has some
> >> >> U-Boot properties in it?
> >> >
> >> >
> >> > I am going to change my position in all mail threads I participate.
> >> > I was trying to make patches relevant in the future and conceptually
> clean. That may not be the most effective position: I should just care
> about Linaro and its members being able to implement SystemReady concepts.
> >> >
> >> >
> >> > If you mandate U-Boot has nodes in the device tree passed to the OS,
> we can put DT fragment in the nt_fw_config section of the fip and merge it
> at boot time. So there is a solution compatible with SystemReady.
> >> >
> >> > If you want to put fake, non future proof, DT sources in the dts for
> platforms that are organized to provide the authoritative DT to U-Boot at
> runtime, that's kind of your choice (hopefully representing the rest of
> U-Boot community). There will be quirk code in U-Boot to redo the
> adaptations on its non authoritative DT that the platform previous stage
> firmware does (already saw one in the past month); as Mark said there will
> be issues over time; and it will confuse people about the role of the DT.
> But I am fine with it as it does not impair Linaro and its members ability
> to implement SystemReady way of handling DT.
> >>
> >> OK thank you. It doesn't sound like you are very on-board though.
> >> Also, you mischaracterise my intent with in-tree devicetrees.
> >>
> >> I would be happy enough for now if you could accept that U-Boot has
> >> nodes/properties of its own in the devicetree. It has been a feature
> >> of U-Boot for 10 years now.
> >
> > On SystemReady systems the DT passed to U-Boot for the OS will be
> assembled from the board DT and a U-Boot fragment/overlay. The board DT is
> free from any software/firmware aspects, just contains hardware
> description. The U-Boot fragment/overlay can contain any nodes it wants.
> The location of the bindings specification is essentially irrelevant: it
> could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be
> stored in the FIP. OEMs making their firmware will just put whatever is
> needed in this “dynamic config” DT. On SystemReady platforms U-Boot will
> always be given a DT, like on the RPI4. U-Boot will be able to ignore it
> obviously. That said, doing so, a platform may end-up failing compliance
> tests.
> > I think we need to document the above in U-Boot and refer to relevant
> specifications. I’ll let Ilias propose something.
>
> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
>
> Are you talking here about what TF-A will do? I assume so, since you
> mention FIP and I believe that is a TF-A invention.
>
Yes
>
> Of course the image is all packaged together in fact, so binman could
> presumably merge the DTs at build time, if desired.
Practically I don’t think so. The passed device tree will contain all
authoritative information such as discovered normal memory (excluded the
secure memory ranges), architectural nodes such as PSCI and other nodes
coming from TEE-OS or secure partitions such as SCMI interface or
firmwareTPM.
If you combine the two static parts at build time you will have to extract
the runtime pieces from the DT passed to U-Boot.
>
>
> Regards,
> Simon
>
> >> >>
> >> >>
> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> >> >> so I think this can be dealt with.
> >> >>
> >> >> >
> >> >> > >
> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they
> get
> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi
> file"), we
> >> >> > > have binman definitions, etc. So we need a way to overlay those
> things
> >> >> > > into the DT. We already support this for in-tree DTs, so IMO
> this is
> >> >> > > easy. Just require every board to have an in-tree DT. It helps
> with
> >> >> > > discoverability and documentation, anyway. That is this series.
> >> >> > >
> >> >> >
> >> >> > Again, the board might decide for it's own reason to provide it's
> own DT.
> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be
> included in
> >> >> > U-Boot source is not the right way to do that, not to mention
> cases were
> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the
> DTB from
> >> >> > it's flash).
> >> >>
> >> >> I think you are at step 2. See above for my response.
> >> >>
> >> >> >
> >> >> > > (I think most of us are at the beginning of step 2, unsure about
> it
> >> >> > > and worried about step 3)
> >> >> > >
> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a
> particular
> >> >> > > flow only, or boards that sometimes use a flow) which need the
> DT to
> >> >> > > come from a prior stage. How to handle that? IMO that is only
> going to
> >> >> > > grow as every man and his dog get into the write-a-bootloader
> >> >> > > business.
> >> >> >
> >> >> > And that's exactly why we have to come up with something that
> scales, without
> >> >> > having to add a bunch of unusable DTs in U-Boot.
> >> >>
> >> >> In what way does this not scale? How are the DTs unusable? If there
> is
> >> >> a standard binding, we should be fine.
> >> >>
> >> >> >
> >> >> > > We need a way to provide the U-Boot nodes/properties in a
> >> >> > > form that the prior stage can consume and integrate with its
> build
> >> >> > > system. Is TF-A the only thing being discussed here? If so,
> let's just
> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the
> image
> >> >> > > together, for example. Or we can get clever and create some sort
> of
> >> >> > > overlay dtb.
> >> >> > >
> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this
> stuff
> >> >> > > then it will need to build it in and use two devicetrees, one
> internal
> >> >> > > and one from the prior stage....well that is not very efficient
> and it
> >> >> > > is going to be confusing for people to figure out what U-Boot is
> >> >> > > actually doing. But we actually already do that in a lot of cases
> >> >> > > where U-Boot passes a DT to the kernel which is different to the
> one
> >> >> > > it uses. So perhaps we have three devicetrees? OMG.
> >> >> >
> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
> >> >> > provides the internal one and inherits one 'generic'. Linux will
> be able to use
> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor*
> breaks the
> >> >> > DT across kernel versions, In which case there's not much you can
> do to
> >> >> > begin with and that's already a case we have to deal with.
> >> >>
> >> >> Linux actually doesn't care if the U-Boot properties are in the tree,
> >> >> so long as we have proper bindings. My point here is we only need
> >> >> either:
> >> >>
> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> >> >> b. two devicetrees, one for use in firmware and one for passing to
> Linux
> >> >>
> >> >> We don't need to separate out the U-Boot properties into a second (or
> >> >> third) devicetree. There just isn't any point.
> >> >>
> >> >> >
> >> >> > > b) Well then
> >> >> > > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> >> >> > > can merge the two when it starts. Again that is not very
> efficient. It
> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g.
> to get
> >> >> > > its public key from there or to enable/disable the console), so
> >> >> > > unified firmware config is not possible. It will get very
> confusing,
> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> >> >> > > accepting step 3...please stop!
> >> >> > >
> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up
> out of
> >> >> > > whole cloth. What about that? Well, we are just going to have to
> deal
> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and
> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> >> >> > > something similar.
> >> >> > >
> >> >> > > To my mind, that deals with both the build-time and run-time
> issues.
> >> >> > > We have a discoverable DT in U-Boot, which should be considered
> the
> >> >> > > source of truth for most boards. We can sync it with Linux
> >> >> > > automatically with the tooling that I hope Rob Herring will come
> up
> >> >> > > with. We can use an empty one where there really is no default,
> >> >> > > although I'd argue that is making perfect an enemy of the good.
> >> >> > >
> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot
> tree
> >> >> > > and pick them up from somewhere else, we can do that with
> sufficient
> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two?
> Six?
> >> >> >
> >> >> > We can start slowly migrating boards and see how that works out.
> >> >> > We could either use 2 device trees as you proposed, or have u-boot
> merge
> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH
> I'd prefer
> >> >> > if linux gets handed a clean device tree without the u-boot
> internals in
> >> >> > it, so I think 2 discrete DTs is cleaner overall.
> >> >>
> >> >> I know you would prefer that, but does it really matter in practice?
> >> >> What is the objection, actually?
> >> >>
> >> >> As I mentioned on the call, I think the prior stage should do any
> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code
> >> >> in U-Boot (or any other program, including Linux) is such a pain.
> With
> >> >> U-Boot, for example, we don't even have any RAM available to do it
> >> >> with half the time and it would dramatically increase the amount of
> >> >> memory needed prior to relocation. It just isn't a very good idea to
> >> >> try to do this in early code. It is also completely unnecessary, once
> >> >> you get past the philosophical objections.
> >> >>
> >> >> If TF-A wants to be in the picture, let it deal with the implications
> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot
> how
> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> >> >> of the size of U-Boot. It duplicates loads of things in there. No one
> >> >> will even *notice* an FDT merge function, which is actually only 70
> >> >> LOC:
> >> >>
> >> >> /**
> >> >> * overlay_apply_node - Merges a node into the base device tree
> >> >> * @fdt: Base Device Tree blob
> >> >> * @target: Node offset in the base device tree to apply the
> fragment to
> >> >> * @fdto: Device tree overlay blob
> >> >> * @node: Node offset in the overlay holding the changes to merge
> >> >> *
> >> >> * overlay_apply_node() merges a node into a target base device tree
> >> >> * node pointed.
> >> >> *
> >> >> * This is part of the final step in the device tree overlay
> >> >> * application process, when all the phandles have been adjusted and
> >> >> * resolved and you just have to merge overlay into the base device
> >> >> * tree.
> >> >> *
> >> >> * returns:
> >> >> * 0 on success
> >> >> * Negative error code on failure
> >> >> */
> >> >> static int overlay_apply_node(void *fdt, int target,
> >> >> void *fdto, int node)
> >> >> {
> >> >> int property;
> >> >> int subnode;
> >> >>
> >> >> fdt_for_each_property_offset(property, fdto, node) {
> >> >> const char *name;
> >> >> const void *prop;
> >> >> int prop_len;
> >> >> int ret;
> >> >>
> >> >> prop = fdt_getprop_by_offset(fdto, property, &name,
> >> >> &prop_len);
> >> >> if (prop_len == -FDT_ERR_NOTFOUND)
> >> >> return -FDT_ERR_INTERNAL;
> >> >> if (prop_len < 0)
> >> >> return prop_len;
> >> >>
> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> >> >> if (ret)
> >> >> return ret;
> >> >> }
> >> >>
> >> >> fdt_for_each_subnode(subnode, fdto, node) {
> >> >> const char *name = fdt_get_name(fdto, subnode, NULL);
> >> >> int nnode;
> >> >> int ret;
> >> >>
> >> >> nnode = fdt_add_subnode(fdt, target, name);
> >> >> if (nnode == -FDT_ERR_EXISTS) {
> >> >> nnode = fdt_subnode_offset(fdt, target, name);
> >> >> if (nnode == -FDT_ERR_NOTFOUND)
> >> >> return -FDT_ERR_INTERNAL;
> >> >> }
> >> >>
> >> >> if (nnode < 0)
> >> >> return nnode;
> >> >>
> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> >> >> if (ret)
> >> >> return ret;
> >> >> }
> >> >>
> >> >> return 0;
> >> >>
> >> >>
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >> >
> >> >> > Regards
> >> >> > /Ilias
> >> >> > >
> >> >> > > To repeat, if we set things up correctly and agree on the
> bindings,
> >> >> > > devicetree can be the unifying configuration mechanism through
> the
> >> >> > > whole of firmware (except for very early bits) and into the OS.
> I feel
> >> >> > > this will set us up very well to deal with the complexity that is
> >> >> > > coming.
> >> >> > >
> >> >>
> >> >> Regards,
> >> >> Simon
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 27251 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 16:25 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-28 16:25 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi Simon
Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi François,
> >>
> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org>
> wrote:
> >> >
> >> > Hi Simon,
> >> >
> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit
> :
> >> >>
> >> >> Hi Ilias,
> >> >>
> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> >> >> <ilias.apalodimas@linaro.org> wrote:
> >> >> >
> >> >> > Hi Simon,
> >> >> >
> >> >> > A bit late to the party, sorry!
> >> >>
> >> >> (Did you remember the beer? I am replying to this but I don't think
> it
> >> >> is all that helpful for me to reply to a lot of things on this
> thread,
> >> >> since I would not be adding much to my cover letter and patches)
> >> >>
> >> >> >
> >> >> > [...]
> >> >> >
> >> >> > > >
> >> >> > > > I really want to see what the binary case looks like since we
> could then
> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> >> >> > > > then also do a rpi_arm32_defconfig too.
> >> >> > > >
> >> >> > > > I want to see less device trees in U-Boot sources, if they can
> come
> >> >> > > > functionally correct from the hardware/our caller.
> >> >> > > >
> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> >> >> > > > use the device tree from build time at run time, ignoring the
> device
> >> >> > > > tree provided to us at run time by the caller.
> >> >> > >
> >> >> > > Firstly I should say that I find building firmware very messy and
> >> >> > > confusing these days. Lots of things to build and it's hard to
> find
> >> >> > > the instructions. It doesn't have to be that way, but if we
> carry on
> >> >> > > as we are, it will continue to be messy and in five years you
> will
> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
> >> >> > > objective here is to simplify things, bringing some consistency
> to the
> >> >> > > different components. Binman was one effort there. I feel that
> putting
> >> >> > > at least the U-Boot house in order, in my role as devicetree
> >> >> > > maintainer (and as author of devicetree support in U-Boot back in
> >> >> > > 2011), is the next step.
> >> >> > >
> >> >> > > If we set things up correctly and agree on the bindings,
> devicetree
> >> >> > > can be the unifying configuration mechanism through the whole of
> >> >> > > firmware (except for very early bits) and into the OS, this will
> set
> >> >> > > us up very well to deal with the complexity that is coming.
> >> >> > >
> >> >> > > Anyway, here are the mental steps that I've gone through over
> the past
> >> >> > > two months:
> >> >> > >
> >> >> > > Step 1: At present, some people think U-Boot is not even allowed
> to
> >> >> > > have its own nodes/properties in the DT. It is an abuse of the
> >> >> > > devicetree standard, like the /chosen node but with less
> history. We
> >> >> > > should sacrifice efficiency, expedience and expandability on the
> altar
> >> >> > > of 'devicetree is a hardware description'. How do we get over
> that
> >> >> > > one? Wel, I just think we need to accept that U-Boot uses
> devicetree
> >> >> > > for its own purposes, as well as for booting the OS. I am not
> saying
> >> >> > > it always has to have those properties, but with existing
> features
> >> >> > > like verified boot, SPL as well as complex firmware images where
> >> >> > > U-Boot needs to be able to find things in the image, it is
> essential.
> >> >> > > So let's just assume that we need this everywhere, since we
> certainly
> >> >> > > need it in at least some places.
> >> >> > >
> >> >> > > (stop reading here if you disagree, because nothing below will
> make
> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> >> >> > > OF_CONTROL :-)
> >> >> >
> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine.
> Adding
> >> >> > that to the DTs that are copied over from linux isn't imho. There
> are
> >> >> > various reasons for that. First of all syncing device trees is a
> huge pain
> >> >> > and that's probably one of the main reasons our DTs are out of
> sync for a
> >> >> > large number of boards.
> >> >> > The point is this was fine in 2011 were we had SPL only, but the
> reality
> >> >> > today is completely different. There's previous stage boot
> loaders (and
> >> >> > enough cases were vendors prefer those over SPL). If that
> bootloader needs
> >> >> > to use it's own device tree for whatever reason, imposing
> restrictions on
> >> >> > it wrt to the device tree it has to include, and require them to
> have
> >> >> > knowledge of U-Boot and it's internal config mechanism makes no
> sense not
> >> >> > to mention it doesn't scale at all.
> >> >>
> >> >> I think the solution here may be the binman image packer. It works
> >> >> from a description of the image (i.e. is data-driver) and can collect
> >> >> all the pieces together. The U-Boot properties (and the ones required
> >> >> by TF-A, etc.) can be added at package time.
> >> >>
> >> >> If you think about it, it doesn't matter what properties are in the
> DT
> >> >> that is put into the firmware image. TF-A, for example, is presumably
> >> >> reading a devicetree from flash, so what does it care if it has some
> >> >> U-Boot properties in it?
> >> >
> >> >
> >> > I am going to change my position in all mail threads I participate.
> >> > I was trying to make patches relevant in the future and conceptually
> clean. That may not be the most effective position: I should just care
> about Linaro and its members being able to implement SystemReady concepts.
> >> >
> >> >
> >> > If you mandate U-Boot has nodes in the device tree passed to the OS,
> we can put DT fragment in the nt_fw_config section of the fip and merge it
> at boot time. So there is a solution compatible with SystemReady.
> >> >
> >> > If you want to put fake, non future proof, DT sources in the dts for
> platforms that are organized to provide the authoritative DT to U-Boot at
> runtime, that's kind of your choice (hopefully representing the rest of
> U-Boot community). There will be quirk code in U-Boot to redo the
> adaptations on its non authoritative DT that the platform previous stage
> firmware does (already saw one in the past month); as Mark said there will
> be issues over time; and it will confuse people about the role of the DT.
> But I am fine with it as it does not impair Linaro and its members ability
> to implement SystemReady way of handling DT.
> >>
> >> OK thank you. It doesn't sound like you are very on-board though.
> >> Also, you mischaracterise my intent with in-tree devicetrees.
> >>
> >> I would be happy enough for now if you could accept that U-Boot has
> >> nodes/properties of its own in the devicetree. It has been a feature
> >> of U-Boot for 10 years now.
> >
> > On SystemReady systems the DT passed to U-Boot for the OS will be
> assembled from the board DT and a U-Boot fragment/overlay. The board DT is
> free from any software/firmware aspects, just contains hardware
> description. The U-Boot fragment/overlay can contain any nodes it wants.
> The location of the bindings specification is essentially irrelevant: it
> could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be
> stored in the FIP. OEMs making their firmware will just put whatever is
> needed in this “dynamic config” DT. On SystemReady platforms U-Boot will
> always be given a DT, like on the RPI4. U-Boot will be able to ignore it
> obviously. That said, doing so, a platform may end-up failing compliance
> tests.
> > I think we need to document the above in U-Boot and refer to relevant
> specifications. I’ll let Ilias propose something.
>
> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
>
> Are you talking here about what TF-A will do? I assume so, since you
> mention FIP and I believe that is a TF-A invention.
>
Yes
>
> Of course the image is all packaged together in fact, so binman could
> presumably merge the DTs at build time, if desired.
Practically I don’t think so. The passed device tree will contain all
authoritative information such as discovered normal memory (excluded the
secure memory ranges), architectural nodes such as PSCI and other nodes
coming from TEE-OS or secure partitions such as SCMI interface or
firmwareTPM.
If you combine the two static parts at build time you will have to extract
the runtime pieces from the DT passed to U-Boot.
>
>
> Regards,
> Simon
>
> >> >>
> >> >>
> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> >> >> so I think this can be dealt with.
> >> >>
> >> >> >
> >> >> > >
> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they
> get
> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi
> file"), we
> >> >> > > have binman definitions, etc. So we need a way to overlay those
> things
> >> >> > > into the DT. We already support this for in-tree DTs, so IMO
> this is
> >> >> > > easy. Just require every board to have an in-tree DT. It helps
> with
> >> >> > > discoverability and documentation, anyway. That is this series.
> >> >> > >
> >> >> >
> >> >> > Again, the board might decide for it's own reason to provide it's
> own DT.
> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be
> included in
> >> >> > U-Boot source is not the right way to do that, not to mention
> cases were
> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the
> DTB from
> >> >> > it's flash).
> >> >>
> >> >> I think you are at step 2. See above for my response.
> >> >>
> >> >> >
> >> >> > > (I think most of us are at the beginning of step 2, unsure about
> it
> >> >> > > and worried about step 3)
> >> >> > >
> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a
> particular
> >> >> > > flow only, or boards that sometimes use a flow) which need the
> DT to
> >> >> > > come from a prior stage. How to handle that? IMO that is only
> going to
> >> >> > > grow as every man and his dog get into the write-a-bootloader
> >> >> > > business.
> >> >> >
> >> >> > And that's exactly why we have to come up with something that
> scales, without
> >> >> > having to add a bunch of unusable DTs in U-Boot.
> >> >>
> >> >> In what way does this not scale? How are the DTs unusable? If there
> is
> >> >> a standard binding, we should be fine.
> >> >>
> >> >> >
> >> >> > > We need a way to provide the U-Boot nodes/properties in a
> >> >> > > form that the prior stage can consume and integrate with its
> build
> >> >> > > system. Is TF-A the only thing being discussed here? If so,
> let's just
> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the
> image
> >> >> > > together, for example. Or we can get clever and create some sort
> of
> >> >> > > overlay dtb.
> >> >> > >
> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this
> stuff
> >> >> > > then it will need to build it in and use two devicetrees, one
> internal
> >> >> > > and one from the prior stage....well that is not very efficient
> and it
> >> >> > > is going to be confusing for people to figure out what U-Boot is
> >> >> > > actually doing. But we actually already do that in a lot of cases
> >> >> > > where U-Boot passes a DT to the kernel which is different to the
> one
> >> >> > > it uses. So perhaps we have three devicetrees? OMG.
> >> >> >
> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
> >> >> > provides the internal one and inherits one 'generic'. Linux will
> be able to use
> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor*
> breaks the
> >> >> > DT across kernel versions, In which case there's not much you can
> do to
> >> >> > begin with and that's already a case we have to deal with.
> >> >>
> >> >> Linux actually doesn't care if the U-Boot properties are in the tree,
> >> >> so long as we have proper bindings. My point here is we only need
> >> >> either:
> >> >>
> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> >> >> b. two devicetrees, one for use in firmware and one for passing to
> Linux
> >> >>
> >> >> We don't need to separate out the U-Boot properties into a second (or
> >> >> third) devicetree. There just isn't any point.
> >> >>
> >> >> >
> >> >> > > b) Well then
> >> >> > > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> >> >> > > can merge the two when it starts. Again that is not very
> efficient. It
> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g.
> to get
> >> >> > > its public key from there or to enable/disable the console), so
> >> >> > > unified firmware config is not possible. It will get very
> confusing,
> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> >> >> > > accepting step 3...please stop!
> >> >> > >
> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up
> out of
> >> >> > > whole cloth. What about that? Well, we are just going to have to
> deal
> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and
> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> >> >> > > something similar.
> >> >> > >
> >> >> > > To my mind, that deals with both the build-time and run-time
> issues.
> >> >> > > We have a discoverable DT in U-Boot, which should be considered
> the
> >> >> > > source of truth for most boards. We can sync it with Linux
> >> >> > > automatically with the tooling that I hope Rob Herring will come
> up
> >> >> > > with. We can use an empty one where there really is no default,
> >> >> > > although I'd argue that is making perfect an enemy of the good.
> >> >> > >
> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot
> tree
> >> >> > > and pick them up from somewhere else, we can do that with
> sufficient
> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two?
> Six?
> >> >> >
> >> >> > We can start slowly migrating boards and see how that works out.
> >> >> > We could either use 2 device trees as you proposed, or have u-boot
> merge
> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH
> I'd prefer
> >> >> > if linux gets handed a clean device tree without the u-boot
> internals in
> >> >> > it, so I think 2 discrete DTs is cleaner overall.
> >> >>
> >> >> I know you would prefer that, but does it really matter in practice?
> >> >> What is the objection, actually?
> >> >>
> >> >> As I mentioned on the call, I think the prior stage should do any
> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code
> >> >> in U-Boot (or any other program, including Linux) is such a pain.
> With
> >> >> U-Boot, for example, we don't even have any RAM available to do it
> >> >> with half the time and it would dramatically increase the amount of
> >> >> memory needed prior to relocation. It just isn't a very good idea to
> >> >> try to do this in early code. It is also completely unnecessary, once
> >> >> you get past the philosophical objections.
> >> >>
> >> >> If TF-A wants to be in the picture, let it deal with the implications
> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot
> how
> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> >> >> of the size of U-Boot. It duplicates loads of things in there. No one
> >> >> will even *notice* an FDT merge function, which is actually only 70
> >> >> LOC:
> >> >>
> >> >> /**
> >> >> * overlay_apply_node - Merges a node into the base device tree
> >> >> * @fdt: Base Device Tree blob
> >> >> * @target: Node offset in the base device tree to apply the
> fragment to
> >> >> * @fdto: Device tree overlay blob
> >> >> * @node: Node offset in the overlay holding the changes to merge
> >> >> *
> >> >> * overlay_apply_node() merges a node into a target base device tree
> >> >> * node pointed.
> >> >> *
> >> >> * This is part of the final step in the device tree overlay
> >> >> * application process, when all the phandles have been adjusted and
> >> >> * resolved and you just have to merge overlay into the base device
> >> >> * tree.
> >> >> *
> >> >> * returns:
> >> >> * 0 on success
> >> >> * Negative error code on failure
> >> >> */
> >> >> static int overlay_apply_node(void *fdt, int target,
> >> >> void *fdto, int node)
> >> >> {
> >> >> int property;
> >> >> int subnode;
> >> >>
> >> >> fdt_for_each_property_offset(property, fdto, node) {
> >> >> const char *name;
> >> >> const void *prop;
> >> >> int prop_len;
> >> >> int ret;
> >> >>
> >> >> prop = fdt_getprop_by_offset(fdto, property, &name,
> >> >> &prop_len);
> >> >> if (prop_len == -FDT_ERR_NOTFOUND)
> >> >> return -FDT_ERR_INTERNAL;
> >> >> if (prop_len < 0)
> >> >> return prop_len;
> >> >>
> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
> >> >> if (ret)
> >> >> return ret;
> >> >> }
> >> >>
> >> >> fdt_for_each_subnode(subnode, fdto, node) {
> >> >> const char *name = fdt_get_name(fdto, subnode, NULL);
> >> >> int nnode;
> >> >> int ret;
> >> >>
> >> >> nnode = fdt_add_subnode(fdt, target, name);
> >> >> if (nnode == -FDT_ERR_EXISTS) {
> >> >> nnode = fdt_subnode_offset(fdt, target, name);
> >> >> if (nnode == -FDT_ERR_NOTFOUND)
> >> >> return -FDT_ERR_INTERNAL;
> >> >> }
> >> >>
> >> >> if (nnode < 0)
> >> >> return nnode;
> >> >>
> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
> >> >> if (ret)
> >> >> return ret;
> >> >> }
> >> >>
> >> >> return 0;
> >> >>
> >> >>
> >> >>
> >> >> }
> >> >>
> >> >>
> >> >> >
> >> >> > Regards
> >> >> > /Ilias
> >> >> > >
> >> >> > > To repeat, if we set things up correctly and agree on the
> bindings,
> >> >> > > devicetree can be the unifying configuration mechanism through
> the
> >> >> > > whole of firmware (except for very early bits) and into the OS.
> I feel
> >> >> > > this will set us up very well to deal with the complexity that is
> >> >> > > coming.
> >> >> > >
> >> >>
> >> >> Regards,
> >> >> Simon
> >
> > --
> > François-Frédéric Ozog | Director Business Development
> > T: +33.67221.6485
> > francois.ozog@linaro.org | Skype: ffozog
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 16:25 ` François Ozog
@ 2021-11-02 14:59 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi François,
On Thu, 28 Oct 2021 at 10:26, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi François,
>> >>
>> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>> >> >>
>> >> >> Hi Ilias,
>> >> >>
>> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> >> <ilias.apalodimas@linaro.org> wrote:
>> >> >> >
>> >> >> > Hi Simon,
>> >> >> >
>> >> >> > A bit late to the party, sorry!
>> >> >>
>> >> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> >> since I would not be adding much to my cover letter and patches)
>> >> >>
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> > > >
>> >> >> > > > I really want to see what the binary case looks like since we could then
>> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> >> >> > > > then also do a rpi_arm32_defconfig too.
>> >> >> > > >
>> >> >> > > > I want to see less device trees in U-Boot sources, if they can come
>> >> >> > > > functionally correct from the hardware/our caller.
>> >> >> > > >
>> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> >> >> > > > use the device tree from build time at run time, ignoring the device
>> >> >> > > > tree provided to us at run time by the caller.
>> >> >> > >
>> >> >> > > Firstly I should say that I find building firmware very messy and
>> >> >> > > confusing these days. Lots of things to build and it's hard to find
>> >> >> > > the instructions. It doesn't have to be that way, but if we carry on
>> >> >> > > as we are, it will continue to be messy and in five years you will
>> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> >> >> > > objective here is to simplify things, bringing some consistency to the
>> >> >> > > different components. Binman was one effort there. I feel that putting
>> >> >> > > at least the U-Boot house in order, in my role as devicetree
>> >> >> > > maintainer (and as author of devicetree support in U-Boot back in
>> >> >> > > 2011), is the next step.
>> >> >> > >
>> >> >> > > If we set things up correctly and agree on the bindings, devicetree
>> >> >> > > can be the unifying configuration mechanism through the whole of
>> >> >> > > firmware (except for very early bits) and into the OS, this will set
>> >> >> > > us up very well to deal with the complexity that is coming.
>> >> >> > >
>> >> >> > > Anyway, here are the mental steps that I've gone through over the past
>> >> >> > > two months:
>> >> >> > >
>> >> >> > > Step 1: At present, some people think U-Boot is not even allowed to
>> >> >> > > have its own nodes/properties in the DT. It is an abuse of the
>> >> >> > > devicetree standard, like the /chosen node but with less history. We
>> >> >> > > should sacrifice efficiency, expedience and expandability on the altar
>> >> >> > > of 'devicetree is a hardware description'. How do we get over that
>> >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> >> >> > > for its own purposes, as well as for booting the OS. I am not saying
>> >> >> > > it always has to have those properties, but with existing features
>> >> >> > > like verified boot, SPL as well as complex firmware images where
>> >> >> > > U-Boot needs to be able to find things in the image, it is essential.
>> >> >> > > So let's just assume that we need this everywhere, since we certainly
>> >> >> > > need it in at least some places.
>> >> >> > >
>> >> >> > > (stop reading here if you disagree, because nothing below will make
>> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> >> >> > > OF_CONTROL :-)
>> >> >> >
>> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> >> >> > that to the DTs that are copied over from linux isn't imho. There are
>> >> >> > various reasons for that. First of all syncing device trees is a huge pain
>> >> >> > and that's probably one of the main reasons our DTs are out of sync for a
>> >> >> > large number of boards.
>> >> >> > The point is this was fine in 2011 were we had SPL only, but the reality
>> >> >> > today is completely different. There's previous stage boot loaders (and
>> >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> >> >> > to use it's own device tree for whatever reason, imposing restrictions on
>> >> >> > it wrt to the device tree it has to include, and require them to have
>> >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> >> >> > to mention it doesn't scale at all.
>> >> >>
>> >> >> I think the solution here may be the binman image packer. It works
>> >> >> from a description of the image (i.e. is data-driver) and can collect
>> >> >> all the pieces together. The U-Boot properties (and the ones required
>> >> >> by TF-A, etc.) can be added at package time.
>> >> >>
>> >> >> If you think about it, it doesn't matter what properties are in the DT
>> >> >> that is put into the firmware image. TF-A, for example, is presumably
>> >> >> reading a devicetree from flash, so what does it care if it has some
>> >> >> U-Boot properties in it?
>> >> >
>> >> >
>> >> > I am going to change my position in all mail threads I participate.
>> >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>> >> >
>> >> >
>> >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>> >> >
>> >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
>> >>
>> >> OK thank you. It doesn't sound like you are very on-board though.
>> >> Also, you mischaracterise my intent with in-tree devicetrees.
>> >>
>> >> I would be happy enough for now if you could accept that U-Boot has
>> >> nodes/properties of its own in the devicetree. It has been a feature
>> >> of U-Boot for 10 years now.
>> >
>> > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests.
>> > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something.
>>
>> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
>>
>> Are you talking here about what TF-A will do? I assume so, since you
>> mention FIP and I believe that is a TF-A invention.
>
> Yes
>>
>>
>> Of course the image is all packaged together in fact, so binman could
>> presumably merge the DTs at build time, if desired.
>
> Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM.
> If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot.
This could be the subject of some future discussion, perhaps, as I
don't think we are talking about the same thing. I am talking about
the DT packaged in the firmware, but I think you are talking about the
things detected at runtime. Binman is for the first problem, not the
second.
Regards,
Simon
>>
>>
>>
>> Regards,
>> Simon
>>
>> >> >>
>> >> >>
>> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> >> >> so I think this can be dealt with.
>> >> >>
>> >> >> >
>> >> >> > >
>> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> >> >> > > have binman definitions, etc. So we need a way to overlay those things
>> >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> >> >> > > easy. Just require every board to have an in-tree DT. It helps with
>> >> >> > > discoverability and documentation, anyway. That is this series.
>> >> >> > >
>> >> >> >
>> >> >> > Again, the board might decide for it's own reason to provide it's own DT.
>> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> >> >> > U-Boot source is not the right way to do that, not to mention cases were
>> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> >> >> > it's flash).
>> >> >>
>> >> >> I think you are at step 2. See above for my response.
>> >> >>
>> >> >> >
>> >> >> > > (I think most of us are at the beginning of step 2, unsure about it
>> >> >> > > and worried about step 3)
>> >> >> > >
>> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> >> >> > > flow only, or boards that sometimes use a flow) which need the DT to
>> >> >> > > come from a prior stage. How to handle that? IMO that is only going to
>> >> >> > > grow as every man and his dog get into the write-a-bootloader
>> >> >> > > business.
>> >> >> >
>> >> >> > And that's exactly why we have to come up with something that scales, without
>> >> >> > having to add a bunch of unusable DTs in U-Boot.
>> >> >>
>> >> >> In what way does this not scale? How are the DTs unusable? If there is
>> >> >> a standard binding, we should be fine.
>> >> >>
>> >> >> >
>> >> >> > > We need a way to provide the U-Boot nodes/properties in a
>> >> >> > > form that the prior stage can consume and integrate with its build
>> >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> >> >> > > together, for example. Or we can get clever and create some sort of
>> >> >> > > overlay dtb.
>> >> >> > >
>> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> >> >> > > then it will need to build it in and use two devicetrees, one internal
>> >> >> > > and one from the prior stage....well that is not very efficient and it
>> >> >> > > is going to be confusing for people to figure out what U-Boot is
>> >> >> > > actually doing. But we actually already do that in a lot of cases
>> >> >> > > where U-Boot passes a DT to the kernel which is different to the one
>> >> >> > > it uses. So perhaps we have three devicetrees? OMG.
>> >> >> >
>> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> >> >> > DT across kernel versions, In which case there's not much you can do to
>> >> >> > begin with and that's already a case we have to deal with.
>> >> >>
>> >> >> Linux actually doesn't care if the U-Boot properties are in the tree,
>> >> >> so long as we have proper bindings. My point here is we only need
>> >> >> either:
>> >> >>
>> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> >> >> b. two devicetrees, one for use in firmware and one for passing to Linux
>> >> >>
>> >> >> We don't need to separate out the U-Boot properties into a second (or
>> >> >> third) devicetree. There just isn't any point.
>> >> >>
>> >> >> >
>> >> >> > > b) Well then
>> >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> >> >> > > can merge the two when it starts. Again that is not very efficient. It
>> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> >> >> > > its public key from there or to enable/disable the console), so
>> >> >> > > unified firmware config is not possible. It will get very confusing,
>> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> >> >> > > accepting step 3...please stop!
>> >> >> > >
>> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> >> >> > > whole cloth. What about that? Well, we are just going to have to deal
>> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and
>> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> >> >> > > something similar.
>> >> >> > >
>> >> >> > > To my mind, that deals with both the build-time and run-time issues.
>> >> >> > > We have a discoverable DT in U-Boot, which should be considered the
>> >> >> > > source of truth for most boards. We can sync it with Linux
>> >> >> > > automatically with the tooling that I hope Rob Herring will come up
>> >> >> > > with. We can use an empty one where there really is no default,
>> >> >> > > although I'd argue that is making perfect an enemy of the good.
>> >> >> > >
>> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> >> >> > > and pick them up from somewhere else, we can do that with sufficient
>> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >> >> >
>> >> >> > We can start slowly migrating boards and see how that works out.
>> >> >> > We could either use 2 device trees as you proposed, or have u-boot merge
>> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> >> >> > if linux gets handed a clean device tree without the u-boot internals in
>> >> >> > it, so I think 2 discrete DTs is cleaner overall.
>> >> >>
>> >> >> I know you would prefer that, but does it really matter in practice?
>> >> >> What is the objection, actually?
>> >> >>
>> >> >> As I mentioned on the call, I think the prior stage should do any
>> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code
>> >> >> in U-Boot (or any other program, including Linux) is such a pain. With
>> >> >> U-Boot, for example, we don't even have any RAM available to do it
>> >> >> with half the time and it would dramatically increase the amount of
>> >> >> memory needed prior to relocation. It just isn't a very good idea to
>> >> >> try to do this in early code. It is also completely unnecessary, once
>> >> >> you get past the philosophical objections.
>> >> >>
>> >> >> If TF-A wants to be in the picture, let it deal with the implications
>> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> >> >> of the size of U-Boot. It duplicates loads of things in there. No one
>> >> >> will even *notice* an FDT merge function, which is actually only 70
>> >> >> LOC:
>> >> >>
>> >> >> /**
>> >> >> * overlay_apply_node - Merges a node into the base device tree
>> >> >> * @fdt: Base Device Tree blob
>> >> >> * @target: Node offset in the base device tree to apply the fragment to
>> >> >> * @fdto: Device tree overlay blob
>> >> >> * @node: Node offset in the overlay holding the changes to merge
>> >> >> *
>> >> >> * overlay_apply_node() merges a node into a target base device tree
>> >> >> * node pointed.
>> >> >> *
>> >> >> * This is part of the final step in the device tree overlay
>> >> >> * application process, when all the phandles have been adjusted and
>> >> >> * resolved and you just have to merge overlay into the base device
>> >> >> * tree.
>> >> >> *
>> >> >> * returns:
>> >> >> * 0 on success
>> >> >> * Negative error code on failure
>> >> >> */
>> >> >> static int overlay_apply_node(void *fdt, int target,
>> >> >> void *fdto, int node)
>> >> >> {
>> >> >> int property;
>> >> >> int subnode;
>> >> >>
>> >> >> fdt_for_each_property_offset(property, fdto, node) {
>> >> >> const char *name;
>> >> >> const void *prop;
>> >> >> int prop_len;
>> >> >> int ret;
>> >> >>
>> >> >> prop = fdt_getprop_by_offset(fdto, property, &name,
>> >> >> &prop_len);
>> >> >> if (prop_len == -FDT_ERR_NOTFOUND)
>> >> >> return -FDT_ERR_INTERNAL;
>> >> >> if (prop_len < 0)
>> >> >> return prop_len;
>> >> >>
>> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> >> >> if (ret)
>> >> >> return ret;
>> >> >> }
>> >> >>
>> >> >> fdt_for_each_subnode(subnode, fdto, node) {
>> >> >> const char *name = fdt_get_name(fdto, subnode, NULL);
>> >> >> int nnode;
>> >> >> int ret;
>> >> >>
>> >> >> nnode = fdt_add_subnode(fdt, target, name);
>> >> >> if (nnode == -FDT_ERR_EXISTS) {
>> >> >> nnode = fdt_subnode_offset(fdt, target, name);
>> >> >> if (nnode == -FDT_ERR_NOTFOUND)
>> >> >> return -FDT_ERR_INTERNAL;
>> >> >> }
>> >> >>
>> >> >> if (nnode < 0)
>> >> >> return nnode;
>> >> >>
>> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> >> >> if (ret)
>> >> >> return ret;
>> >> >> }
>> >> >>
>> >> >> return 0;
>> >> >>
>> >> >>
>> >> >>
>> >> >> }
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Regards
>> >> >> > /Ilias
>> >> >> > >
>> >> >> > > To repeat, if we set things up correctly and agree on the bindings,
>> >> >> > > devicetree can be the unifying configuration mechanism through the
>> >> >> > > whole of firmware (except for very early bits) and into the OS. I feel
>> >> >> > > this will set us up very well to deal with the complexity that is
>> >> >> > > coming.
>> >> >> > >
>> >> >>
>> >> >> Regards,
>> >> >> Simon
>> >
>> > --
>> > François-Frédéric Ozog | Director Business Development
>> > T: +33.67221.6485
>> > francois.ozog@linaro.org | Skype: ffozog
>> >
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-11-02 14:59 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi François,
On Thu, 28 Oct 2021 at 10:26, François Ozog <francois.ozog@linaro.org> wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 17:44, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 08:50, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi François,
>> >>
>> >> On Thu, 28 Oct 2021 at 02:21, François Ozog <francois.ozog@linaro.org> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass <sjg@chromium.org> a écrit :
>> >> >>
>> >> >> Hi Ilias,
>> >> >>
>> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> >> <ilias.apalodimas@linaro.org> wrote:
>> >> >> >
>> >> >> > Hi Simon,
>> >> >> >
>> >> >> > A bit late to the party, sorry!
>> >> >>
>> >> >> (Did you remember the beer? I am replying to this but I don't think it
>> >> >> is all that helpful for me to reply to a lot of things on this thread,
>> >> >> since I would not be adding much to my cover letter and patches)
>> >> >>
>> >> >> >
>> >> >> > [...]
>> >> >> >
>> >> >> > > >
>> >> >> > > > I really want to see what the binary case looks like since we could then
>> >> >> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
>> >> >> > > > then also do a rpi_arm32_defconfig too.
>> >> >> > > >
>> >> >> > > > I want to see less device trees in U-Boot sources, if they can come
>> >> >> > > > functionally correct from the hardware/our caller.
>> >> >> > > >
>> >> >> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
>> >> >> > > > use the device tree from build time at run time, ignoring the device
>> >> >> > > > tree provided to us at run time by the caller.
>> >> >> > >
>> >> >> > > Firstly I should say that I find building firmware very messy and
>> >> >> > > confusing these days. Lots of things to build and it's hard to find
>> >> >> > > the instructions. It doesn't have to be that way, but if we carry on
>> >> >> > > as we are, it will continue to be messy and in five years you will
>> >> >> > > need a Ph.D and a lucky charm to boot on any modern board. My
>> >> >> > > objective here is to simplify things, bringing some consistency to the
>> >> >> > > different components. Binman was one effort there. I feel that putting
>> >> >> > > at least the U-Boot house in order, in my role as devicetree
>> >> >> > > maintainer (and as author of devicetree support in U-Boot back in
>> >> >> > > 2011), is the next step.
>> >> >> > >
>> >> >> > > If we set things up correctly and agree on the bindings, devicetree
>> >> >> > > can be the unifying configuration mechanism through the whole of
>> >> >> > > firmware (except for very early bits) and into the OS, this will set
>> >> >> > > us up very well to deal with the complexity that is coming.
>> >> >> > >
>> >> >> > > Anyway, here are the mental steps that I've gone through over the past
>> >> >> > > two months:
>> >> >> > >
>> >> >> > > Step 1: At present, some people think U-Boot is not even allowed to
>> >> >> > > have its own nodes/properties in the DT. It is an abuse of the
>> >> >> > > devicetree standard, like the /chosen node but with less history. We
>> >> >> > > should sacrifice efficiency, expedience and expandability on the altar
>> >> >> > > of 'devicetree is a hardware description'. How do we get over that
>> >> >> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
>> >> >> > > for its own purposes, as well as for booting the OS. I am not saying
>> >> >> > > it always has to have those properties, but with existing features
>> >> >> > > like verified boot, SPL as well as complex firmware images where
>> >> >> > > U-Boot needs to be able to find things in the image, it is essential.
>> >> >> > > So let's just assume that we need this everywhere, since we certainly
>> >> >> > > need it in at least some places.
>> >> >> > >
>> >> >> > > (stop reading here if you disagree, because nothing below will make
>> >> >> > > any sense...you can still use U-Boot v2011.06 which doesn't have
>> >> >> > > OF_CONTROL :-)
>> >> >> >
>> >> >> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
>> >> >> > that to the DTs that are copied over from linux isn't imho. There are
>> >> >> > various reasons for that. First of all syncing device trees is a huge pain
>> >> >> > and that's probably one of the main reasons our DTs are out of sync for a
>> >> >> > large number of boards.
>> >> >> > The point is this was fine in 2011 were we had SPL only, but the reality
>> >> >> > today is completely different. There's previous stage boot loaders (and
>> >> >> > enough cases were vendors prefer those over SPL). If that bootloader needs
>> >> >> > to use it's own device tree for whatever reason, imposing restrictions on
>> >> >> > it wrt to the device tree it has to include, and require them to have
>> >> >> > knowledge of U-Boot and it's internal config mechanism makes no sense not
>> >> >> > to mention it doesn't scale at all.
>> >> >>
>> >> >> I think the solution here may be the binman image packer. It works
>> >> >> from a description of the image (i.e. is data-driver) and can collect
>> >> >> all the pieces together. The U-Boot properties (and the ones required
>> >> >> by TF-A, etc.) can be added at package time.
>> >> >>
>> >> >> If you think about it, it doesn't matter what properties are in the DT
>> >> >> that is put into the firmware image. TF-A, for example, is presumably
>> >> >> reading a devicetree from flash, so what does it care if it has some
>> >> >> U-Boot properties in it?
>> >> >
>> >> >
>> >> > I am going to change my position in all mail threads I participate.
>> >> > I was trying to make patches relevant in the future and conceptually clean. That may not be the most effective position: I should just care about Linaro and its members being able to implement SystemReady concepts.
>> >> >
>> >> >
>> >> > If you mandate U-Boot has nodes in the device tree passed to the OS, we can put DT fragment in the nt_fw_config section of the fip and merge it at boot time. So there is a solution compatible with SystemReady.
>> >> >
>> >> > If you want to put fake, non future proof, DT sources in the dts for platforms that are organized to provide the authoritative DT to U-Boot at runtime, that's kind of your choice (hopefully representing the rest of U-Boot community). There will be quirk code in U-Boot to redo the adaptations on its non authoritative DT that the platform previous stage firmware does (already saw one in the past month); as Mark said there will be issues over time; and it will confuse people about the role of the DT. But I am fine with it as it does not impair Linaro and its members ability to implement SystemReady way of handling DT.
>> >>
>> >> OK thank you. It doesn't sound like you are very on-board though.
>> >> Also, you mischaracterise my intent with in-tree devicetrees.
>> >>
>> >> I would be happy enough for now if you could accept that U-Boot has
>> >> nodes/properties of its own in the devicetree. It has been a feature
>> >> of U-Boot for 10 years now.
>> >
>> > On SystemReady systems the DT passed to U-Boot for the OS will be assembled from the board DT and a U-Boot fragment/overlay. The board DT is free from any software/firmware aspects, just contains hardware description. The U-Boot fragment/overlay can contain any nodes it wants. The location of the bindings specification is essentially irrelevant: it could be devicetree.org, U-Boot doc or Linux kernel. Both DTs will be stored in the FIP. OEMs making their firmware will just put whatever is needed in this “dynamic config” DT. On SystemReady platforms U-Boot will always be given a DT, like on the RPI4. U-Boot will be able to ignore it obviously. That said, doing so, a platform may end-up failing compliance tests.
>> > I think we need to document the above in U-Boot and refer to relevant specifications. I’ll let Ilias propose something.
>>
>> Hmm. So long as OF_BOARD is enabled, the devicetree will not be 'ignored'.
>>
>> Are you talking here about what TF-A will do? I assume so, since you
>> mention FIP and I believe that is a TF-A invention.
>
> Yes
>>
>>
>> Of course the image is all packaged together in fact, so binman could
>> presumably merge the DTs at build time, if desired.
>
> Practically I don’t think so. The passed device tree will contain all authoritative information such as discovered normal memory (excluded the secure memory ranges), architectural nodes such as PSCI and other nodes coming from TEE-OS or secure partitions such as SCMI interface or firmwareTPM.
> If you combine the two static parts at build time you will have to extract the runtime pieces from the DT passed to U-Boot.
This could be the subject of some future discussion, perhaps, as I
don't think we are talking about the same thing. I am talking about
the DT packaged in the firmware, but I think you are talking about the
things detected at runtime. Binman is for the first problem, not the
second.
Regards,
Simon
>>
>>
>>
>> Regards,
>> Simon
>>
>> >> >>
>> >> >>
>> >> >> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
>> >> >> so I think this can be dealt with.
>> >> >>
>> >> >> >
>> >> >> > >
>> >> >> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
>> >> >> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
>> >> >> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
>> >> >> > > have binman definitions, etc. So we need a way to overlay those things
>> >> >> > > into the DT. We already support this for in-tree DTs, so IMO this is
>> >> >> > > easy. Just require every board to have an in-tree DT. It helps with
>> >> >> > > discoverability and documentation, anyway. That is this series.
>> >> >> > >
>> >> >> >
>> >> >> > Again, the board might decide for it's own reason to provide it's own DT.
>> >> >> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
>> >> >> > U-Boot source is not the right way to do that, not to mention cases were
>> >> >> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
>> >> >> > it's flash).
>> >> >>
>> >> >> I think you are at step 2. See above for my response.
>> >> >>
>> >> >> >
>> >> >> > > (I think most of us are at the beginning of step 2, unsure about it
>> >> >> > > and worried about step 3)
>> >> >> > >
>> >> >> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
>> >> >> > > flow only, or boards that sometimes use a flow) which need the DT to
>> >> >> > > come from a prior stage. How to handle that? IMO that is only going to
>> >> >> > > grow as every man and his dog get into the write-a-bootloader
>> >> >> > > business.
>> >> >> >
>> >> >> > And that's exactly why we have to come up with something that scales, without
>> >> >> > having to add a bunch of unusable DTs in U-Boot.
>> >> >>
>> >> >> In what way does this not scale? How are the DTs unusable? If there is
>> >> >> a standard binding, we should be fine.
>> >> >>
>> >> >> >
>> >> >> > > We need a way to provide the U-Boot nodes/properties in a
>> >> >> > > form that the prior stage can consume and integrate with its build
>> >> >> > > system. Is TF-A the only thing being discussed here? If so, let's just
>> >> >> > > do it. We have the u-boot.dtsi and we can use binman to put the image
>> >> >> > > together, for example. Or we can get clever and create some sort of
>> >> >> > > overlay dtb.
>> >> >> > >
>> >> >> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
>> >> >> > > then it will need to build it in and use two devicetrees, one internal
>> >> >> > > and one from the prior stage....well that is not very efficient and it
>> >> >> > > is going to be confusing for people to figure out what U-Boot is
>> >> >> > > actually doing. But we actually already do that in a lot of cases
>> >> >> > > where U-Boot passes a DT to the kernel which is different to the one
>> >> >> > > it uses. So perhaps we have three devicetrees? OMG.
>> >> >> >
>> >> >> > No we don't. That's a moot point. If you separate the DTs U-Boot
>> >> >> > provides the internal one and inherits one 'generic'. Linux will be able to use
>> >> >> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
>> >> >> > DT across kernel versions, In which case there's not much you can do to
>> >> >> > begin with and that's already a case we have to deal with.
>> >> >>
>> >> >> Linux actually doesn't care if the U-Boot properties are in the tree,
>> >> >> so long as we have proper bindings. My point here is we only need
>> >> >> either:
>> >> >>
>> >> >> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
>> >> >> b. two devicetrees, one for use in firmware and one for passing to Linux
>> >> >>
>> >> >> We don't need to separate out the U-Boot properties into a second (or
>> >> >> third) devicetree. There just isn't any point.
>> >> >>
>> >> >> >
>> >> >> > > b) Well then
>> >> >> > > U-Boot can have its own small devicetree with its bits and then U-Boot
>> >> >> > > can merge the two when it starts. Again that is not very efficient. It
>> >> >> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
>> >> >> > > its public key from there or to enable/disable the console), so
>> >> >> > > unified firmware config is not possible. It will get very confusing,
>> >> >> > > particularly for debugging U-Boot. c) Some other scheme to avoid
>> >> >> > > accepting step 3...please stop!
>> >> >> > >
>> >> >> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
>> >> >> > > whole cloth. What about that? Well, we are just going to have to deal
>> >> >> > > with that. We can easily merge in the U-Boot nodes/properties and
>> >> >> > > update the U-Boot CI scripts to do this, as needed, e.g. with
>> >> >> > > qemu-riscv64_spl. It's only one use case, although Xen might do
>> >> >> > > something similar.
>> >> >> > >
>> >> >> > > To my mind, that deals with both the build-time and run-time issues.
>> >> >> > > We have a discoverable DT in U-Boot, which should be considered the
>> >> >> > > source of truth for most boards. We can sync it with Linux
>> >> >> > > automatically with the tooling that I hope Rob Herring will come up
>> >> >> > > with. We can use an empty one where there really is no default,
>> >> >> > > although I'd argue that is making perfect an enemy of the good.
>> >> >> > >
>> >> >> > > Step 5: If we get clever and want to remove them from the U-Boot tree
>> >> >> > > and pick them up from somewhere else, we can do that with sufficient
>> >> >> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>> >> >> >
>> >> >> > We can start slowly migrating boards and see how that works out.
>> >> >> > We could either use 2 device trees as you proposed, or have u-boot merge
>> >> >> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
>> >> >> > if linux gets handed a clean device tree without the u-boot internals in
>> >> >> > it, so I think 2 discrete DTs is cleaner overall.
>> >> >>
>> >> >> I know you would prefer that, but does it really matter in practice?
>> >> >> What is the objection, actually?
>> >> >>
>> >> >> As I mentioned on the call, I think the prior stage should do any
>> >> >> merging or fixing up. Trying to do that sort of thing in 'early' code
>> >> >> in U-Boot (or any other program, including Linux) is such a pain. With
>> >> >> U-Boot, for example, we don't even have any RAM available to do it
>> >> >> with half the time and it would dramatically increase the amount of
>> >> >> memory needed prior to relocation. It just isn't a very good idea to
>> >> >> try to do this in early code. It is also completely unnecessary, once
>> >> >> you get past the philosophical objections.
>> >> >>
>> >> >> If TF-A wants to be in the picture, let it deal with the implications
>> >> >> and responsibility thus incurred. TF-A has no right to tell U-Boot how
>> >> >> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
>> >> >> of the size of U-Boot. It duplicates loads of things in there. No one
>> >> >> will even *notice* an FDT merge function, which is actually only 70
>> >> >> LOC:
>> >> >>
>> >> >> /**
>> >> >> * overlay_apply_node - Merges a node into the base device tree
>> >> >> * @fdt: Base Device Tree blob
>> >> >> * @target: Node offset in the base device tree to apply the fragment to
>> >> >> * @fdto: Device tree overlay blob
>> >> >> * @node: Node offset in the overlay holding the changes to merge
>> >> >> *
>> >> >> * overlay_apply_node() merges a node into a target base device tree
>> >> >> * node pointed.
>> >> >> *
>> >> >> * This is part of the final step in the device tree overlay
>> >> >> * application process, when all the phandles have been adjusted and
>> >> >> * resolved and you just have to merge overlay into the base device
>> >> >> * tree.
>> >> >> *
>> >> >> * returns:
>> >> >> * 0 on success
>> >> >> * Negative error code on failure
>> >> >> */
>> >> >> static int overlay_apply_node(void *fdt, int target,
>> >> >> void *fdto, int node)
>> >> >> {
>> >> >> int property;
>> >> >> int subnode;
>> >> >>
>> >> >> fdt_for_each_property_offset(property, fdto, node) {
>> >> >> const char *name;
>> >> >> const void *prop;
>> >> >> int prop_len;
>> >> >> int ret;
>> >> >>
>> >> >> prop = fdt_getprop_by_offset(fdto, property, &name,
>> >> >> &prop_len);
>> >> >> if (prop_len == -FDT_ERR_NOTFOUND)
>> >> >> return -FDT_ERR_INTERNAL;
>> >> >> if (prop_len < 0)
>> >> >> return prop_len;
>> >> >>
>> >> >> ret = fdt_setprop(fdt, target, name, prop, prop_len);
>> >> >> if (ret)
>> >> >> return ret;
>> >> >> }
>> >> >>
>> >> >> fdt_for_each_subnode(subnode, fdto, node) {
>> >> >> const char *name = fdt_get_name(fdto, subnode, NULL);
>> >> >> int nnode;
>> >> >> int ret;
>> >> >>
>> >> >> nnode = fdt_add_subnode(fdt, target, name);
>> >> >> if (nnode == -FDT_ERR_EXISTS) {
>> >> >> nnode = fdt_subnode_offset(fdt, target, name);
>> >> >> if (nnode == -FDT_ERR_NOTFOUND)
>> >> >> return -FDT_ERR_INTERNAL;
>> >> >> }
>> >> >>
>> >> >> if (nnode < 0)
>> >> >> return nnode;
>> >> >>
>> >> >> ret = overlay_apply_node(fdt, nnode, fdto, subnode);
>> >> >> if (ret)
>> >> >> return ret;
>> >> >> }
>> >> >>
>> >> >> return 0;
>> >> >>
>> >> >>
>> >> >>
>> >> >> }
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > Regards
>> >> >> > /Ilias
>> >> >> > >
>> >> >> > > To repeat, if we set things up correctly and agree on the bindings,
>> >> >> > > devicetree can be the unifying configuration mechanism through the
>> >> >> > > whole of firmware (except for very early bits) and into the OS. I feel
>> >> >> > > this will set us up very well to deal with the complexity that is
>> >> >> > > coming.
>> >> >> > >
>> >> >>
>> >> >> Regards,
>> >> >> Simon
>> >
>> > --
>> > François-Frédéric Ozog | Director Business Development
>> > T: +33.67221.6485
>> > francois.ozog@linaro.org | Skype: ffozog
>> >
>
> --
> François-Frédéric Ozog | Director Business Development
> T: +33.67221.6485
> francois.ozog@linaro.org | Skype: ffozog
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-28 2:50 ` Simon Glass
@ 2021-11-01 11:04 ` Ilias Apalodimas
-1 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-11-01 11:04 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung,
Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún,
Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp,
Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, François Ozog,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi Simon,
On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer?
We'll probably need something stronger to sort this out :)
> I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader needs
> > to use it's own device tree for whatever reason, imposing restrictions on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
I am not sure I am following you here or why binman is relevant to
this discussion. If the boot process doesn't require a FIP (e.g SPL
+ U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
using binman makes a lot of sense. If the boot process is TF-A ->
U-Boot and requires a FIP, TF-A has it's own set of tools for
preparing that [1] [2] , why would we want to teach binman FIP
packaging? And if we do are you willing to keep it up to date with
everything they come up with? IOW packaging the firmware is not
U-Boot's responsibility, it's the vendors. Why should he not be able
to choose FIP? (ST already changed that in u-boot btw).
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?
It doesn't, but the point here is entirely different. Today there's a
number of U-Boot DTBs that are unable to boot a kernel. The direction
we would like to is have the firmware provide a DTB that's usable for
the kernel. Yes I know vendors mess things up and there's a
correlation of the DTB and the kernel version, but let's set that
aside for a moment. If we want to use a 'generic' DT then we have to
make sure that whoever packages it knows what to put in there. That's
why for me, it's very important to only allow *upstreamed only* DT
properties for whoever ends up being responsible for the packaging.
In that case you can demand TF-A to bundle U-Boot nodes in the DTB it
produces if the board is supposed to use U-Boot. If those are internal
only to U-Boot and not upstreamed this makes little sense to me and I
don't see why people will agree to that.
>
> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> so I think this can be dealt with.
>
> >
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> >
> > Again, the board might decide for it's own reason to provide it's own DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> > it's flash).
>
> I think you are at step 2. See above for my response.
>
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales, without
> > having to add a bunch of unusable DTs in U-Boot.
>
> In what way does this not scale? How are the DTs unusable? If there is
> a standard binding, we should be fine.
The keyword here is the definition of 'standard'. If standard means
upstreamed to DT spec, as I said before I don't see any problem. By
unusable I was referring to the QEMU DTs you are trying to push into
U-Boot or the RPI one. It doesn't scale because you have to maintain
and upstream all the DTs in the U-Boot tree. The story so far is
merge and forget for a big number of DTs, so I find it hard to believe
that everyone will start behaving and sync up their DTs. I'd much
rather prefer having a central repo and force people to use that.
>
> >
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
>
> Linux actually doesn't care if the U-Boot properties are in the tree,
> so long as we have proper bindings. My point here is we only need
> either:
>
> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> b. two devicetrees, one for use in firmware and one for passing to Linux
>
> We don't need to separate out the U-Boot properties into a second (or
> third) devicetree. There just isn't any point.
Again if we are talking about bindings that are upstream in the spec,
then we agree. Depending on the SRAM limitation we can even do (a).
If the vendor messes up the DT backwards compatibility then we can do
(b). If you expect TF-A and FIP to go pick up the special bindings
U-Boot needs, then we disagree.
>
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> I know you would prefer that, but does it really matter in practice?
> What is the objection, actually?
>
> As I mentioned on the call, I think the prior stage should do any
> merging or fixing up. Trying to do that sort of thing in 'early' code
> in U-Boot (or any other program, including Linux) is such a pain. With
> U-Boot, for example, we don't even have any RAM available to do it
> with half the time and it would dramatically increase the amount of
> memory needed prior to relocation. It just isn't a very good idea to
> try to do this in early code. It is also completely unnecessary, once
> you get past the philosophical objections.
>
> If TF-A wants to be in the picture, let it deal with the implications
> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> of the size of U-Boot. It duplicates loads of things in there. No one
> will even *notice* an FDT merge function, which is actually only 70
> LOC:
>
Again I am repeating myself so here's a tl;dr of how I view this:
1. All DT bindings u-boot expect become part of the DT spec -- I am
fine with whatever, since at this point it makes sense to say "You are
booting u-boot go add whatever it expects, it's part of the spec".
The prior stage boot loader can then obviously merge the DT fragments
and everyone will be happy.
2. For the bindings that are not upstreamed, I'd prefer having u-boot
do the fixup. Alternatively, we could provide fragments that are easy
for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts
files, find the fragments you need and add them manually...
[...]
[1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG
[2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html
Regards
/Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-11-01 11:04 ` Ilias Apalodimas
0 siblings, 0 replies; 164+ messages in thread
From: Ilias Apalodimas @ 2021-11-01 11:04 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi Simon,
On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
>
> Hi Ilias,
>
> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
> >
> > Hi Simon,
> >
> > A bit late to the party, sorry!
>
> (Did you remember the beer?
We'll probably need something stronger to sort this out :)
> I am replying to this but I don't think it
> is all that helpful for me to reply to a lot of things on this thread,
> since I would not be adding much to my cover letter and patches)
>
> >
> > [...]
> >
> > > >
> > > > I really want to see what the binary case looks like since we could then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> > >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT. It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> > >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> >
> > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > that to the DTs that are copied over from linux isn't imho. There are
> > various reasons for that. First of all syncing device trees is a huge pain
> > and that's probably one of the main reasons our DTs are out of sync for a
> > large number of boards.
> > The point is this was fine in 2011 were we had SPL only, but the reality
> > today is completely different. There's previous stage boot loaders (and
> > enough cases were vendors prefer those over SPL). If that bootloader needs
> > to use it's own device tree for whatever reason, imposing restrictions on
> > it wrt to the device tree it has to include, and require them to have
> > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > to mention it doesn't scale at all.
>
> I think the solution here may be the binman image packer. It works
> from a description of the image (i.e. is data-driver) and can collect
> all the pieces together. The U-Boot properties (and the ones required
> by TF-A, etc.) can be added at package time.
I am not sure I am following you here or why binman is relevant to
this discussion. If the boot process doesn't require a FIP (e.g SPL
+ U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
using binman makes a lot of sense. If the boot process is TF-A ->
U-Boot and requires a FIP, TF-A has it's own set of tools for
preparing that [1] [2] , why would we want to teach binman FIP
packaging? And if we do are you willing to keep it up to date with
everything they come up with? IOW packaging the firmware is not
U-Boot's responsibility, it's the vendors. Why should he not be able
to choose FIP? (ST already changed that in u-boot btw).
>
> If you think about it, it doesn't matter what properties are in the DT
> that is put into the firmware image. TF-A, for example, is presumably
> reading a devicetree from flash, so what does it care if it has some
> U-Boot properties in it?
It doesn't, but the point here is entirely different. Today there's a
number of U-Boot DTBs that are unable to boot a kernel. The direction
we would like to is have the firmware provide a DTB that's usable for
the kernel. Yes I know vendors mess things up and there's a
correlation of the DTB and the kernel version, but let's set that
aside for a moment. If we want to use a 'generic' DT then we have to
make sure that whoever packages it knows what to put in there. That's
why for me, it's very important to only allow *upstreamed only* DT
properties for whoever ends up being responsible for the packaging.
In that case you can demand TF-A to bundle U-Boot nodes in the DTB it
produces if the board is supposed to use U-Boot. If those are internal
only to U-Boot and not upstreamed this makes little sense to me and I
don't see why people will agree to that.
>
> As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> so I think this can be dealt with.
>
> >
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> >
> > Again, the board might decide for it's own reason to provide it's own DT.
> > IMHO U-Boot must be able to cope with that and asking DTs to be included in
> > U-Boot source is not the right way to do that, not to mention cases were
> > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> > it's flash).
>
> I think you are at step 2. See above for my response.
>
> >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business.
> >
> > And that's exactly why we have to come up with something that scales, without
> > having to add a bunch of unusable DTs in U-Boot.
>
> In what way does this not scale? How are the DTs unusable? If there is
> a standard binding, we should be fine.
The keyword here is the definition of 'standard'. If standard means
upstreamed to DT spec, as I said before I don't see any problem. By
unusable I was referring to the QEMU DTs you are trying to push into
U-Boot or the RPI one. It doesn't scale because you have to maintain
and upstream all the DTs in the U-Boot tree. The story so far is
merge and forget for a big number of DTs, so I find it hard to believe
that everyone will start behaving and sync up their DTs. I'd much
rather prefer having a central repo and force people to use that.
>
> >
> > > We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG.
> >
> > No we don't. That's a moot point. If you separate the DTs U-Boot
> > provides the internal one and inherits one 'generic'. Linux will be able to use
> > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> > DT across kernel versions, In which case there's not much you can do to
> > begin with and that's already a case we have to deal with.
>
> Linux actually doesn't care if the U-Boot properties are in the tree,
> so long as we have proper bindings. My point here is we only need
> either:
>
> a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> b. two devicetrees, one for use in firmware and one for passing to Linux
>
> We don't need to separate out the U-Boot properties into a second (or
> third) devicetree. There just isn't any point.
Again if we are talking about bindings that are upstream in the spec,
then we agree. Depending on the SRAM limitation we can even do (a).
If the vendor messes up the DT backwards compatibility then we can do
(b). If you expect TF-A and FIP to go pick up the special bindings
U-Boot needs, then we disagree.
>
> >
> > > b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient. It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> > >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > We can start slowly migrating boards and see how that works out.
> > We could either use 2 device trees as you proposed, or have u-boot merge
> > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> > if linux gets handed a clean device tree without the u-boot internals in
> > it, so I think 2 discrete DTs is cleaner overall.
>
> I know you would prefer that, but does it really matter in practice?
> What is the objection, actually?
>
> As I mentioned on the call, I think the prior stage should do any
> merging or fixing up. Trying to do that sort of thing in 'early' code
> in U-Boot (or any other program, including Linux) is such a pain. With
> U-Boot, for example, we don't even have any RAM available to do it
> with half the time and it would dramatically increase the amount of
> memory needed prior to relocation. It just isn't a very good idea to
> try to do this in early code. It is also completely unnecessary, once
> you get past the philosophical objections.
>
> If TF-A wants to be in the picture, let it deal with the implications
> and responsibility thus incurred. TF-A has no right to tell U-Boot how
> to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> of the size of U-Boot. It duplicates loads of things in there. No one
> will even *notice* an FDT merge function, which is actually only 70
> LOC:
>
Again I am repeating myself so here's a tl;dr of how I view this:
1. All DT bindings u-boot expect become part of the DT spec -- I am
fine with whatever, since at this point it makes sense to say "You are
booting u-boot go add whatever it expects, it's part of the spec".
The prior stage boot loader can then obviously merge the DT fragments
and everyone will be happy.
2. For the bindings that are not upstreamed, I'd prefer having u-boot
do the fixup. Alternatively, we could provide fragments that are easy
for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts
files, find the fragments you need and add them manually...
[...]
[1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG
[2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html
Regards
/Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-11-01 11:04 ` Ilias Apalodimas
@ 2021-11-02 10:06 ` Michael Walle
-1 siblings, 0 replies; 164+ messages in thread
From: Michael Walle @ 2021-11-02 10:06 UTC (permalink / raw)
To: ilias.apalodimas
Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij,
fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam,
rainer.boschung, francois.ozog, swarren, oleksandr_andrushchenko,
xypron.glpk, lusus, michal.simek, marek.behun, vanbaren,
rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan,
bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma,
qemu-devel, agraf, green.wan, t.karthik.reddy,
anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang,
kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg,
christianshewitt, awilliams, tuomas.tynkkynen,
heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, trini,
dimitri.ledkov, padmarao.begari
Hi,
> On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
..
> > Linux actually doesn't care if the U-Boot properties are in the tree,
> > so long as we have proper bindings. My point here is we only need
> > either:
> >
> > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > b. two devicetrees, one for use in firmware and one for passing to Linux
> >
> > We don't need to separate out the U-Boot properties into a second (or
> > third) devicetree. There just isn't any point.
>
> Again if we are talking about bindings that are upstream in the spec,
> then we agree. Depending on the SRAM limitation we can even do (a).
> If the vendor messes up the DT backwards compatibility then we can do
> (b). If you expect TF-A and FIP to go pick up the special bindings
> U-Boot needs, then we disagree.
*puts developer at board vendor hat on* Sometimes (personally I'd say
usually) it isn't possible to have a backwards compatible tree. Also,
like it or not, in the device tree there *are* configuration options
which are not hardware dependent (eg. internal ethernet connection on
the ls1028a). So a vendor doesn't necessarily need to "mess things up"
to need (b). And as you know, my point is, that this device tree has
to come from the distribution, it must not be compiled in into the
firmware.
I feel like I've repeated this far too many times. Therefore, this
will be my last comment about it and I would really like to see that
this - very real - scenario is treated as a valid use case and will be
supported in your systemready vision.
-michael
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-11-02 10:06 ` Michael Walle
0 siblings, 0 replies; 164+ messages in thread
From: Michael Walle @ 2021-11-02 10:06 UTC (permalink / raw)
To: ilias.apalodimas
Cc: agraf, albert.u.boot, anastasiia_lukianenko, andre.przywara,
ashok.reddy.soma, atish.patra, awilliams, bin.meng, bmeng.cn,
christianshewitt, david.abdurachmanov, dimitri.ledkov, festevam,
fitzsim, francois.ozog, green.wan, heinrich.schuchardt, hs,
jagan, kever.yang, kristo, linus.walleij, liviu.dudau, lusus,
marek.behun, mbrugger, michal.simek, monstr, narmstrong,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, qemu-devel, rainer.boschung, rfried.dev, rick,
seanga2, sinan, sjg, sr, swarren, swarren, t.karthik.reddy,
tharvey, tianrui-wei, trini, tuomas.tynkkynen, u-boot,
valentin.longchamp, vanbaren, vladimir.oltean, wd, xypron.glpk,
ycliang, zong.li
Hi,
> On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
..
> > Linux actually doesn't care if the U-Boot properties are in the tree,
> > so long as we have proper bindings. My point here is we only need
> > either:
> >
> > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > b. two devicetrees, one for use in firmware and one for passing to Linux
> >
> > We don't need to separate out the U-Boot properties into a second (or
> > third) devicetree. There just isn't any point.
>
> Again if we are talking about bindings that are upstream in the spec,
> then we agree. Depending on the SRAM limitation we can even do (a).
> If the vendor messes up the DT backwards compatibility then we can do
> (b). If you expect TF-A and FIP to go pick up the special bindings
> U-Boot needs, then we disagree.
*puts developer at board vendor hat on* Sometimes (personally I'd say
usually) it isn't possible to have a backwards compatible tree. Also,
like it or not, in the device tree there *are* configuration options
which are not hardware dependent (eg. internal ethernet connection on
the ls1028a). So a vendor doesn't necessarily need to "mess things up"
to need (b). And as you know, my point is, that this device tree has
to come from the distribution, it must not be compiled in into the
firmware.
I feel like I've repeated this far too many times. Therefore, this
will be my last comment about it and I would really like to see that
this - very real - scenario is treated as a valid use case and will be
supported in your systemready vision.
-michael
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-11-02 10:06 ` Michael Walle
@ 2021-11-02 12:34 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-11-02 12:34 UTC (permalink / raw)
To: Michael Walle
Cc: ilias.apalodimas, agraf, albert.u.boot, anastasiia_lukianenko,
andre.przywara, ashok.reddy.soma, atish.patra, awilliams,
bin.meng, bmeng.cn, christianshewitt, david.abdurachmanov,
dimitri.ledkov, festevam, fitzsim, green.wan,
heinrich.schuchardt, hs, jagan, kever.yang, kristo,
linus.walleij, liviu.dudau, lusus, marek.behun, mbrugger,
michal.simek, monstr, narmstrong, oleksandr_andrushchenko,
padmarao.begari, pali, pbrobinson, priyanka.jain, qemu-devel,
rainer.boschung, rfried.dev, rick, seanga2, sinan, sjg, sr,
swarren, swarren, t.karthik.reddy, tharvey, tianrui-wei, trini,
tuomas.tynkkynen, u-boot, valentin.longchamp, vanbaren,
vladimir.oltean, wd, xypron.glpk, ycliang, zong.li
On Tue, 2 Nov 2021 at 11:07, Michael Walle <michael@walle.cc> wrote:
> Hi,
>
> > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
>
> ..
>
> > > Linux actually doesn't care if the U-Boot properties are in the tree,
> > > so long as we have proper bindings. My point here is we only need
> > > either:
> > >
> > > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > > b. two devicetrees, one for use in firmware and one for passing to
> Linux
> > >
> > > We don't need to separate out the U-Boot properties into a second (or
> > > third) devicetree. There just isn't any point.
> >
> > Again if we are talking about bindings that are upstream in the spec,
> > then we agree. Depending on the SRAM limitation we can even do (a).
> > If the vendor messes up the DT backwards compatibility then we can do
> > (b). If you expect TF-A and FIP to go pick up the special bindings
> > U-Boot needs, then we disagree.
>
> *puts developer at board vendor hat on* Sometimes (personally I'd say
> usually) it isn't possible to have a backwards compatible tree. Also,
> like it or not, in the device tree there *are* configuration options
> which are not hardware dependent (eg. internal ethernet connection on
> the ls1028a).
Are you referring to DPAA2 configuration to create the ethernet port itself
?
This is indeed configuration. There are many ways to handle those ones.
As well as SerDes configuration to make PCI lanes or MDIO lanes.
Yet the two are different in nature: SerDes configuration must match board
layout,
so it is about "no user choice" configuration. This configuration could be
statically
defined and attached with the board. But it there is a SoM with a carrier
board,
we may need to compose that at runtime for development, or make it static
build
for product packaging.
DPAA2 configuration is user choice driven. Those choices can be merged in
the DT
to be passed to the OS at runtime. There are multiple ways to deal with
that, from DT overlays
to U-Boot DPAA2 command line extensions that would inject the DT necessary
nodes.
> So a vendor doesn't necessarily need to "mess things up"
> to need (b). And as you know, my point is, that this device tree has
> to come from the distribution, it must not be compiled in into the
> firmware.
>
I wouldn't bet that all distro providers will always come with a DT...
>
> I feel like I've repeated this far too many times. Therefore, this
> will be my last comment about it and I would really like to see that
> this - very real - scenario is treated as a valid use case and will be
> supported in your systemready vision.
>
I have been building (shared it on the list) a deck to go into those
details. I am almost ready to talk to it.
>
> -michael
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-11-02 12:34 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-11-02 12:34 UTC (permalink / raw)
To: Michael Walle
Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij,
bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr,
festevam, rainer.boschung, trini, swarren,
oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek,
marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs,
pbrobinson, sinan, fitzsim, wd, swarren, andre.przywara, tharvey,
ashok.reddy.soma, qemu-devel, agraf, green.wan, t.karthik.reddy,
anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang,
kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg,
ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen,
heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov,
padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 3044 bytes --]
On Tue, 2 Nov 2021 at 11:07, Michael Walle <michael@walle.cc> wrote:
> Hi,
>
> > On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> > > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > > <ilias.apalodimas@linaro.org> wrote:
>
> ..
>
> > > Linux actually doesn't care if the U-Boot properties are in the tree,
> > > so long as we have proper bindings. My point here is we only need
> > > either:
> > >
> > > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > > b. two devicetrees, one for use in firmware and one for passing to
> Linux
> > >
> > > We don't need to separate out the U-Boot properties into a second (or
> > > third) devicetree. There just isn't any point.
> >
> > Again if we are talking about bindings that are upstream in the spec,
> > then we agree. Depending on the SRAM limitation we can even do (a).
> > If the vendor messes up the DT backwards compatibility then we can do
> > (b). If you expect TF-A and FIP to go pick up the special bindings
> > U-Boot needs, then we disagree.
>
> *puts developer at board vendor hat on* Sometimes (personally I'd say
> usually) it isn't possible to have a backwards compatible tree. Also,
> like it or not, in the device tree there *are* configuration options
> which are not hardware dependent (eg. internal ethernet connection on
> the ls1028a).
Are you referring to DPAA2 configuration to create the ethernet port itself
?
This is indeed configuration. There are many ways to handle those ones.
As well as SerDes configuration to make PCI lanes or MDIO lanes.
Yet the two are different in nature: SerDes configuration must match board
layout,
so it is about "no user choice" configuration. This configuration could be
statically
defined and attached with the board. But it there is a SoM with a carrier
board,
we may need to compose that at runtime for development, or make it static
build
for product packaging.
DPAA2 configuration is user choice driven. Those choices can be merged in
the DT
to be passed to the OS at runtime. There are multiple ways to deal with
that, from DT overlays
to U-Boot DPAA2 command line extensions that would inject the DT necessary
nodes.
> So a vendor doesn't necessarily need to "mess things up"
> to need (b). And as you know, my point is, that this device tree has
> to come from the distribution, it must not be compiled in into the
> firmware.
>
I wouldn't bet that all distro providers will always come with a DT...
>
> I feel like I've repeated this far too many times. Therefore, this
> will be my last comment about it and I would really like to see that
> this - very real - scenario is treated as a valid use case and will be
> supported in your systemready vision.
>
I have been building (shared it on the list) a deck to go into those
details. I am almost ready to talk to it.
>
> -michael
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 5753 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-11-01 11:04 ` Ilias Apalodimas
@ 2021-11-02 14:59 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
Hi Ilias,
On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> >
> > (Did you remember the beer?
>
> We'll probably need something stronger to sort this out :)
Yes I agree!
>
> > I am replying to this but I don't think it
> > is all that helpful for me to reply to a lot of things on this thread,
> > since I would not be adding much to my cover letter and patches)
> >
> > >
> > > [...]
> > >
> > > > >
> > > > > I really want to see what the binary case looks like since we could then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > devicetree standard, like the /chosen node but with less history. We
> > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > of 'devicetree is a hardware description'. How do we get over that
> > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > it always has to have those properties, but with existing features
> > > > like verified boot, SPL as well as complex firmware images where
> > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > So let's just assume that we need this everywhere, since we certainly
> > > > need it in at least some places.
> > > >
> > > > (stop reading here if you disagree, because nothing below will make
> > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > OF_CONTROL :-)
> > >
> > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > that to the DTs that are copied over from linux isn't imho. There are
> > > various reasons for that. First of all syncing device trees is a huge pain
> > > and that's probably one of the main reasons our DTs are out of sync for a
> > > large number of boards.
> > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > today is completely different. There's previous stage boot loaders (and
> > > enough cases were vendors prefer those over SPL). If that bootloader needs
> > > to use it's own device tree for whatever reason, imposing restrictions on
> > > it wrt to the device tree it has to include, and require them to have
> > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > to mention it doesn't scale at all.
> >
> > I think the solution here may be the binman image packer. It works
> > from a description of the image (i.e. is data-driver) and can collect
> > all the pieces together. The U-Boot properties (and the ones required
> > by TF-A, etc.) can be added at package time.
>
> I am not sure I am following you here or why binman is relevant to
> this discussion. If the boot process doesn't require a FIP (e.g SPL
> + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
> using binman makes a lot of sense. If the boot process is TF-A ->
> U-Boot and requires a FIP, TF-A has it's own set of tools for
> preparing that [1] [2] , why would we want to teach binman FIP
> packaging? And if we do are you willing to keep it up to date with
> everything they come up with? IOW packaging the firmware is not
> U-Boot's responsibility, it's the vendors. Why should he not be able
> to choose FIP? (ST already changed that in u-boot btw).
Binman is a firmware packager. It seems to be the one that is used
last, to produce the final image, although I am not sure as this seems
quite complicated.
My view on firmware is that we should build it step by step with
individual projects but then package it all at the end and Binman is
designed to do the packaging.
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation
So I am not sure what problem FIP solves, or why it was invented, Did
we need another firmware format?
But if FIP is important, then yes I think support for it should be
added to Binman. It will make packaging a lot easier.
>
> >
> > If you think about it, it doesn't matter what properties are in the DT
> > that is put into the firmware image. TF-A, for example, is presumably
> > reading a devicetree from flash, so what does it care if it has some
> > U-Boot properties in it?
>
> It doesn't, but the point here is entirely different. Today there's a
> number of U-Boot DTBs that are unable to boot a kernel. The direction
> we would like to is have the firmware provide a DTB that's usable for
> the kernel. Yes I know vendors mess things up and there's a
> correlation of the DTB and the kernel version, but let's set that
> aside for a moment. If we want to use a 'generic' DT then we have to
> make sure that whoever packages it knows what to put in there. That's
> why for me, it's very important to only allow *upstreamed only* DT
> properties for whoever ends up being responsible for the packaging.
> In that case you can demand TF-A to bundle U-Boot nodes in the DTB it
> produces if the board is supposed to use U-Boot. If those are internal
> only to U-Boot and not upstreamed this makes little sense to me and I
> don't see why people will agree to that.
Well I think all of this is taking too much energy...I have stated my
position. U-Boot needs its nodes and properties.
>
> >
> > As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> > so I think this can be dealt with.
> >
> > >
> > > >
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > have binman definitions, etc. So we need a way to overlay those things
> > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > discoverability and documentation, anyway. That is this series.
> > > >
> > >
> > > Again, the board might decide for it's own reason to provide it's own DT.
> > > IMHO U-Boot must be able to cope with that and asking DTs to be included in
> > > U-Boot source is not the right way to do that, not to mention cases were
> > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> > > it's flash).
> >
> > I think you are at step 2. See above for my response.
> >
> > >
> > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > and worried about step 3)
> > > >
> > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > grow as every man and his dog get into the write-a-bootloader
> > > > business.
> > >
> > > And that's exactly why we have to come up with something that scales, without
> > > having to add a bunch of unusable DTs in U-Boot.
> >
> > In what way does this not scale? How are the DTs unusable? If there is
> > a standard binding, we should be fine.
>
> The keyword here is the definition of 'standard'. If standard means
> upstreamed to DT spec, as I said before I don't see any problem. By
> unusable I was referring to the QEMU DTs you are trying to push into
> U-Boot or the RPI one. It doesn't scale because you have to maintain
> and upstream all the DTs in the U-Boot tree. The story so far is
> merge and forget for a big number of DTs, so I find it hard to believe
> that everyone will start behaving and sync up their DTs. I'd much
> rather prefer having a central repo and force people to use that.
Well let's see how it goes. If we can get some validation in place,
then the picture should get better.
>
> >
> > >
> > > > We need a way to provide the U-Boot nodes/properties in a
> > > > form that the prior stage can consume and integrate with its build
> > > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > > together, for example. Or we can get clever and create some sort of
> > > > overlay dtb.
> > > >
> > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > > then it will need to build it in and use two devicetrees, one internal
> > > > and one from the prior stage....well that is not very efficient and it
> > > > is going to be confusing for people to figure out what U-Boot is
> > > > actually doing. But we actually already do that in a lot of cases
> > > > where U-Boot passes a DT to the kernel which is different to the one
> > > > it uses. So perhaps we have three devicetrees? OMG.
> > >
> > > No we don't. That's a moot point. If you separate the DTs U-Boot
> > > provides the internal one and inherits one 'generic'. Linux will be able to use
> > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> > > DT across kernel versions, In which case there's not much you can do to
> > > begin with and that's already a case we have to deal with.
> >
> > Linux actually doesn't care if the U-Boot properties are in the tree,
> > so long as we have proper bindings. My point here is we only need
> > either:
> >
> > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > b. two devicetrees, one for use in firmware and one for passing to Linux
> >
> > We don't need to separate out the U-Boot properties into a second (or
> > third) devicetree. There just isn't any point.
>
> Again if we are talking about bindings that are upstream in the spec,
> then we agree. Depending on the SRAM limitation we can even do (a).
> If the vendor messes up the DT backwards compatibility then we can do
> (b). If you expect TF-A and FIP to go pick up the special bindings
> U-Boot needs, then we disagree.
I would certainly prefer to be talking about bindings that are
upstreamed, if they can be upstreamed. I sent a patch with a start on
that and then a PR to the repo here:
https://github.com/devicetree-org/dt-schema/pull/62
So perhaps we should hold off on this and see how progress is in a month or so.
>
> >
> > >
> > > > b) Well then
> > > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > > can merge the two when it starts. Again that is not very efficient. It
> > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > > its public key from there or to enable/disable the console), so
> > > > unified firmware config is not possible. It will get very confusing,
> > > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > > accepting step 3...please stop!
> > > >
> > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > > whole cloth. What about that? Well, we are just going to have to deal
> > > > with that. We can easily merge in the U-Boot nodes/properties and
> > > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > > something similar.
> > > >
> > > > To my mind, that deals with both the build-time and run-time issues.
> > > > We have a discoverable DT in U-Boot, which should be considered the
> > > > source of truth for most boards. We can sync it with Linux
> > > > automatically with the tooling that I hope Rob Herring will come up
> > > > with. We can use an empty one where there really is no default,
> > > > although I'd argue that is making perfect an enemy of the good.
> > > >
> > > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > > and pick them up from somewhere else, we can do that with sufficient
> > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> > >
> > > We can start slowly migrating boards and see how that works out.
> > > We could either use 2 device trees as you proposed, or have u-boot merge
> > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> > > if linux gets handed a clean device tree without the u-boot internals in
> > > it, so I think 2 discrete DTs is cleaner overall.
> >
> > I know you would prefer that, but does it really matter in practice?
> > What is the objection, actually?
> >
> > As I mentioned on the call, I think the prior stage should do any
> > merging or fixing up. Trying to do that sort of thing in 'early' code
> > in U-Boot (or any other program, including Linux) is such a pain. With
> > U-Boot, for example, we don't even have any RAM available to do it
> > with half the time and it would dramatically increase the amount of
> > memory needed prior to relocation. It just isn't a very good idea to
> > try to do this in early code. It is also completely unnecessary, once
> > you get past the philosophical objections.
> >
> > If TF-A wants to be in the picture, let it deal with the implications
> > and responsibility thus incurred. TF-A has no right to tell U-Boot how
> > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> > of the size of U-Boot. It duplicates loads of things in there. No one
> > will even *notice* an FDT merge function, which is actually only 70
> > LOC:
> >
>
> Again I am repeating myself so here's a tl;dr of how I view this:
> 1. All DT bindings u-boot expect become part of the DT spec -- I am
> fine with whatever, since at this point it makes sense to say "You are
> booting u-boot go add whatever it expects, it's part of the spec".
> The prior stage boot loader can then obviously merge the DT fragments
> and everyone will be happy.
> 2. For the bindings that are not upstreamed, I'd prefer having u-boot
> do the fixup. Alternatively, we could provide fragments that are easy
> for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts
> files, find the fragments you need and add them manually...
OK, well then I don't think we have anything of concern here, so long
as we can get the bindings agreed. Let's see how it goes.
Regards,
Simon
>
> [...]
>
> [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG
> [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html
>
> Regards
>
> /Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-11-02 14:59 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-11-02 14:59 UTC (permalink / raw)
To: Ilias Apalodimas
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung,
Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún,
Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp,
Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, François Ozog,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi Ilias,
On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas
<ilias.apalodimas@linaro.org> wrote:
>
> Hi Simon,
>
> On Thu, 28 Oct 2021 at 05:51, Simon Glass <sjg@chromium.org> wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > <ilias.apalodimas@linaro.org> wrote:
> > >
> > > Hi Simon,
> > >
> > > A bit late to the party, sorry!
> >
> > (Did you remember the beer?
>
> We'll probably need something stronger to sort this out :)
Yes I agree!
>
> > I am replying to this but I don't think it
> > is all that helpful for me to reply to a lot of things on this thread,
> > since I would not be adding much to my cover letter and patches)
> >
> > >
> > > [...]
> > >
> > > > >
> > > > > I really want to see what the binary case looks like since we could then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT. It is an abuse of the
> > > > devicetree standard, like the /chosen node but with less history. We
> > > > should sacrifice efficiency, expedience and expandability on the altar
> > > > of 'devicetree is a hardware description'. How do we get over that
> > > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > > for its own purposes, as well as for booting the OS. I am not saying
> > > > it always has to have those properties, but with existing features
> > > > like verified boot, SPL as well as complex firmware images where
> > > > U-Boot needs to be able to find things in the image, it is essential.
> > > > So let's just assume that we need this everywhere, since we certainly
> > > > need it in at least some places.
> > > >
> > > > (stop reading here if you disagree, because nothing below will make
> > > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > > OF_CONTROL :-)
> > >
> > > Having U-Boot keep it's *internal* config state in DTs is fine. Adding
> > > that to the DTs that are copied over from linux isn't imho. There are
> > > various reasons for that. First of all syncing device trees is a huge pain
> > > and that's probably one of the main reasons our DTs are out of sync for a
> > > large number of boards.
> > > The point is this was fine in 2011 were we had SPL only, but the reality
> > > today is completely different. There's previous stage boot loaders (and
> > > enough cases were vendors prefer those over SPL). If that bootloader needs
> > > to use it's own device tree for whatever reason, imposing restrictions on
> > > it wrt to the device tree it has to include, and require them to have
> > > knowledge of U-Boot and it's internal config mechanism makes no sense not
> > > to mention it doesn't scale at all.
> >
> > I think the solution here may be the binman image packer. It works
> > from a description of the image (i.e. is data-driver) and can collect
> > all the pieces together. The U-Boot properties (and the ones required
> > by TF-A, etc.) can be added at package time.
>
> I am not sure I am following you here or why binman is relevant to
> this discussion. If the boot process doesn't require a FIP (e.g SPL
> + U-Boot proper or SPL -> EL3 -> U-Boot proper or TF-A + U-Boot) then
> using binman makes a lot of sense. If the boot process is TF-A ->
> U-Boot and requires a FIP, TF-A has it's own set of tools for
> preparing that [1] [2] , why would we want to teach binman FIP
> packaging? And if we do are you willing to keep it up to date with
> everything they come up with? IOW packaging the firmware is not
> U-Boot's responsibility, it's the vendors. Why should he not be able
> to choose FIP? (ST already changed that in u-boot btw).
Binman is a firmware packager. It seems to be the one that is used
last, to produce the final image, although I am not sure as this seems
quite complicated.
My view on firmware is that we should build it step by step with
individual projects but then package it all at the end and Binman is
designed to do the packaging.
https://u-boot.readthedocs.io/en/latest/develop/package/binman.html#motivation
So I am not sure what problem FIP solves, or why it was invented, Did
we need another firmware format?
But if FIP is important, then yes I think support for it should be
added to Binman. It will make packaging a lot easier.
>
> >
> > If you think about it, it doesn't matter what properties are in the DT
> > that is put into the firmware image. TF-A, for example, is presumably
> > reading a devicetree from flash, so what does it care if it has some
> > U-Boot properties in it?
>
> It doesn't, but the point here is entirely different. Today there's a
> number of U-Boot DTBs that are unable to boot a kernel. The direction
> we would like to is have the firmware provide a DTB that's usable for
> the kernel. Yes I know vendors mess things up and there's a
> correlation of the DTB and the kernel version, but let's set that
> aside for a moment. If we want to use a 'generic' DT then we have to
> make sure that whoever packages it knows what to put in there. That's
> why for me, it's very important to only allow *upstreamed only* DT
> properties for whoever ends up being responsible for the packaging.
> In that case you can demand TF-A to bundle U-Boot nodes in the DTB it
> produces if the board is supposed to use U-Boot. If those are internal
> only to U-Boot and not upstreamed this makes little sense to me and I
> don't see why people will agree to that.
Well I think all of this is taking too much energy...I have stated my
position. U-Boot needs its nodes and properties.
>
> >
> > As to syncing, we have solved this using u-boot.dtsi files in U-Boot,
> > so I think this can be dealt with.
> >
> > >
> > > >
> > > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > > have binman definitions, etc. So we need a way to overlay those things
> > > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > > easy. Just require every board to have an in-tree DT. It helps with
> > > > discoverability and documentation, anyway. That is this series.
> > > >
> > >
> > > Again, the board might decide for it's own reason to provide it's own DT.
> > > IMHO U-Boot must be able to cope with that and asking DTs to be included in
> > > U-Boot source is not the right way to do that, not to mention cases were
> > > that's completely unrealistic (e.g QEMU or a board that reads the DTB from
> > > it's flash).
> >
> > I think you are at step 2. See above for my response.
> >
> > >
> > > > (I think most of us are at the beginning of step 2, unsure about it
> > > > and worried about step 3)
> > > >
> > > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > > flow only, or boards that sometimes use a flow) which need the DT to
> > > > come from a prior stage. How to handle that? IMO that is only going to
> > > > grow as every man and his dog get into the write-a-bootloader
> > > > business.
> > >
> > > And that's exactly why we have to come up with something that scales, without
> > > having to add a bunch of unusable DTs in U-Boot.
> >
> > In what way does this not scale? How are the DTs unusable? If there is
> > a standard binding, we should be fine.
>
> The keyword here is the definition of 'standard'. If standard means
> upstreamed to DT spec, as I said before I don't see any problem. By
> unusable I was referring to the QEMU DTs you are trying to push into
> U-Boot or the RPI one. It doesn't scale because you have to maintain
> and upstream all the DTs in the U-Boot tree. The story so far is
> merge and forget for a big number of DTs, so I find it hard to believe
> that everyone will start behaving and sync up their DTs. I'd much
> rather prefer having a central repo and force people to use that.
Well let's see how it goes. If we can get some validation in place,
then the picture should get better.
>
> >
> > >
> > > > We need a way to provide the U-Boot nodes/properties in a
> > > > form that the prior stage can consume and integrate with its build
> > > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > > together, for example. Or we can get clever and create some sort of
> > > > overlay dtb.
> > > >
> > > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > > then it will need to build it in and use two devicetrees, one internal
> > > > and one from the prior stage....well that is not very efficient and it
> > > > is going to be confusing for people to figure out what U-Boot is
> > > > actually doing. But we actually already do that in a lot of cases
> > > > where U-Boot passes a DT to the kernel which is different to the one
> > > > it uses. So perhaps we have three devicetrees? OMG.
> > >
> > > No we don't. That's a moot point. If you separate the DTs U-Boot
> > > provides the internal one and inherits one 'generic'. Linux will be able to use
> > > that. So the only case were you'll need 3 DTs is if the *vendor* breaks the
> > > DT across kernel versions, In which case there's not much you can do to
> > > begin with and that's already a case we have to deal with.
> >
> > Linux actually doesn't care if the U-Boot properties are in the tree,
> > so long as we have proper bindings. My point here is we only need
> > either:
> >
> > a. one devicetree, shared with Linux and U-Boot (and TF-A?)
> > b. two devicetrees, one for use in firmware and one for passing to Linux
> >
> > We don't need to separate out the U-Boot properties into a second (or
> > third) devicetree. There just isn't any point.
>
> Again if we are talking about bindings that are upstream in the spec,
> then we agree. Depending on the SRAM limitation we can even do (a).
> If the vendor messes up the DT backwards compatibility then we can do
> (b). If you expect TF-A and FIP to go pick up the special bindings
> U-Boot needs, then we disagree.
I would certainly prefer to be talking about bindings that are
upstreamed, if they can be upstreamed. I sent a patch with a start on
that and then a PR to the repo here:
https://github.com/devicetree-org/dt-schema/pull/62
So perhaps we should hold off on this and see how progress is in a month or so.
>
> >
> > >
> > > > b) Well then
> > > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > > can merge the two when it starts. Again that is not very efficient. It
> > > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > > its public key from there or to enable/disable the console), so
> > > > unified firmware config is not possible. It will get very confusing,
> > > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > > accepting step 3...please stop!
> > > >
> > > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > > whole cloth. What about that? Well, we are just going to have to deal
> > > > with that. We can easily merge in the U-Boot nodes/properties and
> > > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > > something similar.
> > > >
> > > > To my mind, that deals with both the build-time and run-time issues.
> > > > We have a discoverable DT in U-Boot, which should be considered the
> > > > source of truth for most boards. We can sync it with Linux
> > > > automatically with the tooling that I hope Rob Herring will come up
> > > > with. We can use an empty one where there really is no default,
> > > > although I'd argue that is making perfect an enemy of the good.
> > > >
> > > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > > and pick them up from somewhere else, we can do that with sufficient
> > > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> > >
> > > We can start slowly migrating boards and see how that works out.
> > > We could either use 2 device trees as you proposed, or have u-boot merge
> > > the 'u-boot' DTB and the inherited DTB before DM comes up. OTOH I'd prefer
> > > if linux gets handed a clean device tree without the u-boot internals in
> > > it, so I think 2 discrete DTs is cleaner overall.
> >
> > I know you would prefer that, but does it really matter in practice?
> > What is the objection, actually?
> >
> > As I mentioned on the call, I think the prior stage should do any
> > merging or fixing up. Trying to do that sort of thing in 'early' code
> > in U-Boot (or any other program, including Linux) is such a pain. With
> > U-Boot, for example, we don't even have any RAM available to do it
> > with half the time and it would dramatically increase the amount of
> > memory needed prior to relocation. It just isn't a very good idea to
> > try to do this in early code. It is also completely unnecessary, once
> > you get past the philosophical objections.
> >
> > If TF-A wants to be in the picture, let it deal with the implications
> > and responsibility thus incurred. TF-A has no right to tell U-Boot how
> > to handle its config. TF-A is 0.5m LOC, i.e. a lot, almost a quarter
> > of the size of U-Boot. It duplicates loads of things in there. No one
> > will even *notice* an FDT merge function, which is actually only 70
> > LOC:
> >
>
> Again I am repeating myself so here's a tl;dr of how I view this:
> 1. All DT bindings u-boot expect become part of the DT spec -- I am
> fine with whatever, since at this point it makes sense to say "You are
> booting u-boot go add whatever it expects, it's part of the spec".
> The prior stage boot loader can then obviously merge the DT fragments
> and everyone will be happy.
> 2. For the bindings that are not upstreamed, I'd prefer having u-boot
> do the fixup. Alternatively, we could provide fragments that are easy
> for TF-A to merge? By easy I don't mean read U-Boot code, it's .dts
> files, find the fragments you need and add them manually...
OK, well then I don't think we have anything of concern here, so long
as we can get the bindings agreed. Let's see how it goes.
Regards,
Simon
>
> [...]
>
> [1] https://wiki.st.com/stm32mpu/wiki/How_to_configure_TF-A_FW_CONFIG
> [2] https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot-build.html
>
> Regards
>
> /Ilias
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-15 18:03 ` Simon Glass
@ 2021-10-27 12:48 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 12:48 UTC (permalink / raw)
To: Simon Glass
Cc: François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 18102 bytes --]
On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> Hi all,
>
> On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > Hi François,
> > > > >
> > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon
> > > > > >
> > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > > > >>
> > > > > >> Hi Tom, Bin,François,
> > > > > >>
> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >> >
> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > >> > > Hi Simon,
> > > > > >> > >
> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > > > >> > > >
> > > > > >> > > > 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 at [1].
> > > > > >> > > >
> > > > > >> > > > 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.
> > > > > >> > >
> > > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > > >> > >
> > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > > > >> > > command line parameters, and the device tree you put in this series
> > > > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > > > >> > > in hand-written dts files.
> > > > > >> > >
> > > > > >> > > I am not sure I understand the whole point of this.
> > > > > >> >
> > > > > >> > I am also confused and do not like the idea of adding device trees for
> > > > > >> > platforms that are capable of and can / do have a device tree to give us
> > > > > >> > at run time.
> > > > > >>
> > > > > >> (I'll just reply to this one email, since the same points applies to
> > > > > >> all replies I think)
> > > > > >>
> > > > > >> I have been thinking about this and discussing it with people for a
> > > > > >> few months now. I've been signalling a change like this for over a
> > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > > >> not a surprise!
> > > > > >>
> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > > >> For more context:
> > > > > >>
> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >>
> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > >> maintainer would prefer there was no special support even for booting
> > > > > >> Linux directly!)
> > > > > >
> > > > > > i understand their point of view and agree with it.
> > > > > >>
> > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > > >> properties in it, if people want to use U-Boot features.
> > > > > >>
> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > > > >> build-time one. It creates all sorts of problems and obscurity which
> > > > > >> have taken months to unpick. See the above patch for the rationale.
> > > > > >>
> > > > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > > > >> any board. At some point in the future it may become a common way
> > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > > > >> to it. It doesn't make any sense to have people decide whether or not
> > > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > > >> together. We'll end up with different U-Boot build targets like
> > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > > > >> explosion is not needed.
> > > > > >
> > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > > > >>
> > > > > >> U-Boot needs to be flexible enough to
> > > > > >> function correctly in whatever runtime environment in which it finds
> > > > > >> itself.
> > > > > >>
> > > > > >> Also as binman is pressed into service more and more to build the
> > > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > > >> definition (in the devicetree) that describes how to create the image.
> > > > > >> We can't support that unless we are building a devicetree, nor can the
> > > > > >> running program access the image layout without that information.
> > > > > >>
> > > > > >> François's point about 'don't use this with any kernel' is
> > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > > > >> don't."). So this series is just completing the picture by enforcing
> > > > > >> that *some sort* of devicetree is always present.
> > > > > >
> > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > >
> > > > > I think the key point that will get you closer to where I am on this
> > > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > > has build-time effects and this is quite wrong. If you go through all
> > > > > the material I have written on this I think I have motivated that very
> > > > > clearly.
> > > > >
> > > > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > > > not two that get merged by U-Boot. Again I have gone through that in a
> > > > > lot of detail.
> > > >
> > > > I have a long long reply to your first reply here saved, but, maybe
> > > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > > needs to support being passed a device tree to use, at run time, yes?
> > >
> > > Yes. The OF_BOARD feature provides this.
> > >
> > > >
> > > > And in that case, would not be using the "fake" tree we built in?
> > >
> > > Not at runtime.
> >
> > OK.
> >
> > > > So is the sticking point here that we really have two classes of
> > > > devices, one class where we will never ever be given the device tree at
> > > > run time (think BeagleBone Black) and one where we will always be given
> > > > one at run time (think Raspberry Pi) ?
> > >
> > > I'm not sure it will be that black and white. I suspect there will be
> > > (many) boards which can boot happily with the U-Boot devicetree but
> > > can also accept one at runtime, if provided. For example, you may want
> > > to boot with or without TF-A or some other, earlier stage.
> >
> > I'm not sure I see the value in making this a gray area. There's very
> > much a class of "never" boards. There's also the class of "can" today.
> > Maybe as part of a developer iterative flow it would be nice to not have
> > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > until things are happy, but I'm not sure what the use case is for
> > overriding the previous stage.
> >
> > Especially since the pushback on this series I think has all been "why
> > are we copying in a tree to build with? We don't want to use it at run
> > time!". And then softer push back like "Well, U-Boot says we have to
> > include the device tree file here, but we won't use it...".
>
> See below.
>
> >
> > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > things like binman and U-Boot /config impossible, for example. So I
> > > want to claw that back, so there is always some sort of devicetree in
> > > U-Boot, as we have for rpi_3, etc.
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
>
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.
Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
that know where to grab other known-good binaries of varying licenses
that are needed to assemble something that boots.
> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
>
> Anyway, here are the mental steps that I've gone through over the past
> two months:
>
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying
Yes, we need to have properties present in the device tree, and just
like how "linux," is a valid vendor prefix for the linux kernel (but not
used I would expect by the BSD families) we have cases that need
"u-boot," properties.
> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.
No, we can't / shouldn't assume we need this everywhere. A lot of
places? Yes. But some features are going to be optional. A valid must
be supported use case is something like a Pi where the hardware gives us
a device tree, the tree is correct and some features in U-Boot aren't
needed (SPL) nor possibly supported immediately (verified boot). We can
go off on a tangent about how useful it would be to have HW platforms
that are both common and can demonstrate a number of features, but
that's its own problem to solve.
> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
>
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
>
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business. We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can get clever and create some sort of
> overlay dtb.
>
> Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> then it will need to build it in and use two devicetrees, one internal
> and one from the prior stage....well that is not very efficient and it
> is going to be confusing for people to figure out what U-Boot is
> actually doing. But we actually already do that in a lot of cases
> where U-Boot passes a DT to the kernel which is different to the one
> it uses. So perhaps we have three devicetrees? OMG. b) Well then
> U-Boot can have its own small devicetree with its bits and then U-Boot
> can merge the two when it starts. Again that is not very efficient. It
> means that U-Boot cannot be controlled by the prior stage (e.g. to get
> its public key from there or to enable/disable the console), so
> unified firmware config is not possible. It will get very confusing,
> particularly for debugging U-Boot. c) Some other scheme to avoid
> accepting step 3...please stop!
How the nodes should get there is how the rest of the nodes in a system
get there. Bindings are submitted and reviewed. The authoritative
source of the dtses in question then has them, like any other property.
> Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> whole cloth. What about that? Well, we are just going to have to deal
> with that. We can easily merge in the U-Boot nodes/properties and
> update the U-Boot CI scripts to do this, as needed, e.g. with
> qemu-riscv64_spl. It's only one use case, although Xen might do
> something similar.
>
> To my mind, that deals with both the build-time and run-time issues.
> We have a discoverable DT in U-Boot, which should be considered the
> source of truth for most boards. We can sync it with Linux
> automatically with the tooling that I hope Rob Herring will come up
> with. We can use an empty one where there really is no default,
> although I'd argue that is making perfect an enemy of the good.
>
> Step 5: If we get clever and want to remove them from the U-Boot tree
> and pick them up from somewhere else, we can do that with sufficient
> tooling. Perhaps we should set a timeline for that? A year? Two? Six?
These last two paragraphs condense what I think is honestly close to a
decade of debate / discussion down to a fiat "U-Boot will have the DTS
files". I don't want that. I don't think any of the other projects
that want to leverage DTS files want that.
> To repeat, if we set things up correctly and agree on the bindings,
> devicetree can be the unifying configuration mechanism through the
> whole of firmware (except for very early bits) and into the OS. I feel
> this will set us up very well to deal with the complexity that is
> coming.
Sure, it could. But that doesn't mean that U-Boot is where the dts
files live.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 12:48 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 12:48 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 18102 bytes --]
On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> Hi all,
>
> On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > Hi Tom,
> > >
> > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > Hi François,
> > > > >
> > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > > > >
> > > > > > Hi Simon
> > > > > >
> > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > > > >>
> > > > > >> Hi Tom, Bin,François,
> > > > > >>
> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > > > >> >
> > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > >> > > Hi Simon,
> > > > > >> > >
> > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > > > >> > > >
> > > > > >> > > > 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 at [1].
> > > > > >> > > >
> > > > > >> > > > 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.
> > > > > >> > >
> > > > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > > > >> > >
> > > > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > > > >> > > command line parameters, and the device tree you put in this series
> > > > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > > > >> > > in hand-written dts files.
> > > > > >> > >
> > > > > >> > > I am not sure I understand the whole point of this.
> > > > > >> >
> > > > > >> > I am also confused and do not like the idea of adding device trees for
> > > > > >> > platforms that are capable of and can / do have a device tree to give us
> > > > > >> > at run time.
> > > > > >>
> > > > > >> (I'll just reply to this one email, since the same points applies to
> > > > > >> all replies I think)
> > > > > >>
> > > > > >> I have been thinking about this and discussing it with people for a
> > > > > >> few months now. I've been signalling a change like this for over a
> > > > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > > > >> not a surprise!
> > > > > >>
> > > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > > >> For more context:
> > > > > >>
> > > > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > >>
> > > > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > >> maintainer would prefer there was no special support even for booting
> > > > > >> Linux directly!)
> > > > > >
> > > > > > i understand their point of view and agree with it.
> > > > > >>
> > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > > >> properties in it, if people want to use U-Boot features.
> > > > > >>
> > > > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > > > >> build-time one. It creates all sorts of problems and obscurity which
> > > > > >> have taken months to unpick. See the above patch for the rationale.
> > > > > >>
> > > > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > > > >> any board. At some point in the future it may become a common way
> > > > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > > > >> to it. It doesn't make any sense to have people decide whether or not
> > > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > > >> together. We'll end up with different U-Boot build targets like
> > > > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > > > >> explosion is not needed.
> > > > > >
> > > > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > > > >>
> > > > > >> U-Boot needs to be flexible enough to
> > > > > >> function correctly in whatever runtime environment in which it finds
> > > > > >> itself.
> > > > > >>
> > > > > >> Also as binman is pressed into service more and more to build the
> > > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > > >> definition (in the devicetree) that describes how to create the image.
> > > > > >> We can't support that unless we are building a devicetree, nor can the
> > > > > >> running program access the image layout without that information.
> > > > > >>
> > > > > >> François's point about 'don't use this with any kernel' is
> > > > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > > > >> don't."). So this series is just completing the picture by enforcing
> > > > > >> that *some sort* of devicetree is always present.
> > > > > >
> > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > >
> > > > > I think the key point that will get you closer to where I am on this
> > > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > > has build-time effects and this is quite wrong. If you go through all
> > > > > the material I have written on this I think I have motivated that very
> > > > > clearly.
> > > > >
> > > > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > > > not two that get merged by U-Boot. Again I have gone through that in a
> > > > > lot of detail.
> > > >
> > > > I have a long long reply to your first reply here saved, but, maybe
> > > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > > needs to support being passed a device tree to use, at run time, yes?
> > >
> > > Yes. The OF_BOARD feature provides this.
> > >
> > > >
> > > > And in that case, would not be using the "fake" tree we built in?
> > >
> > > Not at runtime.
> >
> > OK.
> >
> > > > So is the sticking point here that we really have two classes of
> > > > devices, one class where we will never ever be given the device tree at
> > > > run time (think BeagleBone Black) and one where we will always be given
> > > > one at run time (think Raspberry Pi) ?
> > >
> > > I'm not sure it will be that black and white. I suspect there will be
> > > (many) boards which can boot happily with the U-Boot devicetree but
> > > can also accept one at runtime, if provided. For example, you may want
> > > to boot with or without TF-A or some other, earlier stage.
> >
> > I'm not sure I see the value in making this a gray area. There's very
> > much a class of "never" boards. There's also the class of "can" today.
> > Maybe as part of a developer iterative flow it would be nice to not have
> > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > until things are happy, but I'm not sure what the use case is for
> > overriding the previous stage.
> >
> > Especially since the pushback on this series I think has all been "why
> > are we copying in a tree to build with? We don't want to use it at run
> > time!". And then softer push back like "Well, U-Boot says we have to
> > include the device tree file here, but we won't use it...".
>
> See below.
>
> >
> > > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > things like binman and U-Boot /config impossible, for example. So I
> > > want to claw that back, so there is always some sort of devicetree in
> > > U-Boot, as we have for rpi_3, etc.
> >
> > I really want to see what the binary case looks like since we could then
> > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > then also do a rpi_arm32_defconfig too.
> >
> > I want to see less device trees in U-Boot sources, if they can come
> > functionally correct from the hardware/our caller.
> >
> > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > use the device tree from build time at run time, ignoring the device
> > tree provided to us at run time by the caller.
>
> Firstly I should say that I find building firmware very messy and
> confusing these days. Lots of things to build and it's hard to find
> the instructions. It doesn't have to be that way, but if we carry on
> as we are, it will continue to be messy and in five years you will
> need a Ph.D and a lucky charm to boot on any modern board. My
> objective here is to simplify things, bringing some consistency to the
> different components. Binman was one effort there. I feel that putting
> at least the U-Boot house in order, in my role as devicetree
> maintainer (and as author of devicetree support in U-Boot back in
> 2011), is the next step.
Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
that know where to grab other known-good binaries of varying licenses
that are needed to assemble something that boots.
> If we set things up correctly and agree on the bindings, devicetree
> can be the unifying configuration mechanism through the whole of
> firmware (except for very early bits) and into the OS, this will set
> us up very well to deal with the complexity that is coming.
>
> Anyway, here are the mental steps that I've gone through over the past
> two months:
>
> Step 1: At present, some people think U-Boot is not even allowed to
> have its own nodes/properties in the DT. It is an abuse of the
> devicetree standard, like the /chosen node but with less history. We
> should sacrifice efficiency, expedience and expandability on the altar
> of 'devicetree is a hardware description'. How do we get over that
> one? Wel, I just think we need to accept that U-Boot uses devicetree
> for its own purposes, as well as for booting the OS. I am not saying
Yes, we need to have properties present in the device tree, and just
like how "linux," is a valid vendor prefix for the linux kernel (but not
used I would expect by the BSD families) we have cases that need
"u-boot," properties.
> it always has to have those properties, but with existing features
> like verified boot, SPL as well as complex firmware images where
> U-Boot needs to be able to find things in the image, it is essential.
> So let's just assume that we need this everywhere, since we certainly
> need it in at least some places.
No, we can't / shouldn't assume we need this everywhere. A lot of
places? Yes. But some features are going to be optional. A valid must
be supported use case is something like a Pi where the hardware gives us
a device tree, the tree is correct and some features in U-Boot aren't
needed (SPL) nor possibly supported immediately (verified boot). We can
go off on a tangent about how useful it would be to have HW platforms
that are both common and can demonstrate a number of features, but
that's its own problem to solve.
> (stop reading here if you disagree, because nothing below will make
> any sense...you can still use U-Boot v2011.06 which doesn't have
> OF_CONTROL :-)
>
> Step 2: Assume U-Boot has its own nodes/properties. How do they get
> there? Well, we have u-boot.dtsi files for that (the 2016 patch
> "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> have binman definitions, etc. So we need a way to overlay those things
> into the DT. We already support this for in-tree DTs, so IMO this is
> easy. Just require every board to have an in-tree DT. It helps with
> discoverability and documentation, anyway. That is this series.
>
> (I think most of us are at the beginning of step 2, unsure about it
> and worried about step 3)
>
> Step 3: Ah, but there are flows (i.e. boards that use a particular
> flow only, or boards that sometimes use a flow) which need the DT to
> come from a prior stage. How to handle that? IMO that is only going to
> grow as every man and his dog get into the write-a-bootloader
> business. We need a way to provide the U-Boot nodes/properties in a
> form that the prior stage can consume and integrate with its build
> system. Is TF-A the only thing being discussed here? If so, let's just
> do it. We have the u-boot.dtsi and we can use binman to put the image
> together, for example. Or we can get clever and create some sort of
> overlay dtb.
>
> Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> then it will need to build it in and use two devicetrees, one internal
> and one from the prior stage....well that is not very efficient and it
> is going to be confusing for people to figure out what U-Boot is
> actually doing. But we actually already do that in a lot of cases
> where U-Boot passes a DT to the kernel which is different to the one
> it uses. So perhaps we have three devicetrees? OMG. b) Well then
> U-Boot can have its own small devicetree with its bits and then U-Boot
> can merge the two when it starts. Again that is not very efficient. It
> means that U-Boot cannot be controlled by the prior stage (e.g. to get
> its public key from there or to enable/disable the console), so
> unified firmware config is not possible. It will get very confusing,
> particularly for debugging U-Boot. c) Some other scheme to avoid
> accepting step 3...please stop!
How the nodes should get there is how the rest of the nodes in a system
get there. Bindings are submitted and reviewed. The authoritative
source of the dtses in question then has them, like any other property.
> Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> whole cloth. What about that? Well, we are just going to have to deal
> with that. We can easily merge in the U-Boot nodes/properties and
> update the U-Boot CI scripts to do this, as needed, e.g. with
> qemu-riscv64_spl. It's only one use case, although Xen might do
> something similar.
>
> To my mind, that deals with both the build-time and run-time issues.
> We have a discoverable DT in U-Boot, which should be considered the
> source of truth for most boards. We can sync it with Linux
> automatically with the tooling that I hope Rob Herring will come up
> with. We can use an empty one where there really is no default,
> although I'd argue that is making perfect an enemy of the good.
>
> Step 5: If we get clever and want to remove them from the U-Boot tree
> and pick them up from somewhere else, we can do that with sufficient
> tooling. Perhaps we should set a timeline for that? A year? Two? Six?
These last two paragraphs condense what I think is honestly close to a
decade of debate / discussion down to a fiat "U-Boot will have the DTS
files". I don't want that. I don't think any of the other projects
that want to leverage DTS files want that.
> To repeat, if we set things up correctly and agree on the bindings,
> devicetree can be the unifying configuration mechanism through the
> whole of firmware (except for very early bits) and into the OS. I feel
> this will set us up very well to deal with the complexity that is
> coming.
Sure, it could. But that doesn't mean that U-Boot is where the dts
files live.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 12:48 ` Tom Rini
@ 2021-10-27 13:15 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:15 UTC (permalink / raw)
To: Tom Rini
Cc: Simon Glass, Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi,
On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > Hi François,
> > > > > >
> > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> a écrit :
> > > > > > >>
> > > > > > >> Hi Tom, Bin,François,
> > > > > > >>
> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >> >
> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > >> > > Hi Simon,
> > > > > > >> > >
> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> sjg@chromium.org> wrote:
> > > > > > >> > > >
> > > > > > >> > > > 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 at [1].
> > > > > > >> > > >
> > > > > > >> > > > 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.
> > > > > > >> > >
> > > > > > >> > > Adding device trees that are never used sounds like a
> hack to me.
> > > > > > >> > >
> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > > > >> > > command line parameters, and the device tree you put in
> this series
> > > > > > >> > > has various hardcoded <phandle> values which normally do
> not show up
> > > > > > >> > > in hand-written dts files.
> > > > > > >> > >
> > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > >> >
> > > > > > >> > I am also confused and do not like the idea of adding
> device trees for
> > > > > > >> > platforms that are capable of and can / do have a device
> tree to give us
> > > > > > >> > at run time.
> > > > > > >>
> > > > > > >> (I'll just reply to this one email, since the same points
> applies to
> > > > > > >> all replies I think)
> > > > > > >>
> > > > > > >> I have been thinking about this and discussing it with people
> for a
> > > > > > >> few months now. I've been signalling a change like this for
> over a
> > > > > > >> month now, on U-Boot contributor calls and in discussions
> with Linaro
> > > > > > >> people. I sent a patch (below) to try to explain things. I
> hope it is
> > > > > > >> not a surprise!
> > > > > > >>
> > > > > > >> The issue here is that we need a devicetree in-tree in
> U-Boot, to
> > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> OF_BOARD,
> > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> Between
> > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> use.
> > > > > > >> For more context:
> > > > > > >>
> > > > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > >>
> > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> adding the
> > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > >> maintainer would prefer there was no special support even for
> booting
> > > > > > >> Linux directly!)
> > > > > > >
> > > > > > > i understand their point of view and agree with it.
> > > > > > >>
> > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > >> think the path forward might be to run QEMU twice, once to
> get its
> > > > > > >> generated tree and once to give the 'merged' tree with the
> U-Boot
> > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > >>
> > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> option, not a
> > > > > > >> build-time one. It creates all sorts of problems and
> obscurity which
> > > > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > > > >>
> > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > > > >> any board. At some point in the future it may become a common
> way
> > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > > > >> to it. It doesn't make any sense to have people decide
> whether or not
> > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> is put
> > > > > > >> together. We'll end up with different U-Boot build targets
> like
> > > > > > >> capricorn, capricorn_of_board and the like. It should be
> obvious where
> > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> used
> > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> of build
> > > > > > >> explosion is not needed.
> > > > > > >
> > > > > > > If you mean that when boards are by construction providing a
> DTB to U-Boot then I agree very much. But I don’t understand how the patch
> set supports it as it puts dts files for those boards to be built.
> > > > > > >>
> > > > > > >> U-Boot needs to be flexible enough to
> > > > > > >> function correctly in whatever runtime environment in which
> it finds
> > > > > > >> itself.
> > > > > > >>
> > > > > > >> Also as binman is pressed into service more and more to build
> the
> > > > > > >> complex firmware images that are becoming fashionable, it
> needs a
> > > > > > >> definition (in the devicetree) that describes how to create
> the image.
> > > > > > >> We can't support that unless we are building a devicetree,
> nor can the
> > > > > > >> running program access the image layout without that
> information.
> > > > > > >>
> > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > > > >> is, still, enabled. We already use OF_BOARD for various
> boards that
> > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > > > >> (as I said in the cover letter "Most boards do provide one,
> but some
> > > > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > > > >> that *some sort* of devicetree is always present.
> > > > > > >
> > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > >
> > > > > > I think the key point that will get you closer to where I am on
> this
> > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> present it
> > > > > > has build-time effects and this is quite wrong. If you go
> through all
> > > > > > the material I have written on this I think I have motivated
> that very
> > > > > > clearly.
> > > > > >
> > > > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > > > not two that get merged by U-Boot. Again I have gone through
> that in a
> > > > > > lot of detail.
> > > > >
> > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > here's the biggest sticking point. To be clear, you agree that
> U-Boot
> > > > > needs to support being passed a device tree to use, at run time,
> yes?
> > > >
> > > > Yes. The OF_BOARD feature provides this.
> > > >
> > > > >
> > > > > And in that case, would not be using the "fake" tree we built in?
> > > >
> > > > Not at runtime.
> > >
> > > OK.
> > >
> > > > > So is the sticking point here that we really have two classes of
> > > > > devices, one class where we will never ever be given the device
> tree at
> > > > > run time (think BeagleBone Black) and one where we will always be
> given
> > > > > one at run time (think Raspberry Pi) ?
> > > >
> > > > I'm not sure it will be that black and white. I suspect there will be
> > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > can also accept one at runtime, if provided. For example, you may
> want
> > > > to boot with or without TF-A or some other, earlier stage.
> > >
> > > I'm not sure I see the value in making this a gray area. There's very
> > > much a class of "never" boards. There's also the class of "can" today.
> > > Maybe as part of a developer iterative flow it would be nice to not
> have
> > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > until things are happy, but I'm not sure what the use case is for
> > > overriding the previous stage.
> > >
> > > Especially since the pushback on this series I think has all been "why
> > > are we copying in a tree to build with? We don't want to use it at run
> > > time!". And then softer push back like "Well, U-Boot says we have to
> > > include the device tree file here, but we won't use it...".
> >
> > See below.
> >
> > >
> > > > I believe we have got unstuck because OF_BOARD (perhaps
> inadvertently)
> > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > things like binman and U-Boot /config impossible, for example. So I
> > > > want to claw that back, so there is always some sort of devicetree in
> > > > U-Boot, as we have for rpi_3, etc.
> > >
> > > I really want to see what the binary case looks like since we could
> then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
>
> Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> that know where to grab other known-good binaries of varying licenses
> that are needed to assemble something that boots.
>
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT.
In my view U-Boot shall be able to leverage device tree format (source and
binary) to store its own data.
When you say "the" DT, I always think this is "the" DT that is passed to OS
and in "that" DT, there should be no U-Boot entries. As stated in another
mail thread, I also refer to a place in a FIP where that dynamic config DT
is meant to be stored: NT_FW_CONFIG.
But there can be U-Boot defined bindings in "a" control/dynamic config DT;
Trusted Firmware does that.
> It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
>
> Yes, we need to have properties present in the device tree, and just
> like how "linux," is a valid vendor prefix for the linux kernel (but not
> used I would expect by the BSD families) we have cases that need
> "u-boot," properties.
>
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
>
> No, we can't / shouldn't assume we need this everywhere. A lot of
> places? Yes. But some features are going to be optional. A valid must
> be supported use case is something like a Pi where the hardware gives us
> a device tree, the tree is correct and some features in U-Boot aren't
> needed (SPL) nor possibly supported immediately (verified boot). We can
> go off on a tangent about how useful it would be to have HW platforms
> that are both common and can demonstrate a number of features, but
> that's its own problem to solve.
>
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business. We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient.
Does not need to merge the two. hence it does not have any influence on
efficiency.
For properties access, trusted firmware has defined an abstract way to get
them:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
.
The properties are currently implemented as DT but TF.ORG could decide to
move to CBOR.
The API will remain so that a change in backend will not influence existing
code.
I think you are too focused on "THE" device tree. "THE" device tree that is
passed to the OS
shall be hardware description and not a hacky place to fit any piece of
metadata.
I would argue that /chosen shall not even be there as most if not all
information can be passed as OS command line. And actually for the UEFI
contract, /chosen should go empty.
> It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
>
> How the nodes should get there is how the rest of the nodes in a system
> get there. Bindings are submitted and reviewed. The authoritative
> source of the dtses in question then has them, like any other property.
>
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> For SystemReady compliant boards, this has to come much faster.
Do you think distros will keep providing DTs for ever? I bet not.
> These last two paragraphs condense what I think is honestly close to a
> decade of debate / discussion down to a fiat "U-Boot will have the DTS
> files". I don't want that. I don't think any of the other projects
> that want to leverage DTS files want that.
>
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I feel
> > this will set us up very well to deal with the complexity that is
> > coming.
>
> Sure, it could. But that doesn't mean that U-Boot is where the dts
> files live.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:15 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 13:15 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 20593 bytes --]
Hi,
On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > Hi François,
> > > > > >
> > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > > > >
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> a écrit :
> > > > > > >>
> > > > > > >> Hi Tom, Bin,François,
> > > > > > >>
> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >> >
> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > >> > > Hi Simon,
> > > > > > >> > >
> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> sjg@chromium.org> wrote:
> > > > > > >> > > >
> > > > > > >> > > > 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 at [1].
> > > > > > >> > > >
> > > > > > >> > > > 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.
> > > > > > >> > >
> > > > > > >> > > Adding device trees that are never used sounds like a
> hack to me.
> > > > > > >> > >
> > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > > > >> > > command line parameters, and the device tree you put in
> this series
> > > > > > >> > > has various hardcoded <phandle> values which normally do
> not show up
> > > > > > >> > > in hand-written dts files.
> > > > > > >> > >
> > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > >> >
> > > > > > >> > I am also confused and do not like the idea of adding
> device trees for
> > > > > > >> > platforms that are capable of and can / do have a device
> tree to give us
> > > > > > >> > at run time.
> > > > > > >>
> > > > > > >> (I'll just reply to this one email, since the same points
> applies to
> > > > > > >> all replies I think)
> > > > > > >>
> > > > > > >> I have been thinking about this and discussing it with people
> for a
> > > > > > >> few months now. I've been signalling a change like this for
> over a
> > > > > > >> month now, on U-Boot contributor calls and in discussions
> with Linaro
> > > > > > >> people. I sent a patch (below) to try to explain things. I
> hope it is
> > > > > > >> not a surprise!
> > > > > > >>
> > > > > > >> The issue here is that we need a devicetree in-tree in
> U-Boot, to
> > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> OF_BOARD,
> > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> Between
> > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> use.
> > > > > > >> For more context:
> > > > > > >>
> > > > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > >>
> > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> adding the
> > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > >> maintainer would prefer there was no special support even for
> booting
> > > > > > >> Linux directly!)
> > > > > > >
> > > > > > > i understand their point of view and agree with it.
> > > > > > >>
> > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > >> think the path forward might be to run QEMU twice, once to
> get its
> > > > > > >> generated tree and once to give the 'merged' tree with the
> U-Boot
> > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > >>
> > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> option, not a
> > > > > > >> build-time one. It creates all sorts of problems and
> obscurity which
> > > > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > > > >>
> > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > > > >> any board. At some point in the future it may become a common
> way
> > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > > > >> to it. It doesn't make any sense to have people decide
> whether or not
> > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> is put
> > > > > > >> together. We'll end up with different U-Boot build targets
> like
> > > > > > >> capricorn, capricorn_of_board and the like. It should be
> obvious where
> > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> used
> > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> of build
> > > > > > >> explosion is not needed.
> > > > > > >
> > > > > > > If you mean that when boards are by construction providing a
> DTB to U-Boot then I agree very much. But I don’t understand how the patch
> set supports it as it puts dts files for those boards to be built.
> > > > > > >>
> > > > > > >> U-Boot needs to be flexible enough to
> > > > > > >> function correctly in whatever runtime environment in which
> it finds
> > > > > > >> itself.
> > > > > > >>
> > > > > > >> Also as binman is pressed into service more and more to build
> the
> > > > > > >> complex firmware images that are becoming fashionable, it
> needs a
> > > > > > >> definition (in the devicetree) that describes how to create
> the image.
> > > > > > >> We can't support that unless we are building a devicetree,
> nor can the
> > > > > > >> running program access the image layout without that
> information.
> > > > > > >>
> > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > > > >> is, still, enabled. We already use OF_BOARD for various
> boards that
> > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > > > >> (as I said in the cover letter "Most boards do provide one,
> but some
> > > > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > > > >> that *some sort* of devicetree is always present.
> > > > > > >
> > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > >
> > > > > > I think the key point that will get you closer to where I am on
> this
> > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> present it
> > > > > > has build-time effects and this is quite wrong. If you go
> through all
> > > > > > the material I have written on this I think I have motivated
> that very
> > > > > > clearly.
> > > > > >
> > > > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > > > not two that get merged by U-Boot. Again I have gone through
> that in a
> > > > > > lot of detail.
> > > > >
> > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > here's the biggest sticking point. To be clear, you agree that
> U-Boot
> > > > > needs to support being passed a device tree to use, at run time,
> yes?
> > > >
> > > > Yes. The OF_BOARD feature provides this.
> > > >
> > > > >
> > > > > And in that case, would not be using the "fake" tree we built in?
> > > >
> > > > Not at runtime.
> > >
> > > OK.
> > >
> > > > > So is the sticking point here that we really have two classes of
> > > > > devices, one class where we will never ever be given the device
> tree at
> > > > > run time (think BeagleBone Black) and one where we will always be
> given
> > > > > one at run time (think Raspberry Pi) ?
> > > >
> > > > I'm not sure it will be that black and white. I suspect there will be
> > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > can also accept one at runtime, if provided. For example, you may
> want
> > > > to boot with or without TF-A or some other, earlier stage.
> > >
> > > I'm not sure I see the value in making this a gray area. There's very
> > > much a class of "never" boards. There's also the class of "can" today.
> > > Maybe as part of a developer iterative flow it would be nice to not
> have
> > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > until things are happy, but I'm not sure what the use case is for
> > > overriding the previous stage.
> > >
> > > Especially since the pushback on this series I think has all been "why
> > > are we copying in a tree to build with? We don't want to use it at run
> > > time!". And then softer push back like "Well, U-Boot says we have to
> > > include the device tree file here, but we won't use it...".
> >
> > See below.
> >
> > >
> > > > I believe we have got unstuck because OF_BOARD (perhaps
> inadvertently)
> > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > things like binman and U-Boot /config impossible, for example. So I
> > > > want to claw that back, so there is always some sort of devicetree in
> > > > U-Boot, as we have for rpi_3, etc.
> > >
> > > I really want to see what the binary case looks like since we could
> then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > use the device tree from build time at run time, ignoring the device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency to the
> > different components. Binman was one effort there. I feel that putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
>
> Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> that know where to grab other known-good binaries of varying licenses
> that are needed to assemble something that boots.
>
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT.
In my view U-Boot shall be able to leverage device tree format (source and
binary) to store its own data.
When you say "the" DT, I always think this is "the" DT that is passed to OS
and in "that" DT, there should be no U-Boot entries. As stated in another
mail thread, I also refer to a place in a FIP where that dynamic config DT
is meant to be stored: NT_FW_CONFIG.
But there can be U-Boot defined bindings in "a" control/dynamic config DT;
Trusted Firmware does that.
> It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
>
> Yes, we need to have properties present in the device tree, and just
> like how "linux," is a valid vendor prefix for the linux kernel (but not
> used I would expect by the BSD families) we have cases that need
> "u-boot," properties.
>
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
>
> No, we can't / shouldn't assume we need this everywhere. A lot of
> places? Yes. But some features are going to be optional. A valid must
> be supported use case is something like a Pi where the hardware gives us
> a device tree, the tree is correct and some features in U-Boot aren't
> needed (SPL) nor possibly supported immediately (verified boot). We can
> go off on a tangent about how useful it would be to have HW platforms
> that are both common and can demonstrate a number of features, but
> that's its own problem to solve.
>
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only going to
> > grow as every man and his dog get into the write-a-bootloader
> > business. We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one internal
> > and one from the prior stage....well that is not very efficient and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > U-Boot can have its own small devicetree with its bits and then U-Boot
> > can merge the two when it starts. Again that is not very efficient.
Does not need to merge the two. hence it does not have any influence on
efficiency.
For properties access, trusted firmware has defined an abstract way to get
them:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
.
The properties are currently implemented as DT but TF.ORG could decide to
move to CBOR.
The API will remain so that a change in backend will not influence existing
code.
I think you are too focused on "THE" device tree. "THE" device tree that is
passed to the OS
shall be hardware description and not a hacky place to fit any piece of
metadata.
I would argue that /chosen shall not even be there as most if not all
information can be passed as OS command line. And actually for the UEFI
contract, /chosen should go empty.
> It
> > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
>
> How the nodes should get there is how the rest of the nodes in a system
> get there. Bindings are submitted and reviewed. The authoritative
> source of the dtses in question then has them, like any other property.
>
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> For SystemReady compliant boards, this has to come much faster.
Do you think distros will keep providing DTs for ever? I bet not.
> These last two paragraphs condense what I think is honestly close to a
> decade of debate / discussion down to a fiat "U-Boot will have the DTS
> files". I don't want that. I don't think any of the other projects
> that want to leverage DTS files want that.
>
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I feel
> > this will set us up very well to deal with the complexity that is
> > coming.
>
> Sure, it could. But that doesn't mean that U-Boot is where the dts
> files live.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 28207 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:15 ` François Ozog
@ 2021-10-27 13:23 ` Heinrich Schuchardt
-1 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-27 13:23 UTC (permalink / raw)
To: François Ozog, Tom Rini
Cc: Simon Glass, Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt, Ilias Apalodimas,
Jagan Teki, Jerry Van Baren, Kever Yang, Leo, Linus Walleij,
Liviu Dudau, Marek Behún, Matthias Brugger, Michal Simek,
Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
On 10/27/21 15:15, François Ozog wrote:
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
>
> On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
> > >
> > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > Hi François,
> > > > > >
> > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog
> <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> wrote:
> > > > > > >
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass
> <sjg@chromium.org <mailto:sjg@chromium.org>> a écrit :
> > > > > > >>
> > > > > > >> Hi Tom, Bin,François,
> > > > > > >>
> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini
> <trini@konsulko.com <mailto:trini@konsulko.com>> wrote:
> > > > > > >> >
> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > >> > > Hi Simon,
> > > > > > >> > >
> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass
> <sjg@chromium.org <mailto:sjg@chromium.org>> wrote:
> > > > > > >> > > >
> > > > > > >> > > > 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
> at [1].
> > > > > > >> > > >
> > > > > > >> > > > 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.
> > > > > > >> > >
> > > > > > >> > > Adding device trees that are never used sounds
> like a hack to me.
> > > > > > >> > >
> > > > > > >> > > For QEMU, device tree is dynamically generated on
> the fly based on
> > > > > > >> > > command line parameters, and the device tree you
> put in this series
> > > > > > >> > > has various hardcoded <phandle> values which
> normally do not show up
> > > > > > >> > > in hand-written dts files.
> > > > > > >> > >
> > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > >> >
> > > > > > >> > I am also confused and do not like the idea of
> adding device trees for
> > > > > > >> > platforms that are capable of and can / do have a
> device tree to give us
> > > > > > >> > at run time.
> > > > > > >>
> > > > > > >> (I'll just reply to this one email, since the same
> points applies to
> > > > > > >> all replies I think)
> > > > > > >>
> > > > > > >> I have been thinking about this and discussing it with
> people for a
> > > > > > >> few months now. I've been signalling a change like
> this for over a
> > > > > > >> month now, on U-Boot contributor calls and in
> discussions with Linaro
> > > > > > >> people. I sent a patch (below) to try to explain
> things. I hope it is
> > > > > > >> not a surprise!
> > > > > > >>
> > > > > > >> The issue here is that we need a devicetree in-tree in
> U-Boot, to
> > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE, OF_BOARD,
> > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE. Between
> > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger footing.
> > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF use.
> > > > > > >> For more context:
> > > > > > >>
> > > > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> <http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/>
> > > > > > >>
> > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of adding the
> > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > >> maintainer would prefer there was no special support
> even for booting
> > > > > > >> Linux directly!)
> > > > > > >
> > > > > > > i understand their point of view and agree with it.
> > > > > > >>
> > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > >> think the path forward might be to run QEMU twice,
> once to get its
> > > > > > >> generated tree and once to give the 'merged' tree with
> the U-Boot
> > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > >>
> > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> option, not a
> > > > > > >> build-time one. It creates all sorts of problems and
> obscurity which
> > > > > > >> have taken months to unpick. See the above patch for
> the rationale.
> > > > > > >>
> > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option available to
> > > > > > >> any board. At some point in the future it may become a
> common way
> > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a devicetree
> > > > > > >> to it. It doesn't make any sense to have people decide
> whether or not
> > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image is put
> > > > > > >> together. We'll end up with different U-Boot build
> targets like
> > > > > > >> capricorn, capricorn_of_board and the like. It should
> be obvious where
> > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly used
> > > > > > >> option, perhaps enabled by most/all boards, so that
> this sort of build
> > > > > > >> explosion is not needed.
> > > > > > >
> > > > > > > If you mean that when boards are by construction
> providing a DTB to U-Boot then I agree very much. But I don’t
> understand how the patch set supports it as it puts dts files for
> those boards to be built.
> > > > > > >>
> > > > > > >> U-Boot needs to be flexible enough to
> > > > > > >> function correctly in whatever runtime environment in
> which it finds
> > > > > > >> itself.
> > > > > > >>
> > > > > > >> Also as binman is pressed into service more and more
> to build the
> > > > > > >> complex firmware images that are becoming fashionable,
> it needs a
> > > > > > >> definition (in the devicetree) that describes how to
> create the image.
> > > > > > >> We can't support that unless we are building a
> devicetree, nor can the
> > > > > > >> running program access the image layout without that
> information.
> > > > > > >>
> > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > >> germane...but of course I am not suggesting doing
> that, since OF_BOARD
> > > > > > >> is, still, enabled. We already use OF_BOARD for
> various boards that
> > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3, for example
> > > > > > >> (as I said in the cover letter "Most boards do provide
> one, but some
> > > > > > >> don't."). So this series is just completing the
> picture by enforcing
> > > > > > >> that *some sort* of devicetree is always present.
> > > > > > >
> > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > >
> > > > > > I think the key point that will get you closer to where I
> am on this
> > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> present it
> > > > > > has build-time effects and this is quite wrong. If you go
> through all
> > > > > > the material I have written on this I think I have
> motivated that very
> > > > > > clearly.
> > > > > >
> > > > > > Another big issue is that I believe we need ONE
> devicetree for U-Boot,
> > > > > > not two that get merged by U-Boot. Again I have gone
> through that in a
> > > > > > lot of detail.
> > > > >
> > > > > I have a long long reply to your first reply here saved,
> but, maybe
> > > > > here's the biggest sticking point. To be clear, you agree
> that U-Boot
> > > > > needs to support being passed a device tree to use, at run
> time, yes?
> > > >
> > > > Yes. The OF_BOARD feature provides this.
> > > >
> > > > >
> > > > > And in that case, would not be using the "fake" tree we
> built in?
> > > >
> > > > Not at runtime.
> > >
> > > OK.
> > >
> > > > > So is the sticking point here that we really have two
> classes of
> > > > > devices, one class where we will never ever be given the
> device tree at
> > > > > run time (think BeagleBone Black) and one where we will
> always be given
> > > > > one at run time (think Raspberry Pi) ?
> > > >
> > > > I'm not sure it will be that black and white. I suspect there
> will be
> > > > (many) boards which can boot happily with the U-Boot
> devicetree but
> > > > can also accept one at runtime, if provided. For example, you
> may want
> > > > to boot with or without TF-A or some other, earlier stage.
> > >
> > > I'm not sure I see the value in making this a gray area.
> There's very
> > > much a class of "never" boards. There's also the class of
> "can" today.
> > > Maybe as part of a developer iterative flow it would be nice to
> not have
> > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > until things are happy, but I'm not sure what the use case is for
> > > overriding the previous stage.
> > >
> > > Especially since the pushback on this series I think has all
> been "why
> > > are we copying in a tree to build with? We don't want to use
> it at run
> > > time!". And then softer push back like "Well, U-Boot says we
> have to
> > > include the device tree file here, but we won't use it...".
> >
> > See below.
> >
> > >
> > > > I believe we have got unstuck because OF_BOARD (perhaps
> inadvertently)
> > > > provided a way to entirely omit a devicetree from U-Boot,
> thus making
> > > > things like binman and U-Boot /config impossible, for
> example. So I
> > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > U-Boot, as we have for rpi_3, etc.
> > >
> > > I really want to see what the binary case looks like since we
> could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> > > use the device tree from build time at run time, ignoring the
> device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency
> to the
> > different components. Binman was one effort there. I feel that
> putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
>
> Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> that know where to grab other known-good binaries of varying licenses
> that are needed to assemble something that boots.
>
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the
> past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source
> and binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to
> OS and in "that" DT, there should be no U-Boot entries. As stated in
> another mail thread, I also refer to a place in a FIP where that dynamic
> config DT is meant to be stored: NT_FW_CONFIG.
> But there can be U-Boot defined bindings in "a" control/dynamic config
> DT; Trusted Firmware does that.
It ends up in that we need two separate devicetrees.
One passed to U-Boot for fixups and further passed to the OS. This
devicetree may originate from a prior boot stage, from a file loaded by
U-Boot, or from a later bootstage, e.g systemd-boot's devicetree
command. This devicetree will not contain any U-Boot specific information.
A second devicetree to hold everything that U-Boot needs for its
internal purposes.
Best regards
Heinrich
>
> It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the
> altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
>
> Yes, we need to have properties present in the device tree, and just
> like how "linux," is a valid vendor prefix for the linux kernel (but not
> used I would expect by the BSD families) we have cases that need
> "u-boot," properties.
>
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
>
> No, we can't / shouldn't assume we need this everywhere. A lot of
> places? Yes. But some features are going to be optional. A valid must
> be supported use case is something like a Pi where the hardware gives us
> a device tree, the tree is correct and some features in U-Boot aren't
> needed (SPL) nor possibly supported immediately (verified boot). We can
> go off on a tangent about how useful it would be to have HW platforms
> that are both common and can demonstrate a number of features, but
> that's its own problem to solve.
>
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those
> things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only
> going to
> > grow as every man and his dog get into the write-a-bootloader
> > business. We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's
> just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one
> internal
> > and one from the prior stage....well that is not very efficient
> and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> > can merge the two when it starts. Again that is not very efficient.
>
> Does not need to merge the two. hence it does not have any influence on
> efficiency.
> For properties access, trusted firmware has defined an abstract way to
> get them:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> <https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html>.
>
> The properties are currently implemented as DT but TF.ORG
> <http://TF.ORG> could decide to move to CBOR.
> The API will remain so that a change in backend will not influence
> existing code.
> I think you are too focused on "THE" device tree. "THE" device tree that
> is passed to the OS
> shall be hardware description and not a hacky place to fit any piece of
> metadata.
> I would argue that /chosen shall not even be there as most if not all
> information can be passed as OS command line. And actually for the UEFI
> contract, /chosen should go empty.
>
> It
> > means that U-Boot cannot be controlled by the prior stage (e.g.
> to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
>
> How the nodes should get there is how the rest of the nodes in a system
> get there. Bindings are submitted and reviewed. The authoritative
> source of the dtses in question then has them, like any other property.
>
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> For SystemReady compliant boards, this has to come much faster.
> Do you think distros will keep providing DTs for ever? I bet not.
>
> These last two paragraphs condense what I think is honestly close to a
> decade of debate / discussion down to a fiat "U-Boot will have the DTS
> files". I don't want that. I don't think any of the other projects
> that want to leverage DTS files want that.
>
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I
> feel
> > this will set us up very well to deal with the complexity that is
> > coming.
>
> Sure, it could. But that doesn't mean that U-Boot is where the dts
> files live.
>
> --
> Tom
>
>
>
> --
>
> François-Frédéric Ozog | /Director Business Development/
> T: +33.67221.6485
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
>
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 13:23 ` Heinrich Schuchardt
0 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-27 13:23 UTC (permalink / raw)
To: François Ozog, Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
On 10/27/21 15:15, François Ozog wrote:
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
>
> On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > Hi all,
> >
> > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
> > >
> > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com
> <mailto:trini@konsulko.com>> wrote:
> > > > >
> > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > Hi François,
> > > > > >
> > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog
> <francois.ozog@linaro.org <mailto:francois.ozog@linaro.org>> wrote:
> > > > > > >
> > > > > > > Hi Simon
> > > > > > >
> > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass
> <sjg@chromium.org <mailto:sjg@chromium.org>> a écrit :
> > > > > > >>
> > > > > > >> Hi Tom, Bin,François,
> > > > > > >>
> > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini
> <trini@konsulko.com <mailto:trini@konsulko.com>> wrote:
> > > > > > >> >
> > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > >> > > Hi Simon,
> > > > > > >> > >
> > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass
> <sjg@chromium.org <mailto:sjg@chromium.org>> wrote:
> > > > > > >> > > >
> > > > > > >> > > > 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
> at [1].
> > > > > > >> > > >
> > > > > > >> > > > 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.
> > > > > > >> > >
> > > > > > >> > > Adding device trees that are never used sounds
> like a hack to me.
> > > > > > >> > >
> > > > > > >> > > For QEMU, device tree is dynamically generated on
> the fly based on
> > > > > > >> > > command line parameters, and the device tree you
> put in this series
> > > > > > >> > > has various hardcoded <phandle> values which
> normally do not show up
> > > > > > >> > > in hand-written dts files.
> > > > > > >> > >
> > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > >> >
> > > > > > >> > I am also confused and do not like the idea of
> adding device trees for
> > > > > > >> > platforms that are capable of and can / do have a
> device tree to give us
> > > > > > >> > at run time.
> > > > > > >>
> > > > > > >> (I'll just reply to this one email, since the same
> points applies to
> > > > > > >> all replies I think)
> > > > > > >>
> > > > > > >> I have been thinking about this and discussing it with
> people for a
> > > > > > >> few months now. I've been signalling a change like
> this for over a
> > > > > > >> month now, on U-Boot contributor calls and in
> discussions with Linaro
> > > > > > >> people. I sent a patch (below) to try to explain
> things. I hope it is
> > > > > > >> not a surprise!
> > > > > > >>
> > > > > > >> The issue here is that we need a devicetree in-tree in
> U-Boot, to
> > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE, OF_BOARD,
> > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE. Between
> > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger footing.
> > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF use.
> > > > > > >> For more context:
> > > > > > >>
> > > > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> <http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/>
> > > > > > >>
> > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of adding the
> > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > >> maintainer would prefer there was no special support
> even for booting
> > > > > > >> Linux directly!)
> > > > > > >
> > > > > > > i understand their point of view and agree with it.
> > > > > > >>
> > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > >> think the path forward might be to run QEMU twice,
> once to get its
> > > > > > >> generated tree and once to give the 'merged' tree with
> the U-Boot
> > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > >>
> > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> option, not a
> > > > > > >> build-time one. It creates all sorts of problems and
> obscurity which
> > > > > > >> have taken months to unpick. See the above patch for
> the rationale.
> > > > > > >>
> > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option available to
> > > > > > >> any board. At some point in the future it may become a
> common way
> > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a devicetree
> > > > > > >> to it. It doesn't make any sense to have people decide
> whether or not
> > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image is put
> > > > > > >> together. We'll end up with different U-Boot build
> targets like
> > > > > > >> capricorn, capricorn_of_board and the like. It should
> be obvious where
> > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly used
> > > > > > >> option, perhaps enabled by most/all boards, so that
> this sort of build
> > > > > > >> explosion is not needed.
> > > > > > >
> > > > > > > If you mean that when boards are by construction
> providing a DTB to U-Boot then I agree very much. But I don’t
> understand how the patch set supports it as it puts dts files for
> those boards to be built.
> > > > > > >>
> > > > > > >> U-Boot needs to be flexible enough to
> > > > > > >> function correctly in whatever runtime environment in
> which it finds
> > > > > > >> itself.
> > > > > > >>
> > > > > > >> Also as binman is pressed into service more and more
> to build the
> > > > > > >> complex firmware images that are becoming fashionable,
> it needs a
> > > > > > >> definition (in the devicetree) that describes how to
> create the image.
> > > > > > >> We can't support that unless we are building a
> devicetree, nor can the
> > > > > > >> running program access the image layout without that
> information.
> > > > > > >>
> > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > >> germane...but of course I am not suggesting doing
> that, since OF_BOARD
> > > > > > >> is, still, enabled. We already use OF_BOARD for
> various boards that
> > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3, for example
> > > > > > >> (as I said in the cover letter "Most boards do provide
> one, but some
> > > > > > >> don't."). So this series is just completing the
> picture by enforcing
> > > > > > >> that *some sort* of devicetree is always present.
> > > > > > >
> > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > >
> > > > > > I think the key point that will get you closer to where I
> am on this
> > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> present it
> > > > > > has build-time effects and this is quite wrong. If you go
> through all
> > > > > > the material I have written on this I think I have
> motivated that very
> > > > > > clearly.
> > > > > >
> > > > > > Another big issue is that I believe we need ONE
> devicetree for U-Boot,
> > > > > > not two that get merged by U-Boot. Again I have gone
> through that in a
> > > > > > lot of detail.
> > > > >
> > > > > I have a long long reply to your first reply here saved,
> but, maybe
> > > > > here's the biggest sticking point. To be clear, you agree
> that U-Boot
> > > > > needs to support being passed a device tree to use, at run
> time, yes?
> > > >
> > > > Yes. The OF_BOARD feature provides this.
> > > >
> > > > >
> > > > > And in that case, would not be using the "fake" tree we
> built in?
> > > >
> > > > Not at runtime.
> > >
> > > OK.
> > >
> > > > > So is the sticking point here that we really have two
> classes of
> > > > > devices, one class where we will never ever be given the
> device tree at
> > > > > run time (think BeagleBone Black) and one where we will
> always be given
> > > > > one at run time (think Raspberry Pi) ?
> > > >
> > > > I'm not sure it will be that black and white. I suspect there
> will be
> > > > (many) boards which can boot happily with the U-Boot
> devicetree but
> > > > can also accept one at runtime, if provided. For example, you
> may want
> > > > to boot with or without TF-A or some other, earlier stage.
> > >
> > > I'm not sure I see the value in making this a gray area.
> There's very
> > > much a class of "never" boards. There's also the class of
> "can" today.
> > > Maybe as part of a developer iterative flow it would be nice to
> not have
> > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > until things are happy, but I'm not sure what the use case is for
> > > overriding the previous stage.
> > >
> > > Especially since the pushback on this series I think has all
> been "why
> > > are we copying in a tree to build with? We don't want to use
> it at run
> > > time!". And then softer push back like "Well, U-Boot says we
> have to
> > > include the device tree file here, but we won't use it...".
> >
> > See below.
> >
> > >
> > > > I believe we have got unstuck because OF_BOARD (perhaps
> inadvertently)
> > > > provided a way to entirely omit a devicetree from U-Boot,
> thus making
> > > > things like binman and U-Boot /config impossible, for
> example. So I
> > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > U-Boot, as we have for rpi_3, etc.
> > >
> > > I really want to see what the binary case looks like since we
> could then
> > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > then also do a rpi_arm32_defconfig too.
> > >
> > > I want to see less device trees in U-Boot sources, if they can come
> > > functionally correct from the hardware/our caller.
> > >
> > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> > > use the device tree from build time at run time, ignoring the
> device
> > > tree provided to us at run time by the caller.
> >
> > Firstly I should say that I find building firmware very messy and
> > confusing these days. Lots of things to build and it's hard to find
> > the instructions. It doesn't have to be that way, but if we carry on
> > as we are, it will continue to be messy and in five years you will
> > need a Ph.D and a lucky charm to boot on any modern board. My
> > objective here is to simplify things, bringing some consistency
> to the
> > different components. Binman was one effort there. I feel that
> putting
> > at least the U-Boot house in order, in my role as devicetree
> > maintainer (and as author of devicetree support in U-Boot back in
> > 2011), is the next step.
>
> Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> that know where to grab other known-good binaries of varying licenses
> that are needed to assemble something that boots.
>
> > If we set things up correctly and agree on the bindings, devicetree
> > can be the unifying configuration mechanism through the whole of
> > firmware (except for very early bits) and into the OS, this will set
> > us up very well to deal with the complexity that is coming.
> >
> > Anyway, here are the mental steps that I've gone through over the
> past
> > two months:
> >
> > Step 1: At present, some people think U-Boot is not even allowed to
> > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source
> and binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to
> OS and in "that" DT, there should be no U-Boot entries. As stated in
> another mail thread, I also refer to a place in a FIP where that dynamic
> config DT is meant to be stored: NT_FW_CONFIG.
> But there can be U-Boot defined bindings in "a" control/dynamic config
> DT; Trusted Firmware does that.
It ends up in that we need two separate devicetrees.
One passed to U-Boot for fixups and further passed to the OS. This
devicetree may originate from a prior boot stage, from a file loaded by
U-Boot, or from a later bootstage, e.g systemd-boot's devicetree
command. This devicetree will not contain any U-Boot specific information.
A second devicetree to hold everything that U-Boot needs for its
internal purposes.
Best regards
Heinrich
>
> It is an abuse of the
> > devicetree standard, like the /chosen node but with less history. We
> > should sacrifice efficiency, expedience and expandability on the
> altar
> > of 'devicetree is a hardware description'. How do we get over that
> > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > for its own purposes, as well as for booting the OS. I am not saying
>
> Yes, we need to have properties present in the device tree, and just
> like how "linux," is a valid vendor prefix for the linux kernel (but not
> used I would expect by the BSD families) we have cases that need
> "u-boot," properties.
>
> > it always has to have those properties, but with existing features
> > like verified boot, SPL as well as complex firmware images where
> > U-Boot needs to be able to find things in the image, it is essential.
> > So let's just assume that we need this everywhere, since we certainly
> > need it in at least some places.
>
> No, we can't / shouldn't assume we need this everywhere. A lot of
> places? Yes. But some features are going to be optional. A valid must
> be supported use case is something like a Pi where the hardware gives us
> a device tree, the tree is correct and some features in U-Boot aren't
> needed (SPL) nor possibly supported immediately (verified boot). We can
> go off on a tangent about how useful it would be to have HW platforms
> that are both common and can demonstrate a number of features, but
> that's its own problem to solve.
>
> > (stop reading here if you disagree, because nothing below will make
> > any sense...you can still use U-Boot v2011.06 which doesn't have
> > OF_CONTROL :-)
> >
> > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > have binman definitions, etc. So we need a way to overlay those
> things
> > into the DT. We already support this for in-tree DTs, so IMO this is
> > easy. Just require every board to have an in-tree DT. It helps with
> > discoverability and documentation, anyway. That is this series.
> >
> > (I think most of us are at the beginning of step 2, unsure about it
> > and worried about step 3)
> >
> > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > flow only, or boards that sometimes use a flow) which need the DT to
> > come from a prior stage. How to handle that? IMO that is only
> going to
> > grow as every man and his dog get into the write-a-bootloader
> > business. We need a way to provide the U-Boot nodes/properties in a
> > form that the prior stage can consume and integrate with its build
> > system. Is TF-A the only thing being discussed here? If so, let's
> just
> > do it. We have the u-boot.dtsi and we can use binman to put the image
> > together, for example. Or we can get clever and create some sort of
> > overlay dtb.
> >
> > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > then it will need to build it in and use two devicetrees, one
> internal
> > and one from the prior stage....well that is not very efficient
> and it
> > is going to be confusing for people to figure out what U-Boot is
> > actually doing. But we actually already do that in a lot of cases
> > where U-Boot passes a DT to the kernel which is different to the one
> > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > U-Boot can have its own small devicetree with its bits and then
> U-Boot
> > can merge the two when it starts. Again that is not very efficient.
>
> Does not need to merge the two. hence it does not have any influence on
> efficiency.
> For properties access, trusted firmware has defined an abstract way to
> get them:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> <https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html>.
>
> The properties are currently implemented as DT but TF.ORG
> <http://TF.ORG> could decide to move to CBOR.
> The API will remain so that a change in backend will not influence
> existing code.
> I think you are too focused on "THE" device tree. "THE" device tree that
> is passed to the OS
> shall be hardware description and not a hacky place to fit any piece of
> metadata.
> I would argue that /chosen shall not even be there as most if not all
> information can be passed as OS command line. And actually for the UEFI
> contract, /chosen should go empty.
>
> It
> > means that U-Boot cannot be controlled by the prior stage (e.g.
> to get
> > its public key from there or to enable/disable the console), so
> > unified firmware config is not possible. It will get very confusing,
> > particularly for debugging U-Boot. c) Some other scheme to avoid
> > accepting step 3...please stop!
>
> How the nodes should get there is how the rest of the nodes in a system
> get there. Bindings are submitted and reviewed. The authoritative
> source of the dtses in question then has them, like any other property.
>
> > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > whole cloth. What about that? Well, we are just going to have to deal
> > with that. We can easily merge in the U-Boot nodes/properties and
> > update the U-Boot CI scripts to do this, as needed, e.g. with
> > qemu-riscv64_spl. It's only one use case, although Xen might do
> > something similar.
> >
> > To my mind, that deals with both the build-time and run-time issues.
> > We have a discoverable DT in U-Boot, which should be considered the
> > source of truth for most boards. We can sync it with Linux
> > automatically with the tooling that I hope Rob Herring will come up
> > with. We can use an empty one where there really is no default,
> > although I'd argue that is making perfect an enemy of the good.
> >
> > Step 5: If we get clever and want to remove them from the U-Boot tree
> > and pick them up from somewhere else, we can do that with sufficient
> > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
>
> For SystemReady compliant boards, this has to come much faster.
> Do you think distros will keep providing DTs for ever? I bet not.
>
> These last two paragraphs condense what I think is honestly close to a
> decade of debate / discussion down to a fiat "U-Boot will have the DTS
> files". I don't want that. I don't think any of the other projects
> that want to leverage DTS files want that.
>
> > To repeat, if we set things up correctly and agree on the bindings,
> > devicetree can be the unifying configuration mechanism through the
> > whole of firmware (except for very early bits) and into the OS. I
> feel
> > this will set us up very well to deal with the complexity that is
> > coming.
>
> Sure, it could. But that doesn't mean that U-Boot is where the dts
> files live.
>
> --
> Tom
>
>
>
> --
>
> François-Frédéric Ozog | /Director Business Development/
> T: +33.67221.6485
> francois.ozog@linaro.org <mailto:francois.ozog@linaro.org> | Skype: ffozog
>
>
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:23 ` Heinrich Schuchardt
@ 2021-10-27 14:55 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:55 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Ilias Apalodimas, Jagan Teki, Jerry Van Baren, Kever Yang, Leo,
Linus Walleij, Liviu Dudau, Marek Behún, Matthias Brugger,
Michal Simek, Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
[snip]
> One passed to U-Boot for fixups and further passed to the OS. This
> devicetree may originate from a prior boot stage, from a file loaded by
> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
I assume systemd-boot is implementing the same logic that extlinux.conf
has used for forever, yes?
> This devicetree will not contain any U-Boot specific information.
To repeat, it must only have official bindings, yes, regardless of what
project they come from.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 14:55 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:55 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
[snip]
> One passed to U-Boot for fixups and further passed to the OS. This
> devicetree may originate from a prior boot stage, from a file loaded by
> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
I assume systemd-boot is implementing the same logic that extlinux.conf
has used for forever, yes?
> This devicetree will not contain any U-Boot specific information.
To repeat, it must only have official bindings, yes, regardless of what
project they come from.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 14:55 ` Tom Rini
@ 2021-10-27 15:02 ` Heinrich Schuchardt
-1 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-27 15:02 UTC (permalink / raw)
To: Tom Rini
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Ilias Apalodimas, Jagan Teki, Jerry Van Baren, Kever Yang, Leo,
Linus Walleij, Liviu Dudau, Marek Behún, Matthias Brugger,
Michal Simek, Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
On 10/27/21 16:55, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
>
> [snip]
>> One passed to U-Boot for fixups and further passed to the OS. This
>> devicetree may originate from a prior boot stage, from a file loaded by
>> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
>
> I assume systemd-boot is implementing the same logic that extlinux.conf
> has used for forever, yes?
It is loading the file and then calls U-Boot's implementation of the EFI
Device Tree Fixup Protocol for fixups before passing the device-tree to
the OS.
>
>> This devicetree will not contain any U-Boot specific information.
>
> To repeat, it must only have official bindings, yes, regardless of what
> project they come from.
>
Don't expect prior firmware stages to provide any U-Boot specific stuff
whatever official or non-official U-Boot specific bindings exist.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 15:02 ` Heinrich Schuchardt
0 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-27 15:02 UTC (permalink / raw)
To: Tom Rini
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
On 10/27/21 16:55, Tom Rini wrote:
> On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
>
> [snip]
>> One passed to U-Boot for fixups and further passed to the OS. This
>> devicetree may originate from a prior boot stage, from a file loaded by
>> U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
>
> I assume systemd-boot is implementing the same logic that extlinux.conf
> has used for forever, yes?
It is loading the file and then calls U-Boot's implementation of the EFI
Device Tree Fixup Protocol for fixups before passing the device-tree to
the OS.
>
>> This devicetree will not contain any U-Boot specific information.
>
> To repeat, it must only have official bindings, yes, regardless of what
> project they come from.
>
Don't expect prior firmware stages to provide any U-Boot specific stuff
whatever official or non-official U-Boot specific bindings exist.
Best regards
Heinrich
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 15:02 ` Heinrich Schuchardt
@ 2021-10-27 18:04 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:04 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: François Ozog, Simon Glass, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Ilias Apalodimas, Jagan Teki, Jerry Van Baren, Kever Yang, Leo,
Linus Walleij, Liviu Dudau, Marek Behún, Matthias Brugger,
Michal Simek, Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote:
> On 10/27/21 16:55, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
> >
> > [snip]
> > > One passed to U-Boot for fixups and further passed to the OS. This
> > > devicetree may originate from a prior boot stage, from a file loaded by
> > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
> >
> > I assume systemd-boot is implementing the same logic that extlinux.conf
> > has used for forever, yes?
>
> It is loading the file and then calls U-Boot's implementation of the EFI
> Device Tree Fixup Protocol for fixups before passing the device-tree to the
> OS.
So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK.
> > > This devicetree will not contain any U-Boot specific information.
> >
> > To repeat, it must only have official bindings, yes, regardless of what
> > project they come from.
> >
>
> Don't expect prior firmware stages to provide any U-Boot specific stuff
> whatever official or non-official U-Boot specific bindings exist.
Failure to implement official bindings may result in failure to boot,
which would be pretty silly.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:04 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:04 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, François Ozog,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 1238 bytes --]
On Wed, Oct 27, 2021 at 05:02:39PM +0200, Heinrich Schuchardt wrote:
> On 10/27/21 16:55, Tom Rini wrote:
> > On Wed, Oct 27, 2021 at 03:23:01PM +0200, Heinrich Schuchardt wrote:
> >
> > [snip]
> > > One passed to U-Boot for fixups and further passed to the OS. This
> > > devicetree may originate from a prior boot stage, from a file loaded by
> > > U-Boot, or from a later bootstage, e.g systemd-boot's devicetree command.
> >
> > I assume systemd-boot is implementing the same logic that extlinux.conf
> > has used for forever, yes?
>
> It is loading the file and then calls U-Boot's implementation of the EFI
> Device Tree Fixup Protocol for fixups before passing the device-tree to the
> OS.
So it's using https://systemd.io/BOOT_LOADER_SPECIFICATION/ OK.
> > > This devicetree will not contain any U-Boot specific information.
> >
> > To repeat, it must only have official bindings, yes, regardless of what
> > project they come from.
> >
>
> Don't expect prior firmware stages to provide any U-Boot specific stuff
> whatever official or non-official U-Boot specific bindings exist.
Failure to implement official bindings may result in failure to boot,
which would be pretty silly.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:15 ` François Ozog
@ 2021-10-27 14:54 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:54 UTC (permalink / raw)
To: François Ozog
Cc: Simon Glass, Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
[-- Attachment #1: Type: text/plain, Size: 22581 bytes --]
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote:
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.ozog@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > sjg@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >>
> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > adding the
> > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > >> maintainer would prefer there was no special support even for
> > booting
> > > > > > > >> Linux directly!)
> > > > > > > >
> > > > > > > > i understand their point of view and agree with it.
> > > > > > > >>
> > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > >> think the path forward might be to run QEMU twice, once to
> > get its
> > > > > > > >> generated tree and once to give the 'merged' tree with the
> > U-Boot
> > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > >>
> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > option, not a
> > > > > > > >> build-time one. It creates all sorts of problems and
> > obscurity which
> > > > > > > >> have taken months to unpick. See the above patch for the
> > rationale.
> > > > > > > >>
> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > available to
> > > > > > > >> any board. At some point in the future it may become a common
> > way
> > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > devicetree
> > > > > > > >> to it. It doesn't make any sense to have people decide
> > whether or not
> > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > is put
> > > > > > > >> together. We'll end up with different U-Boot build targets
> > like
> > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > obvious where
> > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > used
> > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > of build
> > > > > > > >> explosion is not needed.
> > > > > > > >
> > > > > > > > If you mean that when boards are by construction providing a
> > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > set supports it as it puts dts files for those boards to be built.
> > > > > > > >>
> > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > >> function correctly in whatever runtime environment in which
> > it finds
> > > > > > > >> itself.
> > > > > > > >>
> > > > > > > >> Also as binman is pressed into service more and more to build
> > the
> > > > > > > >> complex firmware images that are becoming fashionable, it
> > needs a
> > > > > > > >> definition (in the devicetree) that describes how to create
> > the image.
> > > > > > > >> We can't support that unless we are building a devicetree,
> > nor can the
> > > > > > > >> running program access the image layout without that
> > information.
> > > > > > > >>
> > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > >> germane...but of course I am not suggesting doing that, since
> > OF_BOARD
> > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > boards that
> > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > example
> > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > but some
> > > > > > > >> don't."). So this series is just completing the picture by
> > enforcing
> > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > >
> > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > >
> > > > > > > I think the key point that will get you closer to where I am on
> > this
> > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > present it
> > > > > > > has build-time effects and this is quite wrong. If you go
> > through all
> > > > > > > the material I have written on this I think I have motivated
> > that very
> > > > > > > clearly.
> > > > > > >
> > > > > > > Another big issue is that I believe we need ONE devicetree for
> > U-Boot,
> > > > > > > not two that get merged by U-Boot. Again I have gone through
> > that in a
> > > > > > > lot of detail.
> > > > > >
> > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > here's the biggest sticking point. To be clear, you agree that
> > U-Boot
> > > > > > needs to support being passed a device tree to use, at run time,
> > yes?
> > > > >
> > > > > Yes. The OF_BOARD feature provides this.
> > > > >
> > > > > >
> > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > >
> > > > > Not at runtime.
> > > >
> > > > OK.
> > > >
> > > > > > So is the sticking point here that we really have two classes of
> > > > > > devices, one class where we will never ever be given the device
> > tree at
> > > > > > run time (think BeagleBone Black) and one where we will always be
> > given
> > > > > > one at run time (think Raspberry Pi) ?
> > > > >
> > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > can also accept one at runtime, if provided. For example, you may
> > want
> > > > > to boot with or without TF-A or some other, earlier stage.
> > > >
> > > > I'm not sure I see the value in making this a gray area. There's very
> > > > much a class of "never" boards. There's also the class of "can" today.
> > > > Maybe as part of a developer iterative flow it would be nice to not
> > have
> > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > until things are happy, but I'm not sure what the use case is for
> > > > overriding the previous stage.
> > > >
> > > > Especially since the pushback on this series I think has all been "why
> > > > are we copying in a tree to build with? We don't want to use it at run
> > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > include the device tree file here, but we won't use it...".
> > >
> > > See below.
> > >
> > > >
> > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > inadvertently)
> > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > U-Boot, as we have for rpi_3, etc.
> > > >
> > > > I really want to see what the binary case looks like since we could
> > then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> >
> > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > that know where to grab other known-good binaries of varying licenses
> > that are needed to assemble something that boots.
> >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source and
> binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to OS
> and in "that" DT, there should be no U-Boot entries. As stated in another
I would (and I know I'm repeating myself and emails have crossed, etc,
but for future clarity) say it's that no un-official nodes/properties
should be passed from one piece of software to another. I mean hell,
"u-boot,bootcount" MUST get passed to the OS, so has some idea how many
times the system has booted. It's just a long standing item to get that
bootcount driver / binding unblocked and merged finally. But that's a
different tangent to get lost on.
> mail thread, I also refer to a place in a FIP where that dynamic config DT
> is meant to be stored: NT_FW_CONFIG.
> But there can be U-Boot defined bindings in "a" control/dynamic config DT;
> Trusted Firmware does that.
Maybe I just need to come out and say if "everyone" has decided how
U-Boot needs to work, but also myself (head custodian) and Simon (head
DM custodian, device tree in U-Boot custodian) aren't 100% on board with
everything, maybe some step back and re-evaluation needs to be taken?
And I'm not saying we're the final word only here either, there has been
and needs to continue to be good faith discussions. It should also be
clear at this point that he and I aren't on the same page on everything,
for example :)
> > It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> >
> > Yes, we need to have properties present in the device tree, and just
> > like how "linux," is a valid vendor prefix for the linux kernel (but not
> > used I would expect by the BSD families) we have cases that need
> > "u-boot," properties.
> >
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> >
> > No, we can't / shouldn't assume we need this everywhere. A lot of
> > places? Yes. But some features are going to be optional. A valid must
> > be supported use case is something like a Pi where the hardware gives us
> > a device tree, the tree is correct and some features in U-Boot aren't
> > needed (SPL) nor possibly supported immediately (verified boot). We can
> > go off on a tangent about how useful it would be to have HW platforms
> > that are both common and can demonstrate a number of features, but
> > that's its own problem to solve.
> >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business. We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient.
>
> Does not need to merge the two. hence it does not have any influence on
> efficiency.
> For properties access, trusted firmware has defined an abstract way to get
> them:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
That's interesting, but I also think fconf_load_config(), etc are the
efficiency and additional overhead Simon is talking about being worried
about.
> The properties are currently implemented as DT but TF.ORG could decide to
> move to CBOR.
> The API will remain so that a change in backend will not influence existing
> code.
> I think you are too focused on "THE" device tree. "THE" device tree that is
> passed to the OS
> shall be hardware description and not a hacky place to fit any piece of
> metadata.
No, but it is the place to put well defined metadata.
> I would argue that /chosen shall not even be there as most if not all
> information can be passed as OS command line. And actually for the UEFI
> contract, /chosen should go empty.
Shoving a bunch of stuff to the kernel command line sounds pretty hacky
to me. But I'll just assume it's already been given the official Not
Hacky stamp of approval since after all, there's not a long standing
cleaner path to do anything like that on x86, and we must all mirror the
x86 world.
> > It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> >
> > How the nodes should get there is how the rest of the nodes in a system
> > get there. Bindings are submitted and reviewed. The authoritative
> > source of the dtses in question then has them, like any other property.
> >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > For SystemReady compliant boards, this has to come much faster.
> Do you think distros will keep providing DTs for ever? I bet not.
Since it seems like it'll be a long time before people stop producing
SBCs that lack on-board flash storage for the world firmware, yeah, I
don't know when distributions will stop shipping DTBs. Maybe a year or
two after the last popular SBC comes out and distros are comfortable
shoving people that have that hardware off to some other community to
support?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 14:54 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 14:54 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Stephen Warren,
Oleksandr Andrushchenko, Heinrich Schuchardt, Niel Fourie,
Michal Simek, Marek Behún, Jerry Van Baren, Ramon Fried,
Jagan Teki, Valentin Longchamp, Heiko Schocher, Peter Robinson,
Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk, Stephen Warren,
qemu-devel@nongnu.org Developers, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 22581 bytes --]
On Wed, Oct 27, 2021 at 03:15:01PM +0200, François Ozog wrote:
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.ozog@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > sjg@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >>
> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > adding the
> > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > >> maintainer would prefer there was no special support even for
> > booting
> > > > > > > >> Linux directly!)
> > > > > > > >
> > > > > > > > i understand their point of view and agree with it.
> > > > > > > >>
> > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > >> think the path forward might be to run QEMU twice, once to
> > get its
> > > > > > > >> generated tree and once to give the 'merged' tree with the
> > U-Boot
> > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > >>
> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > option, not a
> > > > > > > >> build-time one. It creates all sorts of problems and
> > obscurity which
> > > > > > > >> have taken months to unpick. See the above patch for the
> > rationale.
> > > > > > > >>
> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > available to
> > > > > > > >> any board. At some point in the future it may become a common
> > way
> > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > devicetree
> > > > > > > >> to it. It doesn't make any sense to have people decide
> > whether or not
> > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > is put
> > > > > > > >> together. We'll end up with different U-Boot build targets
> > like
> > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > obvious where
> > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > used
> > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > of build
> > > > > > > >> explosion is not needed.
> > > > > > > >
> > > > > > > > If you mean that when boards are by construction providing a
> > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > set supports it as it puts dts files for those boards to be built.
> > > > > > > >>
> > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > >> function correctly in whatever runtime environment in which
> > it finds
> > > > > > > >> itself.
> > > > > > > >>
> > > > > > > >> Also as binman is pressed into service more and more to build
> > the
> > > > > > > >> complex firmware images that are becoming fashionable, it
> > needs a
> > > > > > > >> definition (in the devicetree) that describes how to create
> > the image.
> > > > > > > >> We can't support that unless we are building a devicetree,
> > nor can the
> > > > > > > >> running program access the image layout without that
> > information.
> > > > > > > >>
> > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > >> germane...but of course I am not suggesting doing that, since
> > OF_BOARD
> > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > boards that
> > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > example
> > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > but some
> > > > > > > >> don't."). So this series is just completing the picture by
> > enforcing
> > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > >
> > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > >
> > > > > > > I think the key point that will get you closer to where I am on
> > this
> > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > present it
> > > > > > > has build-time effects and this is quite wrong. If you go
> > through all
> > > > > > > the material I have written on this I think I have motivated
> > that very
> > > > > > > clearly.
> > > > > > >
> > > > > > > Another big issue is that I believe we need ONE devicetree for
> > U-Boot,
> > > > > > > not two that get merged by U-Boot. Again I have gone through
> > that in a
> > > > > > > lot of detail.
> > > > > >
> > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > here's the biggest sticking point. To be clear, you agree that
> > U-Boot
> > > > > > needs to support being passed a device tree to use, at run time,
> > yes?
> > > > >
> > > > > Yes. The OF_BOARD feature provides this.
> > > > >
> > > > > >
> > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > >
> > > > > Not at runtime.
> > > >
> > > > OK.
> > > >
> > > > > > So is the sticking point here that we really have two classes of
> > > > > > devices, one class where we will never ever be given the device
> > tree at
> > > > > > run time (think BeagleBone Black) and one where we will always be
> > given
> > > > > > one at run time (think Raspberry Pi) ?
> > > > >
> > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > can also accept one at runtime, if provided. For example, you may
> > want
> > > > > to boot with or without TF-A or some other, earlier stage.
> > > >
> > > > I'm not sure I see the value in making this a gray area. There's very
> > > > much a class of "never" boards. There's also the class of "can" today.
> > > > Maybe as part of a developer iterative flow it would be nice to not
> > have
> > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > until things are happy, but I'm not sure what the use case is for
> > > > overriding the previous stage.
> > > >
> > > > Especially since the pushback on this series I think has all been "why
> > > > are we copying in a tree to build with? We don't want to use it at run
> > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > include the device tree file here, but we won't use it...".
> > >
> > > See below.
> > >
> > > >
> > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > inadvertently)
> > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > U-Boot, as we have for rpi_3, etc.
> > > >
> > > > I really want to see what the binary case looks like since we could
> > then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> >
> > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > that know where to grab other known-good binaries of varying licenses
> > that are needed to assemble something that boots.
> >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source and
> binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to OS
> and in "that" DT, there should be no U-Boot entries. As stated in another
I would (and I know I'm repeating myself and emails have crossed, etc,
but for future clarity) say it's that no un-official nodes/properties
should be passed from one piece of software to another. I mean hell,
"u-boot,bootcount" MUST get passed to the OS, so has some idea how many
times the system has booted. It's just a long standing item to get that
bootcount driver / binding unblocked and merged finally. But that's a
different tangent to get lost on.
> mail thread, I also refer to a place in a FIP where that dynamic config DT
> is meant to be stored: NT_FW_CONFIG.
> But there can be U-Boot defined bindings in "a" control/dynamic config DT;
> Trusted Firmware does that.
Maybe I just need to come out and say if "everyone" has decided how
U-Boot needs to work, but also myself (head custodian) and Simon (head
DM custodian, device tree in U-Boot custodian) aren't 100% on board with
everything, maybe some step back and re-evaluation needs to be taken?
And I'm not saying we're the final word only here either, there has been
and needs to continue to be good faith discussions. It should also be
clear at this point that he and I aren't on the same page on everything,
for example :)
> > It is an abuse of the
> > > devicetree standard, like the /chosen node but with less history. We
> > > should sacrifice efficiency, expedience and expandability on the altar
> > > of 'devicetree is a hardware description'. How do we get over that
> > > one? Wel, I just think we need to accept that U-Boot uses devicetree
> > > for its own purposes, as well as for booting the OS. I am not saying
> >
> > Yes, we need to have properties present in the device tree, and just
> > like how "linux," is a valid vendor prefix for the linux kernel (but not
> > used I would expect by the BSD families) we have cases that need
> > "u-boot," properties.
> >
> > > it always has to have those properties, but with existing features
> > > like verified boot, SPL as well as complex firmware images where
> > > U-Boot needs to be able to find things in the image, it is essential.
> > > So let's just assume that we need this everywhere, since we certainly
> > > need it in at least some places.
> >
> > No, we can't / shouldn't assume we need this everywhere. A lot of
> > places? Yes. But some features are going to be optional. A valid must
> > be supported use case is something like a Pi where the hardware gives us
> > a device tree, the tree is correct and some features in U-Boot aren't
> > needed (SPL) nor possibly supported immediately (verified boot). We can
> > go off on a tangent about how useful it would be to have HW platforms
> > that are both common and can demonstrate a number of features, but
> > that's its own problem to solve.
> >
> > > (stop reading here if you disagree, because nothing below will make
> > > any sense...you can still use U-Boot v2011.06 which doesn't have
> > > OF_CONTROL :-)
> > >
> > > Step 2: Assume U-Boot has its own nodes/properties. How do they get
> > > there? Well, we have u-boot.dtsi files for that (the 2016 patch
> > > "6d427c6b1fa binman: Automatically include a U-Boot .dtsi file"), we
> > > have binman definitions, etc. So we need a way to overlay those things
> > > into the DT. We already support this for in-tree DTs, so IMO this is
> > > easy. Just require every board to have an in-tree DT. It helps with
> > > discoverability and documentation, anyway. That is this series.
> > >
> > > (I think most of us are at the beginning of step 2, unsure about it
> > > and worried about step 3)
> > >
> > > Step 3: Ah, but there are flows (i.e. boards that use a particular
> > > flow only, or boards that sometimes use a flow) which need the DT to
> > > come from a prior stage. How to handle that? IMO that is only going to
> > > grow as every man and his dog get into the write-a-bootloader
> > > business. We need a way to provide the U-Boot nodes/properties in a
> > > form that the prior stage can consume and integrate with its build
> > > system. Is TF-A the only thing being discussed here? If so, let's just
> > > do it. We have the u-boot.dtsi and we can use binman to put the image
> > > together, for example. Or we can get clever and create some sort of
> > > overlay dtb.
> > >
> > > Step 3a. But I don't want to do that. a) If U-Boot needs this stuff
> > > then it will need to build it in and use two devicetrees, one internal
> > > and one from the prior stage....well that is not very efficient and it
> > > is going to be confusing for people to figure out what U-Boot is
> > > actually doing. But we actually already do that in a lot of cases
> > > where U-Boot passes a DT to the kernel which is different to the one
> > > it uses. So perhaps we have three devicetrees? OMG. b) Well then
> > > U-Boot can have its own small devicetree with its bits and then U-Boot
> > > can merge the two when it starts. Again that is not very efficient.
>
> Does not need to merge the two. hence it does not have any influence on
> efficiency.
> For properties access, trusted firmware has defined an abstract way to get
> them:
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
That's interesting, but I also think fconf_load_config(), etc are the
efficiency and additional overhead Simon is talking about being worried
about.
> The properties are currently implemented as DT but TF.ORG could decide to
> move to CBOR.
> The API will remain so that a change in backend will not influence existing
> code.
> I think you are too focused on "THE" device tree. "THE" device tree that is
> passed to the OS
> shall be hardware description and not a hacky place to fit any piece of
> metadata.
No, but it is the place to put well defined metadata.
> I would argue that /chosen shall not even be there as most if not all
> information can be passed as OS command line. And actually for the UEFI
> contract, /chosen should go empty.
Shoving a bunch of stuff to the kernel command line sounds pretty hacky
to me. But I'll just assume it's already been given the official Not
Hacky stamp of approval since after all, there's not a long standing
cleaner path to do anything like that on x86, and we must all mirror the
x86 world.
> > It
> > > means that U-Boot cannot be controlled by the prior stage (e.g. to get
> > > its public key from there or to enable/disable the console), so
> > > unified firmware config is not possible. It will get very confusing,
> > > particularly for debugging U-Boot. c) Some other scheme to avoid
> > > accepting step 3...please stop!
> >
> > How the nodes should get there is how the rest of the nodes in a system
> > get there. Bindings are submitted and reviewed. The authoritative
> > source of the dtses in question then has them, like any other property.
> >
> > > Step 4: Yes, but there is QEMU, which makes the devicetree up out of
> > > whole cloth. What about that? Well, we are just going to have to deal
> > > with that. We can easily merge in the U-Boot nodes/properties and
> > > update the U-Boot CI scripts to do this, as needed, e.g. with
> > > qemu-riscv64_spl. It's only one use case, although Xen might do
> > > something similar.
> > >
> > > To my mind, that deals with both the build-time and run-time issues.
> > > We have a discoverable DT in U-Boot, which should be considered the
> > > source of truth for most boards. We can sync it with Linux
> > > automatically with the tooling that I hope Rob Herring will come up
> > > with. We can use an empty one where there really is no default,
> > > although I'd argue that is making perfect an enemy of the good.
> > >
> > > Step 5: If we get clever and want to remove them from the U-Boot tree
> > > and pick them up from somewhere else, we can do that with sufficient
> > > tooling. Perhaps we should set a timeline for that? A year? Two? Six?
> >
> > For SystemReady compliant boards, this has to come much faster.
> Do you think distros will keep providing DTs for ever? I bet not.
Since it seems like it'll be a long time before people stop producing
SBCs that lack on-board flash storage for the world firmware, yeah, I
don't know when distributions will stop shipping DTBs. Maybe a year or
two after the last popular SBC comes out and distros are comfortable
shoving people that have that hardware off to some other community to
support?
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 13:15 ` François Ozog
@ 2021-10-27 15:10 ` Mark Kettenis
-1 siblings, 0 replies; 164+ messages in thread
From: Mark Kettenis @ 2021-10-27 15:10 UTC (permalink / raw)
To: François Ozog
Cc: trini, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, ashok.reddy.soma,
atish.patra, bin.meng, bmeng.cn, christianshewitt,
david.abdurachmanov, dimitri.ledkov, festevam, green.wan, hs,
heinrich.schuchardt, xypron.glpk, ilias.apalodimas, jagan,
vanbaren, kever.yang, ycliang, linus.walleij, liviu.dudau,
marek.behun, mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
> From: François Ozog <francois.ozog@linaro.org>
> Date: Wed, 27 Oct 2021 15:15:01 +0200
>
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.ozog@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > sjg@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >>
> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > adding the
> > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > >> maintainer would prefer there was no special support even for
> > booting
> > > > > > > >> Linux directly!)
> > > > > > > >
> > > > > > > > i understand their point of view and agree with it.
> > > > > > > >>
> > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > >> think the path forward might be to run QEMU twice, once to
> > get its
> > > > > > > >> generated tree and once to give the 'merged' tree with the
> > U-Boot
> > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > >>
> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > option, not a
> > > > > > > >> build-time one. It creates all sorts of problems and
> > obscurity which
> > > > > > > >> have taken months to unpick. See the above patch for the
> > rationale.
> > > > > > > >>
> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > available to
> > > > > > > >> any board. At some point in the future it may become a common
> > way
> > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > devicetree
> > > > > > > >> to it. It doesn't make any sense to have people decide
> > whether or not
> > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > is put
> > > > > > > >> together. We'll end up with different U-Boot build targets
> > like
> > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > obvious where
> > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > used
> > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > of build
> > > > > > > >> explosion is not needed.
> > > > > > > >
> > > > > > > > If you mean that when boards are by construction providing a
> > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > set supports it as it puts dts files for those boards to be built.
> > > > > > > >>
> > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > >> function correctly in whatever runtime environment in which
> > it finds
> > > > > > > >> itself.
> > > > > > > >>
> > > > > > > >> Also as binman is pressed into service more and more to build
> > the
> > > > > > > >> complex firmware images that are becoming fashionable, it
> > needs a
> > > > > > > >> definition (in the devicetree) that describes how to create
> > the image.
> > > > > > > >> We can't support that unless we are building a devicetree,
> > nor can the
> > > > > > > >> running program access the image layout without that
> > information.
> > > > > > > >>
> > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > >> germane...but of course I am not suggesting doing that, since
> > OF_BOARD
> > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > boards that
> > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > example
> > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > but some
> > > > > > > >> don't."). So this series is just completing the picture by
> > enforcing
> > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > >
> > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > >
> > > > > > > I think the key point that will get you closer to where I am on
> > this
> > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > present it
> > > > > > > has build-time effects and this is quite wrong. If you go
> > through all
> > > > > > > the material I have written on this I think I have motivated
> > that very
> > > > > > > clearly.
> > > > > > >
> > > > > > > Another big issue is that I believe we need ONE devicetree for
> > U-Boot,
> > > > > > > not two that get merged by U-Boot. Again I have gone through
> > that in a
> > > > > > > lot of detail.
> > > > > >
> > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > here's the biggest sticking point. To be clear, you agree that
> > U-Boot
> > > > > > needs to support being passed a device tree to use, at run time,
> > yes?
> > > > >
> > > > > Yes. The OF_BOARD feature provides this.
> > > > >
> > > > > >
> > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > >
> > > > > Not at runtime.
> > > >
> > > > OK.
> > > >
> > > > > > So is the sticking point here that we really have two classes of
> > > > > > devices, one class where we will never ever be given the device
> > tree at
> > > > > > run time (think BeagleBone Black) and one where we will always be
> > given
> > > > > > one at run time (think Raspberry Pi) ?
> > > > >
> > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > can also accept one at runtime, if provided. For example, you may
> > want
> > > > > to boot with or without TF-A or some other, earlier stage.
> > > >
> > > > I'm not sure I see the value in making this a gray area. There's very
> > > > much a class of "never" boards. There's also the class of "can" today.
> > > > Maybe as part of a developer iterative flow it would be nice to not
> > have
> > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > until things are happy, but I'm not sure what the use case is for
> > > > overriding the previous stage.
> > > >
> > > > Especially since the pushback on this series I think has all been "why
> > > > are we copying in a tree to build with? We don't want to use it at run
> > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > include the device tree file here, but we won't use it...".
> > >
> > > See below.
> > >
> > > >
> > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > inadvertently)
> > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > U-Boot, as we have for rpi_3, etc.
> > > >
> > > > I really want to see what the binary case looks like since we could
> > then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> >
> > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > that know where to grab other known-good binaries of varying licenses
> > that are needed to assemble something that boots.
> >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source and
> binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to OS
> and in "that" DT, there should be no U-Boot entries.
Why not? As long as the device tree validates, it is perfectly fine
to have additional nodes and properties present. The propertiesand
nodes will be simply ignored by the OS.
OpenBSD will print:
"binman" not configured
for the binman node that some of the U-Boot board targets now have,
but it doesn't really make a difference. If there is a proper binding
for that node, I could simply filter it out. Or we have U-Boot filter
it out before the DT gets passed along like Tom suggests.
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 15:10 ` Mark Kettenis
0 siblings, 0 replies; 164+ messages in thread
From: Mark Kettenis @ 2021-10-27 15:10 UTC (permalink / raw)
To: François Ozog
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr,
festevam, rainer.boschung, trini, swarren,
oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek,
marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs,
pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel,
andre.przywara, tharvey, ashok.reddy.soma, rick, agraf,
green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot,
monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov,
priyanka.jain, sjg, ilias.apalodimas, christianshewitt,
awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei,
bmeng.cn, pali, dimitri.ledkov, padmarao.begari
> From: François Ozog <francois.ozog@linaro.org>
> Date: Wed, 27 Oct 2021 15:15:01 +0200
>
> Hi,
>
> On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
>
> > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > Hi all,
> > >
> > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > Hi Tom,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > Hi François,
> > > > > > >
> > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > francois.ozog@linaro.org> wrote:
> > > > > > > >
> > > > > > > > Hi Simon
> > > > > > > >
> > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > a écrit :
> > > > > > > >>
> > > > > > > >> Hi Tom, Bin,François,
> > > > > > > >>
> > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >> >
> > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > >> > > Hi Simon,
> > > > > > > >> > >
> > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > sjg@chromium.org> wrote:
> > > > > > > >> > > >
> > > > > > > >> > > > 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 at [1].
> > > > > > > >> > > >
> > > > > > > >> > > > 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.
> > > > > > > >> > >
> > > > > > > >> > > Adding device trees that are never used sounds like a
> > hack to me.
> > > > > > > >> > >
> > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > based on
> > > > > > > >> > > command line parameters, and the device tree you put in
> > this series
> > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > not show up
> > > > > > > >> > > in hand-written dts files.
> > > > > > > >> > >
> > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > >> >
> > > > > > > >> > I am also confused and do not like the idea of adding
> > device trees for
> > > > > > > >> > platforms that are capable of and can / do have a device
> > tree to give us
> > > > > > > >> > at run time.
> > > > > > > >>
> > > > > > > >> (I'll just reply to this one email, since the same points
> > applies to
> > > > > > > >> all replies I think)
> > > > > > > >>
> > > > > > > >> I have been thinking about this and discussing it with people
> > for a
> > > > > > > >> few months now. I've been signalling a change like this for
> > over a
> > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > with Linaro
> > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > hope it is
> > > > > > > >> not a surprise!
> > > > > > > >>
> > > > > > > >> The issue here is that we need a devicetree in-tree in
> > U-Boot, to
> > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > OF_BOARD,
> > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > Between
> > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > footing.
> > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > use.
> > > > > > > >> For more context:
> > > > > > > >>
> > > > > > > >>
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > >>
> > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > adding the
> > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > >> maintainer would prefer there was no special support even for
> > booting
> > > > > > > >> Linux directly!)
> > > > > > > >
> > > > > > > > i understand their point of view and agree with it.
> > > > > > > >>
> > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > >> think the path forward might be to run QEMU twice, once to
> > get its
> > > > > > > >> generated tree and once to give the 'merged' tree with the
> > U-Boot
> > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > >>
> > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > option, not a
> > > > > > > >> build-time one. It creates all sorts of problems and
> > obscurity which
> > > > > > > >> have taken months to unpick. See the above patch for the
> > rationale.
> > > > > > > >>
> > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > available to
> > > > > > > >> any board. At some point in the future it may become a common
> > way
> > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > devicetree
> > > > > > > >> to it. It doesn't make any sense to have people decide
> > whether or not
> > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > is put
> > > > > > > >> together. We'll end up with different U-Boot build targets
> > like
> > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > obvious where
> > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > used
> > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > of build
> > > > > > > >> explosion is not needed.
> > > > > > > >
> > > > > > > > If you mean that when boards are by construction providing a
> > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > set supports it as it puts dts files for those boards to be built.
> > > > > > > >>
> > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > >> function correctly in whatever runtime environment in which
> > it finds
> > > > > > > >> itself.
> > > > > > > >>
> > > > > > > >> Also as binman is pressed into service more and more to build
> > the
> > > > > > > >> complex firmware images that are becoming fashionable, it
> > needs a
> > > > > > > >> definition (in the devicetree) that describes how to create
> > the image.
> > > > > > > >> We can't support that unless we are building a devicetree,
> > nor can the
> > > > > > > >> running program access the image layout without that
> > information.
> > > > > > > >>
> > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > >> germane...but of course I am not suggesting doing that, since
> > OF_BOARD
> > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > boards that
> > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > example
> > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > but some
> > > > > > > >> don't."). So this series is just completing the picture by
> > enforcing
> > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > >
> > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > >
> > > > > > > I think the key point that will get you closer to where I am on
> > this
> > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > present it
> > > > > > > has build-time effects and this is quite wrong. If you go
> > through all
> > > > > > > the material I have written on this I think I have motivated
> > that very
> > > > > > > clearly.
> > > > > > >
> > > > > > > Another big issue is that I believe we need ONE devicetree for
> > U-Boot,
> > > > > > > not two that get merged by U-Boot. Again I have gone through
> > that in a
> > > > > > > lot of detail.
> > > > > >
> > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > here's the biggest sticking point. To be clear, you agree that
> > U-Boot
> > > > > > needs to support being passed a device tree to use, at run time,
> > yes?
> > > > >
> > > > > Yes. The OF_BOARD feature provides this.
> > > > >
> > > > > >
> > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > >
> > > > > Not at runtime.
> > > >
> > > > OK.
> > > >
> > > > > > So is the sticking point here that we really have two classes of
> > > > > > devices, one class where we will never ever be given the device
> > tree at
> > > > > > run time (think BeagleBone Black) and one where we will always be
> > given
> > > > > > one at run time (think Raspberry Pi) ?
> > > > >
> > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > can also accept one at runtime, if provided. For example, you may
> > want
> > > > > to boot with or without TF-A or some other, earlier stage.
> > > >
> > > > I'm not sure I see the value in making this a gray area. There's very
> > > > much a class of "never" boards. There's also the class of "can" today.
> > > > Maybe as part of a developer iterative flow it would be nice to not
> > have
> > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > until things are happy, but I'm not sure what the use case is for
> > > > overriding the previous stage.
> > > >
> > > > Especially since the pushback on this series I think has all been "why
> > > > are we copying in a tree to build with? We don't want to use it at run
> > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > include the device tree file here, but we won't use it...".
> > >
> > > See below.
> > >
> > > >
> > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > inadvertently)
> > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > U-Boot, as we have for rpi_3, etc.
> > > >
> > > > I really want to see what the binary case looks like since we could
> > then
> > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > then also do a rpi_arm32_defconfig too.
> > > >
> > > > I want to see less device trees in U-Boot sources, if they can come
> > > > functionally correct from the hardware/our caller.
> > > >
> > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > use the device tree from build time at run time, ignoring the device
> > > > tree provided to us at run time by the caller.
> > >
> > > Firstly I should say that I find building firmware very messy and
> > > confusing these days. Lots of things to build and it's hard to find
> > > the instructions. It doesn't have to be that way, but if we carry on
> > > as we are, it will continue to be messy and in five years you will
> > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > objective here is to simplify things, bringing some consistency to the
> > > different components. Binman was one effort there. I feel that putting
> > > at least the U-Boot house in order, in my role as devicetree
> > > maintainer (and as author of devicetree support in U-Boot back in
> > > 2011), is the next step.
> >
> > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > that know where to grab other known-good binaries of varying licenses
> > that are needed to assemble something that boots.
> >
> > > If we set things up correctly and agree on the bindings, devicetree
> > > can be the unifying configuration mechanism through the whole of
> > > firmware (except for very early bits) and into the OS, this will set
> > > us up very well to deal with the complexity that is coming.
> > >
> > > Anyway, here are the mental steps that I've gone through over the past
> > > two months:
> > >
> > > Step 1: At present, some people think U-Boot is not even allowed to
> > > have its own nodes/properties in the DT.
>
> In my view U-Boot shall be able to leverage device tree format (source and
> binary) to store its own data.
> When you say "the" DT, I always think this is "the" DT that is passed to OS
> and in "that" DT, there should be no U-Boot entries.
Why not? As long as the device tree validates, it is perfectly fine
to have additional nodes and properties present. The propertiesand
nodes will be simply ignored by the OS.
OpenBSD will print:
"binman" not configured
for the binman node that some of the U-Boot board targets now have,
but it doesn't really make a difference. If there is a proper binding
for that node, I could simply filter it out. Or we have U-Boot filter
it out before the DT gets passed along like Tom suggests.
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 15:10 ` Mark Kettenis
@ 2021-10-27 15:24 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-27 15:24 UTC (permalink / raw)
To: Mark Kettenis
Cc: François Ozog, Tom Rini, Aaron Williams, Albert ARIBAUD,
Alex Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki, vanbaren,
kever.yang, ycliang, linus.walleij, liviu.dudau, marek.behun,
mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
Hi Mark,
On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: François Ozog <francois.ozog@linaro.org>
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.ozog@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > sjg@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put in
> > > this series
> > > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > Between
> > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > > footing.
> > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > use.
> > > > > > > > >> For more context:
> > > > > > > > >>
> > > > > > > > >>
> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >>
> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > adding the
> > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > > >> maintainer would prefer there was no special support even for
> > > booting
> > > > > > > > >> Linux directly!)
> > > > > > > > >
> > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > >>
> > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > get its
> > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > U-Boot
> > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > >>
> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > option, not a
> > > > > > > > >> build-time one. It creates all sorts of problems and
> > > obscurity which
> > > > > > > > >> have taken months to unpick. See the above patch for the
> > > rationale.
> > > > > > > > >>
> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > available to
> > > > > > > > >> any board. At some point in the future it may become a common
> > > way
> > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > devicetree
> > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > whether or not
> > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > > is put
> > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > like
> > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > obvious where
> > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > > used
> > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > > of build
> > > > > > > > >> explosion is not needed.
> > > > > > > > >
> > > > > > > > > If you mean that when boards are by construction providing a
> > > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > >>
> > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > >> function correctly in whatever runtime environment in which
> > > it finds
> > > > > > > > >> itself.
> > > > > > > > >>
> > > > > > > > >> Also as binman is pressed into service more and more to build
> > > the
> > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > needs a
> > > > > > > > >> definition (in the devicetree) that describes how to create
> > > the image.
> > > > > > > > >> We can't support that unless we are building a devicetree,
> > > nor can the
> > > > > > > > >> running program access the image layout without that
> > > information.
> > > > > > > > >>
> > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > >> germane...but of course I am not suggesting doing that, since
> > > OF_BOARD
> > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > boards that
> > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > > example
> > > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > > but some
> > > > > > > > >> don't."). So this series is just completing the picture by
> > > enforcing
> > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > >
> > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > > >
> > > > > > > > I think the key point that will get you closer to where I am on
> > > this
> > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > present it
> > > > > > > > has build-time effects and this is quite wrong. If you go
> > > through all
> > > > > > > > the material I have written on this I think I have motivated
> > > that very
> > > > > > > > clearly.
> > > > > > > >
> > > > > > > > Another big issue is that I believe we need ONE devicetree for
> > > U-Boot,
> > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > that in a
> > > > > > > > lot of detail.
> > > > > > >
> > > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > U-Boot
> > > > > > > needs to support being passed a device tree to use, at run time,
> > > yes?
> > > > > >
> > > > > > Yes. The OF_BOARD feature provides this.
> > > > > >
> > > > > > >
> > > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > > >
> > > > > > Not at runtime.
> > > > >
> > > > > OK.
> > > > >
> > > > > > > So is the sticking point here that we really have two classes of
> > > > > > > devices, one class where we will never ever be given the device
> > > tree at
> > > > > > > run time (think BeagleBone Black) and one where we will always be
> > > given
> > > > > > > one at run time (think Raspberry Pi) ?
> > > > > >
> > > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > > can also accept one at runtime, if provided. For example, you may
> > > want
> > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > >
> > > > > I'm not sure I see the value in making this a gray area. There's very
> > > > > much a class of "never" boards. There's also the class of "can" today.
> > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > have
> > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > > until things are happy, but I'm not sure what the use case is for
> > > > > overriding the previous stage.
> > > > >
> > > > > Especially since the pushback on this series I think has all been "why
> > > > > are we copying in a tree to build with? We don't want to use it at run
> > > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > > include the device tree file here, but we won't use it...".
> > > >
> > > > See below.
> > > >
> > > > >
> > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > inadvertently)
> > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > > U-Boot, as we have for rpi_3, etc.
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > >
> > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > that know where to grab other known-good binaries of varying licenses
> > > that are needed to assemble something that boots.
> > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT.
> >
> > In my view U-Boot shall be able to leverage device tree format (source and
> > binary) to store its own data.
> > When you say "the" DT, I always think this is "the" DT that is passed to OS
> > and in "that" DT, there should be no U-Boot entries.
>
> Why not? As long as the device tree validates, it is perfectly fine
> to have additional nodes and properties present. The propertiesand
> nodes will be simply ignored by the OS.
>
> OpenBSD will print:
>
> "binman" not configured
>
> for the binman node that some of the U-Boot board targets now have,
> but it doesn't really make a difference. If there is a proper binding
> for that node, I could simply filter it out. Or we have U-Boot filter
> it out before the DT gets passed along like Tom suggests.
Just on that point, I believe the binman falls into the same bucket
that Tom is talking about here, in that it should be a standard
binding. Ideally I would like this to become a standard format so that
anything in firmware can use it to find stuff. I believe it is a good
and extensible way to describe the structure of firmware across all
projects.
Does "not configured" mean that it did not find the compatible string?
We could add one of those, for now, perhaps.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 15:24 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-27 15:24 UTC (permalink / raw)
To: Mark Kettenis
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, swarren, sr,
Fabio Estevam, rainer.boschung, François Ozog, swarren,
oleksandr_andrushchenko, Heinrich Schuchardt, lusus,
michal.simek, marek.behun, vanbaren, rfried.dev, Jagan Teki,
valentin.longchamp, Heiko Schocher, pbrobinson, sinan, fitzsim,
wd, Tom Rini, qemu-devel, Andre Przywara, tharvey,
Ashok Reddy Soma, rick, Alex Graf, Green Wan, t.karthik.reddy,
Anastasiia Lukianenko, Albert ARIBAUD, monstr, mbrugger, ycliang,
kristo, u-boot, David Abdurachmanov, priyanka.jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
tuomas.tynkkynen, Heinrich Schuchardt, tianrui-wei, Bin Meng,
pali, Dimitri John Ledkov, padmarao.begari
Hi Mark,
On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > From: François Ozog <francois.ozog@linaro.org>
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.ozog@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > sjg@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put in
> > > this series
> > > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > Between
> > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > > footing.
> > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > use.
> > > > > > > > >> For more context:
> > > > > > > > >>
> > > > > > > > >>
> > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >>
> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > adding the
> > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > > >> maintainer would prefer there was no special support even for
> > > booting
> > > > > > > > >> Linux directly!)
> > > > > > > > >
> > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > >>
> > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > get its
> > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > U-Boot
> > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > >>
> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > option, not a
> > > > > > > > >> build-time one. It creates all sorts of problems and
> > > obscurity which
> > > > > > > > >> have taken months to unpick. See the above patch for the
> > > rationale.
> > > > > > > > >>
> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > available to
> > > > > > > > >> any board. At some point in the future it may become a common
> > > way
> > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > devicetree
> > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > whether or not
> > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > > is put
> > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > like
> > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > obvious where
> > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > > used
> > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > > of build
> > > > > > > > >> explosion is not needed.
> > > > > > > > >
> > > > > > > > > If you mean that when boards are by construction providing a
> > > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > >>
> > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > >> function correctly in whatever runtime environment in which
> > > it finds
> > > > > > > > >> itself.
> > > > > > > > >>
> > > > > > > > >> Also as binman is pressed into service more and more to build
> > > the
> > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > needs a
> > > > > > > > >> definition (in the devicetree) that describes how to create
> > > the image.
> > > > > > > > >> We can't support that unless we are building a devicetree,
> > > nor can the
> > > > > > > > >> running program access the image layout without that
> > > information.
> > > > > > > > >>
> > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > >> germane...but of course I am not suggesting doing that, since
> > > OF_BOARD
> > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > boards that
> > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > > example
> > > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > > but some
> > > > > > > > >> don't."). So this series is just completing the picture by
> > > enforcing
> > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > >
> > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > > >
> > > > > > > > I think the key point that will get you closer to where I am on
> > > this
> > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > present it
> > > > > > > > has build-time effects and this is quite wrong. If you go
> > > through all
> > > > > > > > the material I have written on this I think I have motivated
> > > that very
> > > > > > > > clearly.
> > > > > > > >
> > > > > > > > Another big issue is that I believe we need ONE devicetree for
> > > U-Boot,
> > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > that in a
> > > > > > > > lot of detail.
> > > > > > >
> > > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > U-Boot
> > > > > > > needs to support being passed a device tree to use, at run time,
> > > yes?
> > > > > >
> > > > > > Yes. The OF_BOARD feature provides this.
> > > > > >
> > > > > > >
> > > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > > >
> > > > > > Not at runtime.
> > > > >
> > > > > OK.
> > > > >
> > > > > > > So is the sticking point here that we really have two classes of
> > > > > > > devices, one class where we will never ever be given the device
> > > tree at
> > > > > > > run time (think BeagleBone Black) and one where we will always be
> > > given
> > > > > > > one at run time (think Raspberry Pi) ?
> > > > > >
> > > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > > can also accept one at runtime, if provided. For example, you may
> > > want
> > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > >
> > > > > I'm not sure I see the value in making this a gray area. There's very
> > > > > much a class of "never" boards. There's also the class of "can" today.
> > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > have
> > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > > until things are happy, but I'm not sure what the use case is for
> > > > > overriding the previous stage.
> > > > >
> > > > > Especially since the pushback on this series I think has all been "why
> > > > > are we copying in a tree to build with? We don't want to use it at run
> > > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > > include the device tree file here, but we won't use it...".
> > > >
> > > > See below.
> > > >
> > > > >
> > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > inadvertently)
> > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > > U-Boot, as we have for rpi_3, etc.
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > use the device tree from build time at run time, ignoring the device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to the
> > > > different components. Binman was one effort there. I feel that putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > >
> > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > that know where to grab other known-good binaries of varying licenses
> > > that are needed to assemble something that boots.
> > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT.
> >
> > In my view U-Boot shall be able to leverage device tree format (source and
> > binary) to store its own data.
> > When you say "the" DT, I always think this is "the" DT that is passed to OS
> > and in "that" DT, there should be no U-Boot entries.
>
> Why not? As long as the device tree validates, it is perfectly fine
> to have additional nodes and properties present. The propertiesand
> nodes will be simply ignored by the OS.
>
> OpenBSD will print:
>
> "binman" not configured
>
> for the binman node that some of the U-Boot board targets now have,
> but it doesn't really make a difference. If there is a proper binding
> for that node, I could simply filter it out. Or we have U-Boot filter
> it out before the DT gets passed along like Tom suggests.
Just on that point, I believe the binman falls into the same bucket
that Tom is talking about here, in that it should be a standard
binding. Ideally I would like this to become a standard format so that
anything in firmware can use it to find stuff. I believe it is a good
and extensible way to describe the structure of firmware across all
projects.
Does "not configured" mean that it did not find the compatible string?
We could add one of those, for now, perhaps.
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 15:24 ` Simon Glass
@ 2021-10-27 18:06 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:06 UTC (permalink / raw)
To: Simon Glass
Cc: Mark Kettenis, François Ozog, Aaron Williams,
Albert ARIBAUD, Alex Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki, vanbaren,
kever.yang, ycliang, linus.walleij, liviu.dudau, marek.behun,
mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 16848 bytes --]
On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > sjg@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put in
> > > > this series
> > > > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with people
> > > > for a
> > > > > > > > > >> few months now. I've been signalling a change like this for
> > > > over a
> > > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > > with Linaro
> > > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > > hope it is
> > > > > > > > > >> not a surprise!
> > > > > > > > > >>
> > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > U-Boot, to
> > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > > OF_BOARD,
> > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > > Between
> > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > > > footing.
> > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > > use.
> > > > > > > > > >> For more context:
> > > > > > > > > >>
> > > > > > > > > >>
> > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >>
> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > > adding the
> > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > > > >> maintainer would prefer there was no special support even for
> > > > booting
> > > > > > > > > >> Linux directly!)
> > > > > > > > > >
> > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > >>
> > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > > get its
> > > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > > U-Boot
> > > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > > >>
> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > option, not a
> > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > obscurity which
> > > > > > > > > >> have taken months to unpick. See the above patch for the
> > > > rationale.
> > > > > > > > > >>
> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > > available to
> > > > > > > > > >> any board. At some point in the future it may become a common
> > > > way
> > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > > devicetree
> > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > whether or not
> > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > > > is put
> > > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > > like
> > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > > obvious where
> > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > > > used
> > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > > > of build
> > > > > > > > > >> explosion is not needed.
> > > > > > > > > >
> > > > > > > > > > If you mean that when boards are by construction providing a
> > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > >>
> > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > >> function correctly in whatever runtime environment in which
> > > > it finds
> > > > > > > > > >> itself.
> > > > > > > > > >>
> > > > > > > > > >> Also as binman is pressed into service more and more to build
> > > > the
> > > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > > needs a
> > > > > > > > > >> definition (in the devicetree) that describes how to create
> > > > the image.
> > > > > > > > > >> We can't support that unless we are building a devicetree,
> > > > nor can the
> > > > > > > > > >> running program access the image layout without that
> > > > information.
> > > > > > > > > >>
> > > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > > >> germane...but of course I am not suggesting doing that, since
> > > > OF_BOARD
> > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > > boards that
> > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > > > example
> > > > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > > > but some
> > > > > > > > > >> don't."). So this series is just completing the picture by
> > > > enforcing
> > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > >
> > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > > > >
> > > > > > > > > I think the key point that will get you closer to where I am on
> > > > this
> > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > present it
> > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > through all
> > > > > > > > > the material I have written on this I think I have motivated
> > > > that very
> > > > > > > > > clearly.
> > > > > > > > >
> > > > > > > > > Another big issue is that I believe we need ONE devicetree for
> > > > U-Boot,
> > > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > > that in a
> > > > > > > > > lot of detail.
> > > > > > > >
> > > > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > > U-Boot
> > > > > > > > needs to support being passed a device tree to use, at run time,
> > > > yes?
> > > > > > >
> > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > >
> > > > > > > >
> > > > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > > > >
> > > > > > > Not at runtime.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > > So is the sticking point here that we really have two classes of
> > > > > > > > devices, one class where we will never ever be given the device
> > > > tree at
> > > > > > > > run time (think BeagleBone Black) and one where we will always be
> > > > given
> > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > >
> > > > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > > > can also accept one at runtime, if provided. For example, you may
> > > > want
> > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > >
> > > > > > I'm not sure I see the value in making this a gray area. There's very
> > > > > > much a class of "never" boards. There's also the class of "can" today.
> > > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > > have
> > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > > > until things are happy, but I'm not sure what the use case is for
> > > > > > overriding the previous stage.
> > > > > >
> > > > > > Especially since the pushback on this series I think has all been "why
> > > > > > are we copying in a tree to build with? We don't want to use it at run
> > > > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > > > include the device tree file here, but we won't use it...".
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > inadvertently)
> > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to the
> > > > > different components. Binman was one effort there. I feel that putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > >
> > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > > that know where to grab other known-good binaries of varying licenses
> > > > that are needed to assemble something that boots.
> > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT.
> > >
> > > In my view U-Boot shall be able to leverage device tree format (source and
> > > binary) to store its own data.
> > > When you say "the" DT, I always think this is "the" DT that is passed to OS
> > > and in "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
> >
> > OpenBSD will print:
> >
> > "binman" not configured
> >
> > for the binman node that some of the U-Boot board targets now have,
> > but it doesn't really make a difference. If there is a proper binding
> > for that node, I could simply filter it out. Or we have U-Boot filter
> > it out before the DT gets passed along like Tom suggests.
>
> Just on that point, I believe the binman falls into the same bucket
> that Tom is talking about here, in that it should be a standard
> binding. Ideally I would like this to become a standard format so that
> anything in firmware can use it to find stuff. I believe it is a good
> and extensible way to describe the structure of firmware across all
> projects.
And at the risk of getting lost on specific details, if we look at:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
it says "In the future, it may be provided as part of a device blob,
along with the rest of the information about images to load." which is
one of the things the binman node solves, so we should probably solve
this problem once, for everyone rather than per-project.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:06 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 18:06 UTC (permalink / raw)
To: Simon Glass
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, sr,
Fabio Estevam, rainer.boschung, Mark Kettenis,
François Ozog, swarren, oleksandr_andrushchenko,
Heinrich Schuchardt, lusus, michal.simek, marek.behun, vanbaren,
rfried.dev, Jagan Teki, valentin.longchamp, Heiko Schocher,
pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel,
Andre Przywara, tharvey, Ashok Reddy Soma, rick, Alex Graf,
Green Wan, t.karthik.reddy, Anastasiia Lukianenko,
Albert ARIBAUD, monstr, mbrugger, ycliang, kristo, u-boot,
David Abdurachmanov, priyanka.jain, Ilias Apalodimas,
Christian Hewitt, Aaron Williams, tuomas.tynkkynen,
Heinrich Schuchardt, tianrui-wei, Bin Meng, pali,
Dimitri John Ledkov, padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 16848 bytes --]
On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org>
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > sjg@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put in
> > > > this series
> > > > > > > > > >> > > has various hardcoded <phandle> values which normally do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with people
> > > > for a
> > > > > > > > > >> few months now. I've been signalling a change like this for
> > > > over a
> > > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > > with Linaro
> > > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > > hope it is
> > > > > > > > > >> not a surprise!
> > > > > > > > > >>
> > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > U-Boot, to
> > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > > OF_BOARD,
> > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > > Between
> > > > > > > > > >> Ilias' series and this one we can get ourselves on a stronger
> > > > footing.
> > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > > use.
> > > > > > > > > >> For more context:
> > > > > > > > > >>
> > > > > > > > > >>
> > > > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >>
> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > > adding the
> > > > > > > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > > > > > > >> maintainer would prefer there was no special support even for
> > > > booting
> > > > > > > > > >> Linux directly!)
> > > > > > > > > >
> > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > >>
> > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > > get its
> > > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > > U-Boot
> > > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > > >>
> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > option, not a
> > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > obscurity which
> > > > > > > > > >> have taken months to unpick. See the above patch for the
> > > > rationale.
> > > > > > > > > >>
> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > > available to
> > > > > > > > > >> any board. At some point in the future it may become a common
> > > > way
> > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > > devicetree
> > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > whether or not
> > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the image
> > > > is put
> > > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > > like
> > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > > obvious where
> > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a commonly
> > > > used
> > > > > > > > > >> option, perhaps enabled by most/all boards, so that this sort
> > > > of build
> > > > > > > > > >> explosion is not needed.
> > > > > > > > > >
> > > > > > > > > > If you mean that when boards are by construction providing a
> > > > DTB to U-Boot then I agree very much. But I don’t understand how the patch
> > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > >>
> > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > >> function correctly in whatever runtime environment in which
> > > > it finds
> > > > > > > > > >> itself.
> > > > > > > > > >>
> > > > > > > > > >> Also as binman is pressed into service more and more to build
> > > > the
> > > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > > needs a
> > > > > > > > > >> definition (in the devicetree) that describes how to create
> > > > the image.
> > > > > > > > > >> We can't support that unless we are building a devicetree,
> > > > nor can the
> > > > > > > > > >> running program access the image layout without that
> > > > information.
> > > > > > > > > >>
> > > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > > >> germane...but of course I am not suggesting doing that, since
> > > > OF_BOARD
> > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > > boards that
> > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> > > > example
> > > > > > > > > >> (as I said in the cover letter "Most boards do provide one,
> > > > but some
> > > > > > > > > >> don't."). So this series is just completing the picture by
> > > > enforcing
> > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > >
> > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > > > > > > >
> > > > > > > > > I think the key point that will get you closer to where I am on
> > > > this
> > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > present it
> > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > through all
> > > > > > > > > the material I have written on this I think I have motivated
> > > > that very
> > > > > > > > > clearly.
> > > > > > > > >
> > > > > > > > > Another big issue is that I believe we need ONE devicetree for
> > > > U-Boot,
> > > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > > that in a
> > > > > > > > > lot of detail.
> > > > > > > >
> > > > > > > > I have a long long reply to your first reply here saved, but, maybe
> > > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > > U-Boot
> > > > > > > > needs to support being passed a device tree to use, at run time,
> > > > yes?
> > > > > > >
> > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > >
> > > > > > > >
> > > > > > > > And in that case, would not be using the "fake" tree we built in?
> > > > > > >
> > > > > > > Not at runtime.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > > So is the sticking point here that we really have two classes of
> > > > > > > > devices, one class where we will never ever be given the device
> > > > tree at
> > > > > > > > run time (think BeagleBone Black) and one where we will always be
> > > > given
> > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > >
> > > > > > > I'm not sure it will be that black and white. I suspect there will be
> > > > > > > (many) boards which can boot happily with the U-Boot devicetree but
> > > > > > > can also accept one at runtime, if provided. For example, you may
> > > > want
> > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > >
> > > > > > I'm not sure I see the value in making this a gray area. There's very
> > > > > > much a class of "never" boards. There's also the class of "can" today.
> > > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > > have
> > > > > > to re-flash the prior stage to change a DT, and just do it in U-Boot
> > > > > > until things are happy, but I'm not sure what the use case is for
> > > > > > overriding the previous stage.
> > > > > >
> > > > > > Especially since the pushback on this series I think has all been "why
> > > > > > are we copying in a tree to build with? We don't want to use it at run
> > > > > > time!". And then softer push back like "Well, U-Boot says we have to
> > > > > > include the device tree file here, but we won't use it...".
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > inadvertently)
> > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus making
> > > > > > > things like binman and U-Boot /config impossible, for example. So I
> > > > > > > want to claw that back, so there is always some sort of devicetree in
> > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also don't
> > > > > > use the device tree from build time at run time, ignoring the device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to the
> > > > > different components. Binman was one effort there. I feel that putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > >
> > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > > that know where to grab other known-good binaries of varying licenses
> > > > that are needed to assemble something that boots.
> > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT.
> > >
> > > In my view U-Boot shall be able to leverage device tree format (source and
> > > binary) to store its own data.
> > > When you say "the" DT, I always think this is "the" DT that is passed to OS
> > > and in "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
> >
> > OpenBSD will print:
> >
> > "binman" not configured
> >
> > for the binman node that some of the U-Boot board targets now have,
> > but it doesn't really make a difference. If there is a proper binding
> > for that node, I could simply filter it out. Or we have U-Boot filter
> > it out before the DT gets passed along like Tom suggests.
>
> Just on that point, I believe the binman falls into the same bucket
> that Tom is talking about here, in that it should be a standard
> binding. Ideally I would like this to become a standard format so that
> anything in firmware can use it to find stuff. I believe it is a good
> and extensible way to describe the structure of firmware across all
> projects.
And at the risk of getting lost on specific details, if we look at:
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
it says "In the future, it may be provided as part of a device blob,
along with the rest of the information about images to load." which is
one of the things the binman node solves, so we should probably solve
this problem once, for everyone rather than per-project.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 18:06 ` Tom Rini
@ 2021-10-27 18:11 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 18:11 UTC (permalink / raw)
To: Tom Rini
Cc: Aaron Williams, Albert ARIBAUD, Alex Graf, Anastasiia Lukianenko,
Andre Przywara, Ashok Reddy Soma, Atish Patra, Bin Meng,
Bin Meng, Christian Hewitt, David Abdurachmanov,
Dimitri John Ledkov, Fabio Estevam, Green Wan, Heiko Schocher,
Heinrich Schuchardt, Heinrich Schuchardt, Ilias Apalodimas,
Jagan Teki, Mark Kettenis, Simon Glass, fitzsim, kever.yang,
kristo, linus.walleij, liviu.dudau, lusus, marek.behun, mbrugger,
michal.simek, monstr, narmstrong, oleksandr_andrushchenko,
padmarao.begari, pali, pbrobinson, priyanka.jain, qemu-devel,
rainer.boschung, rfried.dev, rick, seanga2, sinan, sr, swarren,
swarren, t.karthik.reddy, tharvey, tianrui-wei, tuomas.tynkkynen,
u-boot, valentin.longchamp, vanbaren, vladimir.oltean, wd,
ycliang, zong.li
Hi Tom
Le mer. 27 oct. 2021 à 20:06, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> > >
> > > > From: François Ozog <francois.ozog@linaro.org>
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> sjg@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> trini@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > sjg@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded <phandle> values which
> normally do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > > > > > > > > >> I have been thinking about this and discussing it
> with people
> > > > > for a
> > > > > > > > > > >> few months now. I've been signalling a change like
> this for
> > > > > over a
> > > > > > > > > > >> month now, on U-Boot contributor calls and in
> discussions
> > > > > with Linaro
> > > > > > > > > > >> people. I sent a patch (below) to try to explain
> things. I
> > > > > hope it is
> > > > > > > > > > >> not a surprise!
> > > > > > > > > > >>
> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > U-Boot, to
> > > > > > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE,
> > > > > OF_BOARD,
> > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE.
> > > > > Between
> > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger
> > > > > footing.
> > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF
> > > > > use.
> > > > > > > > > > >> For more context:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >>
> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of
> > > > > adding the
> > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > > > > > >> maintainer would prefer there was no special support
> even for
> > > > > booting
> > > > > > > > > > >> Linux directly!)
> > > > > > > > > > >
> > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > >>
> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > >> think the path forward might be to run QEMU twice,
> once to
> > > > > get its
> > > > > > > > > > >> generated tree and once to give the 'merged' tree
> with the
> > > > > U-Boot
> > > > > > > > > > >> properties in it, if people want to use U-Boot
> features.
> > > > > > > > > > >>
> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > option, not a
> > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > obscurity which
> > > > > > > > > > >> have taken months to unpick. See the above patch for
> the
> > > > > rationale.
> > > > > > > > > > >>
> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option
> > > > > available to
> > > > > > > > > > >> any board. At some point in the future it may become
> a common
> > > > > way
> > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a
> > > > > devicetree
> > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > whether or not
> > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image
> > > > > is put
> > > > > > > > > > >> together. We'll end up with different U-Boot build
> targets
> > > > > like
> > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> be
> > > > > obvious where
> > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly
> > > > > used
> > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> this sort
> > > > > of build
> > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > >
> > > > > > > > > > > If you mean that when boards are by construction
> providing a
> > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> the patch
> > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > >>
> > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > >> function correctly in whatever runtime environment in
> which
> > > > > it finds
> > > > > > > > > > >> itself.
> > > > > > > > > > >>
> > > > > > > > > > >> Also as binman is pressed into service more and more
> to build
> > > > > the
> > > > > > > > > > >> complex firmware images that are becoming
> fashionable, it
> > > > > needs a
> > > > > > > > > > >> definition (in the devicetree) that describes how to
> create
> > > > > the image.
> > > > > > > > > > >> We can't support that unless we are building a
> devicetree,
> > > > > nor can the
> > > > > > > > > > >> running program access the image layout without that
> > > > > information.
> > > > > > > > > > >>
> > > > > > > > > > >> François's point about 'don't use this with any
> kernel' is
> > > > > > > > > > >> germane...but of course I am not suggesting doing
> that, since
> > > > > OF_BOARD
> > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> various
> > > > > boards that
> > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3, for
> > > > > example
> > > > > > > > > > >> (as I said in the cover letter "Most boards do
> provide one,
> > > > > but some
> > > > > > > > > > >> don't."). So this series is just completing the
> picture by
> > > > > enforcing
> > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > >
> > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > > > > > >
> > > > > > > > > > I think the key point that will get you closer to where
> I am on
> > > > > this
> > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > present it
> > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > through all
> > > > > > > > > > the material I have written on this I think I have
> motivated
> > > > > that very
> > > > > > > > > > clearly.
> > > > > > > > > >
> > > > > > > > > > Another big issue is that I believe we need ONE
> devicetree for
> > > > > U-Boot,
> > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> through
> > > > > that in a
> > > > > > > > > > lot of detail.
> > > > > > > > >
> > > > > > > > > I have a long long reply to your first reply here saved,
> but, maybe
> > > > > > > > > here's the biggest sticking point. To be clear, you agree
> that
> > > > > U-Boot
> > > > > > > > > needs to support being passed a device tree to use, at run
> time,
> > > > > yes?
> > > > > > > >
> > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > And in that case, would not be using the "fake" tree we
> built in?
> > > > > > > >
> > > > > > > > Not at runtime.
> > > > > > >
> > > > > > > OK.
> > > > > > >
> > > > > > > > > So is the sticking point here that we really have two
> classes of
> > > > > > > > > devices, one class where we will never ever be given the
> device
> > > > > tree at
> > > > > > > > > run time (think BeagleBone Black) and one where we will
> always be
> > > > > given
> > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > >
> > > > > > > > I'm not sure it will be that black and white. I suspect
> there will be
> > > > > > > > (many) boards which can boot happily with the U-Boot
> devicetree but
> > > > > > > > can also accept one at runtime, if provided. For example,
> you may
> > > > > want
> > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > >
> > > > > > > I'm not sure I see the value in making this a gray area.
> There's very
> > > > > > > much a class of "never" boards. There's also the class of
> "can" today.
> > > > > > > Maybe as part of a developer iterative flow it would be nice
> to not
> > > > > have
> > > > > > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > > > > > until things are happy, but I'm not sure what the use case is
> for
> > > > > > > overriding the previous stage.
> > > > > > >
> > > > > > > Especially since the pushback on this series I think has all
> been "why
> > > > > > > are we copying in a tree to build with? We don't want to use
> it at run
> > > > > > > time!". And then softer push back like "Well, U-Boot says we
> have to
> > > > > > > include the device tree file here, but we won't use it...".
> > > > > >
> > > > > > See below.
> > > > > >
> > > > > > >
> > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > inadvertently)
> > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> thus making
> > > > > > > > things like binman and U-Boot /config impossible, for
> example. So I
> > > > > > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> could
> > > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> > > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to
> find
> > > > > > the instructions. It doesn't have to be that way, but if we
> carry on
> > > > > > as we are, it will continue to be messy and in five years you
> will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency
> to the
> > > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > >
> > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> scripts
> > > > > that know where to grab other known-good binaries of varying
> licenses
> > > > > that are needed to assemble something that boots.
> > > > >
> > > > > > If we set things up correctly and agree on the bindings,
> devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over
> the past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed
> to
> > > > > > have its own nodes/properties in the DT.
> > > >
> > > > In my view U-Boot shall be able to leverage device tree format
> (source and
> > > > binary) to store its own data.
> > > > When you say "the" DT, I always think this is "the" DT that is
> passed to OS
> > > > and in "that" DT, there should be no U-Boot entries.
> > >
> > > Why not? As long as the device tree validates, it is perfectly fine
> > > to have additional nodes and properties present. The propertiesand
> > > nodes will be simply ignored by the OS.
> > >
> > > OpenBSD will print:
> > >
> > > "binman" not configured
> > >
> > > for the binman node that some of the U-Boot board targets now have,
> > > but it doesn't really make a difference. If there is a proper binding
> > > for that node, I could simply filter it out. Or we have U-Boot filter
> > > it out before the DT gets passed along like Tom suggests.
> >
> > Just on that point, I believe the binman falls into the same bucket
> > that Tom is talking about here, in that it should be a standard
> > binding. Ideally I would like this to become a standard format so that
> > anything in firmware can use it to find stuff. I believe it is a good
> > and extensible way to describe the structure of firmware across all
> > projects.
>
> And at the risk of getting lost on specific details, if we look at:
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> it says "In the future, it may be provided as part of a device blob,
> along with the rest of the information about images to load." which is
> one of the things the binman node solves, so we should probably solve
> this problem once, for everyone rather than per-project.
>
i wish we could. We need RISC-V input here.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 18:11 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 18:11 UTC (permalink / raw)
To: Tom Rini
Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij,
Bin Meng, kever.yang, seanga2, Atish Patra, zong.li, sr,
Fabio Estevam, rainer.boschung, Mark Kettenis, swarren,
oleksandr_andrushchenko, Heinrich Schuchardt, lusus,
michal.simek, marek.behun, vanbaren, rfried.dev, Jagan Teki,
valentin.longchamp, Heiko Schocher, pbrobinson, sinan, fitzsim,
wd, swarren, Andre Przywara, tharvey, Ashok Reddy Soma,
qemu-devel, Alex Graf, Green Wan, t.karthik.reddy,
Anastasiia Lukianenko, Albert ARIBAUD, monstr, mbrugger, ycliang,
kristo, u-boot, David Abdurachmanov, priyanka.jain, Simon Glass,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
tuomas.tynkkynen, Heinrich Schuchardt, tianrui-wei, Bin Meng,
pali, Dimitri John Ledkov, padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 18141 bytes --]
Hi Tom
Le mer. 27 oct. 2021 à 20:06, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 09:24:25AM -0600, Simon Glass wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> > >
> > > > From: François Ozog <francois.ozog@linaro.org>
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> sjg@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> trini@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > sjg@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded <phandle> values which
> normally do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > > > > > > > > >> I have been thinking about this and discussing it
> with people
> > > > > for a
> > > > > > > > > > >> few months now. I've been signalling a change like
> this for
> > > > > over a
> > > > > > > > > > >> month now, on U-Boot contributor calls and in
> discussions
> > > > > with Linaro
> > > > > > > > > > >> people. I sent a patch (below) to try to explain
> things. I
> > > > > hope it is
> > > > > > > > > > >> not a surprise!
> > > > > > > > > > >>
> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > U-Boot, to
> > > > > > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE,
> > > > > OF_BOARD,
> > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE.
> > > > > Between
> > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger
> > > > > footing.
> > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF
> > > > > use.
> > > > > > > > > > >> For more context:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >>
> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of
> > > > > adding the
> > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > > > > > >> maintainer would prefer there was no special support
> even for
> > > > > booting
> > > > > > > > > > >> Linux directly!)
> > > > > > > > > > >
> > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > >>
> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > >> think the path forward might be to run QEMU twice,
> once to
> > > > > get its
> > > > > > > > > > >> generated tree and once to give the 'merged' tree
> with the
> > > > > U-Boot
> > > > > > > > > > >> properties in it, if people want to use U-Boot
> features.
> > > > > > > > > > >>
> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > option, not a
> > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > obscurity which
> > > > > > > > > > >> have taken months to unpick. See the above patch for
> the
> > > > > rationale.
> > > > > > > > > > >>
> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option
> > > > > available to
> > > > > > > > > > >> any board. At some point in the future it may become
> a common
> > > > > way
> > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a
> > > > > devicetree
> > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > whether or not
> > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image
> > > > > is put
> > > > > > > > > > >> together. We'll end up with different U-Boot build
> targets
> > > > > like
> > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> be
> > > > > obvious where
> > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly
> > > > > used
> > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> this sort
> > > > > of build
> > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > >
> > > > > > > > > > > If you mean that when boards are by construction
> providing a
> > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> the patch
> > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > >>
> > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > >> function correctly in whatever runtime environment in
> which
> > > > > it finds
> > > > > > > > > > >> itself.
> > > > > > > > > > >>
> > > > > > > > > > >> Also as binman is pressed into service more and more
> to build
> > > > > the
> > > > > > > > > > >> complex firmware images that are becoming
> fashionable, it
> > > > > needs a
> > > > > > > > > > >> definition (in the devicetree) that describes how to
> create
> > > > > the image.
> > > > > > > > > > >> We can't support that unless we are building a
> devicetree,
> > > > > nor can the
> > > > > > > > > > >> running program access the image layout without that
> > > > > information.
> > > > > > > > > > >>
> > > > > > > > > > >> François's point about 'don't use this with any
> kernel' is
> > > > > > > > > > >> germane...but of course I am not suggesting doing
> that, since
> > > > > OF_BOARD
> > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> various
> > > > > boards that
> > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3, for
> > > > > example
> > > > > > > > > > >> (as I said in the cover letter "Most boards do
> provide one,
> > > > > but some
> > > > > > > > > > >> don't."). So this series is just completing the
> picture by
> > > > > enforcing
> > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > >
> > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > > > > > >
> > > > > > > > > > I think the key point that will get you closer to where
> I am on
> > > > > this
> > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > present it
> > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > through all
> > > > > > > > > > the material I have written on this I think I have
> motivated
> > > > > that very
> > > > > > > > > > clearly.
> > > > > > > > > >
> > > > > > > > > > Another big issue is that I believe we need ONE
> devicetree for
> > > > > U-Boot,
> > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> through
> > > > > that in a
> > > > > > > > > > lot of detail.
> > > > > > > > >
> > > > > > > > > I have a long long reply to your first reply here saved,
> but, maybe
> > > > > > > > > here's the biggest sticking point. To be clear, you agree
> that
> > > > > U-Boot
> > > > > > > > > needs to support being passed a device tree to use, at run
> time,
> > > > > yes?
> > > > > > > >
> > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > And in that case, would not be using the "fake" tree we
> built in?
> > > > > > > >
> > > > > > > > Not at runtime.
> > > > > > >
> > > > > > > OK.
> > > > > > >
> > > > > > > > > So is the sticking point here that we really have two
> classes of
> > > > > > > > > devices, one class where we will never ever be given the
> device
> > > > > tree at
> > > > > > > > > run time (think BeagleBone Black) and one where we will
> always be
> > > > > given
> > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > >
> > > > > > > > I'm not sure it will be that black and white. I suspect
> there will be
> > > > > > > > (many) boards which can boot happily with the U-Boot
> devicetree but
> > > > > > > > can also accept one at runtime, if provided. For example,
> you may
> > > > > want
> > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > >
> > > > > > > I'm not sure I see the value in making this a gray area.
> There's very
> > > > > > > much a class of "never" boards. There's also the class of
> "can" today.
> > > > > > > Maybe as part of a developer iterative flow it would be nice
> to not
> > > > > have
> > > > > > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > > > > > until things are happy, but I'm not sure what the use case is
> for
> > > > > > > overriding the previous stage.
> > > > > > >
> > > > > > > Especially since the pushback on this series I think has all
> been "why
> > > > > > > are we copying in a tree to build with? We don't want to use
> it at run
> > > > > > > time!". And then softer push back like "Well, U-Boot says we
> have to
> > > > > > > include the device tree file here, but we won't use it...".
> > > > > >
> > > > > > See below.
> > > > > >
> > > > > > >
> > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > inadvertently)
> > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> thus making
> > > > > > > > things like binman and U-Boot /config impossible, for
> example. So I
> > > > > > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> could
> > > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also don't
> > > > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to
> find
> > > > > > the instructions. It doesn't have to be that way, but if we
> carry on
> > > > > > as we are, it will continue to be messy and in five years you
> will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency
> to the
> > > > > > different components. Binman was one effort there. I feel that
> putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > >
> > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> scripts
> > > > > that know where to grab other known-good binaries of varying
> licenses
> > > > > that are needed to assemble something that boots.
> > > > >
> > > > > > If we set things up correctly and agree on the bindings,
> devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over
> the past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed
> to
> > > > > > have its own nodes/properties in the DT.
> > > >
> > > > In my view U-Boot shall be able to leverage device tree format
> (source and
> > > > binary) to store its own data.
> > > > When you say "the" DT, I always think this is "the" DT that is
> passed to OS
> > > > and in "that" DT, there should be no U-Boot entries.
> > >
> > > Why not? As long as the device tree validates, it is perfectly fine
> > > to have additional nodes and properties present. The propertiesand
> > > nodes will be simply ignored by the OS.
> > >
> > > OpenBSD will print:
> > >
> > > "binman" not configured
> > >
> > > for the binman node that some of the U-Boot board targets now have,
> > > but it doesn't really make a difference. If there is a proper binding
> > > for that node, I could simply filter it out. Or we have U-Boot filter
> > > it out before the DT gets passed along like Tom suggests.
> >
> > Just on that point, I believe the binman falls into the same bucket
> > that Tom is talking about here, in that it should be a standard
> > binding. Ideally I would like this to become a standard format so that
> > anything in firmware can use it to find stuff. I believe it is a good
> > and extensible way to describe the structure of firmware across all
> > projects.
>
> And at the risk of getting lost on specific details, if we look at:
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> it says "In the future, it may be provided as part of a device blob,
> along with the rest of the information about images to load." which is
> one of the things the binman node solves, so we should probably solve
> this problem once, for everyone rather than per-project.
>
i wish we could. We need RISC-V input here.
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 28824 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 15:24 ` Simon Glass
@ 2021-10-27 21:52 ` Mark Kettenis
-1 siblings, 0 replies; 164+ messages in thread
From: Mark Kettenis @ 2021-10-27 21:52 UTC (permalink / raw)
To: Simon Glass
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
bin.meng, kever.yang, seanga2, atish.patra, zong.li, swarren, sr,
festevam, rainer.boschung, francois.ozog, swarren,
oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek,
marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs,
pbrobinson, sinan, fitzsim, wd, trini, qemu-devel,
andre.przywara, tharvey, ashok.reddy.soma, rick, agraf,
green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot,
monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov,
priyanka.jain, ilias.apalodimas, christianshewitt, awilliams,
tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei, bmeng.cn,
pali, dimitri.ledkov, padmarao.begari
> From: Simon Glass <sjg@chromium.org>
> Date: Wed, 27 Oct 2021 09:24:25 -0600
>
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > In my view U-Boot shall be able to leverage device tree format
> > > (source and binary) to store its own data. When you say "the"
> > > DT, I always think this is "the" DT that is passed to OS and in
> > > "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
> >
> > OpenBSD will print:
> >
> > "binman" not configured
> >
> > for the binman node that some of the U-Boot board targets now have,
> > but it doesn't really make a difference. If there is a proper binding
> > for that node, I could simply filter it out. Or we have U-Boot filter
> > it out before the DT gets passed along like Tom suggests.
>
> Just on that point, I believe the binman falls into the same bucket
> that Tom is talking about here, in that it should be a standard
> binding. Ideally I would like this to become a standard format so that
> anything in firmware can use it to find stuff. I believe it is a good
> and extensible way to describe the structure of firmware across all
> projects.
Oh, I agree that it is a reasonable thing to have a description of the
structure of the firmware in the device tree.
> Does "not configured" mean that it did not find the compatible string?
> We could add one of those, for now, perhaps.
"not configured" just means that no device driver attached to the
node. Usually that is because we don't have a device driver for the
device corresponding to the node yet. But in the case of the "binman"
node it doesn't really make sense for a device driver to attach. In
such a case we tend to filter out the node such that the "not
configured" line isn't printed. That can be done either by name or by
compatible string. So an "official" binding would help here and it
should either use a standardized name (that shouldn't be used for
other purposes then) or it should use defined a compatible string.
Anyway, this is not really critical. I just brought it up to
illustrate that such nodes are mostly harmless.
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 21:52 ` Mark Kettenis
0 siblings, 0 replies; 164+ messages in thread
From: Mark Kettenis @ 2021-10-27 21:52 UTC (permalink / raw)
To: Simon Glass
Cc: francois.ozog, trini, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, ashok.reddy.soma,
atish.patra, bin.meng, bmeng.cn, christianshewitt,
david.abdurachmanov, dimitri.ledkov, festevam, green.wan, hs,
heinrich.schuchardt, xypron.glpk, ilias.apalodimas, jagan,
vanbaren, kever.yang, ycliang, linus.walleij, liviu.dudau,
marek.behun, mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
> From: Simon Glass <sjg@chromium.org>
> Date: Wed, 27 Oct 2021 09:24:25 -0600
>
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 09:11, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> >
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > In my view U-Boot shall be able to leverage device tree format
> > > (source and binary) to store its own data. When you say "the"
> > > DT, I always think this is "the" DT that is passed to OS and in
> > > "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
> >
> > OpenBSD will print:
> >
> > "binman" not configured
> >
> > for the binman node that some of the U-Boot board targets now have,
> > but it doesn't really make a difference. If there is a proper binding
> > for that node, I could simply filter it out. Or we have U-Boot filter
> > it out before the DT gets passed along like Tom suggests.
>
> Just on that point, I believe the binman falls into the same bucket
> that Tom is talking about here, in that it should be a standard
> binding. Ideally I would like this to become a standard format so that
> anything in firmware can use it to find stuff. I believe it is a good
> and extensible way to describe the structure of firmware across all
> projects.
Oh, I agree that it is a reasonable thing to have a description of the
structure of the firmware in the device tree.
> Does "not configured" mean that it did not find the compatible string?
> We could add one of those, for now, perhaps.
"not configured" just means that no device driver attached to the
node. Usually that is because we don't have a device driver for the
device corresponding to the node yet. But in the case of the "binman"
node it doesn't really make sense for a device driver to attach. In
such a case we tend to filter out the node such that the "not
configured" line isn't printed. That can be done either by name or by
compatible string. So an "official" binding would help here and it
should either use a standardized name (that shouldn't be used for
other purposes then) or it should use defined a compatible string.
Anyway, this is not really critical. I just brought it up to
illustrate that such nodes are mostly harmless.
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 15:10 ` Mark Kettenis
@ 2021-10-27 16:02 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 16:02 UTC (permalink / raw)
To: Mark Kettenis
Cc: trini, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, ashok.reddy.soma,
atish.patra, bin.meng, bmeng.cn, christianshewitt,
david.abdurachmanov, dimitri.ledkov, festevam, green.wan, hs,
heinrich.schuchardt, xypron.glpk, ilias.apalodimas, jagan,
vanbaren, kever.yang, ycliang, linus.walleij, liviu.dudau,
marek.behun, mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
Hi Mark,
On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: François Ozog <francois.ozog@linaro.org>
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.ozog@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> sjg@chromium.org>
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> trini@konsulko.com>
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > sjg@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at
> [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put
> in
> > > this series
> > > > > > > > >> > > has various hardcoded <phandle> values which normally
> do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with
> people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this
> for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > Between
> > > > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger
> > > footing.
> > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > use.
> > > > > > > > >> For more context:
> > > > > > > > >>
> > > > > > > > >>
> > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >>
> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > adding the
> > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > > > >> maintainer would prefer there was no special support even
> for
> > > booting
> > > > > > > > >> Linux directly!)
> > > > > > > > >
> > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > >>
> > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > get its
> > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > U-Boot
> > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > >>
> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > option, not a
> > > > > > > > >> build-time one. It creates all sorts of problems and
> > > obscurity which
> > > > > > > > >> have taken months to unpick. See the above patch for the
> > > rationale.
> > > > > > > > >>
> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > available to
> > > > > > > > >> any board. At some point in the future it may become a
> common
> > > way
> > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > devicetree
> > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > whether or not
> > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image
> > > is put
> > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > like
> > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > obvious where
> > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly
> > > used
> > > > > > > > >> option, perhaps enabled by most/all boards, so that this
> sort
> > > of build
> > > > > > > > >> explosion is not needed.
> > > > > > > > >
> > > > > > > > > If you mean that when boards are by construction providing
> a
> > > DTB to U-Boot then I agree very much. But I don’t understand how the
> patch
> > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > >>
> > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > >> function correctly in whatever runtime environment in
> which
> > > it finds
> > > > > > > > >> itself.
> > > > > > > > >>
> > > > > > > > >> Also as binman is pressed into service more and more to
> build
> > > the
> > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > needs a
> > > > > > > > >> definition (in the devicetree) that describes how to
> create
> > > the image.
> > > > > > > > >> We can't support that unless we are building a devicetree,
> > > nor can the
> > > > > > > > >> running program access the image layout without that
> > > information.
> > > > > > > > >>
> > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > >> germane...but of course I am not suggesting doing that,
> since
> > > OF_BOARD
> > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > boards that
> > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3,
> for
> > > example
> > > > > > > > >> (as I said in the cover letter "Most boards do provide
> one,
> > > but some
> > > > > > > > >> don't."). So this series is just completing the picture by
> > > enforcing
> > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > >
> > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > > > >
> > > > > > > > I think the key point that will get you closer to where I am
> on
> > > this
> > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > present it
> > > > > > > > has build-time effects and this is quite wrong. If you go
> > > through all
> > > > > > > > the material I have written on this I think I have motivated
> > > that very
> > > > > > > > clearly.
> > > > > > > >
> > > > > > > > Another big issue is that I believe we need ONE devicetree
> for
> > > U-Boot,
> > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > that in a
> > > > > > > > lot of detail.
> > > > > > >
> > > > > > > I have a long long reply to your first reply here saved, but,
> maybe
> > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > U-Boot
> > > > > > > needs to support being passed a device tree to use, at run
> time,
> > > yes?
> > > > > >
> > > > > > Yes. The OF_BOARD feature provides this.
> > > > > >
> > > > > > >
> > > > > > > And in that case, would not be using the "fake" tree we built
> in?
> > > > > >
> > > > > > Not at runtime.
> > > > >
> > > > > OK.
> > > > >
> > > > > > > So is the sticking point here that we really have two classes
> of
> > > > > > > devices, one class where we will never ever be given the device
> > > tree at
> > > > > > > run time (think BeagleBone Black) and one where we will always
> be
> > > given
> > > > > > > one at run time (think Raspberry Pi) ?
> > > > > >
> > > > > > I'm not sure it will be that black and white. I suspect there
> will be
> > > > > > (many) boards which can boot happily with the U-Boot devicetree
> but
> > > > > > can also accept one at runtime, if provided. For example, you may
> > > want
> > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > >
> > > > > I'm not sure I see the value in making this a gray area. There's
> very
> > > > > much a class of "never" boards. There's also the class of "can"
> today.
> > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > have
> > > > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > > > until things are happy, but I'm not sure what the use case is for
> > > > > overriding the previous stage.
> > > > >
> > > > > Especially since the pushback on this series I think has all been
> "why
> > > > > are we copying in a tree to build with? We don't want to use it
> at run
> > > > > time!". And then softer push back like "Well, U-Boot says we have
> to
> > > > > include the device tree file here, but we won't use it...".
> > > >
> > > > See below.
> > > >
> > > > >
> > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > inadvertently)
> > > > > > provided a way to entirely omit a devicetree from U-Boot, thus
> making
> > > > > > things like binman and U-Boot /config impossible, for example.
> So I
> > > > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > > > U-Boot, as we have for rpi_3, etc.
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to
> the
> > > > different components. Binman was one effort there. I feel that
> putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > >
> > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > that know where to grab other known-good binaries of varying licenses
> > > that are needed to assemble something that boots.
> > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT.
> >
> > In my view U-Boot shall be able to leverage device tree format (source
> and
> > binary) to store its own data.
> > When you say "the" DT, I always think this is "the" DT that is passed to
> OS
> > and in "that" DT, there should be no U-Boot entries.
>
> Why not? As long as the device tree validates, it is perfectly fine
> to have additional nodes and properties present. The propertiesand
> nodes will be simply ignored by the OS.
>
> Because of the way we want to organize the firmware supply chain: when the
board is built, it is "attached" a device tree.
At that moment, we don't know what "non trusted firmware" will be used. It
could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes
it works with DT).
And we aim at keeping device tree as close to the original intent: hardware
description only. It's not because we can stuff anything in the DT and that
it is simple to do that we should.
Driver parameters shall be in the OS facility built for that purpose. Using
device tree has been an ugly habit.
> OpenBSD will print:
>
> "binman" not configured
>
> for the binman node that some of the U-Boot board targets now have,
> but it doesn't really make a difference. If there is a proper binding
> for that node, I could simply filter it out. Or we have U-Boot filter
> it out before the DT gets passed along like Tom suggests.
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 16:02 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 16:02 UTC (permalink / raw)
To: Mark Kettenis
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr,
festevam, rainer.boschung, trini, swarren,
oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek,
marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs,
pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel,
andre.przywara, tharvey, ashok.reddy.soma, rick, agraf,
green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot,
monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov,
priyanka.jain, sjg, ilias.apalodimas, christianshewitt,
awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei,
bmeng.cn, pali, dimitri.ledkov, padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 16248 bytes --]
Hi Mark,
On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> > From: François Ozog <francois.ozog@linaro.org>
> > Date: Wed, 27 Oct 2021 15:15:01 +0200
> >
> > Hi,
> >
> > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> >
> > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > Hi all,
> > > >
> > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > Hi François,
> > > > > > > >
> > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > francois.ozog@linaro.org> wrote:
> > > > > > > > >
> > > > > > > > > Hi Simon
> > > > > > > > >
> > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> sjg@chromium.org>
> > > a écrit :
> > > > > > > > >>
> > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > >>
> > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> trini@konsulko.com>
> > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> wrote:
> > > > > > > > >> > > Hi Simon,
> > > > > > > > >> > >
> > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > sjg@chromium.org> wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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 at
> [1].
> > > > > > > > >> > > >
> > > > > > > > >> > > > 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.
> > > > > > > > >> > >
> > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > hack to me.
> > > > > > > > >> > >
> > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> fly
> > > based on
> > > > > > > > >> > > command line parameters, and the device tree you put
> in
> > > this series
> > > > > > > > >> > > has various hardcoded <phandle> values which normally
> do
> > > not show up
> > > > > > > > >> > > in hand-written dts files.
> > > > > > > > >> > >
> > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > >> >
> > > > > > > > >> > I am also confused and do not like the idea of adding
> > > device trees for
> > > > > > > > >> > platforms that are capable of and can / do have a device
> > > tree to give us
> > > > > > > > >> > at run time.
> > > > > > > > >>
> > > > > > > > >> (I'll just reply to this one email, since the same points
> > > applies to
> > > > > > > > >> all replies I think)
> > > > > > > > >>
> > > > > > > > >> I have been thinking about this and discussing it with
> people
> > > for a
> > > > > > > > >> few months now. I've been signalling a change like this
> for
> > > over a
> > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > with Linaro
> > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > hope it is
> > > > > > > > >> not a surprise!
> > > > > > > > >>
> > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > U-Boot, to
> > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > OF_BOARD,
> > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > Between
> > > > > > > > >> Ilias' series and this one we can get ourselves on a
> stronger
> > > footing.
> > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > use.
> > > > > > > > >> For more context:
> > > > > > > > >>
> > > > > > > > >>
> > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > >>
> > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > adding the
> > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> fact the
> > > > > > > > >> maintainer would prefer there was no special support even
> for
> > > booting
> > > > > > > > >> Linux directly!)
> > > > > > > > >
> > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > >>
> > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > get its
> > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > U-Boot
> > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > >>
> > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > option, not a
> > > > > > > > >> build-time one. It creates all sorts of problems and
> > > obscurity which
> > > > > > > > >> have taken months to unpick. See the above patch for the
> > > rationale.
> > > > > > > > >>
> > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > available to
> > > > > > > > >> any board. At some point in the future it may become a
> common
> > > way
> > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > devicetree
> > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > whether or not
> > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> image
> > > is put
> > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > like
> > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > obvious where
> > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> commonly
> > > used
> > > > > > > > >> option, perhaps enabled by most/all boards, so that this
> sort
> > > of build
> > > > > > > > >> explosion is not needed.
> > > > > > > > >
> > > > > > > > > If you mean that when boards are by construction providing
> a
> > > DTB to U-Boot then I agree very much. But I don’t understand how the
> patch
> > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > >>
> > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > >> function correctly in whatever runtime environment in
> which
> > > it finds
> > > > > > > > >> itself.
> > > > > > > > >>
> > > > > > > > >> Also as binman is pressed into service more and more to
> build
> > > the
> > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > needs a
> > > > > > > > >> definition (in the devicetree) that describes how to
> create
> > > the image.
> > > > > > > > >> We can't support that unless we are building a devicetree,
> > > nor can the
> > > > > > > > >> running program access the image layout without that
> > > information.
> > > > > > > > >>
> > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > >> germane...but of course I am not suggesting doing that,
> since
> > > OF_BOARD
> > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > boards that
> > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3,
> for
> > > example
> > > > > > > > >> (as I said in the cover letter "Most boards do provide
> one,
> > > but some
> > > > > > > > >> don't."). So this series is just completing the picture by
> > > enforcing
> > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > >
> > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> default.
> > > > > > > >
> > > > > > > > I think the key point that will get you closer to where I am
> on
> > > this
> > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > present it
> > > > > > > > has build-time effects and this is quite wrong. If you go
> > > through all
> > > > > > > > the material I have written on this I think I have motivated
> > > that very
> > > > > > > > clearly.
> > > > > > > >
> > > > > > > > Another big issue is that I believe we need ONE devicetree
> for
> > > U-Boot,
> > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > that in a
> > > > > > > > lot of detail.
> > > > > > >
> > > > > > > I have a long long reply to your first reply here saved, but,
> maybe
> > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > U-Boot
> > > > > > > needs to support being passed a device tree to use, at run
> time,
> > > yes?
> > > > > >
> > > > > > Yes. The OF_BOARD feature provides this.
> > > > > >
> > > > > > >
> > > > > > > And in that case, would not be using the "fake" tree we built
> in?
> > > > > >
> > > > > > Not at runtime.
> > > > >
> > > > > OK.
> > > > >
> > > > > > > So is the sticking point here that we really have two classes
> of
> > > > > > > devices, one class where we will never ever be given the device
> > > tree at
> > > > > > > run time (think BeagleBone Black) and one where we will always
> be
> > > given
> > > > > > > one at run time (think Raspberry Pi) ?
> > > > > >
> > > > > > I'm not sure it will be that black and white. I suspect there
> will be
> > > > > > (many) boards which can boot happily with the U-Boot devicetree
> but
> > > > > > can also accept one at runtime, if provided. For example, you may
> > > want
> > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > >
> > > > > I'm not sure I see the value in making this a gray area. There's
> very
> > > > > much a class of "never" boards. There's also the class of "can"
> today.
> > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > have
> > > > > to re-flash the prior stage to change a DT, and just do it in
> U-Boot
> > > > > until things are happy, but I'm not sure what the use case is for
> > > > > overriding the previous stage.
> > > > >
> > > > > Especially since the pushback on this series I think has all been
> "why
> > > > > are we copying in a tree to build with? We don't want to use it
> at run
> > > > > time!". And then softer push back like "Well, U-Boot says we have
> to
> > > > > include the device tree file here, but we won't use it...".
> > > >
> > > > See below.
> > > >
> > > > >
> > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > inadvertently)
> > > > > > provided a way to entirely omit a devicetree from U-Boot, thus
> making
> > > > > > things like binman and U-Boot /config impossible, for example.
> So I
> > > > > > want to claw that back, so there is always some sort of
> devicetree in
> > > > > > U-Boot, as we have for rpi_3, etc.
> > > > >
> > > > > I really want to see what the binary case looks like since we could
> > > then
> > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> could
> > > > > then also do a rpi_arm32_defconfig too.
> > > > >
> > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > functionally correct from the hardware/our caller.
> > > > >
> > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> don't
> > > > > use the device tree from build time at run time, ignoring the
> device
> > > > > tree provided to us at run time by the caller.
> > > >
> > > > Firstly I should say that I find building firmware very messy and
> > > > confusing these days. Lots of things to build and it's hard to find
> > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > as we are, it will continue to be messy and in five years you will
> > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > objective here is to simplify things, bringing some consistency to
> the
> > > > different components. Binman was one effort there. I feel that
> putting
> > > > at least the U-Boot house in order, in my role as devicetree
> > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > 2011), is the next step.
> > >
> > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > that know where to grab other known-good binaries of varying licenses
> > > that are needed to assemble something that boots.
> > >
> > > > If we set things up correctly and agree on the bindings, devicetree
> > > > can be the unifying configuration mechanism through the whole of
> > > > firmware (except for very early bits) and into the OS, this will set
> > > > us up very well to deal with the complexity that is coming.
> > > >
> > > > Anyway, here are the mental steps that I've gone through over the
> past
> > > > two months:
> > > >
> > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > have its own nodes/properties in the DT.
> >
> > In my view U-Boot shall be able to leverage device tree format (source
> and
> > binary) to store its own data.
> > When you say "the" DT, I always think this is "the" DT that is passed to
> OS
> > and in "that" DT, there should be no U-Boot entries.
>
> Why not? As long as the device tree validates, it is perfectly fine
> to have additional nodes and properties present. The propertiesand
> nodes will be simply ignored by the OS.
>
> Because of the way we want to organize the firmware supply chain: when the
board is built, it is "attached" a device tree.
At that moment, we don't know what "non trusted firmware" will be used. It
could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes
it works with DT).
And we aim at keeping device tree as close to the original intent: hardware
description only. It's not because we can stuff anything in the DT and that
it is simple to do that we should.
Driver parameters shall be in the OS facility built for that purpose. Using
device tree has been an ugly habit.
> OpenBSD will print:
>
> "binman" not configured
>
> for the binman node that some of the U-Boot board targets now have,
> but it doesn't really make a difference. If there is a proper binding
> for that node, I could simply filter it out. Or we have U-Boot filter
> it out before the DT gets passed along like Tom suggests.
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 25049 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 16:02 ` François Ozog
@ 2021-10-27 19:06 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 19:06 UTC (permalink / raw)
To: François Ozog
Cc: Mark Kettenis, sjg, awilliams, albert.u.boot, agraf,
anastasiia_lukianenko, andre.przywara, ashok.reddy.soma,
atish.patra, bin.meng, bmeng.cn, christianshewitt,
david.abdurachmanov, dimitri.ledkov, festevam, green.wan, hs,
heinrich.schuchardt, xypron.glpk, ilias.apalodimas, jagan,
vanbaren, kever.yang, ycliang, linus.walleij, liviu.dudau,
marek.behun, mbrugger, michal.simek, monstr, narmstrong, lusus,
oleksandr_andrushchenko, padmarao.begari, pali, pbrobinson,
priyanka.jain, rainer.boschung, rfried.dev, rick, seanga2, sinan,
sr, swarren, swarren, t.karthik.reddy, kristo, fitzsim,
tianrui-wei, tharvey, tuomas.tynkkynen, u-boot,
valentin.longchamp, vladimir.oltean, wd, zong.li, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 17811 bytes --]
On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > sjg@chromium.org>
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > sjg@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at
> > [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> > fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put
> > in
> > > > this series
> > > > > > > > > >> > > has various hardcoded <phandle> values which normally
> > do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with
> > people
> > > > for a
> > > > > > > > > >> few months now. I've been signalling a change like this
> > for
> > > > over a
> > > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > > with Linaro
> > > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > > hope it is
> > > > > > > > > >> not a surprise!
> > > > > > > > > >>
> > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > U-Boot, to
> > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > > OF_BOARD,
> > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > > Between
> > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > stronger
> > > > footing.
> > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > > use.
> > > > > > > > > >> For more context:
> > > > > > > > > >>
> > > > > > > > > >>
> > > >
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >>
> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > > adding the
> > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > fact the
> > > > > > > > > >> maintainer would prefer there was no special support even
> > for
> > > > booting
> > > > > > > > > >> Linux directly!)
> > > > > > > > > >
> > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > >>
> > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > > get its
> > > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > > U-Boot
> > > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > > >>
> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > option, not a
> > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > obscurity which
> > > > > > > > > >> have taken months to unpick. See the above patch for the
> > > > rationale.
> > > > > > > > > >>
> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > > available to
> > > > > > > > > >> any board. At some point in the future it may become a
> > common
> > > > way
> > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > > devicetree
> > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > whether or not
> > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > image
> > > > is put
> > > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > > like
> > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > > obvious where
> > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > commonly
> > > > used
> > > > > > > > > >> option, perhaps enabled by most/all boards, so that this
> > sort
> > > > of build
> > > > > > > > > >> explosion is not needed.
> > > > > > > > > >
> > > > > > > > > > If you mean that when boards are by construction providing
> > a
> > > > DTB to U-Boot then I agree very much. But I don’t understand how the
> > patch
> > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > >>
> > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > >> function correctly in whatever runtime environment in
> > which
> > > > it finds
> > > > > > > > > >> itself.
> > > > > > > > > >>
> > > > > > > > > >> Also as binman is pressed into service more and more to
> > build
> > > > the
> > > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > > needs a
> > > > > > > > > >> definition (in the devicetree) that describes how to
> > create
> > > > the image.
> > > > > > > > > >> We can't support that unless we are building a devicetree,
> > > > nor can the
> > > > > > > > > >> running program access the image layout without that
> > > > information.
> > > > > > > > > >>
> > > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > > >> germane...but of course I am not suggesting doing that,
> > since
> > > > OF_BOARD
> > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > > boards that
> > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3,
> > for
> > > > example
> > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > one,
> > > > but some
> > > > > > > > > >> don't."). So this series is just completing the picture by
> > > > enforcing
> > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > >
> > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > default.
> > > > > > > > >
> > > > > > > > > I think the key point that will get you closer to where I am
> > on
> > > > this
> > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > present it
> > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > through all
> > > > > > > > > the material I have written on this I think I have motivated
> > > > that very
> > > > > > > > > clearly.
> > > > > > > > >
> > > > > > > > > Another big issue is that I believe we need ONE devicetree
> > for
> > > > U-Boot,
> > > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > > that in a
> > > > > > > > > lot of detail.
> > > > > > > >
> > > > > > > > I have a long long reply to your first reply here saved, but,
> > maybe
> > > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > > U-Boot
> > > > > > > > needs to support being passed a device tree to use, at run
> > time,
> > > > yes?
> > > > > > >
> > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > >
> > > > > > > >
> > > > > > > > And in that case, would not be using the "fake" tree we built
> > in?
> > > > > > >
> > > > > > > Not at runtime.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > > So is the sticking point here that we really have two classes
> > of
> > > > > > > > devices, one class where we will never ever be given the device
> > > > tree at
> > > > > > > > run time (think BeagleBone Black) and one where we will always
> > be
> > > > given
> > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > >
> > > > > > > I'm not sure it will be that black and white. I suspect there
> > will be
> > > > > > > (many) boards which can boot happily with the U-Boot devicetree
> > but
> > > > > > > can also accept one at runtime, if provided. For example, you may
> > > > want
> > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > >
> > > > > > I'm not sure I see the value in making this a gray area. There's
> > very
> > > > > > much a class of "never" boards. There's also the class of "can"
> > today.
> > > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > > have
> > > > > > to re-flash the prior stage to change a DT, and just do it in
> > U-Boot
> > > > > > until things are happy, but I'm not sure what the use case is for
> > > > > > overriding the previous stage.
> > > > > >
> > > > > > Especially since the pushback on this series I think has all been
> > "why
> > > > > > are we copying in a tree to build with? We don't want to use it
> > at run
> > > > > > time!". And then softer push back like "Well, U-Boot says we have
> > to
> > > > > > include the device tree file here, but we won't use it...".
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > inadvertently)
> > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus
> > making
> > > > > > > things like binman and U-Boot /config impossible, for example.
> > So I
> > > > > > > want to claw that back, so there is always some sort of
> > devicetree in
> > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > don't
> > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > >
> > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > > that know where to grab other known-good binaries of varying licenses
> > > > that are needed to assemble something that boots.
> > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT.
> > >
> > > In my view U-Boot shall be able to leverage device tree format (source
> > and
> > > binary) to store its own data.
> > > When you say "the" DT, I always think this is "the" DT that is passed to
> > OS
> > > and in "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
>
> Because of the way we want to organize the firmware supply chain: when the
> board is built, it is "attached" a device tree.
> At that moment, we don't know what "non trusted firmware" will be used. It
> could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes
> it works with DT).
> And we aim at keeping device tree as close to the original intent: hardware
> description only. It's not because we can stuff anything in the DT and that
> it is simple to do that we should.
> Driver parameters shall be in the OS facility built for that purpose. Using
> device tree has been an ugly habit.
So we're going to continue to re-litigate what does and doesn't live in
the device tree for forever, aren't we? To continue to be clear, I'm
not saying that non-upstream bindings should be present. But for
example, Simon is working on the "U-Boot config node" binding, which is
going to get re-spun next as /options/ as I read the thread right.
Populate it and anyone can read it, and probably be getting information
that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
I keep repeating that projects need to push bindings upstream. I'll
repeat my comment about
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
and the binman node both noting a common problem to solve.
In so far as there's objections to "U-Boot" nodes, it seems to me like
it comes down to "shouldn't need U-Boot internals expressed in DT nor
added to the DTB by someone else". And I've not objected to that
either. But I think we do have a subset of "how do we express ..."
issues that have come down to "well, we buried the bodies over at ...
before". And it's time to dig them up and give them a proper burial
perhaps now :)
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 19:06 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-27 19:06 UTC (permalink / raw)
To: François Ozog
Cc: liviu.dudau, narmstrong, vladimir.oltean, linus.walleij,
bin.meng, kever.yang, seanga2, atish.patra, zong.li, sr,
festevam, rainer.boschung, Mark Kettenis, swarren,
oleksandr_andrushchenko, xypron.glpk, lusus, michal.simek,
marek.behun, vanbaren, rfried.dev, jagan, valentin.longchamp, hs,
pbrobinson, sinan, fitzsim, wd, swarren, qemu-devel,
andre.przywara, tharvey, ashok.reddy.soma, rick, agraf,
green.wan, t.karthik.reddy, anastasiia_lukianenko, albert.u.boot,
monstr, mbrugger, ycliang, kristo, u-boot, david.abdurachmanov,
priyanka.jain, sjg, ilias.apalodimas, christianshewitt,
awilliams, tuomas.tynkkynen, heinrich.schuchardt, tianrui-wei,
bmeng.cn, pali, dimitri.ledkov, padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 17811 bytes --]
On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> Hi Mark,
>
> On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
>
> > > From: François Ozog <francois.ozog@linaro.org>
> > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > >
> > > Hi,
> > >
> > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > Hi all,
> > > > >
> > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com> wrote:
> > > > > >
> > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > Hi Tom,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > > > > > > Hi François,
> > > > > > > > >
> > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > >
> > > > > > > > > > Hi Simon
> > > > > > > > > >
> > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > sjg@chromium.org>
> > > > a écrit :
> > > > > > > > > >>
> > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > >>
> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >> >
> > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > wrote:
> > > > > > > > > >> > > Hi Simon,
> > > > > > > > > >> > >
> > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > sjg@chromium.org> wrote:
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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 at
> > [1].
> > > > > > > > > >> > > >
> > > > > > > > > >> > > > 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.
> > > > > > > > > >> > >
> > > > > > > > > >> > > Adding device trees that are never used sounds like a
> > > > hack to me.
> > > > > > > > > >> > >
> > > > > > > > > >> > > For QEMU, device tree is dynamically generated on the
> > fly
> > > > based on
> > > > > > > > > >> > > command line parameters, and the device tree you put
> > in
> > > > this series
> > > > > > > > > >> > > has various hardcoded <phandle> values which normally
> > do
> > > > not show up
> > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > >> > >
> > > > > > > > > >> > > I am not sure I understand the whole point of this.
> > > > > > > > > >> >
> > > > > > > > > >> > I am also confused and do not like the idea of adding
> > > > device trees for
> > > > > > > > > >> > platforms that are capable of and can / do have a device
> > > > tree to give us
> > > > > > > > > >> > at run time.
> > > > > > > > > >>
> > > > > > > > > >> (I'll just reply to this one email, since the same points
> > > > applies to
> > > > > > > > > >> all replies I think)
> > > > > > > > > >>
> > > > > > > > > >> I have been thinking about this and discussing it with
> > people
> > > > for a
> > > > > > > > > >> few months now. I've been signalling a change like this
> > for
> > > > over a
> > > > > > > > > >> month now, on U-Boot contributor calls and in discussions
> > > > with Linaro
> > > > > > > > > >> people. I sent a patch (below) to try to explain things. I
> > > > hope it is
> > > > > > > > > >> not a surprise!
> > > > > > > > > >>
> > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > U-Boot, to
> > > > > > > > > >> avoid the mess that has been created by OF_PRIOR_STAGE,
> > > > OF_BOARD,
> > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE.
> > > > Between
> > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > stronger
> > > > footing.
> > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF
> > > > use.
> > > > > > > > > >> For more context:
> > > > > > > > > >>
> > > > > > > > > >>
> > > >
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > >>
> > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way of
> > > > adding the
> > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > fact the
> > > > > > > > > >> maintainer would prefer there was no special support even
> > for
> > > > booting
> > > > > > > > > >> Linux directly!)
> > > > > > > > > >
> > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > >>
> > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > >> think the path forward might be to run QEMU twice, once to
> > > > get its
> > > > > > > > > >> generated tree and once to give the 'merged' tree with the
> > > > U-Boot
> > > > > > > > > >> properties in it, if people want to use U-Boot features.
> > > > > > > > > >>
> > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > option, not a
> > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > obscurity which
> > > > > > > > > >> have taken months to unpick. See the above patch for the
> > > > rationale.
> > > > > > > > > >>
> > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an option
> > > > available to
> > > > > > > > > >> any board. At some point in the future it may become a
> > common
> > > > way
> > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> > > > devicetree
> > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > whether or not
> > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > image
> > > > is put
> > > > > > > > > >> together. We'll end up with different U-Boot build targets
> > > > like
> > > > > > > > > >> capricorn, capricorn_of_board and the like. It should be
> > > > obvious where
> > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > commonly
> > > > used
> > > > > > > > > >> option, perhaps enabled by most/all boards, so that this
> > sort
> > > > of build
> > > > > > > > > >> explosion is not needed.
> > > > > > > > > >
> > > > > > > > > > If you mean that when boards are by construction providing
> > a
> > > > DTB to U-Boot then I agree very much. But I don’t understand how the
> > patch
> > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > >>
> > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > >> function correctly in whatever runtime environment in
> > which
> > > > it finds
> > > > > > > > > >> itself.
> > > > > > > > > >>
> > > > > > > > > >> Also as binman is pressed into service more and more to
> > build
> > > > the
> > > > > > > > > >> complex firmware images that are becoming fashionable, it
> > > > needs a
> > > > > > > > > >> definition (in the devicetree) that describes how to
> > create
> > > > the image.
> > > > > > > > > >> We can't support that unless we are building a devicetree,
> > > > nor can the
> > > > > > > > > >> running program access the image layout without that
> > > > information.
> > > > > > > > > >>
> > > > > > > > > >> François's point about 'don't use this with any kernel' is
> > > > > > > > > >> germane...but of course I am not suggesting doing that,
> > since
> > > > OF_BOARD
> > > > > > > > > >> is, still, enabled. We already use OF_BOARD for various
> > > > boards that
> > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3,
> > for
> > > > example
> > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > one,
> > > > but some
> > > > > > > > > >> don't."). So this series is just completing the picture by
> > > > enforcing
> > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > >
> > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > default.
> > > > > > > > >
> > > > > > > > > I think the key point that will get you closer to where I am
> > on
> > > > this
> > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > present it
> > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > through all
> > > > > > > > > the material I have written on this I think I have motivated
> > > > that very
> > > > > > > > > clearly.
> > > > > > > > >
> > > > > > > > > Another big issue is that I believe we need ONE devicetree
> > for
> > > > U-Boot,
> > > > > > > > > not two that get merged by U-Boot. Again I have gone through
> > > > that in a
> > > > > > > > > lot of detail.
> > > > > > > >
> > > > > > > > I have a long long reply to your first reply here saved, but,
> > maybe
> > > > > > > > here's the biggest sticking point. To be clear, you agree that
> > > > U-Boot
> > > > > > > > needs to support being passed a device tree to use, at run
> > time,
> > > > yes?
> > > > > > >
> > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > >
> > > > > > > >
> > > > > > > > And in that case, would not be using the "fake" tree we built
> > in?
> > > > > > >
> > > > > > > Not at runtime.
> > > > > >
> > > > > > OK.
> > > > > >
> > > > > > > > So is the sticking point here that we really have two classes
> > of
> > > > > > > > devices, one class where we will never ever be given the device
> > > > tree at
> > > > > > > > run time (think BeagleBone Black) and one where we will always
> > be
> > > > given
> > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > >
> > > > > > > I'm not sure it will be that black and white. I suspect there
> > will be
> > > > > > > (many) boards which can boot happily with the U-Boot devicetree
> > but
> > > > > > > can also accept one at runtime, if provided. For example, you may
> > > > want
> > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > >
> > > > > > I'm not sure I see the value in making this a gray area. There's
> > very
> > > > > > much a class of "never" boards. There's also the class of "can"
> > today.
> > > > > > Maybe as part of a developer iterative flow it would be nice to not
> > > > have
> > > > > > to re-flash the prior stage to change a DT, and just do it in
> > U-Boot
> > > > > > until things are happy, but I'm not sure what the use case is for
> > > > > > overriding the previous stage.
> > > > > >
> > > > > > Especially since the pushback on this series I think has all been
> > "why
> > > > > > are we copying in a tree to build with? We don't want to use it
> > at run
> > > > > > time!". And then softer push back like "Well, U-Boot says we have
> > to
> > > > > > include the device tree file here, but we won't use it...".
> > > > >
> > > > > See below.
> > > > >
> > > > > >
> > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > inadvertently)
> > > > > > > provided a way to entirely omit a devicetree from U-Boot, thus
> > making
> > > > > > > things like binman and U-Boot /config impossible, for example.
> > So I
> > > > > > > want to claw that back, so there is always some sort of
> > devicetree in
> > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > >
> > > > > > I really want to see what the binary case looks like since we could
> > > > then
> > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > could
> > > > > > then also do a rpi_arm32_defconfig too.
> > > > > >
> > > > > > I want to see less device trees in U-Boot sources, if they can come
> > > > > > functionally correct from the hardware/our caller.
> > > > > >
> > > > > > And I'm not seeing how we make use of "U-Boot /config" if we also
> > don't
> > > > > > use the device tree from build time at run time, ignoring the
> > device
> > > > > > tree provided to us at run time by the caller.
> > > > >
> > > > > Firstly I should say that I find building firmware very messy and
> > > > > confusing these days. Lots of things to build and it's hard to find
> > > > > the instructions. It doesn't have to be that way, but if we carry on
> > > > > as we are, it will continue to be messy and in five years you will
> > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > objective here is to simplify things, bringing some consistency to
> > the
> > > > > different components. Binman was one effort there. I feel that
> > putting
> > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > 2011), is the next step.
> > > >
> > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh scripts
> > > > that know where to grab other known-good binaries of varying licenses
> > > > that are needed to assemble something that boots.
> > > >
> > > > > If we set things up correctly and agree on the bindings, devicetree
> > > > > can be the unifying configuration mechanism through the whole of
> > > > > firmware (except for very early bits) and into the OS, this will set
> > > > > us up very well to deal with the complexity that is coming.
> > > > >
> > > > > Anyway, here are the mental steps that I've gone through over the
> > past
> > > > > two months:
> > > > >
> > > > > Step 1: At present, some people think U-Boot is not even allowed to
> > > > > have its own nodes/properties in the DT.
> > >
> > > In my view U-Boot shall be able to leverage device tree format (source
> > and
> > > binary) to store its own data.
> > > When you say "the" DT, I always think this is "the" DT that is passed to
> > OS
> > > and in "that" DT, there should be no U-Boot entries.
> >
> > Why not? As long as the device tree validates, it is perfectly fine
> > to have additional nodes and properties present. The propertiesand
> > nodes will be simply ignored by the OS.
>
> Because of the way we want to organize the firmware supply chain: when the
> board is built, it is "attached" a device tree.
> At that moment, we don't know what "non trusted firmware" will be used. It
> could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2 (yes
> it works with DT).
> And we aim at keeping device tree as close to the original intent: hardware
> description only. It's not because we can stuff anything in the DT and that
> it is simple to do that we should.
> Driver parameters shall be in the OS facility built for that purpose. Using
> device tree has been an ugly habit.
So we're going to continue to re-litigate what does and doesn't live in
the device tree for forever, aren't we? To continue to be clear, I'm
not saying that non-upstream bindings should be present. But for
example, Simon is working on the "U-Boot config node" binding, which is
going to get re-spun next as /options/ as I read the thread right.
Populate it and anyone can read it, and probably be getting information
that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
I keep repeating that projects need to push bindings upstream. I'll
repeat my comment about
https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
and the binman node both noting a common problem to solve.
In so far as there's objections to "U-Boot" nodes, it seems to me like
it comes down to "shouldn't need U-Boot internals expressed in DT nor
added to the DTB by someone else". And I've not objected to that
either. But I think we do have a subset of "how do we express ..."
issues that have come down to "well, we buried the bodies over at ...
before". And it's time to dig them up and give them a proper burial
perhaps now :)
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 19:06 ` Tom Rini
@ 2021-10-27 22:00 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 22:00 UTC (permalink / raw)
To: Tom Rini
Cc: Mark Kettenis, agraf, albert.u.boot, anastasiia_lukianenko,
andre.przywara, ashok.reddy.soma, atish.patra, awilliams,
bin.meng, bmeng.cn, christianshewitt, david.abdurachmanov,
dimitri.ledkov, festevam, fitzsim, green.wan,
heinrich.schuchardt, hs, ilias.apalodimas, jagan, kever.yang,
kristo, linus.walleij, liviu.dudau, lusus, marek.behun, mbrugger,
michal.simek, monstr, narmstrong, oleksandr_andrushchenko,
padmarao.begari, pali, pbrobinson, priyanka.jain, qemu-devel,
rainer.boschung, rfried.dev, rick, seanga2, sinan, sjg, sr,
swarren, swarren, t.karthik.reddy, tharvey, tianrui-wei,
tuomas.tynkkynen, u-boot, valentin.longchamp, vanbaren,
vladimir.oltean, wd, xypron.glpk, ycliang, zong.li
Hi Tom
Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> >
> > > > From: François Ozog <francois.ozog@linaro.org>
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > sjg@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > trini@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > sjg@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at
> > > [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the
> > > fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put
> > > in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded <phandle> values which
> normally
> > > do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > > > > > > > > >> I have been thinking about this and discussing it with
> > > people
> > > > > for a
> > > > > > > > > > >> few months now. I've been signalling a change like
> this
> > > for
> > > > > over a
> > > > > > > > > > >> month now, on U-Boot contributor calls and in
> discussions
> > > > > with Linaro
> > > > > > > > > > >> people. I sent a patch (below) to try to explain
> things. I
> > > > > hope it is
> > > > > > > > > > >> not a surprise!
> > > > > > > > > > >>
> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > U-Boot, to
> > > > > > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE,
> > > > > OF_BOARD,
> > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE.
> > > > > Between
> > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > > stronger
> > > > > footing.
> > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF
> > > > > use.
> > > > > > > > > > >> For more context:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > >
> > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >>
> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of
> > > > > adding the
> > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > > fact the
> > > > > > > > > > >> maintainer would prefer there was no special support
> even
> > > for
> > > > > booting
> > > > > > > > > > >> Linux directly!)
> > > > > > > > > > >
> > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > >>
> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > >> think the path forward might be to run QEMU twice,
> once to
> > > > > get its
> > > > > > > > > > >> generated tree and once to give the 'merged' tree
> with the
> > > > > U-Boot
> > > > > > > > > > >> properties in it, if people want to use U-Boot
> features.
> > > > > > > > > > >>
> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > option, not a
> > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > obscurity which
> > > > > > > > > > >> have taken months to unpick. See the above patch for
> the
> > > > > rationale.
> > > > > > > > > > >>
> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option
> > > > > available to
> > > > > > > > > > >> any board. At some point in the future it may become a
> > > common
> > > > > way
> > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a
> > > > > devicetree
> > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > whether or not
> > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > > image
> > > > > is put
> > > > > > > > > > >> together. We'll end up with different U-Boot build
> targets
> > > > > like
> > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> be
> > > > > obvious where
> > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > > commonly
> > > > > used
> > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> this
> > > sort
> > > > > of build
> > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > >
> > > > > > > > > > > If you mean that when boards are by construction
> providing
> > > a
> > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> the
> > > patch
> > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > >>
> > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > >> function correctly in whatever runtime environment in
> > > which
> > > > > it finds
> > > > > > > > > > >> itself.
> > > > > > > > > > >>
> > > > > > > > > > >> Also as binman is pressed into service more and more
> to
> > > build
> > > > > the
> > > > > > > > > > >> complex firmware images that are becoming
> fashionable, it
> > > > > needs a
> > > > > > > > > > >> definition (in the devicetree) that describes how to
> > > create
> > > > > the image.
> > > > > > > > > > >> We can't support that unless we are building a
> devicetree,
> > > > > nor can the
> > > > > > > > > > >> running program access the image layout without that
> > > > > information.
> > > > > > > > > > >>
> > > > > > > > > > >> François's point about 'don't use this with any
> kernel' is
> > > > > > > > > > >> germane...but of course I am not suggesting doing
> that,
> > > since
> > > > > OF_BOARD
> > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> various
> > > > > boards that
> > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3,
> > > for
> > > > > example
> > > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > > one,
> > > > > but some
> > > > > > > > > > >> don't."). So this series is just completing the
> picture by
> > > > > enforcing
> > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > >
> > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > > default.
> > > > > > > > > >
> > > > > > > > > > I think the key point that will get you closer to where
> I am
> > > on
> > > > > this
> > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > present it
> > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > through all
> > > > > > > > > > the material I have written on this I think I have
> motivated
> > > > > that very
> > > > > > > > > > clearly.
> > > > > > > > > >
> > > > > > > > > > Another big issue is that I believe we need ONE
> devicetree
> > > for
> > > > > U-Boot,
> > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> through
> > > > > that in a
> > > > > > > > > > lot of detail.
> > > > > > > > >
> > > > > > > > > I have a long long reply to your first reply here saved,
> but,
> > > maybe
> > > > > > > > > here's the biggest sticking point. To be clear, you agree
> that
> > > > > U-Boot
> > > > > > > > > needs to support being passed a device tree to use, at run
> > > time,
> > > > > yes?
> > > > > > > >
> > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > And in that case, would not be using the "fake" tree we
> built
> > > in?
> > > > > > > >
> > > > > > > > Not at runtime.
> > > > > > >
> > > > > > > OK.
> > > > > > >
> > > > > > > > > So is the sticking point here that we really have two
> classes
> > > of
> > > > > > > > > devices, one class where we will never ever be given the
> device
> > > > > tree at
> > > > > > > > > run time (think BeagleBone Black) and one where we will
> always
> > > be
> > > > > given
> > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > >
> > > > > > > > I'm not sure it will be that black and white. I suspect there
> > > will be
> > > > > > > > (many) boards which can boot happily with the U-Boot
> devicetree
> > > but
> > > > > > > > can also accept one at runtime, if provided. For example,
> you may
> > > > > want
> > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > >
> > > > > > > I'm not sure I see the value in making this a gray area.
> There's
> > > very
> > > > > > > much a class of "never" boards. There's also the class of
> "can"
> > > today.
> > > > > > > Maybe as part of a developer iterative flow it would be nice
> to not
> > > > > have
> > > > > > > to re-flash the prior stage to change a DT, and just do it in
> > > U-Boot
> > > > > > > until things are happy, but I'm not sure what the use case is
> for
> > > > > > > overriding the previous stage.
> > > > > > >
> > > > > > > Especially since the pushback on this series I think has all
> been
> > > "why
> > > > > > > are we copying in a tree to build with? We don't want to use
> it
> > > at run
> > > > > > > time!". And then softer push back like "Well, U-Boot says we
> have
> > > to
> > > > > > > include the device tree file here, but we won't use it...".
> > > > > >
> > > > > > See below.
> > > > > >
> > > > > > >
> > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > inadvertently)
> > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> thus
> > > making
> > > > > > > > things like binman and U-Boot /config impossible, for
> example.
> > > So I
> > > > > > > > want to claw that back, so there is always some sort of
> > > devicetree in
> > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> could
> > > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also
> > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to
> find
> > > > > > the instructions. It doesn't have to be that way, but if we
> carry on
> > > > > > as we are, it will continue to be messy and in five years you
> will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency
> to
> > > the
> > > > > > different components. Binman was one effort there. I feel that
> > > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > >
> > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> scripts
> > > > > that know where to grab other known-good binaries of varying
> licenses
> > > > > that are needed to assemble something that boots.
> > > > >
> > > > > > If we set things up correctly and agree on the bindings,
> devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed
> to
> > > > > > have its own nodes/properties in the DT.
> > > >
> > > > In my view U-Boot shall be able to leverage device tree format
> (source
> > > and
> > > > binary) to store its own data.
> > > > When you say "the" DT, I always think this is "the" DT that is
> passed to
> > > OS
> > > > and in "that" DT, there should be no U-Boot entries.
> > >
> > > Why not? As long as the device tree validates, it is perfectly fine
> > > to have additional nodes and properties present. The propertiesand
> > > nodes will be simply ignored by the OS.
> >
> > Because of the way we want to organize the firmware supply chain: when
> the
> > board is built, it is "attached" a device tree.
> > At that moment, we don't know what "non trusted firmware" will be used.
> It
> > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2
> (yes
> > it works with DT).
> > And we aim at keeping device tree as close to the original intent:
> hardware
> > description only. It's not because we can stuff anything in the DT and
> that
> > it is simple to do that we should.
> > Driver parameters shall be in the OS facility built for that purpose.
> Using
> > device tree has been an ugly habit.
>
> So we're going to continue to re-litigate what does and doesn't live in
> the device tree for forever, aren't we? To continue to be clear, I'm
> not saying that non-upstream bindings should be present. But for
> example, Simon is working on the "U-Boot config node" binding, which is
> going to get re-spun next as /options/ as I read the thread right.
> Populate it and anyone can read it, and probably be getting information
> that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
> I keep repeating that projects need to push bindings upstream. I'll
> repeat my comment about
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> and the binman node both noting a common problem to solve.
i think you are right. Now tfa is comfortable being its own upstream for
the binding specifications. Could U-Boot community be comfortable doing so?
Now I also recognize that DT specification state is far from clean. If you
want full story on PCI ECAM you need Linux/documentation and IEEE text
(kind of hosted on DT.org but not easily browasable to). In the long run it
may be much better to have all bindings (including U-Boot ones) in DT.org.
We should also have information from Qemu about the DT it generates for all
its devices and how it is associated to command line .
>
>
> In so far as there's objections to "U-Boot" nodes, it seems to me like
> it comes down to "shouldn't need U-Boot internals expressed in DT nor
> added to the DTB by someone else". And I've not objected to that
> either. But I think we do have a subset of "how do we express ..."
> issues that have come down to "well, we buried the bodies over at ...
> before". And it's time to dig them up and give them a proper burial
> perhaps now :)
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-27 22:00 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-27 22:00 UTC (permalink / raw)
To: Tom Rini
Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij,
fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam,
rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko,
xypron.glpk, lusus, michal.simek, marek.behun, vanbaren,
rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan,
bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma,
qemu-devel, agraf, green.wan, t.karthik.reddy,
anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang,
kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg,
ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen,
heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov,
padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 19713 bytes --]
Hi Tom
Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit :
> On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > Hi Mark,
> >
> > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl>
> wrote:
> >
> > > > From: François Ozog <francois.ozog@linaro.org>
> > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > >
> > > > Hi,
> > > >
> > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > >
> > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> wrote:
> > > > > > >
> > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > > wrote:
> > > > > > > > >
> > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> wrote:
> > > > > > > > > > Hi François,
> > > > > > > > > >
> > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Simon
> > > > > > > > > > >
> > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > sjg@chromium.org>
> > > > > a écrit :
> > > > > > > > > > >>
> > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > >>
> > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > trini@konsulko.com>
> > > > > wrote:
> > > > > > > > > > >> >
> > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > wrote:
> > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > sjg@chromium.org> wrote:
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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
> at
> > > [1].
> > > > > > > > > > >> > > >
> > > > > > > > > > >> > > > 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.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > Adding device trees that are never used sounds
> like a
> > > > > hack to me.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> the
> > > fly
> > > > > based on
> > > > > > > > > > >> > > command line parameters, and the device tree you
> put
> > > in
> > > > > this series
> > > > > > > > > > >> > > has various hardcoded <phandle> values which
> normally
> > > do
> > > > > not show up
> > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > >> > >
> > > > > > > > > > >> > > I am not sure I understand the whole point of
> this.
> > > > > > > > > > >> >
> > > > > > > > > > >> > I am also confused and do not like the idea of
> adding
> > > > > device trees for
> > > > > > > > > > >> > platforms that are capable of and can / do have a
> device
> > > > > tree to give us
> > > > > > > > > > >> > at run time.
> > > > > > > > > > >>
> > > > > > > > > > >> (I'll just reply to this one email, since the same
> points
> > > > > applies to
> > > > > > > > > > >> all replies I think)
> > > > > > > > > > >>
> > > > > > > > > > >> I have been thinking about this and discussing it with
> > > people
> > > > > for a
> > > > > > > > > > >> few months now. I've been signalling a change like
> this
> > > for
> > > > > over a
> > > > > > > > > > >> month now, on U-Boot contributor calls and in
> discussions
> > > > > with Linaro
> > > > > > > > > > >> people. I sent a patch (below) to try to explain
> things. I
> > > > > hope it is
> > > > > > > > > > >> not a surprise!
> > > > > > > > > > >>
> > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > U-Boot, to
> > > > > > > > > > >> avoid the mess that has been created by
> OF_PRIOR_STAGE,
> > > > > OF_BOARD,
> > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> OF_HOSTFILE.
> > > > > Between
> > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > > stronger
> > > > > footing.
> > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> debugging/ELF
> > > > > use.
> > > > > > > > > > >> For more context:
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > >
> > >
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > >>
> > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> of
> > > > > adding the
> > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > > fact the
> > > > > > > > > > >> maintainer would prefer there was no special support
> even
> > > for
> > > > > booting
> > > > > > > > > > >> Linux directly!)
> > > > > > > > > > >
> > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > >>
> > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > >> think the path forward might be to run QEMU twice,
> once to
> > > > > get its
> > > > > > > > > > >> generated tree and once to give the 'merged' tree
> with the
> > > > > U-Boot
> > > > > > > > > > >> properties in it, if people want to use U-Boot
> features.
> > > > > > > > > > >>
> > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > option, not a
> > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > obscurity which
> > > > > > > > > > >> have taken months to unpick. See the above patch for
> the
> > > > > rationale.
> > > > > > > > > > >>
> > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> option
> > > > > available to
> > > > > > > > > > >> any board. At some point in the future it may become a
> > > common
> > > > > way
> > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> providing a
> > > > > devicetree
> > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > whether or not
> > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > > image
> > > > > is put
> > > > > > > > > > >> together. We'll end up with different U-Boot build
> targets
> > > > > like
> > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> be
> > > > > obvious where
> > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > > commonly
> > > > > used
> > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> this
> > > sort
> > > > > of build
> > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > >
> > > > > > > > > > > If you mean that when boards are by construction
> providing
> > > a
> > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> the
> > > patch
> > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > >>
> > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > >> function correctly in whatever runtime environment in
> > > which
> > > > > it finds
> > > > > > > > > > >> itself.
> > > > > > > > > > >>
> > > > > > > > > > >> Also as binman is pressed into service more and more
> to
> > > build
> > > > > the
> > > > > > > > > > >> complex firmware images that are becoming
> fashionable, it
> > > > > needs a
> > > > > > > > > > >> definition (in the devicetree) that describes how to
> > > create
> > > > > the image.
> > > > > > > > > > >> We can't support that unless we are building a
> devicetree,
> > > > > nor can the
> > > > > > > > > > >> running program access the image layout without that
> > > > > information.
> > > > > > > > > > >>
> > > > > > > > > > >> François's point about 'don't use this with any
> kernel' is
> > > > > > > > > > >> germane...but of course I am not suggesting doing
> that,
> > > since
> > > > > OF_BOARD
> > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> various
> > > > > boards that
> > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> 3,
> > > for
> > > > > example
> > > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > > one,
> > > > > but some
> > > > > > > > > > >> don't."). So this series is just completing the
> picture by
> > > > > enforcing
> > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > >
> > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > > default.
> > > > > > > > > >
> > > > > > > > > > I think the key point that will get you closer to where
> I am
> > > on
> > > > > this
> > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > present it
> > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > through all
> > > > > > > > > > the material I have written on this I think I have
> motivated
> > > > > that very
> > > > > > > > > > clearly.
> > > > > > > > > >
> > > > > > > > > > Another big issue is that I believe we need ONE
> devicetree
> > > for
> > > > > U-Boot,
> > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> through
> > > > > that in a
> > > > > > > > > > lot of detail.
> > > > > > > > >
> > > > > > > > > I have a long long reply to your first reply here saved,
> but,
> > > maybe
> > > > > > > > > here's the biggest sticking point. To be clear, you agree
> that
> > > > > U-Boot
> > > > > > > > > needs to support being passed a device tree to use, at run
> > > time,
> > > > > yes?
> > > > > > > >
> > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > >
> > > > > > > > >
> > > > > > > > > And in that case, would not be using the "fake" tree we
> built
> > > in?
> > > > > > > >
> > > > > > > > Not at runtime.
> > > > > > >
> > > > > > > OK.
> > > > > > >
> > > > > > > > > So is the sticking point here that we really have two
> classes
> > > of
> > > > > > > > > devices, one class where we will never ever be given the
> device
> > > > > tree at
> > > > > > > > > run time (think BeagleBone Black) and one where we will
> always
> > > be
> > > > > given
> > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > >
> > > > > > > > I'm not sure it will be that black and white. I suspect there
> > > will be
> > > > > > > > (many) boards which can boot happily with the U-Boot
> devicetree
> > > but
> > > > > > > > can also accept one at runtime, if provided. For example,
> you may
> > > > > want
> > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > >
> > > > > > > I'm not sure I see the value in making this a gray area.
> There's
> > > very
> > > > > > > much a class of "never" boards. There's also the class of
> "can"
> > > today.
> > > > > > > Maybe as part of a developer iterative flow it would be nice
> to not
> > > > > have
> > > > > > > to re-flash the prior stage to change a DT, and just do it in
> > > U-Boot
> > > > > > > until things are happy, but I'm not sure what the use case is
> for
> > > > > > > overriding the previous stage.
> > > > > > >
> > > > > > > Especially since the pushback on this series I think has all
> been
> > > "why
> > > > > > > are we copying in a tree to build with? We don't want to use
> it
> > > at run
> > > > > > > time!". And then softer push back like "Well, U-Boot says we
> have
> > > to
> > > > > > > include the device tree file here, but we won't use it...".
> > > > > >
> > > > > > See below.
> > > > > >
> > > > > > >
> > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > inadvertently)
> > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> thus
> > > making
> > > > > > > > things like binman and U-Boot /config impossible, for
> example.
> > > So I
> > > > > > > > want to claw that back, so there is always some sort of
> > > devicetree in
> > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > >
> > > > > > > I really want to see what the binary case looks like since we
> could
> > > > > then
> > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > > could
> > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > >
> > > > > > > I want to see less device trees in U-Boot sources, if they can
> come
> > > > > > > functionally correct from the hardware/our caller.
> > > > > > >
> > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> also
> > > don't
> > > > > > > use the device tree from build time at run time, ignoring the
> > > device
> > > > > > > tree provided to us at run time by the caller.
> > > > > >
> > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > confusing these days. Lots of things to build and it's hard to
> find
> > > > > > the instructions. It doesn't have to be that way, but if we
> carry on
> > > > > > as we are, it will continue to be messy and in five years you
> will
> > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > objective here is to simplify things, bringing some consistency
> to
> > > the
> > > > > > different components. Binman was one effort there. I feel that
> > > putting
> > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > 2011), is the next step.
> > > > >
> > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> scripts
> > > > > that know where to grab other known-good binaries of varying
> licenses
> > > > > that are needed to assemble something that boots.
> > > > >
> > > > > > If we set things up correctly and agree on the bindings,
> devicetree
> > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > firmware (except for very early bits) and into the OS, this will
> set
> > > > > > us up very well to deal with the complexity that is coming.
> > > > > >
> > > > > > Anyway, here are the mental steps that I've gone through over the
> > > past
> > > > > > two months:
> > > > > >
> > > > > > Step 1: At present, some people think U-Boot is not even allowed
> to
> > > > > > have its own nodes/properties in the DT.
> > > >
> > > > In my view U-Boot shall be able to leverage device tree format
> (source
> > > and
> > > > binary) to store its own data.
> > > > When you say "the" DT, I always think this is "the" DT that is
> passed to
> > > OS
> > > > and in "that" DT, there should be no U-Boot entries.
> > >
> > > Why not? As long as the device tree validates, it is perfectly fine
> > > to have additional nodes and properties present. The propertiesand
> > > nodes will be simply ignored by the OS.
> >
> > Because of the way we want to organize the firmware supply chain: when
> the
> > board is built, it is "attached" a device tree.
> > At that moment, we don't know what "non trusted firmware" will be used.
> It
> > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2
> (yes
> > it works with DT).
> > And we aim at keeping device tree as close to the original intent:
> hardware
> > description only. It's not because we can stuff anything in the DT and
> that
> > it is simple to do that we should.
> > Driver parameters shall be in the OS facility built for that purpose.
> Using
> > device tree has been an ugly habit.
>
> So we're going to continue to re-litigate what does and doesn't live in
> the device tree for forever, aren't we? To continue to be clear, I'm
> not saying that non-upstream bindings should be present. But for
> example, Simon is working on the "U-Boot config node" binding, which is
> going to get re-spun next as /options/ as I read the thread right.
> Populate it and anyone can read it, and probably be getting information
> that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
> I keep repeating that projects need to push bindings upstream. I'll
> repeat my comment about
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> and the binman node both noting a common problem to solve.
i think you are right. Now tfa is comfortable being its own upstream for
the binding specifications. Could U-Boot community be comfortable doing so?
Now I also recognize that DT specification state is far from clean. If you
want full story on PCI ECAM you need Linux/documentation and IEEE text
(kind of hosted on DT.org but not easily browasable to). In the long run it
may be much better to have all bindings (including U-Boot ones) in DT.org.
We should also have information from Qemu about the DT it generates for all
its devices and how it is associated to command line .
>
>
> In so far as there's objections to "U-Boot" nodes, it seems to me like
> it comes down to "shouldn't need U-Boot internals expressed in DT nor
> added to the DTB by someone else". And I've not objected to that
> either. But I think we do have a subset of "how do we express ..."
> issues that have come down to "well, we buried the bodies over at ...
> before". And it's time to dig them up and give them a proper burial
> perhaps now :)
>
> --
> Tom
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 31166 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-27 22:00 ` François Ozog
@ 2021-10-28 14:41 ` Tom Rini
-1 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-28 14:41 UTC (permalink / raw)
To: François Ozog
Cc: Mark Kettenis, agraf, albert.u.boot, anastasiia_lukianenko,
andre.przywara, ashok.reddy.soma, atish.patra, awilliams,
bin.meng, bmeng.cn, christianshewitt, david.abdurachmanov,
dimitri.ledkov, festevam, fitzsim, green.wan,
heinrich.schuchardt, hs, ilias.apalodimas, jagan, kever.yang,
kristo, linus.walleij, liviu.dudau, lusus, marek.behun, mbrugger,
michal.simek, monstr, narmstrong, oleksandr_andrushchenko,
padmarao.begari, pali, pbrobinson, priyanka.jain, qemu-devel,
rainer.boschung, rfried.dev, rick, seanga2, sinan, sjg, sr,
swarren, swarren, t.karthik.reddy, tharvey, tianrui-wei,
tuomas.tynkkynen, u-boot, valentin.longchamp, vanbaren,
vladimir.oltean, wd, xypron.glpk, ycliang, zong.li
[-- Attachment #1: Type: text/plain, Size: 19928 bytes --]
On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote:
> Hi Tom
>
> Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit :
>
> > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > > Hi Mark,
> > >
> > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl>
> > wrote:
> > >
> > > > > From: François Ozog <francois.ozog@linaro.org>
> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> > wrote:
> > > > > > > > > > > Hi François,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon
> > > > > > > > > > > >
> > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > > sjg@chromium.org>
> > > > > > a écrit :
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > > trini@konsulko.com>
> > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > > wrote:
> > > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > > sjg@chromium.org> wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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
> > at
> > > > [1].
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Adding device trees that are never used sounds
> > like a
> > > > > > hack to me.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> > the
> > > > fly
> > > > > > based on
> > > > > > > > > > > >> > > command line parameters, and the device tree you
> > put
> > > > in
> > > > > > this series
> > > > > > > > > > > >> > > has various hardcoded <phandle> values which
> > normally
> > > > do
> > > > > > not show up
> > > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I am not sure I understand the whole point of
> > this.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > I am also confused and do not like the idea of
> > adding
> > > > > > device trees for
> > > > > > > > > > > >> > platforms that are capable of and can / do have a
> > device
> > > > > > tree to give us
> > > > > > > > > > > >> > at run time.
> > > > > > > > > > > >>
> > > > > > > > > > > >> (I'll just reply to this one email, since the same
> > points
> > > > > > applies to
> > > > > > > > > > > >> all replies I think)
> > > > > > > > > > > >>
> > > > > > > > > > > >> I have been thinking about this and discussing it with
> > > > people
> > > > > > for a
> > > > > > > > > > > >> few months now. I've been signalling a change like
> > this
> > > > for
> > > > > > over a
> > > > > > > > > > > >> month now, on U-Boot contributor calls and in
> > discussions
> > > > > > with Linaro
> > > > > > > > > > > >> people. I sent a patch (below) to try to explain
> > things. I
> > > > > > hope it is
> > > > > > > > > > > >> not a surprise!
> > > > > > > > > > > >>
> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > > U-Boot, to
> > > > > > > > > > > >> avoid the mess that has been created by
> > OF_PRIOR_STAGE,
> > > > > > OF_BOARD,
> > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> > OF_HOSTFILE.
> > > > > > Between
> > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > > > stronger
> > > > > > footing.
> > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> > debugging/ELF
> > > > > > use.
> > > > > > > > > > > >> For more context:
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > >
> > > >
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > > >>
> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> > of
> > > > > > adding the
> > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > > > fact the
> > > > > > > > > > > >> maintainer would prefer there was no special support
> > even
> > > > for
> > > > > > booting
> > > > > > > > > > > >> Linux directly!)
> > > > > > > > > > > >
> > > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > > >>
> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > > >> think the path forward might be to run QEMU twice,
> > once to
> > > > > > get its
> > > > > > > > > > > >> generated tree and once to give the 'merged' tree
> > with the
> > > > > > U-Boot
> > > > > > > > > > > >> properties in it, if people want to use U-Boot
> > features.
> > > > > > > > > > > >>
> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > > option, not a
> > > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > > obscurity which
> > > > > > > > > > > >> have taken months to unpick. See the above patch for
> > the
> > > > > > rationale.
> > > > > > > > > > > >>
> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> > option
> > > > > > available to
> > > > > > > > > > > >> any board. At some point in the future it may become a
> > > > common
> > > > > > way
> > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> > providing a
> > > > > > devicetree
> > > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > > whether or not
> > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > > > image
> > > > > > is put
> > > > > > > > > > > >> together. We'll end up with different U-Boot build
> > targets
> > > > > > like
> > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> > be
> > > > > > obvious where
> > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > > > commonly
> > > > > > used
> > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> > this
> > > > sort
> > > > > > of build
> > > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > > >
> > > > > > > > > > > > If you mean that when boards are by construction
> > providing
> > > > a
> > > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> > the
> > > > patch
> > > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > > >>
> > > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > > >> function correctly in whatever runtime environment in
> > > > which
> > > > > > it finds
> > > > > > > > > > > >> itself.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Also as binman is pressed into service more and more
> > to
> > > > build
> > > > > > the
> > > > > > > > > > > >> complex firmware images that are becoming
> > fashionable, it
> > > > > > needs a
> > > > > > > > > > > >> definition (in the devicetree) that describes how to
> > > > create
> > > > > > the image.
> > > > > > > > > > > >> We can't support that unless we are building a
> > devicetree,
> > > > > > nor can the
> > > > > > > > > > > >> running program access the image layout without that
> > > > > > information.
> > > > > > > > > > > >>
> > > > > > > > > > > >> François's point about 'don't use this with any
> > kernel' is
> > > > > > > > > > > >> germane...but of course I am not suggesting doing
> > that,
> > > > since
> > > > > > OF_BOARD
> > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> > various
> > > > > > boards that
> > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> > 3,
> > > > for
> > > > > > example
> > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > > > one,
> > > > > > but some
> > > > > > > > > > > >> don't."). So this series is just completing the
> > picture by
> > > > > > enforcing
> > > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > > >
> > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > > > default.
> > > > > > > > > > >
> > > > > > > > > > > I think the key point that will get you closer to where
> > I am
> > > > on
> > > > > > this
> > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > > present it
> > > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > > through all
> > > > > > > > > > > the material I have written on this I think I have
> > motivated
> > > > > > that very
> > > > > > > > > > > clearly.
> > > > > > > > > > >
> > > > > > > > > > > Another big issue is that I believe we need ONE
> > devicetree
> > > > for
> > > > > > U-Boot,
> > > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> > through
> > > > > > that in a
> > > > > > > > > > > lot of detail.
> > > > > > > > > >
> > > > > > > > > > I have a long long reply to your first reply here saved,
> > but,
> > > > maybe
> > > > > > > > > > here's the biggest sticking point. To be clear, you agree
> > that
> > > > > > U-Boot
> > > > > > > > > > needs to support being passed a device tree to use, at run
> > > > time,
> > > > > > yes?
> > > > > > > > >
> > > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > And in that case, would not be using the "fake" tree we
> > built
> > > > in?
> > > > > > > > >
> > > > > > > > > Not at runtime.
> > > > > > > >
> > > > > > > > OK.
> > > > > > > >
> > > > > > > > > > So is the sticking point here that we really have two
> > classes
> > > > of
> > > > > > > > > > devices, one class where we will never ever be given the
> > device
> > > > > > tree at
> > > > > > > > > > run time (think BeagleBone Black) and one where we will
> > always
> > > > be
> > > > > > given
> > > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > > >
> > > > > > > > > I'm not sure it will be that black and white. I suspect there
> > > > will be
> > > > > > > > > (many) boards which can boot happily with the U-Boot
> > devicetree
> > > > but
> > > > > > > > > can also accept one at runtime, if provided. For example,
> > you may
> > > > > > want
> > > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > > >
> > > > > > > > I'm not sure I see the value in making this a gray area.
> > There's
> > > > very
> > > > > > > > much a class of "never" boards. There's also the class of
> > "can"
> > > > today.
> > > > > > > > Maybe as part of a developer iterative flow it would be nice
> > to not
> > > > > > have
> > > > > > > > to re-flash the prior stage to change a DT, and just do it in
> > > > U-Boot
> > > > > > > > until things are happy, but I'm not sure what the use case is
> > for
> > > > > > > > overriding the previous stage.
> > > > > > > >
> > > > > > > > Especially since the pushback on this series I think has all
> > been
> > > > "why
> > > > > > > > are we copying in a tree to build with? We don't want to use
> > it
> > > > at run
> > > > > > > > time!". And then softer push back like "Well, U-Boot says we
> > have
> > > > to
> > > > > > > > include the device tree file here, but we won't use it...".
> > > > > > >
> > > > > > > See below.
> > > > > > >
> > > > > > > >
> > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > > inadvertently)
> > > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> > thus
> > > > making
> > > > > > > > > things like binman and U-Boot /config impossible, for
> > example.
> > > > So I
> > > > > > > > > want to claw that back, so there is always some sort of
> > > > devicetree in
> > > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > > >
> > > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > > > then
> > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > > > could
> > > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > > >
> > > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > > functionally correct from the hardware/our caller.
> > > > > > > >
> > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> > also
> > > > don't
> > > > > > > > use the device tree from build time at run time, ignoring the
> > > > device
> > > > > > > > tree provided to us at run time by the caller.
> > > > > > >
> > > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > > confusing these days. Lots of things to build and it's hard to
> > find
> > > > > > > the instructions. It doesn't have to be that way, but if we
> > carry on
> > > > > > > as we are, it will continue to be messy and in five years you
> > will
> > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > > objective here is to simplify things, bringing some consistency
> > to
> > > > the
> > > > > > > different components. Binman was one effort there. I feel that
> > > > putting
> > > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > > 2011), is the next step.
> > > > > >
> > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> > scripts
> > > > > > that know where to grab other known-good binaries of varying
> > licenses
> > > > > > that are needed to assemble something that boots.
> > > > > >
> > > > > > > If we set things up correctly and agree on the bindings,
> > devicetree
> > > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > > us up very well to deal with the complexity that is coming.
> > > > > > >
> > > > > > > Anyway, here are the mental steps that I've gone through over the
> > > > past
> > > > > > > two months:
> > > > > > >
> > > > > > > Step 1: At present, some people think U-Boot is not even allowed
> > to
> > > > > > > have its own nodes/properties in the DT.
> > > > >
> > > > > In my view U-Boot shall be able to leverage device tree format
> > (source
> > > > and
> > > > > binary) to store its own data.
> > > > > When you say "the" DT, I always think this is "the" DT that is
> > passed to
> > > > OS
> > > > > and in "that" DT, there should be no U-Boot entries.
> > > >
> > > > Why not? As long as the device tree validates, it is perfectly fine
> > > > to have additional nodes and properties present. The propertiesand
> > > > nodes will be simply ignored by the OS.
> > >
> > > Because of the way we want to organize the firmware supply chain: when
> > the
> > > board is built, it is "attached" a device tree.
> > > At that moment, we don't know what "non trusted firmware" will be used.
> > It
> > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2
> > (yes
> > > it works with DT).
> > > And we aim at keeping device tree as close to the original intent:
> > hardware
> > > description only. It's not because we can stuff anything in the DT and
> > that
> > > it is simple to do that we should.
> > > Driver parameters shall be in the OS facility built for that purpose.
> > Using
> > > device tree has been an ugly habit.
> >
> > So we're going to continue to re-litigate what does and doesn't live in
> > the device tree for forever, aren't we? To continue to be clear, I'm
> > not saying that non-upstream bindings should be present. But for
> > example, Simon is working on the "U-Boot config node" binding, which is
> > going to get re-spun next as /options/ as I read the thread right.
> > Populate it and anyone can read it, and probably be getting information
> > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
> > I keep repeating that projects need to push bindings upstream. I'll
> > repeat my comment about
> >
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > and the binman node both noting a common problem to solve.
>
> i think you are right. Now tfa is comfortable being its own upstream for
> the binding specifications. Could U-Boot community be comfortable doing so?
Well, since we need to and are trying to solve the same problem, why
should we duplicate efforts? This is something that should be common
and upstream is my point.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-28 14:41 ` Tom Rini
0 siblings, 0 replies; 164+ messages in thread
From: Tom Rini @ 2021-10-28 14:41 UTC (permalink / raw)
To: François Ozog
Cc: liviu.dudau, narmstrong, rick, vladimir.oltean, linus.walleij,
fitzsim, kever.yang, seanga2, atish.patra, zong.li, sr, festevam,
rainer.boschung, Mark Kettenis, swarren, oleksandr_andrushchenko,
xypron.glpk, lusus, michal.simek, marek.behun, vanbaren,
rfried.dev, jagan, valentin.longchamp, hs, pbrobinson, sinan,
bin.meng, wd, swarren, andre.przywara, tharvey, ashok.reddy.soma,
qemu-devel, agraf, green.wan, t.karthik.reddy,
anastasiia_lukianenko, albert.u.boot, monstr, mbrugger, ycliang,
kristo, u-boot, david.abdurachmanov, priyanka.jain, sjg,
ilias.apalodimas, christianshewitt, awilliams, tuomas.tynkkynen,
heinrich.schuchardt, tianrui-wei, bmeng.cn, pali, dimitri.ledkov,
padmarao.begari
[-- Attachment #1: Type: text/plain, Size: 19928 bytes --]
On Thu, Oct 28, 2021 at 12:00:44AM +0200, François Ozog wrote:
> Hi Tom
>
> Le mer. 27 oct. 2021 à 21:06, Tom Rini <trini@konsulko.com> a écrit :
>
> > On Wed, Oct 27, 2021 at 06:02:19PM +0200, François Ozog wrote:
> > > Hi Mark,
> > >
> > > On Wed, 27 Oct 2021 at 17:10, Mark Kettenis <mark.kettenis@xs4all.nl>
> > wrote:
> > >
> > > > > From: François Ozog <francois.ozog@linaro.org>
> > > > > Date: Wed, 27 Oct 2021 15:15:01 +0200
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini <trini@konsulko.com> wrote:
> > > > >
> > > > > > On Fri, Oct 15, 2021 at 12:03:44PM -0600, Simon Glass wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > On Thu, 14 Oct 2021 at 09:28, Tom Rini <trini@konsulko.com>
> > wrote:
> > > > > > > >
> > > > > > > > On Thu, Oct 14, 2021 at 09:17:52AM -0600, Simon Glass wrote:
> > > > > > > > > Hi Tom,
> > > > > > > > >
> > > > > > > > > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com>
> > > > wrote:
> > > > > > > > > >
> > > > > > > > > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass
> > wrote:
> > > > > > > > > > > Hi François,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> > > > > > francois.ozog@linaro.org> wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Simon
> > > > > > > > > > > >
> > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <
> > > > sjg@chromium.org>
> > > > > > a écrit :
> > > > > > > > > > > >>
> > > > > > > > > > > >> Hi Tom, Bin,François,
> > > > > > > > > > > >>
> > > > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <
> > > > trini@konsulko.com>
> > > > > > wrote:
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng
> > > > wrote:
> > > > > > > > > > > >> > > Hi Simon,
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <
> > > > > > sjg@chromium.org> wrote:
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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
> > at
> > > > [1].
> > > > > > > > > > > >> > > >
> > > > > > > > > > > >> > > > 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.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > Adding device trees that are never used sounds
> > like a
> > > > > > hack to me.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > For QEMU, device tree is dynamically generated on
> > the
> > > > fly
> > > > > > based on
> > > > > > > > > > > >> > > command line parameters, and the device tree you
> > put
> > > > in
> > > > > > this series
> > > > > > > > > > > >> > > has various hardcoded <phandle> values which
> > normally
> > > > do
> > > > > > not show up
> > > > > > > > > > > >> > > in hand-written dts files.
> > > > > > > > > > > >> > >
> > > > > > > > > > > >> > > I am not sure I understand the whole point of
> > this.
> > > > > > > > > > > >> >
> > > > > > > > > > > >> > I am also confused and do not like the idea of
> > adding
> > > > > > device trees for
> > > > > > > > > > > >> > platforms that are capable of and can / do have a
> > device
> > > > > > tree to give us
> > > > > > > > > > > >> > at run time.
> > > > > > > > > > > >>
> > > > > > > > > > > >> (I'll just reply to this one email, since the same
> > points
> > > > > > applies to
> > > > > > > > > > > >> all replies I think)
> > > > > > > > > > > >>
> > > > > > > > > > > >> I have been thinking about this and discussing it with
> > > > people
> > > > > > for a
> > > > > > > > > > > >> few months now. I've been signalling a change like
> > this
> > > > for
> > > > > > over a
> > > > > > > > > > > >> month now, on U-Boot contributor calls and in
> > discussions
> > > > > > with Linaro
> > > > > > > > > > > >> people. I sent a patch (below) to try to explain
> > things. I
> > > > > > hope it is
> > > > > > > > > > > >> not a surprise!
> > > > > > > > > > > >>
> > > > > > > > > > > >> The issue here is that we need a devicetree in-tree in
> > > > > > U-Boot, to
> > > > > > > > > > > >> avoid the mess that has been created by
> > OF_PRIOR_STAGE,
> > > > > > OF_BOARD,
> > > > > > > > > > > >> BINMAN_STANDALONE_FDT and to a lesser extent,
> > OF_HOSTFILE.
> > > > > > Between
> > > > > > > > > > > >> Ilias' series and this one we can get ourselves on a
> > > > stronger
> > > > > > footing.
> > > > > > > > > > > >> There is just OF_SEPARATE, with OF_EMBED for
> > debugging/ELF
> > > > > > use.
> > > > > > > > > > > >> For more context:
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > >
> > > >
> > http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > > > > > > > > >>
> > > > > > > > > > > >> BTW I did suggest to QEMU ARM that they support a way
> > of
> > > > > > adding the
> > > > > > > > > > > >> u-boot.dtsi but there was not much interest there (in
> > > > fact the
> > > > > > > > > > > >> maintainer would prefer there was no special support
> > even
> > > > for
> > > > > > booting
> > > > > > > > > > > >> Linux directly!)
> > > > > > > > > > > >
> > > > > > > > > > > > i understand their point of view and agree with it.
> > > > > > > > > > > >>
> > > > > > > > > > > >> But in any case it doesn't really help U-Boot. I
> > > > > > > > > > > >> think the path forward might be to run QEMU twice,
> > once to
> > > > > > get its
> > > > > > > > > > > >> generated tree and once to give the 'merged' tree
> > with the
> > > > > > U-Boot
> > > > > > > > > > > >> properties in it, if people want to use U-Boot
> > features.
> > > > > > > > > > > >>
> > > > > > > > > > > >> I do strongly believe that OF_BOARD must be a run-time
> > > > > > option, not a
> > > > > > > > > > > >> build-time one. It creates all sorts of problems and
> > > > > > obscurity which
> > > > > > > > > > > >> have taken months to unpick. See the above patch for
> > the
> > > > > > rationale.
> > > > > > > > > > > >>
> > > > > > > > > > > >> To add to that rationale, OF_BOARD needs to be an
> > option
> > > > > > available to
> > > > > > > > > > > >> any board. At some point in the future it may become a
> > > > common
> > > > > > way
> > > > > > > > > > > >> things are done, e.g. TF-A calling U-Boot and
> > providing a
> > > > > > devicetree
> > > > > > > > > > > >> to it. It doesn't make any sense to have people decide
> > > > > > whether or not
> > > > > > > > > > > >> to set OF_BOARD at build time, thus affecting how the
> > > > image
> > > > > > is put
> > > > > > > > > > > >> together. We'll end up with different U-Boot build
> > targets
> > > > > > like
> > > > > > > > > > > >> capricorn, capricorn_of_board and the like. It should
> > be
> > > > > > obvious where
> > > > > > > > > > > >> that will lead. Instead, OF_BOARD needs to become a
> > > > commonly
> > > > > > used
> > > > > > > > > > > >> option, perhaps enabled by most/all boards, so that
> > this
> > > > sort
> > > > > > of build
> > > > > > > > > > > >> explosion is not needed.
> > > > > > > > > > > >
> > > > > > > > > > > > If you mean that when boards are by construction
> > providing
> > > > a
> > > > > > DTB to U-Boot then I agree very much. But I don’t understand how
> > the
> > > > patch
> > > > > > set supports it as it puts dts files for those boards to be built.
> > > > > > > > > > > >>
> > > > > > > > > > > >> U-Boot needs to be flexible enough to
> > > > > > > > > > > >> function correctly in whatever runtime environment in
> > > > which
> > > > > > it finds
> > > > > > > > > > > >> itself.
> > > > > > > > > > > >>
> > > > > > > > > > > >> Also as binman is pressed into service more and more
> > to
> > > > build
> > > > > > the
> > > > > > > > > > > >> complex firmware images that are becoming
> > fashionable, it
> > > > > > needs a
> > > > > > > > > > > >> definition (in the devicetree) that describes how to
> > > > create
> > > > > > the image.
> > > > > > > > > > > >> We can't support that unless we are building a
> > devicetree,
> > > > > > nor can the
> > > > > > > > > > > >> running program access the image layout without that
> > > > > > information.
> > > > > > > > > > > >>
> > > > > > > > > > > >> François's point about 'don't use this with any
> > kernel' is
> > > > > > > > > > > >> germane...but of course I am not suggesting doing
> > that,
> > > > since
> > > > > > OF_BOARD
> > > > > > > > > > > >> is, still, enabled. We already use OF_BOARD for
> > various
> > > > > > boards that
> > > > > > > > > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and
> > 3,
> > > > for
> > > > > > example
> > > > > > > > > > > >> (as I said in the cover letter "Most boards do provide
> > > > one,
> > > > > > but some
> > > > > > > > > > > >> don't."). So this series is just completing the
> > picture by
> > > > > > enforcing
> > > > > > > > > > > >> that *some sort* of devicetree is always present.
> > > > > > > > > > > >
> > > > > > > > > > > > That seems inconsistent with the OF_BOARD becomes the
> > > > default.
> > > > > > > > > > >
> > > > > > > > > > > I think the key point that will get you closer to where
> > I am
> > > > on
> > > > > > this
> > > > > > > > > > > issue, is that OF_BOARD needs to be a run-time option. At
> > > > > > present it
> > > > > > > > > > > has build-time effects and this is quite wrong. If you go
> > > > > > through all
> > > > > > > > > > > the material I have written on this I think I have
> > motivated
> > > > > > that very
> > > > > > > > > > > clearly.
> > > > > > > > > > >
> > > > > > > > > > > Another big issue is that I believe we need ONE
> > devicetree
> > > > for
> > > > > > U-Boot,
> > > > > > > > > > > not two that get merged by U-Boot. Again I have gone
> > through
> > > > > > that in a
> > > > > > > > > > > lot of detail.
> > > > > > > > > >
> > > > > > > > > > I have a long long reply to your first reply here saved,
> > but,
> > > > maybe
> > > > > > > > > > here's the biggest sticking point. To be clear, you agree
> > that
> > > > > > U-Boot
> > > > > > > > > > needs to support being passed a device tree to use, at run
> > > > time,
> > > > > > yes?
> > > > > > > > >
> > > > > > > > > Yes. The OF_BOARD feature provides this.
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > And in that case, would not be using the "fake" tree we
> > built
> > > > in?
> > > > > > > > >
> > > > > > > > > Not at runtime.
> > > > > > > >
> > > > > > > > OK.
> > > > > > > >
> > > > > > > > > > So is the sticking point here that we really have two
> > classes
> > > > of
> > > > > > > > > > devices, one class where we will never ever be given the
> > device
> > > > > > tree at
> > > > > > > > > > run time (think BeagleBone Black) and one where we will
> > always
> > > > be
> > > > > > given
> > > > > > > > > > one at run time (think Raspberry Pi) ?
> > > > > > > > >
> > > > > > > > > I'm not sure it will be that black and white. I suspect there
> > > > will be
> > > > > > > > > (many) boards which can boot happily with the U-Boot
> > devicetree
> > > > but
> > > > > > > > > can also accept one at runtime, if provided. For example,
> > you may
> > > > > > want
> > > > > > > > > to boot with or without TF-A or some other, earlier stage.
> > > > > > > >
> > > > > > > > I'm not sure I see the value in making this a gray area.
> > There's
> > > > very
> > > > > > > > much a class of "never" boards. There's also the class of
> > "can"
> > > > today.
> > > > > > > > Maybe as part of a developer iterative flow it would be nice
> > to not
> > > > > > have
> > > > > > > > to re-flash the prior stage to change a DT, and just do it in
> > > > U-Boot
> > > > > > > > until things are happy, but I'm not sure what the use case is
> > for
> > > > > > > > overriding the previous stage.
> > > > > > > >
> > > > > > > > Especially since the pushback on this series I think has all
> > been
> > > > "why
> > > > > > > > are we copying in a tree to build with? We don't want to use
> > it
> > > > at run
> > > > > > > > time!". And then softer push back like "Well, U-Boot says we
> > have
> > > > to
> > > > > > > > include the device tree file here, but we won't use it...".
> > > > > > >
> > > > > > > See below.
> > > > > > >
> > > > > > > >
> > > > > > > > > I believe we have got unstuck because OF_BOARD (perhaps
> > > > > > inadvertently)
> > > > > > > > > provided a way to entirely omit a devicetree from U-Boot,
> > thus
> > > > making
> > > > > > > > > things like binman and U-Boot /config impossible, for
> > example.
> > > > So I
> > > > > > > > > want to claw that back, so there is always some sort of
> > > > devicetree in
> > > > > > > > > U-Boot, as we have for rpi_3, etc.
> > > > > > > >
> > > > > > > > I really want to see what the binary case looks like since we
> > could
> > > > > > then
> > > > > > > > kill off rpi_{3,3_b,4}_defconfig and I would need to see if we
> > > > could
> > > > > > > > then also do a rpi_arm32_defconfig too.
> > > > > > > >
> > > > > > > > I want to see less device trees in U-Boot sources, if they can
> > come
> > > > > > > > functionally correct from the hardware/our caller.
> > > > > > > >
> > > > > > > > And I'm not seeing how we make use of "U-Boot /config" if we
> > also
> > > > don't
> > > > > > > > use the device tree from build time at run time, ignoring the
> > > > device
> > > > > > > > tree provided to us at run time by the caller.
> > > > > > >
> > > > > > > Firstly I should say that I find building firmware very messy and
> > > > > > > confusing these days. Lots of things to build and it's hard to
> > find
> > > > > > > the instructions. It doesn't have to be that way, but if we
> > carry on
> > > > > > > as we are, it will continue to be messy and in five years you
> > will
> > > > > > > need a Ph.D and a lucky charm to boot on any modern board. My
> > > > > > > objective here is to simplify things, bringing some consistency
> > to
> > > > the
> > > > > > > different components. Binman was one effort there. I feel that
> > > > putting
> > > > > > > at least the U-Boot house in order, in my role as devicetree
> > > > > > > maintainer (and as author of devicetree support in U-Boot back in
> > > > > > > 2011), is the next step.
> > > > > >
> > > > > > Yes, it's Not Great. I don't like my handful of build-BOARD.sh
> > scripts
> > > > > > that know where to grab other known-good binaries of varying
> > licenses
> > > > > > that are needed to assemble something that boots.
> > > > > >
> > > > > > > If we set things up correctly and agree on the bindings,
> > devicetree
> > > > > > > can be the unifying configuration mechanism through the whole of
> > > > > > > firmware (except for very early bits) and into the OS, this will
> > set
> > > > > > > us up very well to deal with the complexity that is coming.
> > > > > > >
> > > > > > > Anyway, here are the mental steps that I've gone through over the
> > > > past
> > > > > > > two months:
> > > > > > >
> > > > > > > Step 1: At present, some people think U-Boot is not even allowed
> > to
> > > > > > > have its own nodes/properties in the DT.
> > > > >
> > > > > In my view U-Boot shall be able to leverage device tree format
> > (source
> > > > and
> > > > > binary) to store its own data.
> > > > > When you say "the" DT, I always think this is "the" DT that is
> > passed to
> > > > OS
> > > > > and in "that" DT, there should be no U-Boot entries.
> > > >
> > > > Why not? As long as the device tree validates, it is perfectly fine
> > > > to have additional nodes and properties present. The propertiesand
> > > > nodes will be simply ignored by the OS.
> > >
> > > Because of the way we want to organize the firmware supply chain: when
> > the
> > > board is built, it is "attached" a device tree.
> > > At that moment, we don't know what "non trusted firmware" will be used.
> > It
> > > could be U-Boot or LinuxBoot (https://www.linuxboot.org) or even EDK2
> > (yes
> > > it works with DT).
> > > And we aim at keeping device tree as close to the original intent:
> > hardware
> > > description only. It's not because we can stuff anything in the DT and
> > that
> > > it is simple to do that we should.
> > > Driver parameters shall be in the OS facility built for that purpose.
> > Using
> > > device tree has been an ugly habit.
> >
> > So we're going to continue to re-litigate what does and doesn't live in
> > the device tree for forever, aren't we? To continue to be clear, I'm
> > not saying that non-upstream bindings should be present. But for
> > example, Simon is working on the "U-Boot config node" binding, which is
> > going to get re-spun next as /options/ as I read the thread right.
> > Populate it and anyone can read it, and probably be getting information
> > that's useful to U-Boot or LinuxBoot or EDK2 or anyone else. That's why
> > I keep repeating that projects need to push bindings upstream. I'll
> > repeat my comment about
> >
> > https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html
> > and the binman node both noting a common problem to solve.
>
> i think you are right. Now tfa is comfortable being its own upstream for
> the binding specifications. Could U-Boot community be comfortable doing so?
Well, since we need to and are trying to solve the same problem, why
should we duplicate efforts? This is something that should be common
and upstream is my point.
--
Tom
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 15:17 ` Simon Glass
@ 2021-10-14 16:24 ` Andre Przywara
-1 siblings, 0 replies; 164+ messages in thread
From: Andre Przywara @ 2021-10-14 16:24 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stephen Warren, Stefan Roese, Fabio Estevam, Rainer Boschung,
Tom Rini, Stephen Warren, Oleksandr Andrushchenko,
Heinrich Schuchardt, Niel Fourie, Michal Simek, Marek Behún,
Jerry Van Baren, Ramon Fried, Jagan Teki, Valentin Longchamp,
Heiko Schocher, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, François Ozog,
qemu-devel@nongnu.org Developers, Tim Harvey, Ashok Reddy Soma,
Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy,
Anastasiia Lukianenko, Albert Aribaud, Michal Simek,
Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List,
David Abdurachmanov, Priyanka Jain, Ilias Apalodimas,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
On Thu, 14 Oct 2021 09:17:52 -0600
Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees for
> > > >> > platforms that are capable of and can / do have a device tree to give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)
> > > >
> > > > i understand their point of view and agree with it.
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to unpick. See the above patch for the rationale.
> > > >>
> > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > >> any board. At some point in the future it may become a common way
> > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > >> to it. It doesn't make any sense to have people decide whether or not
> > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > >> together. We'll end up with different U-Boot build targets like
> > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > >> explosion is not needed.
> > > >
> > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > >>
> > > >> U-Boot needs to be flexible enough to
> > > >> function correctly in whatever runtime environment in which it finds
> > > >> itself.
> > > >>
> > > >> Also as binman is pressed into service more and more to build the
> > > >> complex firmware images that are becoming fashionable, it needs a
> > > >> definition (in the devicetree) that describes how to create the image.
> > > >> We can't support that unless we are building a devicetree, nor can the
> > > >> running program access the image layout without that information.
> > > >>
> > > >> François's point about 'don't use this with any kernel' is
> > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > >> don't."). So this series is just completing the picture by enforcing
> > > >> that *some sort* of devicetree is always present.
> > > >
> > > > That seems inconsistent with the OF_BOARD becomes the default.
> > >
> > > I think the key point that will get you closer to where I am on this
> > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > has build-time effects and this is quite wrong. If you go through all
> > > the material I have written on this I think I have motivated that very
> > > clearly.
> > >
> > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > not two that get merged by U-Boot. Again I have gone through that in a
> > > lot of detail.
> >
> > I have a long long reply to your first reply here saved, but, maybe
> > here's the biggest sticking point. To be clear, you agree that U-Boot
> > needs to support being passed a device tree to use, at run time, yes?
>
> Yes. The OF_BOARD feature provides this.
>
> >
> > And in that case, would not be using the "fake" tree we built in?
>
> Not at runtime.
>
> >
> > So is the sticking point here that we really have two classes of
> > devices, one class where we will never ever be given the device tree at
> > run time (think BeagleBone Black) and one where we will always be given
> > one at run time (think Raspberry Pi) ?
>
> I'm not sure it will be that black and white. I suspect there will be
> (many) boards which can boot happily with the U-Boot devicetree but
> can also accept one at runtime, if provided. For example, you may want
> to boot with or without TF-A or some other, earlier stage.
I don't understand this: as Tom mentioned this is a platform decision:
either it provides a DT somewhere (flash, EEPROM, prior firmware stage),
or it doesn't. Sure, you can always hack your own DT in, somehow, for
development or experimentation purposes, but that is a separate issue.
Most of those platforms actually utilise some dynamic DTs, btw, where
software amends the DT on the fly:
- Highbank has a stub DT in SPI flash, and the management controller
firmware detects the size and some extra DRAM (DIMMs!) parameters at boot
time, and writes the /memory node accordingly.
- RPi3/4 have DT overlay files on the SD card, and depending on what a
user wrote in config.txt, they get applied to the DT (or not).
- Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in
DRAM in TF-A, to carve out the DRAM region TF-A occupies.
- QEMU is the obvious example, where the whole machine is highly dynamic,
and there is no such thing as a fixed DT (how many cores?, how much
memory?, how many virtio devices?, flash?, SCSI?)
> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> provided a way to entirely omit a devicetree from U-Boot, thus making
> things like binman and U-Boot /config impossible, for example.
I have the feeling this is because we abuse DT for this. Conceptually the
DT is not a configuration file, but a hardware description. I see that it
is also a nice and flexible, hierarchical key/value storage, for which we
have code in anyway, so it makes hardcoding data in the code easier to avoid.
But as we see now, this has problems as well.
So shall we separate those use cases? And attach just a tree with /binman
and /config (in DTB format), but treat this separately from the hardware
description? (Admittedly I have still to wrap my head around why we need
/binman at U-Boot runtime in the first place.)
Cheers,
Andre
> So I
> want to claw that back, so there is always some sort of devicetree in
> U-Boot, as we have for rpi_3, etc.
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 16:24 ` Andre Przywara
0 siblings, 0 replies; 164+ messages in thread
From: Andre Przywara @ 2021-10-14 16:24 UTC (permalink / raw)
To: Simon Glass
Cc: Tom Rini, François Ozog, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
On Thu, 14 Oct 2021 09:17:52 -0600
Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> >
> > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > Hi François,
> > >
> > > On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
> > > >
> > > > Hi Simon
> > > >
> > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> > > >>
> > > >> Hi Tom, Bin,François,
> > > >>
> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> > > >> >
> > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > >> > > Hi Simon,
> > > >> > >
> > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> > > >> > > >
> > > >> > > > 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 at [1].
> > > >> > > >
> > > >> > > > 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.
> > > >> > >
> > > >> > > Adding device trees that are never used sounds like a hack to me.
> > > >> > >
> > > >> > > For QEMU, device tree is dynamically generated on the fly based on
> > > >> > > command line parameters, and the device tree you put in this series
> > > >> > > has various hardcoded <phandle> values which normally do not show up
> > > >> > > in hand-written dts files.
> > > >> > >
> > > >> > > I am not sure I understand the whole point of this.
> > > >> >
> > > >> > I am also confused and do not like the idea of adding device trees for
> > > >> > platforms that are capable of and can / do have a device tree to give us
> > > >> > at run time.
> > > >>
> > > >> (I'll just reply to this one email, since the same points applies to
> > > >> all replies I think)
> > > >>
> > > >> I have been thinking about this and discussing it with people for a
> > > >> few months now. I've been signalling a change like this for over a
> > > >> month now, on U-Boot contributor calls and in discussions with Linaro
> > > >> people. I sent a patch (below) to try to explain things. I hope it is
> > > >> not a surprise!
> > > >>
> > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > >> Ilias' series and this one we can get ourselves on a stronger footing.
> > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > >> For more context:
> > > >>
> > > >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > >>
> > > >> BTW I did suggest to QEMU ARM that they support a way of adding the
> > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > >> maintainer would prefer there was no special support even for booting
> > > >> Linux directly!)
> > > >
> > > > i understand their point of view and agree with it.
> > > >>
> > > >> But in any case it doesn't really help U-Boot. I
> > > >> think the path forward might be to run QEMU twice, once to get its
> > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > >> properties in it, if people want to use U-Boot features.
> > > >>
> > > >> I do strongly believe that OF_BOARD must be a run-time option, not a
> > > >> build-time one. It creates all sorts of problems and obscurity which
> > > >> have taken months to unpick. See the above patch for the rationale.
> > > >>
> > > >> To add to that rationale, OF_BOARD needs to be an option available to
> > > >> any board. At some point in the future it may become a common way
> > > >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> > > >> to it. It doesn't make any sense to have people decide whether or not
> > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > >> together. We'll end up with different U-Boot build targets like
> > > >> capricorn, capricorn_of_board and the like. It should be obvious where
> > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > >> option, perhaps enabled by most/all boards, so that this sort of build
> > > >> explosion is not needed.
> > > >
> > > > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
> > > >>
> > > >> U-Boot needs to be flexible enough to
> > > >> function correctly in whatever runtime environment in which it finds
> > > >> itself.
> > > >>
> > > >> Also as binman is pressed into service more and more to build the
> > > >> complex firmware images that are becoming fashionable, it needs a
> > > >> definition (in the devicetree) that describes how to create the image.
> > > >> We can't support that unless we are building a devicetree, nor can the
> > > >> running program access the image layout without that information.
> > > >>
> > > >> François's point about 'don't use this with any kernel' is
> > > >> germane...but of course I am not suggesting doing that, since OF_BOARD
> > > >> is, still, enabled. We already use OF_BOARD for various boards that
> > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> > > >> (as I said in the cover letter "Most boards do provide one, but some
> > > >> don't."). So this series is just completing the picture by enforcing
> > > >> that *some sort* of devicetree is always present.
> > > >
> > > > That seems inconsistent with the OF_BOARD becomes the default.
> > >
> > > I think the key point that will get you closer to where I am on this
> > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > has build-time effects and this is quite wrong. If you go through all
> > > the material I have written on this I think I have motivated that very
> > > clearly.
> > >
> > > Another big issue is that I believe we need ONE devicetree for U-Boot,
> > > not two that get merged by U-Boot. Again I have gone through that in a
> > > lot of detail.
> >
> > I have a long long reply to your first reply here saved, but, maybe
> > here's the biggest sticking point. To be clear, you agree that U-Boot
> > needs to support being passed a device tree to use, at run time, yes?
>
> Yes. The OF_BOARD feature provides this.
>
> >
> > And in that case, would not be using the "fake" tree we built in?
>
> Not at runtime.
>
> >
> > So is the sticking point here that we really have two classes of
> > devices, one class where we will never ever be given the device tree at
> > run time (think BeagleBone Black) and one where we will always be given
> > one at run time (think Raspberry Pi) ?
>
> I'm not sure it will be that black and white. I suspect there will be
> (many) boards which can boot happily with the U-Boot devicetree but
> can also accept one at runtime, if provided. For example, you may want
> to boot with or without TF-A or some other, earlier stage.
I don't understand this: as Tom mentioned this is a platform decision:
either it provides a DT somewhere (flash, EEPROM, prior firmware stage),
or it doesn't. Sure, you can always hack your own DT in, somehow, for
development or experimentation purposes, but that is a separate issue.
Most of those platforms actually utilise some dynamic DTs, btw, where
software amends the DT on the fly:
- Highbank has a stub DT in SPI flash, and the management controller
firmware detects the size and some extra DRAM (DIMMs!) parameters at boot
time, and writes the /memory node accordingly.
- RPi3/4 have DT overlay files on the SD card, and depending on what a
user wrote in config.txt, they get applied to the DT (or not).
- Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in
DRAM in TF-A, to carve out the DRAM region TF-A occupies.
- QEMU is the obvious example, where the whole machine is highly dynamic,
and there is no such thing as a fixed DT (how many cores?, how much
memory?, how many virtio devices?, flash?, SCSI?)
> I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> provided a way to entirely omit a devicetree from U-Boot, thus making
> things like binman and U-Boot /config impossible, for example.
I have the feeling this is because we abuse DT for this. Conceptually the
DT is not a configuration file, but a hardware description. I see that it
is also a nice and flexible, hierarchical key/value storage, for which we
have code in anyway, so it makes hardcoding data in the code easier to avoid.
But as we see now, this has problems as well.
So shall we separate those use cases? And attach just a tree with /binman
and /config (in DTB format), but treat this separately from the hardware
description? (Admittedly I have still to wrap my head around why we need
/binman at U-Boot runtime in the first place.)
Cheers,
Andre
> So I
> want to claw that back, so there is always some sort of devicetree in
> U-Boot, as we have for rpi_3, etc.
>
> Regards,
> Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 16:24 ` Andre Przywara
@ 2021-10-14 17:48 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 17:48 UTC (permalink / raw)
To: Andre Przywara
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 11468 bytes --]
Le jeu. 14 oct. 2021 à 18:24, Andre Przywara <andre.przywara@arm.com> a
écrit :
> On Thu, 14 Oct 2021 09:17:52 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded <phandle> values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all sorts of problems and obscurity
> which
> > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or
> not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious
> where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of
> build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB
> to U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it
> finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the
> image.
> > > > >> We can't support that unless we are building a devicetree, nor
> can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards
> that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > >> (as I said in the cover letter "Most boards do provide one, but
> some
> > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that
> very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in
> a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
> >
> > >
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I don't understand this: as Tom mentioned this is a platform decision:
> either it provides a DT somewhere (flash, EEPROM, prior firmware stage),
> or it doesn't. Sure, you can always hack your own DT in, somehow, for
> development or experimentation purposes, but that is a separate issue.
>
> Most of those platforms actually utilise some dynamic DTs, btw, where
> software amends the DT on the fly:
> - Highbank has a stub DT in SPI flash, and the management controller
> firmware detects the size and some extra DRAM (DIMMs!) parameters at boot
> time, and writes the /memory node accordingly.
> - RPi3/4 have DT overlay files on the SD card, and depending on what a
> user wrote in config.txt, they get applied to the DT (or not).
> - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in
> DRAM in TF-A, to carve out the DRAM region TF-A occupies.
> - QEMU is the obvious example, where the whole machine is highly dynamic,
> and there is no such thing as a fixed DT (how many cores?, how much
> memory?, how many virtio devices?, flash?, SCSI?)
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example.
>
> I have the feeling this is because we abuse DT for this. Conceptually the
> DT is not a configuration file, but a hardware description.
+42!!!
> I see that it
> is also a nice and flexible, hierarchical key/value storage, for which we
> have code in anyway, so it makes hardcoding data in the code easier to
> avoid.
> But as we see now, this has problems as well.
>
> So shall we separate those use cases? And attach just a tree with /binman
> and /config (in DTB format), but treat this separately from the hardware
> description? (Admittedly I have still to wrap my head around why we need
> /binman at U-Boot runtime in the first place.)
+1
>
>
> Cheers,
> Andre
>
> > So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
> >
> > Regards,
> > Simon
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 16742 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 17:48 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 17:48 UTC (permalink / raw)
To: Andre Przywara
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Ashok Reddy Soma, Atish Patra, Bin Meng,
Bin Meng, Christian Hewitt, David Abdurachmanov,
Dimitri John Ledkov, Fabio Estevam, Green Wan, Heiko Schocher,
Heinrich Schuchardt, Heinrich Schuchardt, Ilias Apalodimas,
Jagan Teki, Jerry Van Baren, Kever Yang, Leo, Linus Walleij,
Liviu Dudau, Marek Behún, Matthias Brugger, Michal Simek,
Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Simon Glass, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List, Valentin Longchamp,
Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Le jeu. 14 oct. 2021 à 18:24, Andre Przywara <andre.przywara@arm.com> a
écrit :
> On Thu, 14 Oct 2021 09:17:52 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
> > Hi Tom,
> >
> > On Thu, 14 Oct 2021 at 08:56, Tom Rini <trini@konsulko.com> wrote:
> > >
> > > On Wed, Oct 13, 2021 at 12:06:02PM -0600, Simon Glass wrote:
> > > > Hi François,
> > > >
> > > > On Wed, 13 Oct 2021 at 11:35, François Ozog <
> francois.ozog@linaro.org> wrote:
> > > > >
> > > > > Hi Simon
> > > > >
> > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a
> écrit :
> > > > >>
> > > > >> Hi Tom, Bin,François,
> > > > >>
> > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com>
> wrote:
> > > > >> >
> > > > >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> > > > >> > > Hi Simon,
> > > > >> > >
> > > > >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> > > > >> > > >
> > > > >> > > > 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 at [1].
> > > > >> > > >
> > > > >> > > > 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.
> > > > >> > >
> > > > >> > > Adding device trees that are never used sounds like a hack to
> me.
> > > > >> > >
> > > > >> > > For QEMU, device tree is dynamically generated on the fly
> based on
> > > > >> > > command line parameters, and the device tree you put in this
> series
> > > > >> > > has various hardcoded <phandle> values which normally do not
> show up
> > > > >> > > in hand-written dts files.
> > > > >> > >
> > > > >> > > I am not sure I understand the whole point of this.
> > > > >> >
> > > > >> > I am also confused and do not like the idea of adding device
> trees for
> > > > >> > platforms that are capable of and can / do have a device tree
> to give us
> > > > >> > at run time.
> > > > >>
> > > > >> (I'll just reply to this one email, since the same points applies
> to
> > > > >> all replies I think)
> > > > >>
> > > > >> I have been thinking about this and discussing it with people for
> a
> > > > >> few months now. I've been signalling a change like this for over a
> > > > >> month now, on U-Boot contributor calls and in discussions with
> Linaro
> > > > >> people. I sent a patch (below) to try to explain things. I hope
> it is
> > > > >> not a surprise!
> > > > >>
> > > > >> The issue here is that we need a devicetree in-tree in U-Boot, to
> > > > >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> > > > >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> > > > >> Ilias' series and this one we can get ourselves on a stronger
> footing.
> > > > >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> > > > >> For more context:
> > > > >>
> > > > >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> > > > >>
> > > > >> BTW I did suggest to QEMU ARM that they support a way of adding
> the
> > > > >> u-boot.dtsi but there was not much interest there (in fact the
> > > > >> maintainer would prefer there was no special support even for
> booting
> > > > >> Linux directly!)
> > > > >
> > > > > i understand their point of view and agree with it.
> > > > >>
> > > > >> But in any case it doesn't really help U-Boot. I
> > > > >> think the path forward might be to run QEMU twice, once to get its
> > > > >> generated tree and once to give the 'merged' tree with the U-Boot
> > > > >> properties in it, if people want to use U-Boot features.
> > > > >>
> > > > >> I do strongly believe that OF_BOARD must be a run-time option,
> not a
> > > > >> build-time one. It creates all sorts of problems and obscurity
> which
> > > > >> have taken months to unpick. See the above patch for the
> rationale.
> > > > >>
> > > > >> To add to that rationale, OF_BOARD needs to be an option
> available to
> > > > >> any board. At some point in the future it may become a common way
> > > > >> things are done, e.g. TF-A calling U-Boot and providing a
> devicetree
> > > > >> to it. It doesn't make any sense to have people decide whether or
> not
> > > > >> to set OF_BOARD at build time, thus affecting how the image is put
> > > > >> together. We'll end up with different U-Boot build targets like
> > > > >> capricorn, capricorn_of_board and the like. It should be obvious
> where
> > > > >> that will lead. Instead, OF_BOARD needs to become a commonly used
> > > > >> option, perhaps enabled by most/all boards, so that this sort of
> build
> > > > >> explosion is not needed.
> > > > >
> > > > > If you mean that when boards are by construction providing a DTB
> to U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> > > > >>
> > > > >> U-Boot needs to be flexible enough to
> > > > >> function correctly in whatever runtime environment in which it
> finds
> > > > >> itself.
> > > > >>
> > > > >> Also as binman is pressed into service more and more to build the
> > > > >> complex firmware images that are becoming fashionable, it needs a
> > > > >> definition (in the devicetree) that describes how to create the
> image.
> > > > >> We can't support that unless we are building a devicetree, nor
> can the
> > > > >> running program access the image layout without that information.
> > > > >>
> > > > >> François's point about 'don't use this with any kernel' is
> > > > >> germane...but of course I am not suggesting doing that, since
> OF_BOARD
> > > > >> is, still, enabled. We already use OF_BOARD for various boards
> that
> > > > >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for
> example
> > > > >> (as I said in the cover letter "Most boards do provide one, but
> some
> > > > >> don't."). So this series is just completing the picture by
> enforcing
> > > > >> that *some sort* of devicetree is always present.
> > > > >
> > > > > That seems inconsistent with the OF_BOARD becomes the default.
> > > >
> > > > I think the key point that will get you closer to where I am on this
> > > > issue, is that OF_BOARD needs to be a run-time option. At present it
> > > > has build-time effects and this is quite wrong. If you go through all
> > > > the material I have written on this I think I have motivated that
> very
> > > > clearly.
> > > >
> > > > Another big issue is that I believe we need ONE devicetree for
> U-Boot,
> > > > not two that get merged by U-Boot. Again I have gone through that in
> a
> > > > lot of detail.
> > >
> > > I have a long long reply to your first reply here saved, but, maybe
> > > here's the biggest sticking point. To be clear, you agree that U-Boot
> > > needs to support being passed a device tree to use, at run time, yes?
> >
> > Yes. The OF_BOARD feature provides this.
> >
> > >
> > > And in that case, would not be using the "fake" tree we built in?
> >
> > Not at runtime.
> >
> > >
> > > So is the sticking point here that we really have two classes of
> > > devices, one class where we will never ever be given the device tree at
> > > run time (think BeagleBone Black) and one where we will always be given
> > > one at run time (think Raspberry Pi) ?
> >
> > I'm not sure it will be that black and white. I suspect there will be
> > (many) boards which can boot happily with the U-Boot devicetree but
> > can also accept one at runtime, if provided. For example, you may want
> > to boot with or without TF-A or some other, earlier stage.
>
> I don't understand this: as Tom mentioned this is a platform decision:
> either it provides a DT somewhere (flash, EEPROM, prior firmware stage),
> or it doesn't. Sure, you can always hack your own DT in, somehow, for
> development or experimentation purposes, but that is a separate issue.
>
> Most of those platforms actually utilise some dynamic DTs, btw, where
> software amends the DT on the fly:
> - Highbank has a stub DT in SPI flash, and the management controller
> firmware detects the size and some extra DRAM (DIMMs!) parameters at boot
> time, and writes the /memory node accordingly.
> - RPi3/4 have DT overlay files on the SD card, and depending on what a
> user wrote in config.txt, they get applied to the DT (or not).
> - Even for the Allwinner H616 we amend the OF_SEPARATE provided DT copy in
> DRAM in TF-A, to carve out the DRAM region TF-A occupies.
> - QEMU is the obvious example, where the whole machine is highly dynamic,
> and there is no such thing as a fixed DT (how many cores?, how much
> memory?, how many virtio devices?, flash?, SCSI?)
>
> > I believe we have got unstuck because OF_BOARD (perhaps inadvertently)
> > provided a way to entirely omit a devicetree from U-Boot, thus making
> > things like binman and U-Boot /config impossible, for example.
>
> I have the feeling this is because we abuse DT for this. Conceptually the
> DT is not a configuration file, but a hardware description.
+42!!!
> I see that it
> is also a nice and flexible, hierarchical key/value storage, for which we
> have code in anyway, so it makes hardcoding data in the code easier to
> avoid.
> But as we see now, this has problems as well.
>
> So shall we separate those use cases? And attach just a tree with /binman
> and /config (in DTB format), but treat this separately from the hardware
> description? (Admittedly I have still to wrap my head around why we need
> /binman at U-Boot runtime in the first place.)
+1
>
>
> Cheers,
> Andre
>
> > So I
> > want to claw that back, so there is always some sort of devicetree in
> > U-Boot, as we have for rpi_3, etc.
> >
> > Regards,
> > Simon
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 18:06 ` Simon Glass
@ 2021-10-14 18:12 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 18:12 UTC (permalink / raw)
To: Simon Glass
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded <phandle> values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give
> us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is not needed.
> >
> > If you mean that when boards are by construction providing a DTB to
> U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> >>
> >> U-Boot needs to be flexible enough to
> >> function correctly in whatever runtime environment in which it finds
> >> itself.
> >>
> >> Also as binman is pressed into service more and more to build the
> >> complex firmware images that are becoming fashionable, it needs a
> >> definition (in the devicetree) that describes how to create the image.
> >> We can't support that unless we are building a devicetree, nor can the
> >> running program access the image layout without that information.
> >>
> >> François's point about 'don't use this with any kernel' is
> >> germane...but of course I am not suggesting doing that, since OF_BOARD
> >> is, still, enabled. We already use OF_BOARD for various boards that
> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> >> (as I said in the cover letter "Most boards do provide one, but some
> >> don't."). So this series is just completing the picture by enforcing
> >> that *some sort* of devicetree is always present.
> >
> > That seems inconsistent with the OF_BOARD becomes the default.
>
> I think the key point that will get you closer to where I am on this
> issue, is that OF_BOARD needs to be a run-time option. At present it
> has build-time effects and this is quite wrong.
Doesn’t that mean that the current build system is not fully supporting
boards that do provide the DT and you try to hack your way in ? As I
replied to Tom, I could accept temporarily a void.dts containing nothing to
actually uallly pass any build problem until we properly fix the build
system.
(But no “close to real” fake dts in the dts section)
> If you go through all
> the material I have written on this I think I have motivated that very
> clearly.
>
> Another big issue is that I believe we need ONE devicetree for U-Boot,
> not two that get merged by U-Boot. Again I have gone through that in a
> lot of detail.
>
i know but a number of people do not agree with your position. U-Boot can
leverage many DTs coming from hats and capes to finalize the DT it passes
to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a
FIT section formatted as FDT for its own configuration.
>
> >>
> >>
> >> I can't quite pinpoint the patch where U-Boot started allowing the
> >> devicetree to be omitted, but if people are interested I could try a
> >> little harder. It was certainly not my intention (putting on my
> >> device-tree-maintainer hat) to go down that path and it slipped in
> >> somehow in all the confusion. I'm not sure anyone could tell you that
> >> rpi_3 has an in-tree devicetree but rpi_4 does not...
> >>
> >> Anyway this series is very modest. It just adds the requirement that
> >> all in-tree boards have some sort of sample devicetree and preferably
> >> some documentation as to where it might come from at runtime.
> >
> > That’s a very good goal. But adding files in dts make them not samples
> but templates to be used and replace board provided DTB.
> > If you push all your DTS files in documentation, you do what you say:
> adding sample files.
> >>
> >> That
> >> should not be a tough call IMO. Assuming we can get the validation in
> >> place (mentioned by Rob Herring recently) it will be quite natural to
> >> sync them between (presumably) Linux and U-Boot.
> >>
> >> I am also quite happy to discuss what should actually be in these
> >> devicetree files and whether some of them should be essentially empty.
> >> As you probably noticed, some of them are empty since I literally
> >> could not figure out where they come from! But there needs to be at
> >> least some skeleton for U-Boot to progress, since devicetree is
> >> critical to its feature set.
> >
> > absolutely. And thank you for your efforts to make that center stage.
> This is also Linaro Edge group mist challenging task on the next 6 moths.
> Knowing that we have lived in a floating situation for over 10 years, I
> just hope we get consensus across projects and distro providers about the
> right end goal and migration strategy.
> >>
>
> Thank you.
>
> >>
> >>
> >> It is high time we tidied all this up. I predict it will be much
> >> harder, and much more confusing, in 6 months.
>
> Just to set a road map here in case you can help unblock anything,
> here are the things I am aware of, excluding the things I have
> forgotten:
>
> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
> - this series
> - the devicetree docs patch
> - devicetree bindings upstream for U-Boot (first patch under discussion)
> - bloblist as a means of passing devicetree, ACPI, tiny config info as
the “ABI” of U-Boot entry need more specification. Having something close
to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we
could start from here. The blob list may be an extra arg (x0=DTB,
x1=bloblist in Arm).
>
> C structs to U-Boot (needs to be written)
> - VPL so we can handle verification (patches pending)
> - bootflow / VBE v2 series (coming next week)
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 18:12 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-14 18:12 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 10694 bytes --]
Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit :
> Hi François,
>
> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org>
> wrote:
> >
> > Hi Simon
> >
> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
> >>
> >> Hi Tom, Bin,François,
> >>
> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
> >> >
> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
> >> > > Hi Simon,
> >> > >
> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org>
> wrote:
> >> > > >
> >> > > > 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 at [1].
> >> > > >
> >> > > > 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.
> >> > >
> >> > > Adding device trees that are never used sounds like a hack to me.
> >> > >
> >> > > For QEMU, device tree is dynamically generated on the fly based on
> >> > > command line parameters, and the device tree you put in this series
> >> > > has various hardcoded <phandle> values which normally do not show up
> >> > > in hand-written dts files.
> >> > >
> >> > > I am not sure I understand the whole point of this.
> >> >
> >> > I am also confused and do not like the idea of adding device trees for
> >> > platforms that are capable of and can / do have a device tree to give
> us
> >> > at run time.
> >>
> >> (I'll just reply to this one email, since the same points applies to
> >> all replies I think)
> >>
> >> I have been thinking about this and discussing it with people for a
> >> few months now. I've been signalling a change like this for over a
> >> month now, on U-Boot contributor calls and in discussions with Linaro
> >> people. I sent a patch (below) to try to explain things. I hope it is
> >> not a surprise!
> >>
> >> The issue here is that we need a devicetree in-tree in U-Boot, to
> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
> >> Ilias' series and this one we can get ourselves on a stronger footing.
> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
> >> For more context:
> >>
> >>
> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >> BTW I did suggest to QEMU ARM that they support a way of adding the
> >> u-boot.dtsi but there was not much interest there (in fact the
> >> maintainer would prefer there was no special support even for booting
> >> Linux directly!)
> >
> > i understand their point of view and agree with it.
> >>
> >> But in any case it doesn't really help U-Boot. I
> >> think the path forward might be to run QEMU twice, once to get its
> >> generated tree and once to give the 'merged' tree with the U-Boot
> >> properties in it, if people want to use U-Boot features.
> >>
> >> I do strongly believe that OF_BOARD must be a run-time option, not a
> >> build-time one. It creates all sorts of problems and obscurity which
> >> have taken months to unpick. See the above patch for the rationale.
> >>
> >> To add to that rationale, OF_BOARD needs to be an option available to
> >> any board. At some point in the future it may become a common way
> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
> >> to it. It doesn't make any sense to have people decide whether or not
> >> to set OF_BOARD at build time, thus affecting how the image is put
> >> together. We'll end up with different U-Boot build targets like
> >> capricorn, capricorn_of_board and the like. It should be obvious where
> >> that will lead. Instead, OF_BOARD needs to become a commonly used
> >> option, perhaps enabled by most/all boards, so that this sort of build
> >> explosion is not needed.
> >
> > If you mean that when boards are by construction providing a DTB to
> U-Boot then I agree very much. But I don’t understand how the patch set
> supports it as it puts dts files for those boards to be built.
> >>
> >> U-Boot needs to be flexible enough to
> >> function correctly in whatever runtime environment in which it finds
> >> itself.
> >>
> >> Also as binman is pressed into service more and more to build the
> >> complex firmware images that are becoming fashionable, it needs a
> >> definition (in the devicetree) that describes how to create the image.
> >> We can't support that unless we are building a devicetree, nor can the
> >> running program access the image layout without that information.
> >>
> >> François's point about 'don't use this with any kernel' is
> >> germane...but of course I am not suggesting doing that, since OF_BOARD
> >> is, still, enabled. We already use OF_BOARD for various boards that
> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
> >> (as I said in the cover letter "Most boards do provide one, but some
> >> don't."). So this series is just completing the picture by enforcing
> >> that *some sort* of devicetree is always present.
> >
> > That seems inconsistent with the OF_BOARD becomes the default.
>
> I think the key point that will get you closer to where I am on this
> issue, is that OF_BOARD needs to be a run-time option. At present it
> has build-time effects and this is quite wrong.
Doesn’t that mean that the current build system is not fully supporting
boards that do provide the DT and you try to hack your way in ? As I
replied to Tom, I could accept temporarily a void.dts containing nothing to
actually uallly pass any build problem until we properly fix the build
system.
(But no “close to real” fake dts in the dts section)
> If you go through all
> the material I have written on this I think I have motivated that very
> clearly.
>
> Another big issue is that I believe we need ONE devicetree for U-Boot,
> not two that get merged by U-Boot. Again I have gone through that in a
> lot of detail.
>
i know but a number of people do not agree with your position. U-Boot can
leverage many DTs coming from hats and capes to finalize the DT it passes
to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a
FIT section formatted as FDT for its own configuration.
>
> >>
> >>
> >> I can't quite pinpoint the patch where U-Boot started allowing the
> >> devicetree to be omitted, but if people are interested I could try a
> >> little harder. It was certainly not my intention (putting on my
> >> device-tree-maintainer hat) to go down that path and it slipped in
> >> somehow in all the confusion. I'm not sure anyone could tell you that
> >> rpi_3 has an in-tree devicetree but rpi_4 does not...
> >>
> >> Anyway this series is very modest. It just adds the requirement that
> >> all in-tree boards have some sort of sample devicetree and preferably
> >> some documentation as to where it might come from at runtime.
> >
> > That’s a very good goal. But adding files in dts make them not samples
> but templates to be used and replace board provided DTB.
> > If you push all your DTS files in documentation, you do what you say:
> adding sample files.
> >>
> >> That
> >> should not be a tough call IMO. Assuming we can get the validation in
> >> place (mentioned by Rob Herring recently) it will be quite natural to
> >> sync them between (presumably) Linux and U-Boot.
> >>
> >> I am also quite happy to discuss what should actually be in these
> >> devicetree files and whether some of them should be essentially empty.
> >> As you probably noticed, some of them are empty since I literally
> >> could not figure out where they come from! But there needs to be at
> >> least some skeleton for U-Boot to progress, since devicetree is
> >> critical to its feature set.
> >
> > absolutely. And thank you for your efforts to make that center stage.
> This is also Linaro Edge group mist challenging task on the next 6 moths.
> Knowing that we have lived in a floating situation for over 10 years, I
> just hope we get consensus across projects and distro providers about the
> right end goal and migration strategy.
> >>
>
> Thank you.
>
> >>
> >>
> >> It is high time we tidied all this up. I predict it will be much
> >> harder, and much more confusing, in 6 months.
>
> Just to set a road map here in case you can help unblock anything,
> here are the things I am aware of, excluding the things I have
> forgotten:
>
> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
> - this series
> - the devicetree docs patch
> - devicetree bindings upstream for U-Boot (first patch under discussion)
> - bloblist as a means of passing devicetree, ACPI, tiny config info as
the “ABI” of U-Boot entry need more specification. Having something close
to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we
could start from here. The blob list may be an extra arg (x0=DTB,
x1=bloblist in Arm).
>
> C structs to U-Boot (needs to be written)
> - VPL so we can handle verification (patches pending)
> - bootflow / VBE v2 series (coming next week)
>
> Regards,
> Simon
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 14786 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-14 18:12 ` François Ozog
@ 2021-10-14 21:00 ` Simon Glass
-1 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-14 21:00 UTC (permalink / raw)
To: François Ozog
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi François,
On Thu, 14 Oct 2021 at 12:13, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi Tom, Bin,François,
>> >>
>> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>> >> >
>> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> >> > > Hi Simon,
>> >> > >
>> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>> >> > > >
>> >> > > > 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 at [1].
>> >> > > >
>> >> > > > 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.
>> >> > >
>> >> > > Adding device trees that are never used sounds like a hack to me.
>> >> > >
>> >> > > For QEMU, device tree is dynamically generated on the fly based on
>> >> > > command line parameters, and the device tree you put in this series
>> >> > > has various hardcoded <phandle> values which normally do not show up
>> >> > > in hand-written dts files.
>> >> > >
>> >> > > I am not sure I understand the whole point of this.
>> >> >
>> >> > I am also confused and do not like the idea of adding device trees for
>> >> > platforms that are capable of and can / do have a device tree to give us
>> >> > at run time.
>> >>
>> >> (I'll just reply to this one email, since the same points applies to
>> >> all replies I think)
>> >>
>> >> I have been thinking about this and discussing it with people for a
>> >> few months now. I've been signalling a change like this for over a
>> >> month now, on U-Boot contributor calls and in discussions with Linaro
>> >> people. I sent a patch (below) to try to explain things. I hope it is
>> >> not a surprise!
>> >>
>> >> The issue here is that we need a devicetree in-tree in U-Boot, to
>> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> >> Ilias' series and this one we can get ourselves on a stronger footing.
>> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> >> For more context:
>> >>
>> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>> >>
>> >> BTW I did suggest to QEMU ARM that they support a way of adding the
>> >> u-boot.dtsi but there was not much interest there (in fact the
>> >> maintainer would prefer there was no special support even for booting
>> >> Linux directly!)
>> >
>> > i understand their point of view and agree with it.
>> >>
>> >> But in any case it doesn't really help U-Boot. I
>> >> think the path forward might be to run QEMU twice, once to get its
>> >> generated tree and once to give the 'merged' tree with the U-Boot
>> >> properties in it, if people want to use U-Boot features.
>> >>
>> >> I do strongly believe that OF_BOARD must be a run-time option, not a
>> >> build-time one. It creates all sorts of problems and obscurity which
>> >> have taken months to unpick. See the above patch for the rationale.
>> >>
>> >> To add to that rationale, OF_BOARD needs to be an option available to
>> >> any board. At some point in the future it may become a common way
>> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> >> to it. It doesn't make any sense to have people decide whether or not
>> >> to set OF_BOARD at build time, thus affecting how the image is put
>> >> together. We'll end up with different U-Boot build targets like
>> >> capricorn, capricorn_of_board and the like. It should be obvious where
>> >> that will lead. Instead, OF_BOARD needs to become a commonly used
>> >> option, perhaps enabled by most/all boards, so that this sort of build
>> >> explosion is not needed.
>> >
>> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
>> >>
>> >> U-Boot needs to be flexible enough to
>> >> function correctly in whatever runtime environment in which it finds
>> >> itself.
>> >>
>> >> Also as binman is pressed into service more and more to build the
>> >> complex firmware images that are becoming fashionable, it needs a
>> >> definition (in the devicetree) that describes how to create the image.
>> >> We can't support that unless we are building a devicetree, nor can the
>> >> running program access the image layout without that information.
>> >>
>> >> François's point about 'don't use this with any kernel' is
>> >> germane...but of course I am not suggesting doing that, since OF_BOARD
>> >> is, still, enabled. We already use OF_BOARD for various boards that
>> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
>> >> (as I said in the cover letter "Most boards do provide one, but some
>> >> don't."). So this series is just completing the picture by enforcing
>> >> that *some sort* of devicetree is always present.
>> >
>> > That seems inconsistent with the OF_BOARD becomes the default.
>>
>> I think the key point that will get you closer to where I am on this
>> issue, is that OF_BOARD needs to be a run-time option. At present it
>> has build-time effects and this is quite wrong.
>
> Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system.
> (But no “close to real” fake dts in the dts section)
Can you rephrase that paragraph, particularly the first setence? I am
not sure what you are getting at.
>>
>> If you go through all
>> the material I have written on this I think I have motivated that very
>> clearly.
>>
>> Another big issue is that I believe we need ONE devicetree for U-Boot,
>> not two that get merged by U-Boot. Again I have gone through that in a
>> lot of detail.
>
> i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration.
Perhaps it wasn't clear from the context, but I was talking about the
devicetree for U-Boot, i.e. the control DTB for U-Boot. It's fine to
merge overlays, etc. to pass to Linux, of course.
>>
>>
>> >>
>> >>
>> >> I can't quite pinpoint the patch where U-Boot started allowing the
>> >> devicetree to be omitted, but if people are interested I could try a
>> >> little harder. It was certainly not my intention (putting on my
>> >> device-tree-maintainer hat) to go down that path and it slipped in
>> >> somehow in all the confusion. I'm not sure anyone could tell you that
>> >> rpi_3 has an in-tree devicetree but rpi_4 does not...
>> >>
>> >> Anyway this series is very modest. It just adds the requirement that
>> >> all in-tree boards have some sort of sample devicetree and preferably
>> >> some documentation as to where it might come from at runtime.
>> >
>> > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB.
>> > If you push all your DTS files in documentation, you do what you say: adding sample files.
>> >>
>> >> That
>> >> should not be a tough call IMO. Assuming we can get the validation in
>> >> place (mentioned by Rob Herring recently) it will be quite natural to
>> >> sync them between (presumably) Linux and U-Boot.
>> >>
>> >> I am also quite happy to discuss what should actually be in these
>> >> devicetree files and whether some of them should be essentially empty.
>> >> As you probably noticed, some of them are empty since I literally
>> >> could not figure out where they come from! But there needs to be at
>> >> least some skeleton for U-Boot to progress, since devicetree is
>> >> critical to its feature set.
>> >
>> > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy.
>> >>
>>
>> Thank you.
>>
>> >>
>> >>
>> >> It is high time we tidied all this up. I predict it will be much
>> >> harder, and much more confusing, in 6 months.
>>
>> Just to set a road map here in case you can help unblock anything,
>> here are the things I am aware of, excluding the things I have
>> forgotten:
>>
>> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
>> - this series
>> - the devicetree docs patch
>> - devicetree bindings upstream for U-Boot (first patch under discussion)
>> - bloblist as a means of passing devicetree, ACPI, tiny config info as
>
> the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm).
Yes that's my intent, hopefully in a few weeks.
>>
>>
>> C structs to U-Boot (needs to be written)
>> - VPL so we can handle verification (patches pending)
>> - bootflow / VBE v2 series (coming next week)
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-14 21:00 ` Simon Glass
0 siblings, 0 replies; 164+ messages in thread
From: Simon Glass @ 2021-10-14 21:00 UTC (permalink / raw)
To: François Ozog
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Sinan Akman, Stefan Roese, Stephen Warren, Stephen Warren,
T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons, Tianrui Wei,
Tim Harvey, Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel@nongnu.org Developers
Hi François,
On Thu, 14 Oct 2021 at 12:13, François Ozog <francois.ozog@linaro.org> wrote:
>
>
>
> Le mer. 13 oct. 2021 à 20:06, Simon Glass <sjg@chromium.org> a écrit :
>>
>> Hi François,
>>
>> On Wed, 13 Oct 2021 at 11:35, François Ozog <francois.ozog@linaro.org> wrote:
>> >
>> > Hi Simon
>> >
>> > Le mer. 13 oct. 2021 à 16:49, Simon Glass <sjg@chromium.org> a écrit :
>> >>
>> >> Hi Tom, Bin,François,
>> >>
>> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini <trini@konsulko.com> wrote:
>> >> >
>> >> > On Wed, Oct 13, 2021 at 09:29:14AM +0800, Bin Meng wrote:
>> >> > > Hi Simon,
>> >> > >
>> >> > > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>> >> > > >
>> >> > > > 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 at [1].
>> >> > > >
>> >> > > > 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.
>> >> > >
>> >> > > Adding device trees that are never used sounds like a hack to me.
>> >> > >
>> >> > > For QEMU, device tree is dynamically generated on the fly based on
>> >> > > command line parameters, and the device tree you put in this series
>> >> > > has various hardcoded <phandle> values which normally do not show up
>> >> > > in hand-written dts files.
>> >> > >
>> >> > > I am not sure I understand the whole point of this.
>> >> >
>> >> > I am also confused and do not like the idea of adding device trees for
>> >> > platforms that are capable of and can / do have a device tree to give us
>> >> > at run time.
>> >>
>> >> (I'll just reply to this one email, since the same points applies to
>> >> all replies I think)
>> >>
>> >> I have been thinking about this and discussing it with people for a
>> >> few months now. I've been signalling a change like this for over a
>> >> month now, on U-Boot contributor calls and in discussions with Linaro
>> >> people. I sent a patch (below) to try to explain things. I hope it is
>> >> not a surprise!
>> >>
>> >> The issue here is that we need a devicetree in-tree in U-Boot, to
>> >> avoid the mess that has been created by OF_PRIOR_STAGE, OF_BOARD,
>> >> BINMAN_STANDALONE_FDT and to a lesser extent, OF_HOSTFILE. Between
>> >> Ilias' series and this one we can get ourselves on a stronger footing.
>> >> There is just OF_SEPARATE, with OF_EMBED for debugging/ELF use.
>> >> For more context:
>> >>
>> >> http://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>> >>
>> >> BTW I did suggest to QEMU ARM that they support a way of adding the
>> >> u-boot.dtsi but there was not much interest there (in fact the
>> >> maintainer would prefer there was no special support even for booting
>> >> Linux directly!)
>> >
>> > i understand their point of view and agree with it.
>> >>
>> >> But in any case it doesn't really help U-Boot. I
>> >> think the path forward might be to run QEMU twice, once to get its
>> >> generated tree and once to give the 'merged' tree with the U-Boot
>> >> properties in it, if people want to use U-Boot features.
>> >>
>> >> I do strongly believe that OF_BOARD must be a run-time option, not a
>> >> build-time one. It creates all sorts of problems and obscurity which
>> >> have taken months to unpick. See the above patch for the rationale.
>> >>
>> >> To add to that rationale, OF_BOARD needs to be an option available to
>> >> any board. At some point in the future it may become a common way
>> >> things are done, e.g. TF-A calling U-Boot and providing a devicetree
>> >> to it. It doesn't make any sense to have people decide whether or not
>> >> to set OF_BOARD at build time, thus affecting how the image is put
>> >> together. We'll end up with different U-Boot build targets like
>> >> capricorn, capricorn_of_board and the like. It should be obvious where
>> >> that will lead. Instead, OF_BOARD needs to become a commonly used
>> >> option, perhaps enabled by most/all boards, so that this sort of build
>> >> explosion is not needed.
>> >
>> > If you mean that when boards are by construction providing a DTB to U-Boot then I agree very much. But I don’t understand how the patch set supports it as it puts dts files for those boards to be built.
>> >>
>> >> U-Boot needs to be flexible enough to
>> >> function correctly in whatever runtime environment in which it finds
>> >> itself.
>> >>
>> >> Also as binman is pressed into service more and more to build the
>> >> complex firmware images that are becoming fashionable, it needs a
>> >> definition (in the devicetree) that describes how to create the image.
>> >> We can't support that unless we are building a devicetree, nor can the
>> >> running program access the image layout without that information.
>> >>
>> >> François's point about 'don't use this with any kernel' is
>> >> germane...but of course I am not suggesting doing that, since OF_BOARD
>> >> is, still, enabled. We already use OF_BOARD for various boards that
>> >> include an in-tree devicetree - Raspberry Pi 1, 2 and 3, for example
>> >> (as I said in the cover letter "Most boards do provide one, but some
>> >> don't."). So this series is just completing the picture by enforcing
>> >> that *some sort* of devicetree is always present.
>> >
>> > That seems inconsistent with the OF_BOARD becomes the default.
>>
>> I think the key point that will get you closer to where I am on this
>> issue, is that OF_BOARD needs to be a run-time option. At present it
>> has build-time effects and this is quite wrong.
>
> Doesn’t that mean that the current build system is not fully supporting boards that do provide the DT and you try to hack your way in ? As I replied to Tom, I could accept temporarily a void.dts containing nothing to actually uallly pass any build problem until we properly fix the build system.
> (But no “close to real” fake dts in the dts section)
Can you rephrase that paragraph, particularly the first setence? I am
not sure what you are getting at.
>>
>> If you go through all
>> the material I have written on this I think I have motivated that very
>> clearly.
>>
>> Another big issue is that I believe we need ONE devicetree for U-Boot,
>> not two that get merged by U-Boot. Again I have gone through that in a
>> lot of detail.
>
> i know but a number of people do not agree with your position. U-Boot can leverage many DTs coming from hats and capes to finalize the DT it passes to OS. It can also leverage a file, a FIP section (NT_FW_CONFIG in TFA) a FIT section formatted as FDT for its own configuration.
Perhaps it wasn't clear from the context, but I was talking about the
devicetree for U-Boot, i.e. the control DTB for U-Boot. It's fine to
merge overlays, etc. to pass to Linux, of course.
>>
>>
>> >>
>> >>
>> >> I can't quite pinpoint the patch where U-Boot started allowing the
>> >> devicetree to be omitted, but if people are interested I could try a
>> >> little harder. It was certainly not my intention (putting on my
>> >> device-tree-maintainer hat) to go down that path and it slipped in
>> >> somehow in all the confusion. I'm not sure anyone could tell you that
>> >> rpi_3 has an in-tree devicetree but rpi_4 does not...
>> >>
>> >> Anyway this series is very modest. It just adds the requirement that
>> >> all in-tree boards have some sort of sample devicetree and preferably
>> >> some documentation as to where it might come from at runtime.
>> >
>> > That’s a very good goal. But adding files in dts make them not samples but templates to be used and replace board provided DTB.
>> > If you push all your DTS files in documentation, you do what you say: adding sample files.
>> >>
>> >> That
>> >> should not be a tough call IMO. Assuming we can get the validation in
>> >> place (mentioned by Rob Herring recently) it will be quite natural to
>> >> sync them between (presumably) Linux and U-Boot.
>> >>
>> >> I am also quite happy to discuss what should actually be in these
>> >> devicetree files and whether some of them should be essentially empty.
>> >> As you probably noticed, some of them are empty since I literally
>> >> could not figure out where they come from! But there needs to be at
>> >> least some skeleton for U-Boot to progress, since devicetree is
>> >> critical to its feature set.
>> >
>> > absolutely. And thank you for your efforts to make that center stage. This is also Linaro Edge group mist challenging task on the next 6 moths. Knowing that we have lived in a floating situation for over 10 years, I just hope we get consensus across projects and distro providers about the right end goal and migration strategy.
>> >>
>>
>> Thank you.
>>
>> >>
>> >>
>> >> It is high time we tidied all this up. I predict it will be much
>> >> harder, and much more confusing, in 6 months.
>>
>> Just to set a road map here in case you can help unblock anything,
>> here are the things I am aware of, excluding the things I have
>> forgotten:
>>
>> - Ilias OF_PRIOR_STAGE, OF_HOSTFILE series
>> - this series
>> - the devicetree docs patch
>> - devicetree bindings upstream for U-Boot (first patch under discussion)
>> - bloblist as a means of passing devicetree, ACPI, tiny config info as
>
> the “ABI” of U-Boot entry need more specification. Having something close to Linux helped to get U-Boot in the RPI4 and other boards I believe. So we could start from here. The blob list may be an extra arg (x0=DTB, x1=bloblist in Arm).
Yes that's my intent, hopefully in a few weeks.
>>
>>
>> C structs to U-Boot (needs to be written)
>> - VPL so we can handle verification (patches pending)
>> - bootflow / VBE v2 series (coming next week)
Regards,
Simon
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:29 ` Bin Meng
@ 2021-10-13 12:39 ` Philippe Mathieu-Daudé
-1 siblings, 0 replies; 164+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-10-13 12:39 UTC (permalink / raw)
To: Bin Meng, Simon Glass, qemu-arm
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List,
Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
Atish Patra, David Abdurachmanov, Priyanka Jain,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei,
Pali Rohár, Dimitri John Ledkov, Padmarao Begari
Hi Simon,
On 10/13/21 03:29, Bin Meng wrote:
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>>
>> 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 at [1].
>>
>> 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.
>
> Adding device trees that are never used sounds like a hack to me.
>
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded <phandle> values which normally do not show up
> in hand-written dts files.
Besides, QEMU generates these dtb at runtime on purpose: it gives
emulated machines the freedom to evolve by adding new devices,
mapping/wiring peripherals differently.
By adding static dtb this gives QEMU users false expectations the
machine hardware is stable, or force QEMU to have this interface
become a stable API.
From QEMU perspective this seems counter-productive.
Digging a bit I see this has already been discussed on qemu-devel@
mailing list recently:
https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/
> I am not sure I understand the whole point of this.
>
>>
>> It also provides a few qemu clean-ups discovered along the way.
>>
>> This series is based on Ilias' two series for OF_HOSTFILE and
>> OF_PRIOR_STAGE removal.
>>
>> It is available at u-boot-dm/ofb-working
>>
>> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>>
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 12:39 ` Philippe Mathieu-Daudé
0 siblings, 0 replies; 164+ messages in thread
From: Philippe Mathieu-Daudé @ 2021-10-13 12:39 UTC (permalink / raw)
To: Bin Meng, Simon Glass, qemu-arm
Cc: Liviu Dudau, Neil Armstrong, Rick Chen, Vladimir Oltean,
Linus Walleij, Bin Meng, Kever Yang, Sean Anderson,
U-Boot Mailing List, Zong Li, Stefan Roese, Fabio Estevam,
Rainer Boschung, Tom Rini, Stephen Warren,
Oleksandr Andrushchenko, Green Wan, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Heiko Schocher, Peter Robinson,
Anastasiia Lukianenko, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, Andre Przywara, Tim Harvey, Ashok Reddy Soma,
qemu-devel@nongnu.org Developers, Alexander Graf,
Valentin Longchamp, T Karthik Reddy, Sinan Akman, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo, Atish Patra,
David Abdurachmanov, Priyanka Jain, Ilias Apalodimas,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
Hi Simon,
On 10/13/21 03:29, Bin Meng wrote:
> On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
>>
>> 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 at [1].
>>
>> 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.
>
> Adding device trees that are never used sounds like a hack to me.
>
> For QEMU, device tree is dynamically generated on the fly based on
> command line parameters, and the device tree you put in this series
> has various hardcoded <phandle> values which normally do not show up
> in hand-written dts files.
Besides, QEMU generates these dtb at runtime on purpose: it gives
emulated machines the freedom to evolve by adding new devices,
mapping/wiring peripherals differently.
By adding static dtb this gives QEMU users false expectations the
machine hardware is stable, or force QEMU to have this interface
become a stable API.
From QEMU perspective this seems counter-productive.
Digging a bit I see this has already been discussed on qemu-devel@
mailing list recently:
https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/
> I am not sure I understand the whole point of this.
>
>>
>> It also provides a few qemu clean-ups discovered along the way.
>>
>> This series is based on Ilias' two series for OF_HOSTFILE and
>> OF_PRIOR_STAGE removal.
>>
>> It is available at u-boot-dm/ofb-working
>>
>> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>>
>
> Regards,
> Bin
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 12:39 ` Philippe Mathieu-Daudé
@ 2021-10-13 13:06 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Ilias Apalodimas, Jagan Teki,
Jerry Van Baren, Kever Yang, Leo, Linus Walleij, Liviu Dudau,
Marek Behún, Matthias Brugger, Michal Simek, Michal Simek,
Neil Armstrong, Niel Fourie, Oleksandr Andrushchenko,
Padmarao Begari, Pali Rohár, Peter Robinson, Priyanka Jain,
Rainer Boschung, Ramon Fried, Rick Chen, Sean Anderson,
Simon Glass, Sinan Akman, Stefan Roese, Stephen Warren,
Stephen Warren, T Karthik Reddy, Tero Kristo, Thomas Fitzsimmons,
Tianrui Wei, Tim Harvey, Tom Rini, Tuomas Tynkkynen,
U-Boot Mailing List, Valentin Longchamp, Vladimir Oltean,
Wolfgang Denk, Zong Li, qemu-arm,
qemu-devel@nongnu.org Developers
Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé <philmd@redhat.com> a
écrit :
> Hi Simon,
>
> On 10/13/21 03:29, Bin Meng wrote:
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >>
> >> 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 at [1].
> >>
> >> 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
>
> Besides, QEMU generates these dtb at runtime on purpose: it gives
> emulated machines the freedom to evolve by adding new devices,
> mapping/wiring peripherals differently.
>
> By adding static dtb this gives QEMU users false expectations the
> machine hardware is stable, or force QEMU to have this interface
> become a stable API.
>
> From QEMU perspective this seems counter-productive.
>
+1
>
> Digging a bit I see this has already been discussed on qemu-devel@
> mailing list recently:
>
>
> https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/
>
> > I am not sure I understand the whole point of this.
> >
> >>
> >> It also provides a few qemu clean-ups discovered along the way.
> >>
> >> This series is based on Ilias' two series for OF_HOSTFILE and
> >> OF_PRIOR_STAGE removal.
> >>
> >> It is available at u-boot-dm/ofb-working
> >>
> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >
> > Regards,
> > Bin
> >
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 13:06 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw)
To: Philippe Mathieu-Daudé
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel@nongnu.org Developers, Andre Przywara,
Tim Harvey, Ashok Reddy Soma, Rick Chen, Alexander Graf,
Green Wan, T Karthik Reddy, Anastasiia Lukianenko,
Albert Aribaud, Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, qemu-arm, Heinrich Schuchardt, Tianrui Wei,
Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 3143 bytes --]
Le mer. 13 oct. 2021 à 14:42, Philippe Mathieu-Daudé <philmd@redhat.com> a
écrit :
> Hi Simon,
>
> On 10/13/21 03:29, Bin Meng wrote:
> > On Wed, Oct 13, 2021 at 9:01 AM Simon Glass <sjg@chromium.org> wrote:
> >>
> >> 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 at [1].
> >>
> >> 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.
> >
> > Adding device trees that are never used sounds like a hack to me.
> >
> > For QEMU, device tree is dynamically generated on the fly based on
> > command line parameters, and the device tree you put in this series
> > has various hardcoded <phandle> values which normally do not show up
> > in hand-written dts files.
>
> Besides, QEMU generates these dtb at runtime on purpose: it gives
> emulated machines the freedom to evolve by adding new devices,
> mapping/wiring peripherals differently.
>
> By adding static dtb this gives QEMU users false expectations the
> machine hardware is stable, or force QEMU to have this interface
> become a stable API.
>
> From QEMU perspective this seems counter-productive.
>
+1
>
> Digging a bit I see this has already been discussed on qemu-devel@
> mailing list recently:
>
>
> https://lore.kernel.org/qemu-devel/CAFEAcA_QNcAHtdxUPLpmyzMYgb9YzhcE0-zyh=N8rqm4vOcGZA@mail.gmail.com/
>
> > I am not sure I understand the whole point of this.
> >
> >>
> >> It also provides a few qemu clean-ups discovered along the way.
> >>
> >> This series is based on Ilias' two series for OF_HOSTFILE and
> >> OF_PRIOR_STAGE removal.
> >>
> >> It is available at u-boot-dm/ofb-working
> >>
> >> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >>
> >
> > Regards,
> > Bin
> >
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 5718 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 4:26 ` Heinrich Schuchardt
-1 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-13 4:26 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
David Abdurachmanov, Priyanka Jain, Ilias Apalodimas,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen, Tianrui Wei,
Bin Meng, Pali Rohár, Dimitri John Ledkov, Padmarao Begari
On 10/13/21 03:01, Simon Glass wrote:
> 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 at [1].
>
> 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.
Why should we add dummy files with irrelevant content (see patch 06/16)
to make the build work? Why don't you fix the Makefile instead?
Best regards
Heinrich
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
>
> Simon Glass (16):
> arm: qemu: Mention -nographic in the docs
> arm: qemu: Explain how to extract the generate devicetree
> riscv: qemu: Explain how to extract the generate devicetree
> 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
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 1 +
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 19 +-
> doc/board/emulation/qemu-riscv.rst | 12 +
> dts/Kconfig | 27 +-
> tools/binman/binman.rst | 20 -
> 43 files changed, 4922 insertions(+), 61 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 4:26 ` Heinrich Schuchardt
0 siblings, 0 replies; 164+ messages in thread
From: Heinrich Schuchardt @ 2021-10-13 4:26 UTC (permalink / raw)
To: Simon Glass, U-Boot Mailing List
Cc: Tom Rini, Ilias Apalodimas, Aaron Williams, Albert Aribaud,
Alexander Graf, Anastasiia Lukianenko, Andre Przywara,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Jagan Teki, Jerry Van Baren, Kever Yang, Leo, Linus Walleij,
Liviu Dudau, Marek Behún, Matthias Brugger, Michal Simek,
Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel
On 10/13/21 03:01, Simon Glass wrote:
> 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 at [1].
>
> 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.
Why should we add dummy files with irrelevant content (see patch 06/16)
to make the build work? Why don't you fix the Makefile instead?
Best regards
Heinrich
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
>
> Simon Glass (16):
> arm: qemu: Mention -nographic in the docs
> arm: qemu: Explain how to extract the generate devicetree
> riscv: qemu: Explain how to extract the generate devicetree
> 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
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 1 +
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 19 +-
> doc/board/emulation/qemu-riscv.rst | 12 +
> dts/Kconfig | 27 +-
> tools/binman/binman.rst | 20 -
> 43 files changed, 4922 insertions(+), 61 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 4:26 ` Heinrich Schuchardt
@ 2021-10-13 13:06 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Andre Przywara, Ashok Reddy Soma,
Atish Patra, Bin Meng, Bin Meng, Christian Hewitt,
David Abdurachmanov, Dimitri John Ledkov, Fabio Estevam,
Green Wan, Heiko Schocher, Heinrich Schuchardt, Ilias Apalodimas,
Jagan Teki, Jerry Van Baren, Kever Yang, Leo, Linus Walleij,
Liviu Dudau, Marek Behún, Matthias Brugger, Michal Simek,
Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Sean Anderson, Simon Glass, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tom Rini,
Tuomas Tynkkynen, U-Boot Mailing List, Valentin Longchamp,
Vladimir Oltean, Wolfgang Denk, Zong Li, qemu-devel
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt <
heinrich.schuchardt@canonical.com> a écrit :
>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > 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 at [1].
> >
> > 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.
>
> Why should we add dummy files with irrelevant content (see patch 06/16)
> to make the build work? Why don't you fix the Makefile instead?
>
+1
>
> Best regards
>
> Heinrich
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> > arm: qemu: Mention -nographic in the docs
> > arm: qemu: Explain how to extract the generate devicetree
> > riscv: qemu: Explain how to extract the generate devicetree
> > 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
> >
> > Makefile | 3 +-
> > arch/arm/dts/Makefile | 20 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> > arch/arm/dts/bcm7xxx.dts | 15 +
> > arch/arm/dts/highbank.dts | 14 +
> > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> > arch/arm/dts/octeontx.dts | 14 +
> > arch/arm/dts/qemu-arm.dts | 402 +++++
> > arch/arm/dts/qemu-arm64.dts | 381 +++++
> > arch/arm/dts/xenguest-arm64.dts | 15 +
> > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> > arch/powerpc/dts/Makefile | 1 +
> > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> > arch/riscv/dts/Makefile | 2 +-
> > arch/riscv/dts/qemu-virt.dts | 8 -
> > arch/riscv/dts/qemu-virt32.dts | 217 +++
> > arch/riscv/dts/qemu-virt64.dts | 217 +++
> > configs/bcm7260_defconfig | 1 +
> > configs/bcm7445_defconfig | 1 +
> > configs/highbank_defconfig | 2 +-
> > configs/octeontx2_95xx_defconfig | 1 +
> > configs/octeontx2_96xx_defconfig | 1 +
> > configs/octeontx_81xx_defconfig | 1 +
> > configs/octeontx_83xx_defconfig | 1 +
> > configs/qemu-ppce500_defconfig | 2 +
> > configs/qemu-riscv32_defconfig | 1 +
> > configs/qemu-riscv32_smode_defconfig | 1 +
> > configs/qemu-riscv32_spl_defconfig | 4 +-
> > configs/qemu-riscv64_defconfig | 1 +
> > configs/qemu-riscv64_smode_defconfig | 1 +
> > configs/qemu-riscv64_spl_defconfig | 3 +-
> > configs/qemu_arm64_defconfig | 1 +
> > configs/qemu_arm_defconfig | 1 +
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > configs/vexpress_aemv8a_juno_defconfig | 1 +
> > configs/xenguest_arm64_defconfig | 1 +
> > configs/xilinx_versal_virt_defconfig | 1 +
> > doc/board/emulation/qemu-arm.rst | 19 +-
> > doc/board/emulation/qemu-riscv.rst | 12 +
> > dts/Kconfig | 27 +-
> > tools/binman/binman.rst | 20 -
> > 43 files changed, 4922 insertions(+), 61 deletions(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > create mode 100644 arch/arm/dts/bcm7xxx.dts
> > create mode 100644 arch/arm/dts/highbank.dts
> > create mode 100644 arch/arm/dts/juno-r2.dts
> > create mode 100644 arch/arm/dts/octeontx.dts
> > create mode 100644 arch/arm/dts/qemu-arm.dts
> > create mode 100644 arch/arm/dts/qemu-arm64.dts
> > create mode 100644 arch/arm/dts/xenguest-arm64.dts
> > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> > delete mode 100644 arch/riscv/dts/qemu-virt.dts
> > create mode 100644 arch/riscv/dts/qemu-virt32.dts
> > create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 13:06 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:06 UTC (permalink / raw)
To: Heinrich Schuchardt
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel, Andre Przywara, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo,
U-Boot Mailing List, David Abdurachmanov, Priyanka Jain,
Simon Glass, Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 6265 bytes --]
Le mer. 13 oct. 2021 à 14:41, Heinrich Schuchardt <
heinrich.schuchardt@canonical.com> a écrit :
>
>
> On 10/13/21 03:01, Simon Glass wrote:
> > 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 at [1].
> >
> > 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.
>
> Why should we add dummy files with irrelevant content (see patch 06/16)
> to make the build work? Why don't you fix the Makefile instead?
>
+1
>
> Best regards
>
> Heinrich
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> > arm: qemu: Mention -nographic in the docs
> > arm: qemu: Explain how to extract the generate devicetree
> > riscv: qemu: Explain how to extract the generate devicetree
> > 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
> >
> > Makefile | 3 +-
> > arch/arm/dts/Makefile | 20 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> > arch/arm/dts/bcm7xxx.dts | 15 +
> > arch/arm/dts/highbank.dts | 14 +
> > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> > arch/arm/dts/octeontx.dts | 14 +
> > arch/arm/dts/qemu-arm.dts | 402 +++++
> > arch/arm/dts/qemu-arm64.dts | 381 +++++
> > arch/arm/dts/xenguest-arm64.dts | 15 +
> > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> > arch/powerpc/dts/Makefile | 1 +
> > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> > arch/riscv/dts/Makefile | 2 +-
> > arch/riscv/dts/qemu-virt.dts | 8 -
> > arch/riscv/dts/qemu-virt32.dts | 217 +++
> > arch/riscv/dts/qemu-virt64.dts | 217 +++
> > configs/bcm7260_defconfig | 1 +
> > configs/bcm7445_defconfig | 1 +
> > configs/highbank_defconfig | 2 +-
> > configs/octeontx2_95xx_defconfig | 1 +
> > configs/octeontx2_96xx_defconfig | 1 +
> > configs/octeontx_81xx_defconfig | 1 +
> > configs/octeontx_83xx_defconfig | 1 +
> > configs/qemu-ppce500_defconfig | 2 +
> > configs/qemu-riscv32_defconfig | 1 +
> > configs/qemu-riscv32_smode_defconfig | 1 +
> > configs/qemu-riscv32_spl_defconfig | 4 +-
> > configs/qemu-riscv64_defconfig | 1 +
> > configs/qemu-riscv64_smode_defconfig | 1 +
> > configs/qemu-riscv64_spl_defconfig | 3 +-
> > configs/qemu_arm64_defconfig | 1 +
> > configs/qemu_arm_defconfig | 1 +
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > configs/vexpress_aemv8a_juno_defconfig | 1 +
> > configs/xenguest_arm64_defconfig | 1 +
> > configs/xilinx_versal_virt_defconfig | 1 +
> > doc/board/emulation/qemu-arm.rst | 19 +-
> > doc/board/emulation/qemu-riscv.rst | 12 +
> > dts/Kconfig | 27 +-
> > tools/binman/binman.rst | 20 -
> > 43 files changed, 4922 insertions(+), 61 deletions(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > create mode 100644 arch/arm/dts/bcm7xxx.dts
> > create mode 100644 arch/arm/dts/highbank.dts
> > create mode 100644 arch/arm/dts/juno-r2.dts
> > create mode 100644 arch/arm/dts/octeontx.dts
> > create mode 100644 arch/arm/dts/qemu-arm.dts
> > create mode 100644 arch/arm/dts/qemu-arm64.dts
> > create mode 100644 arch/arm/dts/xenguest-arm64.dts
> > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> > delete mode 100644 arch/riscv/dts/qemu-virt.dts
> > create mode 100644 arch/riscv/dts/qemu-virt32.dts
> > create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
--
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 9300 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 1:01 ` Simon Glass
@ 2021-10-13 9:50 ` Andre Przywara
-1 siblings, 0 replies; 164+ messages in thread
From: Andre Przywara @ 2021-10-13 9:50 UTC (permalink / raw)
To: Simon Glass
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, U-Boot Mailing List,
Zong Li, Stefan Roese, Fabio Estevam, Rainer Boschung, Tom Rini,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Rob Herring, Peter Robinson, Sinan Akman, Thomas Fitzsimmons,
Wolfgang Denk, Stephen Warren, qemu-devel, Tim Harvey,
Ashok Reddy Soma, Rick Chen, Alexander Graf, Green Wan,
T Karthik Reddy, Anastasiia Lukianenko, Albert Aribaud,
Michal Simek, Matthias Brugger, Leo, Tero Kristo, Atish Patra,
David Abdurachmanov, Priyanka Jain, Ilias Apalodimas,
Christian Hewitt, Aaron Williams, Tuomas Tynkkynen,
Heinrich Schuchardt, Tianrui Wei, Bin Meng, Pali Rohár,
Dimitri John Ledkov, Padmarao Begari
On Tue, 12 Oct 2021 19:01:04 -0600
Simon Glass <sjg@chromium.org> wrote:
Hi,
> 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 at [1].
>
> 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.
So I am possibly fine with that, but:
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.
If we just need it to make the build work, we not just have pure stub DTs,
as you do for highbank, everywhere?
Adding *some* DT files for those platforms that actually do the right
thing seems like the wrong direction to me.
Providing DTs in the source repositories of the actual consumers is more
of a bad habit that dragged on since Linux started this around 10 years
ago (for practical reasons). For *some* platforms U-Boot is the firmware
component that is in the best situation to provide the DTB (because it's
more than a mere bootloader), but for other it's just not. And this is not
even looking at really dynamic platforms like QEMU, where providing some
kind of fixed DT is just not working.
I don't get the argument that people would need to see the DT in the tree
to develop code. The DT spec and binding documentation (currently living
in the Linux kernel source tree) provide the specification to code
against, and the platform specific selection of drivers in Kconfig and
_defconfig select the drivers for the devices that people are expected to
see. Why does one need actual DT files in the tree?
I totally agree on adding more documentation, possibly *pointing* to example
DTs or giving commands on how to obtain the actual copy (-dumpdtb,
/sys/firmware/devicetree), but don't think that adding some .dts files for
platforms that don't need them is the right way.
Cheers,
Andre.
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
>
> Simon Glass (16):
> arm: qemu: Mention -nographic in the docs
> arm: qemu: Explain how to extract the generate devicetree
> riscv: qemu: Explain how to extract the generate devicetree
> 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
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 1 +
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 19 +-
> doc/board/emulation/qemu-riscv.rst | 12 +
> dts/Kconfig | 27 +-
> tools/binman/binman.rst | 20 -
> 43 files changed, 4922 insertions(+), 61 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 9:50 ` Andre Przywara
0 siblings, 0 replies; 164+ messages in thread
From: Andre Przywara @ 2021-10-13 9:50 UTC (permalink / raw)
To: Simon Glass
Cc: U-Boot Mailing List, Tom Rini, Ilias Apalodimas, Aaron Williams,
Albert Aribaud, Alexander Graf, Anastasiia Lukianenko,
Ashok Reddy Soma, Atish Patra, Bin Meng, Bin Meng,
Christian Hewitt, David Abdurachmanov, Dimitri John Ledkov,
Fabio Estevam, Green Wan, Heiko Schocher, Heinrich Schuchardt,
Heinrich Schuchardt, Jagan Teki, Jerry Van Baren, Kever Yang,
Leo, Linus Walleij, Liviu Dudau, Marek Behún,
Matthias Brugger, Michal Simek, Michal Simek, Neil Armstrong,
Niel Fourie, Oleksandr Andrushchenko, Padmarao Begari,
Pali Rohár, Peter Robinson, Priyanka Jain, Rainer Boschung,
Ramon Fried, Rick Chen, Sean Anderson, Sinan Akman, Stefan Roese,
Stephen Warren, Stephen Warren, T Karthik Reddy, Tero Kristo,
Thomas Fitzsimmons, Tianrui Wei, Tim Harvey, Tuomas Tynkkynen,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel, Rob Herring
On Tue, 12 Oct 2021 19:01:04 -0600
Simon Glass <sjg@chromium.org> wrote:
Hi,
> 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 at [1].
>
> 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.
So I am possibly fine with that, but:
> This series makes this change, adding various missing devicetree files
> (and placeholders) to make the build work.
If we just need it to make the build work, we not just have pure stub DTs,
as you do for highbank, everywhere?
Adding *some* DT files for those platforms that actually do the right
thing seems like the wrong direction to me.
Providing DTs in the source repositories of the actual consumers is more
of a bad habit that dragged on since Linux started this around 10 years
ago (for practical reasons). For *some* platforms U-Boot is the firmware
component that is in the best situation to provide the DTB (because it's
more than a mere bootloader), but for other it's just not. And this is not
even looking at really dynamic platforms like QEMU, where providing some
kind of fixed DT is just not working.
I don't get the argument that people would need to see the DT in the tree
to develop code. The DT spec and binding documentation (currently living
in the Linux kernel source tree) provide the specification to code
against, and the platform specific selection of drivers in Kconfig and
_defconfig select the drivers for the devices that people are expected to
see. Why does one need actual DT files in the tree?
I totally agree on adding more documentation, possibly *pointing* to example
DTs or giving commands on how to obtain the actual copy (-dumpdtb,
/sys/firmware/devicetree), but don't think that adding some .dts files for
platforms that don't need them is the right way.
Cheers,
Andre.
>
> It also provides a few qemu clean-ups discovered along the way.
>
> This series is based on Ilias' two series for OF_HOSTFILE and
> OF_PRIOR_STAGE removal.
>
> It is available at u-boot-dm/ofb-working
>
> [1]
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
>
>
> Simon Glass (16):
> arm: qemu: Mention -nographic in the docs
> arm: qemu: Explain how to extract the generate devicetree
> riscv: qemu: Explain how to extract the generate devicetree
> 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
>
> Makefile | 3 +-
> arch/arm/dts/Makefile | 20 +-
> arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> arch/arm/dts/bcm7xxx.dts | 15 +
> arch/arm/dts/highbank.dts | 14 +
> arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> arch/arm/dts/octeontx.dts | 14 +
> arch/arm/dts/qemu-arm.dts | 402 +++++
> arch/arm/dts/qemu-arm64.dts | 381 +++++
> arch/arm/dts/xenguest-arm64.dts | 15 +
> arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> arch/powerpc/dts/Makefile | 1 +
> arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> arch/riscv/dts/Makefile | 2 +-
> arch/riscv/dts/qemu-virt.dts | 8 -
> arch/riscv/dts/qemu-virt32.dts | 217 +++
> arch/riscv/dts/qemu-virt64.dts | 217 +++
> configs/bcm7260_defconfig | 1 +
> configs/bcm7445_defconfig | 1 +
> configs/highbank_defconfig | 2 +-
> configs/octeontx2_95xx_defconfig | 1 +
> configs/octeontx2_96xx_defconfig | 1 +
> configs/octeontx_81xx_defconfig | 1 +
> configs/octeontx_83xx_defconfig | 1 +
> configs/qemu-ppce500_defconfig | 2 +
> configs/qemu-riscv32_defconfig | 1 +
> configs/qemu-riscv32_smode_defconfig | 1 +
> configs/qemu-riscv32_spl_defconfig | 4 +-
> configs/qemu-riscv64_defconfig | 1 +
> configs/qemu-riscv64_smode_defconfig | 1 +
> configs/qemu-riscv64_spl_defconfig | 3 +-
> configs/qemu_arm64_defconfig | 1 +
> configs/qemu_arm_defconfig | 1 +
> configs/rpi_4_32b_defconfig | 1 +
> configs/rpi_4_defconfig | 1 +
> configs/rpi_arm64_defconfig | 1 +
> configs/vexpress_aemv8a_juno_defconfig | 1 +
> configs/xenguest_arm64_defconfig | 1 +
> configs/xilinx_versal_virt_defconfig | 1 +
> doc/board/emulation/qemu-arm.rst | 19 +-
> doc/board/emulation/qemu-riscv.rst | 12 +
> dts/Kconfig | 27 +-
> tools/binman/binman.rst | 20 -
> 43 files changed, 4922 insertions(+), 61 deletions(-)
> create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> create mode 100644 arch/arm/dts/bcm7xxx.dts
> create mode 100644 arch/arm/dts/highbank.dts
> create mode 100644 arch/arm/dts/juno-r2.dts
> create mode 100644 arch/arm/dts/octeontx.dts
> create mode 100644 arch/arm/dts/qemu-arm.dts
> create mode 100644 arch/arm/dts/qemu-arm64.dts
> create mode 100644 arch/arm/dts/xenguest-arm64.dts
> create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> delete mode 100644 arch/riscv/dts/qemu-virt.dts
> create mode 100644 arch/riscv/dts/qemu-virt32.dts
> create mode 100644 arch/riscv/dts/qemu-virt64.dts
>
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
2021-10-13 9:50 ` Andre Przywara
@ 2021-10-13 13:05 ` François Ozog
-1 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:05 UTC (permalink / raw)
To: Andre Przywara
Cc: Aaron Williams, Albert Aribaud, Alexander Graf,
Anastasiia Lukianenko, Ashok Reddy Soma, Atish Patra, Bin Meng,
Bin Meng, Christian Hewitt, David Abdurachmanov,
Dimitri John Ledkov, Fabio Estevam, Green Wan, Heiko Schocher,
Heinrich Schuchardt, Heinrich Schuchardt, Ilias Apalodimas,
Jagan Teki, Jerry Van Baren, Kever Yang, Leo, Linus Walleij,
Liviu Dudau, Marek Behún, Matthias Brugger, Michal Simek,
Michal Simek, Neil Armstrong, Niel Fourie,
Oleksandr Andrushchenko, Padmarao Begari, Pali Rohár,
Peter Robinson, Priyanka Jain, Rainer Boschung, Ramon Fried,
Rick Chen, Rob Herring, Sean Anderson, Simon Glass, Sinan Akman,
Stefan Roese, Stephen Warren, Stephen Warren, T Karthik Reddy,
Tero Kristo, Thomas Fitzsimmons, Tianrui Wei, Tim Harvey,
Tom Rini, Tuomas Tynkkynen, U-Boot Mailing List,
Valentin Longchamp, Vladimir Oltean, Wolfgang Denk, Zong Li,
qemu-devel
Le mer. 13 oct. 2021 à 14:41, Andre Przywara <andre.przywara@arm.com> a
écrit :
> On Tue, 12 Oct 2021 19:01:04 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> > 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 at [1].
> >
> > 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.
>
> So I am possibly fine with that, but:
>
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
>
> If we just need it to make the build work, we not just have pure stub DTs,
> as you do for highbank, everywhere?
> Adding *some* DT files for those platforms that actually do the right
> thing seems like the wrong direction to me.
> Providing DTs in the source repositories of the actual consumers is more
> of a bad habit that dragged on since Linux started this around 10 years
> ago (for practical reasons). For *some* platforms U-Boot is the firmware
> component that is in the best situation to provide the DTB (because it's
> more than a mere bootloader), but for other it's just not. And this is not
> even looking at really dynamic platforms like QEMU, where providing some
> kind of fixed DT is just not working.
>
> I don't get the argument that people would need to see the DT in the tree
> to develop code. The DT spec and binding documentation (currently living
> in the Linux kernel source tree) provide the specification to code
> against, and the platform specific selection of drivers in Kconfig and
> _defconfig select the drivers for the devices that people are expected to
> see. Why does one need actual DT files in the tree?
>
> I totally agree on adding more documentation, possibly *pointing* to
> example
> DTs or giving commands on how to obtain the actual copy (-dumpdtb,
> /sys/firmware/devicetree), but don't think that adding some .dts files for
> platforms that don't need them is the right way.
>
> Cheers,
> Andre.
+1
>
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> > arm: qemu: Mention -nographic in the docs
> > arm: qemu: Explain how to extract the generate devicetree
> > riscv: qemu: Explain how to extract the generate devicetree
> > 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
> >
> > Makefile | 3 +-
> > arch/arm/dts/Makefile | 20 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> > arch/arm/dts/bcm7xxx.dts | 15 +
> > arch/arm/dts/highbank.dts | 14 +
> > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> > arch/arm/dts/octeontx.dts | 14 +
> > arch/arm/dts/qemu-arm.dts | 402 +++++
> > arch/arm/dts/qemu-arm64.dts | 381 +++++
> > arch/arm/dts/xenguest-arm64.dts | 15 +
> > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> > arch/powerpc/dts/Makefile | 1 +
> > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> > arch/riscv/dts/Makefile | 2 +-
> > arch/riscv/dts/qemu-virt.dts | 8 -
> > arch/riscv/dts/qemu-virt32.dts | 217 +++
> > arch/riscv/dts/qemu-virt64.dts | 217 +++
> > configs/bcm7260_defconfig | 1 +
> > configs/bcm7445_defconfig | 1 +
> > configs/highbank_defconfig | 2 +-
> > configs/octeontx2_95xx_defconfig | 1 +
> > configs/octeontx2_96xx_defconfig | 1 +
> > configs/octeontx_81xx_defconfig | 1 +
> > configs/octeontx_83xx_defconfig | 1 +
> > configs/qemu-ppce500_defconfig | 2 +
> > configs/qemu-riscv32_defconfig | 1 +
> > configs/qemu-riscv32_smode_defconfig | 1 +
> > configs/qemu-riscv32_spl_defconfig | 4 +-
> > configs/qemu-riscv64_defconfig | 1 +
> > configs/qemu-riscv64_smode_defconfig | 1 +
> > configs/qemu-riscv64_spl_defconfig | 3 +-
> > configs/qemu_arm64_defconfig | 1 +
> > configs/qemu_arm_defconfig | 1 +
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > configs/vexpress_aemv8a_juno_defconfig | 1 +
> > configs/xenguest_arm64_defconfig | 1 +
> > configs/xilinx_versal_virt_defconfig | 1 +
> > doc/board/emulation/qemu-arm.rst | 19 +-
> > doc/board/emulation/qemu-riscv.rst | 12 +
> > dts/Kconfig | 27 +-
> > tools/binman/binman.rst | 20 -
> > 43 files changed, 4922 insertions(+), 61 deletions(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > create mode 100644 arch/arm/dts/bcm7xxx.dts
> > create mode 100644 arch/arm/dts/highbank.dts
> > create mode 100644 arch/arm/dts/juno-r2.dts
> > create mode 100644 arch/arm/dts/octeontx.dts
> > create mode 100644 arch/arm/dts/qemu-arm.dts
> > create mode 100644 arch/arm/dts/qemu-arm64.dts
> > create mode 100644 arch/arm/dts/xenguest-arm64.dts
> > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> > delete mode 100644 arch/riscv/dts/qemu-virt.dts
> > create mode 100644 arch/riscv/dts/qemu-virt32.dts
> > create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
^ permalink raw reply [flat|nested] 164+ messages in thread
* Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
@ 2021-10-13 13:05 ` François Ozog
0 siblings, 0 replies; 164+ messages in thread
From: François Ozog @ 2021-10-13 13:05 UTC (permalink / raw)
To: Andre Przywara
Cc: Liviu Dudau, Neil Armstrong, Vladimir Oltean, Linus Walleij,
Bin Meng, Kever Yang, Sean Anderson, Atish Patra, Zong Li,
Stefan Roese, Fabio Estevam, Rainer Boschung, Rob Herring,
Stephen Warren, Oleksandr Andrushchenko, Heinrich Schuchardt,
Niel Fourie, Michal Simek, Marek Behún, Jerry Van Baren,
Ramon Fried, Jagan Teki, Valentin Longchamp, Heiko Schocher,
Peter Robinson, Sinan Akman, Thomas Fitzsimmons, Wolfgang Denk,
Stephen Warren, qemu-devel, Tim Harvey, Ashok Reddy Soma,
Rick Chen, Alexander Graf, Green Wan, T Karthik Reddy,
Anastasiia Lukianenko, Albert Aribaud, Michal Simek,
Matthias Brugger, Leo, Tero Kristo, U-Boot Mailing List,
David Abdurachmanov, Priyanka Jain, Simon Glass,
Ilias Apalodimas, Christian Hewitt, Aaron Williams,
Tuomas Tynkkynen, Heinrich Schuchardt, Tianrui Wei, Bin Meng,
Pali Rohár, Tom Rini, Dimitri John Ledkov, Padmarao Begari
[-- Attachment #1: Type: text/plain, Size: 7566 bytes --]
Le mer. 13 oct. 2021 à 14:41, Andre Przywara <andre.przywara@arm.com> a
écrit :
> On Tue, 12 Oct 2021 19:01:04 -0600
> Simon Glass <sjg@chromium.org> wrote:
>
> Hi,
>
> > 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 at [1].
> >
> > 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.
>
> So I am possibly fine with that, but:
>
> > This series makes this change, adding various missing devicetree files
> > (and placeholders) to make the build work.
>
> If we just need it to make the build work, we not just have pure stub DTs,
> as you do for highbank, everywhere?
> Adding *some* DT files for those platforms that actually do the right
> thing seems like the wrong direction to me.
> Providing DTs in the source repositories of the actual consumers is more
> of a bad habit that dragged on since Linux started this around 10 years
> ago (for practical reasons). For *some* platforms U-Boot is the firmware
> component that is in the best situation to provide the DTB (because it's
> more than a mere bootloader), but for other it's just not. And this is not
> even looking at really dynamic platforms like QEMU, where providing some
> kind of fixed DT is just not working.
>
> I don't get the argument that people would need to see the DT in the tree
> to develop code. The DT spec and binding documentation (currently living
> in the Linux kernel source tree) provide the specification to code
> against, and the platform specific selection of drivers in Kconfig and
> _defconfig select the drivers for the devices that people are expected to
> see. Why does one need actual DT files in the tree?
>
> I totally agree on adding more documentation, possibly *pointing* to
> example
> DTs or giving commands on how to obtain the actual copy (-dumpdtb,
> /sys/firmware/devicetree), but don't think that adding some .dts files for
> platforms that don't need them is the right way.
>
> Cheers,
> Andre.
+1
>
>
> >
> > It also provides a few qemu clean-ups discovered along the way.
> >
> > This series is based on Ilias' two series for OF_HOSTFILE and
> > OF_PRIOR_STAGE removal.
> >
> > It is available at u-boot-dm/ofb-working
> >
> > [1]
> >
> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-sjg@chromium.org/
> >
> >
> > Simon Glass (16):
> > arm: qemu: Mention -nographic in the docs
> > arm: qemu: Explain how to extract the generate devicetree
> > riscv: qemu: Explain how to extract the generate devicetree
> > 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
> >
> > Makefile | 3 +-
> > arch/arm/dts/Makefile | 20 +-
> > arch/arm/dts/bcm2711-rpi-4-b.dts | 1958 ++++++++++++++++++++++++
> > arch/arm/dts/bcm7xxx.dts | 15 +
> > arch/arm/dts/highbank.dts | 14 +
> > arch/arm/dts/juno-r2.dts | 1038 +++++++++++++
> > arch/arm/dts/octeontx.dts | 14 +
> > arch/arm/dts/qemu-arm.dts | 402 +++++
> > arch/arm/dts/qemu-arm64.dts | 381 +++++
> > arch/arm/dts/xenguest-arm64.dts | 15 +
> > arch/arm/dts/xilinx-versal-virt.dts | 307 ++++
> > arch/powerpc/dts/Makefile | 1 +
> > arch/powerpc/dts/qemu-ppce500.dts | 264 ++++
> > arch/riscv/dts/Makefile | 2 +-
> > arch/riscv/dts/qemu-virt.dts | 8 -
> > arch/riscv/dts/qemu-virt32.dts | 217 +++
> > arch/riscv/dts/qemu-virt64.dts | 217 +++
> > configs/bcm7260_defconfig | 1 +
> > configs/bcm7445_defconfig | 1 +
> > configs/highbank_defconfig | 2 +-
> > configs/octeontx2_95xx_defconfig | 1 +
> > configs/octeontx2_96xx_defconfig | 1 +
> > configs/octeontx_81xx_defconfig | 1 +
> > configs/octeontx_83xx_defconfig | 1 +
> > configs/qemu-ppce500_defconfig | 2 +
> > configs/qemu-riscv32_defconfig | 1 +
> > configs/qemu-riscv32_smode_defconfig | 1 +
> > configs/qemu-riscv32_spl_defconfig | 4 +-
> > configs/qemu-riscv64_defconfig | 1 +
> > configs/qemu-riscv64_smode_defconfig | 1 +
> > configs/qemu-riscv64_spl_defconfig | 3 +-
> > configs/qemu_arm64_defconfig | 1 +
> > configs/qemu_arm_defconfig | 1 +
> > configs/rpi_4_32b_defconfig | 1 +
> > configs/rpi_4_defconfig | 1 +
> > configs/rpi_arm64_defconfig | 1 +
> > configs/vexpress_aemv8a_juno_defconfig | 1 +
> > configs/xenguest_arm64_defconfig | 1 +
> > configs/xilinx_versal_virt_defconfig | 1 +
> > doc/board/emulation/qemu-arm.rst | 19 +-
> > doc/board/emulation/qemu-riscv.rst | 12 +
> > dts/Kconfig | 27 +-
> > tools/binman/binman.rst | 20 -
> > 43 files changed, 4922 insertions(+), 61 deletions(-)
> > create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts
> > create mode 100644 arch/arm/dts/bcm7xxx.dts
> > create mode 100644 arch/arm/dts/highbank.dts
> > create mode 100644 arch/arm/dts/juno-r2.dts
> > create mode 100644 arch/arm/dts/octeontx.dts
> > create mode 100644 arch/arm/dts/qemu-arm.dts
> > create mode 100644 arch/arm/dts/qemu-arm64.dts
> > create mode 100644 arch/arm/dts/xenguest-arm64.dts
> > create mode 100644 arch/arm/dts/xilinx-versal-virt.dts
> > create mode 100644 arch/powerpc/dts/qemu-ppce500.dts
> > delete mode 100644 arch/riscv/dts/qemu-virt.dts
> > create mode 100644 arch/riscv/dts/qemu-virt32.dts
> > create mode 100644 arch/riscv/dts/qemu-virt64.dts
> >
>
> --
François-Frédéric Ozog | *Director Business Development*
T: +33.67221.6485
francois.ozog@linaro.org | Skype: ffozog
[-- Attachment #2: Type: text/html, Size: 10669 bytes --]
^ permalink raw reply [flat|nested] 164+ messages in thread