[PATCH v6 6/7] x86: qemu: Expand ROM size
Expand the ROM for x86_64 to 2MB to make space for the font, as it is already on the edge. Signed-off-by: Simon Glass --- (no changes since v1) board/emulation/qemu-x86/Kconfig | 3 ++- configs/qemu-x86_64_defconfig| 4 ++-- 2 files changed, 4 insertions(+), 3 deletions(-) diff --git a/board/emulation/qemu-x86/Kconfig b/board/emulation/qemu-x86/Kconfig index 01dc1d497ae..34d665a3e4c 100644 --- a/board/emulation/qemu-x86/Kconfig +++ b/board/emulation/qemu-x86/Kconfig @@ -21,7 +21,8 @@ config BOARD_SPECIFIC_OPTIONS # dummy select X86_RESET_VECTOR select QEMU select QFW_PIO if CMD_QFW - select BOARD_ROMSIZE_KB_1024 + select BOARD_ROMSIZE_KB_1024 if TARGET_QEMU_X86 + select BOARD_ROMSIZE_KB_2048 if TARGET_QEMU_X86_64 imply VIRTIO_PCI imply VIRTIO_NET imply VIRTIO_BLK diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 8b4c5aff7f6..79cdb0bddb2 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -6,7 +6,7 @@ CONFIG_ENV_SIZE=0x4 CONFIG_MAX_CPUS=2 CONFIG_SPL_DM_SPI=y CONFIG_DEFAULT_DEVICE_TREE="qemu-x86_i440fx" -CONFIG_SPL_TEXT_BASE=0xfffd8000 +CONFIG_SPL_TEXT_BASE=0xfffd4000 CONFIG_SPL_SYS_MALLOC_F_LEN=0x2000 CONFIG_DEBUG_UART_BASE=0x3f8 CONFIG_DEBUG_UART_CLOCK=1843200 @@ -17,7 +17,7 @@ CONFIG_DEBUG_UART=y CONFIG_SMP=y CONFIG_GENERATE_PIRQ_TABLE=y CONFIG_GENERATE_MP_TABLE=y -CONFIG_X86_OFFSET_U_BOOT=0xfff0 +CONFIG_X86_OFFSET_U_BOOT=0xffe0 CONFIG_SYS_MONITOR_BASE=0x0111 CONFIG_FIT=y CONFIG_SPL_LOAD_FIT=y -- 2.34.1
[PATCH v6 0/7] Resolve issues with booting distros on x86
This little series reprises the EFI-video fix, fixes a USB problem and enables a boot script for coreboot. It also moves to truetype fonts for coreboot and qemu-x86, since the menus look much better and there are no strong size constraints. With these changes it is possible to boot a Linux distro automatically with U-Boot on x86, including when U-Boot is the second-stage bootloader. Changes in v6: - Rebase to -next - Move 'Avoid unbinding devices in use by bootflows' to another series Changes in v4: - Use a Kconfig option Changes in v3: - Clear the screen before booting - Add new patch to drop unnecessary truetype operations from SPL - Add new patch to enable truetype fonts in coreboot - Add new patch to enable truetype fonts in qemu-x86 and qemu-x86_64 Changes in v2: - Add new patch to add a coreboot boot script Simon Glass (7): x86: coreboot: Add a boot script video: Correct setting of cursor position video: Drop unnecessary truetype operations from SPL x86: Enable SSE in 64-bit mode x86: coreboot: Enable truetype fonts x86: qemu: Expand ROM size x86: qemu: Enable truetype fonts arch/x86/Kconfig | 8 arch/x86/config.mk| 4 arch/x86/cpu/x86_64/cpu.c | 12 arch/x86/dts/coreboot.dts | 10 ++ board/emulation/qemu-x86/Kconfig | 3 ++- configs/coreboot64_defconfig | 2 ++ configs/coreboot_defconfig| 2 ++ configs/qemu-x86_64_defconfig | 5 +++-- configs/qemu-x86_defconfig| 1 + drivers/video/Kconfig | 1 + drivers/video/console_truetype.c | 10 ++ drivers/video/vidconsole-uclass.c | 15 --- 12 files changed, 63 insertions(+), 10 deletions(-) -- 2.34.1
[PATCH v6 7/7] x86: qemu: Enable truetype fonts
Enable this feature to provide a larger font choice and more attractive menus. Expand the ROM for x86_64 to 2MB to make space for the font. Signed-off-by: Simon Glass --- Changes in v6: - Move 'Avoid unbinding devices in use by bootflows' to another series Changes in v3: - Add new patch to enable truetype fonts in qemu-x86 and qemu-x86_64 configs/qemu-x86_64_defconfig | 1 + configs/qemu-x86_defconfig| 1 + 2 files changed, 2 insertions(+) diff --git a/configs/qemu-x86_64_defconfig b/configs/qemu-x86_64_defconfig index 79cdb0bddb2..f084f8e2989 100644 --- a/configs/qemu-x86_64_defconfig +++ b/configs/qemu-x86_64_defconfig @@ -81,6 +81,7 @@ CONFIG_SPL_DM_RTC=y CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SPI=y CONFIG_USB_KEYBOARD=y +CONFIG_CONSOLE_TRUETYPE=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_USER=y CONFIG_FRAMEBUFFER_VESA_MODE=0x144 diff --git a/configs/qemu-x86_defconfig b/configs/qemu-x86_defconfig index 9bcf06c137f..b0d397bae08 100644 --- a/configs/qemu-x86_defconfig +++ b/configs/qemu-x86_defconfig @@ -58,6 +58,7 @@ CONFIG_NVME_PCI=y CONFIG_SYS_NS16550_PORT_MAPPED=y CONFIG_SPI=y CONFIG_USB_KEYBOARD=y +CONFIG_CONSOLE_TRUETYPE=y CONFIG_FRAMEBUFFER_SET_VESA_MODE=y CONFIG_FRAMEBUFFER_VESA_MODE_USER=y CONFIG_FRAMEBUFFER_VESA_MODE=0x144 -- 2.34.1
[PATCH v2] hw/arm/virt: Allow additions to the generated device tree
At present qemu creates a device tree automatically with the 'virt' generic
virtual platform. This is very convenient in most cases but there is not
much control over what is generated.
Add a way to provide a device tree binary file with additional properties
to add before booting. This provides flexibility for situations where
Linux needs some tweak to operate correctly. It also allows configuration
information to be passed to U-Boot, supporting verified boot, for example.
The term 'merge' is used here to avoid confusion with device tree overlays,
which are a particular type of format.
[resending this as the original patch has gone stale]
Signed-off-by: Simon Glass
---
Changes in v2:
- Rebase to master
docs/system/arm/virt.rst | 13 +++-
hw/arm/virt.c| 135 +++
hw/core/machine.c| 20 ++
include/hw/boards.h | 1 +
qemu-options.hx | 8 +++
system/vl.c | 3 +
6 files changed, 178 insertions(+), 2 deletions(-)
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 7c4c80180c..0f63a773f2 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -186,8 +186,17 @@ Hardware configuration information for bare-metal
programming
The ``virt`` board automatically generates a device tree blob ("dtb")
which it passes to the guest. This provides information about the
addresses, interrupt lines and other configuration of the various devices
-in the system. Guest code can rely on and hard-code the following
-addresses:
+in the system.
+
+The optional ``-dtbi`` argument is used to specify a device tree blob to merge
+with this generated device tree, to add any properties required by the guest
but
+not included by qemu. Properties are merged after the generated device tree is
+created, so take precedence over generated properties. This can be useful for
+overriding the ``stdout-path`` for Linux, for example, or to add configuration
+information needed by U-Boot. This is intended for simple nodes and properties
+and does not support use of phandles or device tree overlays.
+
+Guest code can rely on and hard-code the following addresses:
- Flash memory starts at address 0x_
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index be2856c018..fb790a2e24 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -41,6 +41,7 @@
#include "hw/vfio/vfio-calxeda-xgmac.h"
#include "hw/vfio/vfio-amd-xgbe.h"
#include "hw/display/ramfb.h"
+#include
#include "net/net.h"
#include "sysemu/device_tree.h"
#include "sysemu/numa.h"
@@ -320,6 +321,135 @@ static void create_fdt(VirtMachineState *vms)
}
}
+
+/*
+ * From U-Boot v2021.07 (under BSD-2-Clause license)
+ *
+ * This does not use the qemu_fdt interface because that requires node names.
+ * Here we are using offsets.
+ *
+ * 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;
+}
+
+/* Merge nodes and properties into fdt from fdto */
+static int merge_fdt(void *fdt, void *fdto)
+{
+int
Re: [PULL 2/3] edk2: replace build scripts
Hi Gerd, On Thu, 16 Mar 2023 at 04:49, Gerd Hoffmann wrote: > > Hi, > > > The README should mention that you need to use > > > > . edk2setup.sh > > > > first. > > The script will do that if needed. > > > Also you need to be in the edk2 directory, I think. > > Or use the --core switch, or place the location in the config file in > the [global] section. That seems to be resolved with the latest script. > > > It would be good if the edk2-clone.sh script could deal with updating > > an existing checkout so I don't need to remove the old ones each time. > > Updating is just "git pull && git submodules update". Even more reason to put it in the script :-) > > > edk2-build.py -c ../edk2-build-config/kraxel/x64.platforms -j30 --silent > > That config file expects cwd being edk2-platforms and edk2 being placed > next to it (../ekd2). edk2-non-osi too. See the [global] section at > the start of the file. OK I see. > > > BaseTools/BuildEnv: 160: Bad substitution > > Using Pip Basetools > > BaseTools/BuildEnv: 184: Bad substitution > > BaseTools/BuildEnv: 202: -c: not found > > Ok, tried updated the script to use bash not sh for that. Does this > work better for you? Yes, fixed. > > > Do I need to make -C BaseTools first? > > No, the script will do that. Seems to work fine now. > > > > +import optparse > > > > I think this is obsolete and argparse should be used for new things. > > The conversion is pretty easy. > > Done. > OK > > Silent mode still produces output. Can you add a -s alias and also > > make it fully silent? > > Well, silent means no output from the "build" command, so the console is > not flooded with build logs (unless there are build errors), output is > written to logfiles instead. We have a different understanding of 'silent' ::-) > > > If the config file is not found, it seems to say nothing, but just > > does not work. It should give an error. > > Fixed. Works fine. Thanks for the great script and the fixes. Regards, Simon
Re: [PULL 3/3] edk2: update firmware binaries
Hi Gerd, On Thu, 9 Mar 2023 at 22:38, Gerd Hoffmann wrote: > > On Thu, Mar 09, 2023 at 02:09:30PM -0800, Simon Glass wrote: > > Hi Gerd, > > > > Where did these binaries come from? What commit and how were they built? > > See patch 1/3 for the source (edk2 submodule) update and patch 2/3 for > the build scripts. OK, got it, thank you. I made a few comments. This script is very, very useful. I wonder if it could end up in the edk repo? Regards, Simon
Re: [PULL 2/3] edk2: replace build scripts
Hi Gerd,
On Thu, 9 Mar 2023 at 03:58, Gerd Hoffmann wrote:
>
> Remove Makefile.edk2 and the edk2*.sh scripts with a python script
> (which already handles fedora rpm builds) and a config file for it.
>
> Signed-off-by: Gerd Hoffmann
> ---
> roms/edk2-build.py | 372 +
> roms/Makefile | 29 +---
> roms/Makefile.edk2 | 178
> roms/edk2-build.config | 119 +
> roms/edk2-build.sh | 55 --
> roms/edk2-funcs.sh | 273 --
> 6 files changed, 498 insertions(+), 528 deletions(-)
> create mode 100755 roms/edk2-build.py
> delete mode 100644 roms/Makefile.edk2
> create mode 100644 roms/edk2-build.config
> delete mode 100755 roms/edk2-build.sh
> delete mode 100644 roms/edk2-funcs.sh
I am very pleased to see this as I find building edk2 a bit of a pain.
The README should mention that you need to use
. edk2setup.sh
first. Also you need to be in the edk2 directory, I think. Also
mention that the builds appear as subdirs in the edk2/Build directory.
It would be good if the edk2-clone.sh script could deal with updating
an existing checkout so I don't need to remove the old ones each time.
When I tried to build platform.rpi I get this:
edk2-build.py -c ../edk2-build-config/kraxel/x64.platforms -j30 --silent
###
### building: BaseTools
###
['make', '-C', '/scratch/sglass/edk2/BaseTools']
### building in silent mode ...
### writing log to build.basetools.log ...
### OK
###
### building: Platform/RaspberryPi/RPi4/RPi4.dsc (AARCH64, DEBUG)
### description: EFI Firmware for Raspberry PI 4
###
['build', '-t', 'GCC5', '-p', 'Platform/RaspberryPi/RPi4/RPi4.dsc',
'-n', '30', '-a', 'AARCH64', '-b', 'DEBUG']
### building in silent mode ...
### writing log to build.platform.rpi4.DEBUG.log ...
### BUILD FAILURE
### output
Build environment: Linux-5.15.0-60-generic-x86_64-with-glibc2.35
Build start time: 06:46:28, Mar.10 2023
build.py...
: error 000E: One Path in PACKAGES_PATH doesn't exist
/scratch/sglass/edk2/Platform/Intel
- Failed -
Build end time: 06:46:28, Mar.10 2023
Build total time: 00:00:00
### exit code: 14
ERROR: build exited with 14 while building Platform/RaspberryPi/RPi4/RPi4.dsc
Also the first time running it after cloning, I get errors:
edk2-build.py -c ../edk2-build-config/kraxel/x64.core -j30 -m
ovmf.qemu.ia32 --silent
###
### running BaseTools/BuildEnv
###
BaseTools/BuildEnv: 160: Bad substitution
Using Pip Basetools
BaseTools/BuildEnv: 184: Bad substitution
BaseTools/BuildEnv: 202: -c: not found
Do I need to make -C BaseTools first?
>
> diff --git a/roms/edk2-build.py b/roms/edk2-build.py
> new file mode 100755
> index ..5b34620271f7
> --- /dev/null
> +++ b/roms/edk2-build.py
> @@ -0,0 +1,372 @@
> +#!/usr/bin/python3
> +"""
> +build helper script for edk2, see
> +https://gitlab.com/kraxel/edk2-build-config
> +
> +"""
> +import os
> +import sys
> +import glob
> +import shutil
> +import optparse
I think this is obsolete and argparse should be used for new things.
The conversion is pretty easy.
> +import subprocess
> +import configparser
> +
> +rebase_prefix= ""
> +version_override = None
> +release_date = None
There are a lot of pylint warnings. Also functions / arguments /
return values lack comments.
Silent mode still produces output. Can you add a -s alias and also
make it fully silent?
If the config file is not found, it seems to say nothing, but just
does not work. It should give an error.
> +
> +def check_rebase():
> +""" detect 'git rebase -x edk2-build.py master' testbuilds """
> +global rebase_prefix
> +global version_override
> +gitdir = '.git'
> +
> +if os.path.isfile(gitdir):
> +with open(gitdir) as f:
> +(unused, gitdir) = f.read().split()
> +
> +if not os.path.exists(f'{gitdir}/rebase-merge/msgnum'):
> +return ""
> +with open(f'{gitdir}/rebase-merge/msgnum', 'r') as f:
> +msgnum = int(f.read())
> +with open(f'{gitdir}/rebase-merge/end', 'r') as f:
> +end = int(f.read())
> +with open(f'{gitdir}/rebase-merge/head-name', 'r') as f:
> +head = f.read().strip().split('/')
> +
> +rebase_prefix = f'[ {int(msgnum/2)} / {int(end/2)} - {head[-1]} ] '
> +if msgnum != end and not version_override:
> +# fixed version speeds up builds
> +version_override = "test-build-patch-series"
> +
> +def get_coredir(cfg):
> +if cfg.has_option('global', 'core'):
> +return os.path.abspath(cfg['global']['core'])
> +else:
> +return os.getcwd()
> +
> +def get_version(cfg):
> +coredir = get_coredir(cfg)
> +if version_override:
> +version = version_override
> +print('')
> +print(f'### version [override]: {version}')
> +return version
> +if os.environ.get('RPM_PACKAGE_NAME'):
> +version = os.environ.get('RPM_PACKAGE_NAME');
> +version += '-' + os.environ.get('RPM
Re: [PULL 3/3] edk2: update firmware binaries
Hi Gerd, Where did these binaries come from? What commit and how were they built? Regards, Simon
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi, On Fri, 5 Nov 2021 at 09:51, François Ozog wrote: > > Hi, > > On Wed, 3 Nov 2021 at 14:17, François Ozog wrote: >> >> Hi, >> >> Thanks Alex to patch me in. >> >> I'd like to present another perspective on the motivation as I can't really >> comment on the actual "how". >> >> On real Arm boards, firmware is often assembled into a FIP. >> That FIP can contain quite a good deal of things, including an NT_FW_CONFIG, >> NonTrusted_FirmWare_CONFIGuration (NT_FW = BL33 which is U-Boot in our case). >> So the expected typical content for that section is a DT fragment/overlay. >> That section is to be used in different ways but one is >> https://trustedfirmware-a.readthedocs.io/en/latest/components/fconf/index.html. >> For SystemReady systems we will almost inevitably put a device tree fragment >> in this section and have BL2 merge it with the board DT before handing it >> over to BL33 (U-Boot is one of them). >> In some real world examples based on carrier board + som for instance, it >> may contain SerDes configuration for U-Boot that will result in appropriate >> PCI lanes or MDIO lanes for the booted OS. >> >> So I could say there is precedence in Simon's effort. >> >> In any case, when we will have made the changes in TFA for the SystemReady >> boards we work on, booting the full SystemReady stack (TFA, OP-TEE, U-Boot) >> on Qemu will allow that late merge based through the FIP. >> >> Other boot flows such as VBE (without TFA but with TPL/SPL/U-Boot proper) >> need a similar facility. >> >> >> Hence I am supporting Simon's proposal at least on the intent. On the how >> exactly, that is outside my skillset. > > Responding to my own comment: > As the boot flow TFA+U-Boot works, it looks like a cleaner option is to leave > QEMU alone and have > U-Boot SPL do the same work as with TFA: use a section for the FIT for the DT > to be merged. > > >> >> >> future comments below >> >> >> On Wed, 3 Nov 2021 at 12:48, Alex Bennée wrote: >>> >>> >>> Peter Maydell writes: >>> >>> > On Mon, 27 Sept 2021 at 16:18, Simon Glass wrote: >>> >> On Mon, 27 Sept 2021 at 02:48, Peter Maydell >>> >> wrote: >>> >> > So what is missing in the QEMU-provided DTB that it needs? >>> >> >>> >> Quite a lot. Here are some examples: >>> >> >>> >> U-Boot has limited pre-relocation memory so tries to avoid >>> >> binding/probing devices that are not used before relocation: >>> >> >>> >> https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support >>> > >>> > It's up to u-boot to decide what it wants to touch and >>> > what it does not. QEMU tells u-boot what all the available >>> > devices are; I don't think we should have extra stuff saying >>> > "and if you are u-boot, do something odd". >>> > >>> >> There is a configuration node (which is likely to change form in >>> >> future releases, but will still be there) >>> >> >>> >> https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt >>> > >>> > I think u-boot should be storing this kind of thing somewhere >>> > else (e.g. as part of the binary blob that is u-boot itself, >>> > or stored in flash or RAM as a separate blob). >>> > >>> >> Then there are various features which put things in U-Boot's control >>> >> dtb, such as verified boot, which adds public keys during signing: >>> >> >>> >> https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135 >>> >> >>> >> More generally, the U-Boot tree has hundreds of files which add >>> >> properties for each board, since we try to keep the U-Boot-specific >>> >> things out of the Linux tree: >>> >> >>> >> $ find . -name *u-boot.dtsi |wc -l >>> >> 398 >>> > >>> > If any of this is actual information about the hardware then you >>> > should sort out getting the bindings documented officially >>> > (which I think is still in the Linux tree), and then QEMU can >>> > provide them. >>> > >>> >> Quite a bit of this is to do with SPL and so far it seems that QEMU >>> >> mostly runs U-Boot prop
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi François, On Mon, 8 Nov 2021 at 09:20, François Ozog wrote: > > > > On Fri, 5 Nov 2021 at 18:17, Simon Glass wrote: >> >> ) to signal Hi François, >> >> On Fri, 5 Nov 2021 at 10:31, François Ozog wrote: >> > >> > Hi Simon, >> > >> > Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : >> >> >> >> Hi François, >> >> >> >> On Fri, 5 Nov 2021 at 02:27, François Ozog >> >> wrote: >> >> > >> >> > >> >> > >> >> > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: >> >> >> >> >> >> Hi François, >> >> >> >> >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog >> >> >> wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> >> >> >> >> >> >> Hi François, >> >> >> >> >> >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog >> >> >> >> wrote: >> >> >> >> > >> >> >> >> > Hi Simon, >> >> >> >> > >> >> >> >> > this seems a great endeavor. I'd like to better understand the >> >> >> >> > scope of it. >> >> >> >> > >> >> >> >> > Is it to be used as part of what could become a U-Boot entry ABI >> >> >> >> > scheme? By that I mean giving some fixed aspects >> >> >> >> > to U-Boot entry while letting boards to have flexibility (say for >> >> >> >> > instance that the first 5 architecture ABI >> >> >> >> > parameter registers are reserved for U-Boot), and the Passage is >> >> >> >> > about specifying either those reserved registers >> >> >> >> > or one of them? >> >> >> >> >> >> >> >> The goal is to provide a standard entry scheme for all firmware >> >> >> >> binaries. Whether it achieves that (or can with some mods) is up for >> >> >> >> discussion. >> >> >> >> >> >> >> > If you say >> >> >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware >> >> >> > information passing facility which would be part of all firmware >> >> >> > ABIs (as the projects decide to define their own ABI) it looks good. >> >> >> > but If you say >> >> >> >> >> >> It is an ABI to be adopted by U-Boot but also other firmware. For >> >> >> example, if TF-A calls U-Boot it should use standard passage. If >> >> >> U-Boot calls TF-A or Optee it should use standard passage. >> >> >> >> >> >> > b) define a standard entry scheme (register map, processor state, >> >> >> > MMU state, SMMU state, GIC state...) that does not look realistic. >> >> >> >> >> >> No I don't mean that. This data structure could be used in any state, >> >> >> so long as the two registers are set correctly. >> >> >> >> >> >> > I think you mean a) but just want to be sure. >> >> >> >> >> >> Yes I think so. >> >> >> >> >> >> >> >> >> >> >> Re the registers, do you think we need 5? >> >> >> >> >> >> >> >> >> >> I don't :-) >> >> >> >> >> >> >> > >> >> >> >> > Thinking entry ABI, here is what I observed on Arm: >> >> >> >> > >> >> >> >> > Linux has two entry ABIs: >> >> >> >> > - plain: x0 = dtb; >> >> >> >> > command line = dtb:/chosen/bootargs; initrd = >> >> >> >> > dtb:/chosen/linux,initrd-* >> >> >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >> >> >> >dtb = EFI_UUID config table; initrd = >> >> >> >> > efi:> >> >> >> > image_protocol::load_options >> >> >> >> > >> >> >>
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
) to signal Hi François, On Fri, 5 Nov 2021 at 10:31, François Ozog wrote: > > Hi Simon, > > Le ven. 5 nov. 2021 à 17:12, Simon Glass a écrit : >> >> Hi François, >> >> On Fri, 5 Nov 2021 at 02:27, François Ozog wrote: >> > >> > >> > >> > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> >> >> >> >> Hi François, >> >> >> >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog >> >> >> wrote: >> >> >> > >> >> >> > Hi Simon, >> >> >> > >> >> >> > this seems a great endeavor. I'd like to better understand the scope >> >> >> > of it. >> >> >> > >> >> >> > Is it to be used as part of what could become a U-Boot entry ABI >> >> >> > scheme? By that I mean giving some fixed aspects >> >> >> > to U-Boot entry while letting boards to have flexibility (say for >> >> >> > instance that the first 5 architecture ABI >> >> >> > parameter registers are reserved for U-Boot), and the Passage is >> >> >> > about specifying either those reserved registers >> >> >> > or one of them? >> >> >> >> >> >> The goal is to provide a standard entry scheme for all firmware >> >> >> binaries. Whether it achieves that (or can with some mods) is up for >> >> >> discussion. >> >> >> >> >> > If you say >> >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware >> >> > information passing facility which would be part of all firmware ABIs >> >> > (as the projects decide to define their own ABI) it looks good. >> >> > but If you say >> >> >> >> It is an ABI to be adopted by U-Boot but also other firmware. For >> >> example, if TF-A calls U-Boot it should use standard passage. If >> >> U-Boot calls TF-A or Optee it should use standard passage. >> >> >> >> > b) define a standard entry scheme (register map, processor state, MMU >> >> > state, SMMU state, GIC state...) that does not look realistic. >> >> >> >> No I don't mean that. This data structure could be used in any state, >> >> so long as the two registers are set correctly. >> >> >> >> > I think you mean a) but just want to be sure. >> >> >> >> Yes I think so. >> >> >> >> >> >> >> >> Re the registers, do you think we need 5? >> >> >> >> >> >> >> I don't :-) >> >> >> >> >> > >> >> >> > Thinking entry ABI, here is what I observed on Arm: >> >> >> > >> >> >> > Linux has two entry ABIs: >> >> >> > - plain: x0 = dtb; >> >> >> > command line = dtb:/chosen/bootargs; initrd = >> >> >> > dtb:/chosen/linux,initrd-* >> >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >> >> >dtb = EFI_UUID config table; initrd = >> >> >> > efi:> >> >> > image_protocol::load_options >> >> >> > >> >> >> > U-Boot (proper) has plenty of schemes: >> >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is >> >> >> > bad in itself), or other registers >> >> >> > - additional information passing: board specific register scheme, >> >> >> > SMC calls >> >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be >> >> >> > launched by Videocore firmware >> >> >> > >> >> >> > Based on all the above, I would tend to think that RPI scheme is a >> >> >> > good idea but also >> >> >> > shall not prevent additional schemes for the boards. >> >> >> >> >> >> I was not actually considering Linux since I believe/assume its entry >> >> &g
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi François, On Fri, 5 Nov 2021 at 02:27, François Ozog wrote: > > > > On Fri, 5 Nov 2021 at 03:02, Simon Glass wrote: >> >> Hi François, >> >> On Tue, 2 Nov 2021 at 10:03, François Ozog wrote: >> > >> > Hi Simon, >> > >> > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon, >> >> > >> >> > this seems a great endeavor. I'd like to better understand the scope of >> >> > it. >> >> > >> >> > Is it to be used as part of what could become a U-Boot entry ABI >> >> > scheme? By that I mean giving some fixed aspects >> >> > to U-Boot entry while letting boards to have flexibility (say for >> >> > instance that the first 5 architecture ABI >> >> > parameter registers are reserved for U-Boot), and the Passage is about >> >> > specifying either those reserved registers >> >> > or one of them? >> >> >> >> The goal is to provide a standard entry scheme for all firmware >> >> binaries. Whether it achieves that (or can with some mods) is up for >> >> discussion. >> >> >> > If you say >> > a) define a U-Boot entry ABI and providing a firmware-to-firmware >> > information passing facility which would be part of all firmware ABIs (as >> > the projects decide to define their own ABI) it looks good. >> > but If you say >> >> It is an ABI to be adopted by U-Boot but also other firmware. For >> example, if TF-A calls U-Boot it should use standard passage. If >> U-Boot calls TF-A or Optee it should use standard passage. >> >> > b) define a standard entry scheme (register map, processor state, MMU >> > state, SMMU state, GIC state...) that does not look realistic. >> >> No I don't mean that. This data structure could be used in any state, >> so long as the two registers are set correctly. >> >> > I think you mean a) but just want to be sure. >> >> Yes I think so. >> >> >> >> >> Re the registers, do you think we need 5? >> >> >> >> I don't :-) >> >> >> > >> >> > Thinking entry ABI, here is what I observed on Arm: >> >> > >> >> > Linux has two entry ABIs: >> >> > - plain: x0 = dtb; >> >> > command line = dtb:/chosen/bootargs; initrd = >> >> > dtb:/chosen/linux,initrd-* >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >> >dtb = EFI_UUID config table; initrd = efi:> >> > vendor media UUID); command line = efi: image_protocol::load_options >> >> > >> >> > U-Boot (proper) has plenty of schemes: >> >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad >> >> > in itself), or other registers >> >> > - additional information passing: board specific register scheme, SMC >> >> > calls >> >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be >> >> > launched by Videocore firmware >> >> > >> >> > Based on all the above, I would tend to think that RPI scheme is a good >> >> > idea but also >> >> > shall not prevent additional schemes for the boards. >> >> >> >> I was not actually considering Linux since I believe/assume its entry >> >> scheme is fixed and not up for discussion. >> >> >> >> I also did not think about the EFI case. As I understand it we cannot >> >> touch it as it is used by UEFI today. Maybe it is even in the >> >> standard? >> > >> > It is in the spec and we are making it evolve, or its understanding evolve >> > (jurisprudence) for instance on initrd standard handling. >> >> Well perhaps we could merge it with standard passage. But EFI is not >> going to want to use a bloblist, it will want to use a HOB. >> >> >> >> >> >> >> Really I am hoping we can start afresh...? >> >> >> >> > >> >> > What about a U-Boot Arm entry ABI like: >> >> > - plain: x0=dtb, x1=, x2-x5 = , other >> >> > registers are per platform, SMC calls allowed too >> >> >> >> Hmm
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi François, On Tue, 2 Nov 2021 at 10:03, François Ozog wrote: > > Hi Simon, > > On Tue, 2 Nov 2021 at 15:59, Simon Glass wrote: >> >> Hi François, >> >> On Mon, 1 Nov 2021 at 02:53, François Ozog wrote: >> > >> > Hi Simon, >> > >> > this seems a great endeavor. I'd like to better understand the scope of it. >> > >> > Is it to be used as part of what could become a U-Boot entry ABI scheme? >> > By that I mean giving some fixed aspects >> > to U-Boot entry while letting boards to have flexibility (say for instance >> > that the first 5 architecture ABI >> > parameter registers are reserved for U-Boot), and the Passage is about >> > specifying either those reserved registers >> > or one of them? >> >> The goal is to provide a standard entry scheme for all firmware >> binaries. Whether it achieves that (or can with some mods) is up for >> discussion. >> > If you say > a) define a U-Boot entry ABI and providing a firmware-to-firmware information > passing facility which would be part of all firmware ABIs (as the projects > decide to define their own ABI) it looks good. > but If you say It is an ABI to be adopted by U-Boot but also other firmware. For example, if TF-A calls U-Boot it should use standard passage. If U-Boot calls TF-A or Optee it should use standard passage. > b) define a standard entry scheme (register map, processor state, MMU state, > SMMU state, GIC state...) that does not look realistic. No I don't mean that. This data structure could be used in any state, so long as the two registers are set correctly. > I think you mean a) but just want to be sure. Yes I think so. >> >> Re the registers, do you think we need 5? >> I don't :-) >> > >> > Thinking entry ABI, here is what I observed on Arm: >> > >> > Linux has two entry ABIs: >> > - plain: x0 = dtb; >> > command line = dtb:/chosen/bootargs; initrd = >> > dtb:/chosen/linux,initrd-* >> > - EFI: x0=handle, x1=systemtable, x30=return address; >> >dtb = EFI_UUID config table; initrd = efi:> > vendor media UUID); command line = efi: image_protocol::load_options >> > >> > U-Boot (proper) has plenty of schemes: >> > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in >> > itself), or other registers >> > - additional information passing: board specific register scheme, SMC calls >> > - U-Boot for RPI boards implement a Linux shaped entry ABI to be launched >> > by Videocore firmware >> > >> > Based on all the above, I would tend to think that RPI scheme is a good >> > idea but also >> > shall not prevent additional schemes for the boards. >> >> I was not actually considering Linux since I believe/assume its entry >> scheme is fixed and not up for discussion. >> >> I also did not think about the EFI case. As I understand it we cannot >> touch it as it is used by UEFI today. Maybe it is even in the >> standard? > > It is in the spec and we are making it evolve, or its understanding evolve > (jurisprudence) for instance on initrd standard handling. Well perhaps we could merge it with standard passage. But EFI is not going to want to use a bloblist, it will want to use a HOB. >> >> >> Really I am hoping we can start afresh...? >> >> > >> > What about a U-Boot Arm entry ABI like: >> > - plain: x0=dtb, x1=, x2-x5 = , other registers >> > are per platform, SMC calls allowed too >> >> Hmm we don't actually need the dtb as it is available in the bloblist. > > If you don't have x0=dtb, then you will not be able to use U-Boot on RPI4. > Unless you want to redo everything the RPI firmware is doing. That's right, RPI cannot support standard passage. It is not open-source firmware so it isn't really relevant to this discussion. It will just do what it does and have limited functionality, with work-arounds to deal with the pain, as one might expect. >> >> But I added an offset to it as a convenience. >> >> > - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is >> > launched as an EFI app) >> >dtb = EFI_UUID config table, + Passage = Passage UUID config table >> >> I don't understand the last line. Where is the passage info / >> bloblist? Do you mean it goes in the HOB list with a UUID? I suppose >> that is the most EFI-compatible way. > > The Passage config table could just contain the "head" of the > blobl
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Tom, On Wed, 3 Nov 2021 at 10:02, Tom Rini wrote: > > On Wed, Nov 03, 2021 at 09:22:58AM +0100, Mark Kettenis wrote: > > > From: Simon Glass > > > Date: Tue, 2 Nov 2021 19:20:51 -0600 > > > > > > Hi Mark, > > > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis > > > wrote: > > > > > > > > > From: Simon Glass > > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > > > Hi François, > > > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > > > >> > > > > > >> Hi François, > > > > > >> > > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > > > > >> wrote: > > > > > >> > > > > > > >> > Hi Simon > > > > > >> > > > > > > >> > Position unchanged on this series: adding fake dts for boards > > > > > >> > that generate their device tree in the dts directory is not > > > > > >> > good. If you have them in documentation the it is acceptable. > > > > > >> > > > > > >> I think we are going to have to disagree on this one. I actually > > > > > >> used > > > > > >> the qemu one in testing/development recently. We have to have a > > > > > >> way to > > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > > >> cases, so far as I know. > > > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée > > > > > > from Qemu saying the same thing. > > > > > > I understand the advanced debug/development scenario you mention. > > > > > > But locating the DT files in the dts directory is mis-leading the > > > > > > contributors to think that they need to compile the DT for the > > > > > > targeted platforms. > > > > > > For your advanced scenario, you can still have the dts in the > > > > > > documentation area, or whatever directory (except dts). compile it > > > > > > and supply to U-Boot. > > > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > > going on. > > > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > > configures the hardware differently such that the addresses in the > > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > > as well as more recently on the rpi 4. > > > > > > So I update my SD card with a new private-binary bootloader and things > > > stop working? I think I can narrow that one down :-) > > > > > > > > We can add a message to U-Boot indicating where the devicetree came > > > > > from, perhaps? That might be useful given everything that is going on. > > > > > > > > > > As in this case, quite often in these discussions I struggle to > > > > > understand what is behind the objection. Is it that your customers are > > > > > demanding that devicetrees become private, secret data, not included > > > > > in open-source projects? Or is it just the strange case of QEMU that > > > > > is informing your thinking? I know of at least one project where the > > > > > first-stage bootloader produces a devicetree and no one has the source > > > > > for it. I believe TF-A was created for licensing reasons...so can you > > > > > be a bit clearer about what the problem actually is? If a board is > > > > > in-tree in U-Boot I would like it to have a devicetree there, at least > > > > > until we have a better option. At the very least, it MUST be > > > > > discoverable and it must be possible to undertake U-Boot development > > > > > easily without a
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Tom, On Wed, 3 Nov 2021 at 09:56, Tom Rini wrote: > > On Tue, Nov 02, 2021 at 07:20:51PM -0600, Simon Glass wrote: > > Hi Mark, > > > > On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote: > > > > > > > From: Simon Glass > > > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > > > > > Hi François, > > > > > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > > > wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > > > >> > > > > >> Hi François, > > > > >> > > > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > > > >> wrote: > > > > >> > > > > > >> > Hi Simon > > > > >> > > > > > >> > Position unchanged on this series: adding fake dts for boards that > > > > >> > generate their device tree in the dts directory is not good. If > > > > >> > you have them in documentation the it is acceptable. > > > > >> > > > > >> I think we are going to have to disagree on this one. I actually used > > > > >> the qemu one in testing/development recently. We have to have a way > > > > >> to > > > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > > > >> cases, so far as I know. > > > > > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > > > Qemu saying the same thing. > > > > > I understand the advanced debug/development scenario you mention. > > > > > But locating the DT files in the dts directory is mis-leading the > > > > > contributors to think that they need to compile the DT for the > > > > > targeted platforms. > > > > > For your advanced scenario, you can still have the dts in the > > > > > documentation area, or whatever directory (except dts). compile it > > > > > and supply to U-Boot. > > > > > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > > > has noticed. U-Boot handles the build automatically. If you turn off > > > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > > > going on. > > > > > > Until. The Raspberry Pi foundation releases a new firmware that > > > configures the hardware differently such that the addresses in the > > > U-Boot devicetree are wrong and nothing works anymore. Can't speak > > > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > > > as well as more recently on the rpi 4. > > > > So I update my SD card with a new private-binary bootloader and things > > stop working? I think I can narrow that one down :-) > > Well, wait, no, this is the point. You can just not update your board. > But that all of the users running a more recent release are now broken > is the problem. It's already an opt-in thing to use U-Boot on Pis and > if we make it even more annoying to be recent, there'll be even less > reason to use U-Boot over over the Pi+TianoCore if you want anything > more fancy that direct-to-Linux booting. This is all totally in the weeds at this point. What are you referring to? I'm talking about turning off OF_BOARD in my private build of U-Boot so that it picks up the devicetree built with U-Boot. I thought that was what Mark was saying...? Regards, Simon
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Tom, On Wed, 27 Oct 2021 at 13:25, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 12:23:21PM -0600, Simon Glass wrote: > > Hi François, > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > wrote: > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > >> wrote: > > >> > > > >> > Hi Simon > > >> > > > >> > Position unchanged on this series: adding fake dts for boards that > > >> > generate their device tree in the dts directory is not good. If you > > >> > have them in documentation the it is acceptable. > > >> > > >> I think we are going to have to disagree on this one. I actually used > > >> the qemu one in testing/development recently. We have to have a way to > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > >> cases, so far as I know. > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > Qemu saying the same thing. > > > I understand the advanced debug/development scenario you mention. > > > But locating the DT files in the dts directory is mis-leading the > > > contributors to think that they need to compile the DT for the targeted > > > platforms. > > > For your advanced scenario, you can still have the dts in the > > > documentation area, or whatever directory (except dts). compile it and > > > supply to U-Boot. > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > has noticed. U-Boot handles the build automatically. If you turn off > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > going on. > > That we have to have so many separate rpi build targets, and can't just > use rpm_arm64 and add rpi_arm32 is not a good feature. The various rpi > configs that use CONFIG_OF_EMBED are on your list of things that need to > be cleaned up, yes? Yes, it should use CONFIG_OF_SEPARATE. It think it didn't for historical reasons, but not sure why. > > > We can add a message to U-Boot indicating where the devicetree came > > from, perhaps? That might be useful given everything that is going on. > > > > As in this case, quite often in these discussions I struggle to > > understand what is behind the objection. Is it that your customers are > > demanding that devicetrees become private, secret data, not included > > in open-source projects? Or is it just the strange case of QEMU that > > is informing your thinking? I know of at least one project where the > > first-stage bootloader produces a devicetree and no one has the source > > for it. I believe TF-A was created for licensing reasons...so can you > > be a bit clearer about what the problem actually is? If a board is > > in-tree in U-Boot I would like it to have a devicetree there, at least > > until we have a better option. At the very least, it MUST be > > discoverable and it must be possible to undertake U-Boot development > > easily without a lot of messing around. > > What I don't understand here is why or how U-Boot is supposed to become > the source of truth for device trees. The general goal is that the > device tree be something that actually comes along on the hardware, > because it's stable enough and correct enough that it's not going to be > changed from one OS kernel release to the next. That should be where > the correct and true tree comes from, the device itself. Is that the confusion here? I am not saying that U-Boot becomes the 'source of truth' (horrible term). Where did that idea come from? By hardware you mean firmware, I think. If you are developing firmware, you need control of the devicetree. It is part of the firmware. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Tue, 2 Nov 2021 at 10:57, Tom Rini wrote: > > On Tue, Nov 02, 2021 at 08:59:45AM -0600, Simon Glass wrote: > > Hi François, > > > > On Mon, 1 Nov 2021 at 11:33, François Ozog wrote: > > > > > > Hi Simon > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > >> > > >> Hi Peter, > > >> > > >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > >> wrote: > > >> > > > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > >> > > > > >> > > Add this file, generated from qemu, so there is a reference > > >> > > devicetree > > >> > > in the U-Boot tree. > > >> > > > > >> > > Signed-off-by: Simon Glass > > >> > > > >> > Note that the dtb you get from QEMU is only guaranteed to work if: > > >> > 1) you run it on the exact same QEMU version you generated it with > > >> > 2) you pass QEMU the exact same command line arguments you used > > >> > when you generated it > > >> > > >> Yes, I certainly understand that. In general this is not safe, but in > > >> practice it works well enough for development and CI. > > > > > > You recognize that you hijack a product directory with development hack > > > facility. There is a test directory to keep things clear. There can be a > > > dev-dts or something similar for Dev time tools. > > > I have only seen push back on those fake dts files in the dts directory: > > > I guess that unless someone strongly favors a continuation of the > > > discussion, you may consider re-shaping the proposal to address concerns. > > > > As stated previously, I would like to have at least a sample DT > > in-tree for all boards. I cannot see another way to get the Kconfig > > What's the point of having a sample when it's not going to always be > correct or may be actively wrong and we can tell interested developers / > users how to get the correct DTB/DTS to examine? > > > options in line. If we are able to put these files somewhere else in > > the future and get them out of U-Boot, with perhaps just an overlay > > for development purposes, I'd be keen to see it. But for now, this is > > where we are, I believe. > > > > In this particular case, this is not just a dev hack. It is also for > > CI tests which need to use a devicetree. See for example here: > > > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ > > https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ > > This example would probably be better done on vexpress_ca9x4 where we do > test in CI via QEMU but do not need to modify a device tree that is > passed on to us, we already control the source of truth DTB in this > case. But that board: - uses OF_EMBED, which it should not - does not use SPL, which I need > > And also yes, I'm behind on reviewing things I need to review. Aren't we all...I can't even keep up with these threads. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Tue, 2 Nov 2021 at 11:28, Tom Rini wrote: > > On Tue, Nov 02, 2021 at 09:00:53AM -0600, Simon Glass wrote: > > Hi Tom, > > > > On Mon, 1 Nov 2021 at 12:07, Tom Rini wrote: > > > > > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > > > > Hi Simon > > > > > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > > > > > > > > Hi Peter, > > > > > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > > > wrote: > > > > > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > > > > > > > Add this file, generated from qemu, so there is a reference > > > > > > > devicetree > > > > > > > in the U-Boot tree. > > > > > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > > > > > 1) you run it on the exact same QEMU version you generated it with > > > > > > 2) you pass QEMU the exact same command line arguments you used > > > > > > when you generated it > > > > > > > > > > Yes, I certainly understand that. In general this is not safe, but in > > > > > practice it works well enough for development and CI. > > > > > > > > You recognize that you hijack a product directory with development hack > > > > facility. There is a test directory to keep things clear. There can be a > > > > dev-dts or something similar for Dev time tools. > > > > I have only seen push back on those fake dts files in the dts > > > > directory: I > > > > guess that unless someone strongly favors a continuation of the > > > > discussion, > > > > you may consider re-shaping the proposal to address concerns. > > > > > > Yes. We need to document how to make development easier. But I'm still > > > not on board with the notion of including DTS files for platforms where > > > the source of truth for the DTB is elsewhere. That's going to bring us > > > a lot more pain. > > > > Are you talking about QEMU specifically, or Raspberry Pi? > > I was using two of the more common and readily available platforms where > the source of truth for the DTS/DTB is not (and will not be) U-Boot. > > > How can we get this resolved? I very much want to get to just having > > OF_SEPARATE and OF_EMBED as the only available build-time options, > > with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for > > runtime support. I feel that separating the build-time and run-time > > behaviour is very important. Over time perhaps we will have some > > success in upstreaming bindings, but for now we have what we have. > > There is still a lot of pushback on U-Boot having things in the > > devicetree, although I do see that softening somewhat. > > > To reiterate, the uniform bit of feedback on this series has been that > everyone else disagrees with your notion that we _must_ have a dts > in-tree. [I would like everyone to take a deep breath and think about what this actually impacts. I argue the impact outside U-Boot is approximately zero. What are we actually discussing here?] A few have responded that they can just add the files. I think that is the case for everything except QEMU, right? I think even François agrees with the documentation argument. There is no real burden in adding the files so we can see what is going on, add a binman node, SPL nodes, etc. So I am going to stand my ground on that one. It affects: - highbank - qemu-ppce500 - rpi_4 - xilinx_versal_virt - octeontx - xenguest_arm64 - juno So that is just 7 boards that I want to add devicetree files for. I think that is reasonable and not a burden on these maintainers. Let me deal with QEMU. Let's imagine that we were in the state that I am proposing here, which we would be if I were a better devicetree maintainer for U-Boot and had not taken my eye off the ball, basically with my review of [1], where I should have pushed to get a response on the questions before it was applied. That might have triggered me to think about the implications of this at the time. Anyway, in the state that I am proposing, what problems would we have? 1. QEMU has a DT which only matches the 'standard' invocation as documented at [2] 2. QEMU may get out of date if there is a new release. I don't think (1) is really a problem. People will have to rem
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi François, On Wed, 27 Oct 2021 at 14:07, François Ozog wrote: > > Hi Simon > > Le mer. 27 oct. 2021 à 20:23, Simon Glass a écrit : >> >> Hi François, >> >> On Wed, 27 Oct 2021 at 09:14, François Ozog wrote: >> > >> > >> > >> > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: >> >> >> >> Hi François, >> >> >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog >> >> wrote: >> >> > >> >> > Hi Simon >> >> > >> >> > Position unchanged on this series: adding fake dts for boards that >> >> > generate their device tree in the dts directory is not good. If you >> >> > have them in documentation the it is acceptable. >> >> >> >> I think we are going to have to disagree on this one. I actually used >> >> the qemu one in testing/development recently. We have to have a way to >> >> develop in-tree with U-Boot. It does not impinge on any of your use >> >> cases, so far as I know. >> > >> > I am not the only one in disagreement... You just saw Alex Bénée from Qemu >> > saying the same thing. >> > I understand the advanced debug/development scenario you mention. >> > But locating the DT files in the dts directory is mis-leading the >> > contributors to think that they need to compile the DT for the targeted >> > platforms. >> > For your advanced scenario, you can still have the dts in the >> > documentation area, or whatever directory (except dts). compile it and >> > supply to U-Boot. >> >> We have this situation with rpi 1, 2 and 3 and I don't believe anyone >> has noticed. U-Boot handles the build automatically. If you turn off >> OF_BOARD, it will use the U-Boot devicetree always so you know what is >> going on. >> >> We can add a message to U-Boot indicating where the devicetree came >> from, perhaps? That might be useful given everything that is going on. >> >> As in this case, quite often in these discussions I struggle to >> understand what is behind the objection. Is it that your customers are >> demanding that devicetrees become private, secret data, not included >> in open-source projects? Or is it just the strange case of QEMU that >> is informing your thinking? I know of at least one project where the >> first-stage bootloader produces a devicetree and no one has the source >> for it. I believe TF-A was created for licensing reasons...so can you >> be a bit clearer about what the problem actually is? > > there are situations where U-Boot must have a dtb. Then those dTB sources are > logically found in the dts directory. > There are situations where U-Boot should not have a dtb. In that case there > should be no element in the dts directory. Otherwise it creates confusion. > Now as you point out, we need “playgrounds” to deal with some situation. So > having examples in an ad-hoc directory, different from dts is fine. I > proposed documentation but you may find a better place. > In other words, dts shall host only dt source when U-Boot cannot do but make > a dTB for a platform. > As you have seen in different mail thread (firmware sustainability and OCP > checklist) freedom is important to Linaro and there are no hidden Trojan > horse for licensing. I don't understand what you are getting at with the Trojan horse. But you have no objection to requiring boards to supply a DT (whether in documentation or arch/arm/dts) to be in U-Boot? > > >> If a board is >> in-tree in U-Boot I would like it to have a devicetree there, at least >> until we have a better option. At the very least, it MUST be >> discoverable and it must be possible to undertake U-Boot development >> easily without a lot of messing around. > > You can if you keep two dts directories separate: > dts for boards for which U-Boot must have one > debug-dts for boards for which U-Boot get the DT at runtime but for which you > want a playground for debug/easier development. >> >> >> >> >> >> >> >> But trying to do any driver / core work for a board where you don't >> >> have the devicetree is currently not possible. The devicetree is a >> >> core component and being unable to modify it is simply not practical. >> >> We are talking here about an option that can be enabled or disabled. >> >> In my case I am able to disable it locally and do my development work. >> >> >> >> >> >> BTW I've got the bloblist handoff working with a devi
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi Mark, On Wed, 27 Oct 2021 at 16:30, Mark Kettenis wrote: > > > From: Simon Glass > > Date: Wed, 27 Oct 2021 12:23:21 -0600 > > > > Hi François, > > > > On Wed, 27 Oct 2021 at 09:14, François Ozog > > wrote: > > > > > > > > > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: > > >> > > >> Hi François, > > >> > > >> On Tue, 26 Oct 2021 at 00:07, François Ozog > > >> wrote: > > >> > > > >> > Hi Simon > > >> > > > >> > Position unchanged on this series: adding fake dts for boards that > > >> > generate their device tree in the dts directory is not good. If you > > >> > have them in documentation the it is acceptable. > > >> > > >> I think we are going to have to disagree on this one. I actually used > > >> the qemu one in testing/development recently. We have to have a way to > > >> develop in-tree with U-Boot. It does not impinge on any of your use > > >> cases, so far as I know. > > > > > > I am not the only one in disagreement... You just saw Alex Bénée from > > > Qemu saying the same thing. > > > I understand the advanced debug/development scenario you mention. > > > But locating the DT files in the dts directory is mis-leading the > > > contributors to think that they need to compile the DT for the targeted > > > platforms. > > > For your advanced scenario, you can still have the dts in the > > > documentation area, or whatever directory (except dts). compile it and > > > supply to U-Boot. > > > > We have this situation with rpi 1, 2 and 3 and I don't believe anyone > > has noticed. U-Boot handles the build automatically. If you turn off > > OF_BOARD, it will use the U-Boot devicetree always so you know what is > > going on. > > Until. The Raspberry Pi foundation releases a new firmware that > configures the hardware differently such that the addresses in the > U-Boot devicetree are wrong and nothing works anymore. Can't speak > for the rpi 1, but this has happened in the past for the rpi 2 and 3 > as well as more recently on the rpi 4. So I update my SD card with a new private-binary bootloader and things stop working? I think I can narrow that one down :-) > > > We can add a message to U-Boot indicating where the devicetree came > > from, perhaps? That might be useful given everything that is going on. > > > > As in this case, quite often in these discussions I struggle to > > understand what is behind the objection. Is it that your customers are > > demanding that devicetrees become private, secret data, not included > > in open-source projects? Or is it just the strange case of QEMU that > > is informing your thinking? I know of at least one project where the > > first-stage bootloader produces a devicetree and no one has the source > > for it. I believe TF-A was created for licensing reasons...so can you > > be a bit clearer about what the problem actually is? If a board is > > in-tree in U-Boot I would like it to have a devicetree there, at least > > until we have a better option. At the very least, it MUST be > > discoverable and it must be possible to undertake U-Boot development > > easily without a lot of messing around. > > How many people are there out there that work on U-Boot that don't > have a Linux source tree checked out? Even I have several of those > lying around on my development systems and I am an OpenBSD developer ;). So it is OK to have the DT in Linux but not in U-Boot? I don't even know what to say that. How does that square with your point above? I am not talking about disabling OF_BOARD, just making it *possible* to do so. Regards, Simon
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Tom, On Mon, 1 Nov 2021 at 12:07, Tom Rini wrote: > > On Mon, Nov 01, 2021 at 06:33:35PM +0100, François Ozog wrote: > > Hi Simon > > > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : > > > > > Hi Peter, > > > > > > On Mon, 1 Nov 2021 at 04:48, Peter Maydell > > > wrote: > > > > > > > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > > > > > > > Add this file, generated from qemu, so there is a reference devicetree > > > > > in the U-Boot tree. > > > > > > > > > > Signed-off-by: Simon Glass > > > > > > > > Note that the dtb you get from QEMU is only guaranteed to work if: > > > > 1) you run it on the exact same QEMU version you generated it with > > > > 2) you pass QEMU the exact same command line arguments you used > > > > when you generated it > > > > > > Yes, I certainly understand that. In general this is not safe, but in > > > practice it works well enough for development and CI. > > > > You recognize that you hijack a product directory with development hack > > facility. There is a test directory to keep things clear. There can be a > > dev-dts or something similar for Dev time tools. > > I have only seen push back on those fake dts files in the dts directory: I > > guess that unless someone strongly favors a continuation of the discussion, > > you may consider re-shaping the proposal to address concerns. > > Yes. We need to document how to make development easier. But I'm still > not on board with the notion of including DTS files for platforms where > the source of truth for the DTB is elsewhere. That's going to bring us > a lot more pain. Are you talking about QEMU specifically, or Raspberry Pi? How can we get this resolved? I very much want to get to just having OF_SEPARATE and OF_EMBED as the only available build-time options, with OF_BOARD (and perhaps OF_PASSAGE) as something we can enable for runtime support. I feel that separating the build-time and run-time behaviour is very important. Over time perhaps we will have some success in upstreaming bindings, but for now we have what we have. There is still a lot of pushback on U-Boot having things in the devicetree, although I do see that softening somewhat. > > It is important to make sure our "develop our project" workflow is sane > and relatively pain free. But that needs to not come by making > sacrifices to the "use our project" outcome. I would hope for example > that the new Pi zero platform is just dtb changes, as far as the linux > kernel is concerned which means that for rpi_arm64 (which uses run time > dtb) it also just works. And that's what we want to see. So long as OF_BOARD is enabled then the flow should work as you expect. Regards, Simon
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi François,
On Thu, 28 Oct 2021 at 10:26, François Ozog wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 17:44, Simon Glass a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 08:50, François Ozog wrote:
>> >
>> > Hi Simon
>> >
>> > Le jeu. 28 oct. 2021 à 16:30, Simon Glass a écrit :
>> >>
>> >> Hi François,
>> >>
>> >> On Thu, 28 Oct 2021 at 02:21, François Ozog
>> >> wrote:
>> >> >
>> >> > Hi Simon,
>> >> >
>> >> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit :
>> >> >>
>> >> >> Hi Ilias,
>> >> >>
>> >> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> >> 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 sa
Re: [PATCH 00/31] passage: Define a standard for firmware data flow
Hi François, On Mon, 1 Nov 2021 at 02:53, François Ozog wrote: > > Hi Simon, > > this seems a great endeavor. I'd like to better understand the scope of it. > > Is it to be used as part of what could become a U-Boot entry ABI scheme? By > that I mean giving some fixed aspects > to U-Boot entry while letting boards to have flexibility (say for instance > that the first 5 architecture ABI > parameter registers are reserved for U-Boot), and the Passage is about > specifying either those reserved registers > or one of them? The goal is to provide a standard entry scheme for all firmware binaries. Whether it achieves that (or can with some mods) is up for discussion. Re the registers, do you think we need 5? > > Thinking entry ABI, here is what I observed on Arm: > > Linux has two entry ABIs: > - plain: x0 = dtb; > command line = dtb:/chosen/bootargs; initrd = > dtb:/chosen/linux,initrd-* > - EFI: x0=handle, x1=systemtable, x30=return address; >dtb = EFI_UUID config table; initrd = efi: media UUID); command line = efi: image_protocol::load_options > > U-Boot (proper) has plenty of schemes: > - dtb is passed as either x0, x1, fixed memory area (Qemu which is bad in > itself), or other registers > - additional information passing: board specific register scheme, SMC calls > - U-Boot for RPI boards implement a Linux shaped entry ABI to be launched by > Videocore firmware > > Based on all the above, I would tend to think that RPI scheme is a good idea > but also > shall not prevent additional schemes for the boards. I was not actually considering Linux since I believe/assume its entry scheme is fixed and not up for discussion. I also did not think about the EFI case. As I understand it we cannot touch it as it is used by UEFI today. Maybe it is even in the standard? Really I am hoping we can start afresh...? > > What about a U-Boot Arm entry ABI like: > - plain: x0=dtb, x1=, x2-x5 = , other registers > are per platform, SMC calls allowed too Hmm we don't actually need the dtb as it is available in the bloblist. But I added an offset to it as a convenience. > - EFI: x0=handle, x1=systemtable, x30=return address; (when U-Boot is > launched as an EFI app) >dtb = EFI_UUID config table, + Passage = Passage UUID config table I don't understand the last line. Where is the passage info / bloblist? Do you mean it goes in the HOB list with a UUID? I suppose that is the most EFI-compatible way. What do you think about the idea of using an offset into the bloblist for the dtb? Also, can we make the standard passage ABI a build-time option, so it is deterministic? > > We could further leverage Passage to pass Operating Systems parameters that > could be removed from device tree (migration of /chosen to Passage). Memory > inventory would still be in DT but allocations for CMA or GPUs would be in > Passage. This idea is to reach a point where device tree is a "pristine" > hardware description. I'm worried about this becoming a substitute for devicetree. Really my intent is to provide a way to pass simple info, whereas what you talk about there seems like something that should be DT, just that it might need suitable bindings. As you know I have more expansive views about what should be in DT. > > Cheers > > PS: as Ilias mentions, this patch set contains bug fixes, non immediately > related additional functions (DM stats). It would be great to carve those out > to fast path them and keep this one with the very core of your idea. The DM stats is used in 'passage: Report the devicetree source'. I know it is sideways but I think it is better to make the output line more useful than just reporting the devicetree source. The first patch is indeed unrelated. I will pick it up so we can drop it for the next rev. Regards, Simon > > On Mon, 1 Nov 2021 at 02:17, Simon Glass wrote: >> >> >> This series adds a standard way of passing information between different >> firmware phases. This already exists in U-Boot at a very basic level, in >> the form of a bloblist containing an spl_handoff structure, but the intent >> here is to define something useful across projects. >> >> The need for this is growing as firmware fragments into multiple binaries >> each with its own purpose. Without any run-time connection, we must rely >> on build-time settings which are brittle and painful to keep in sync. >> >> This feature is named 'standard passage' since the name is more unique >> than many others that could be chosen, it is a passage in the sense that >> information is flowing from one place to another and it is standard, >> because that is what we want to create. >> >&
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi François, On Mon, 1 Nov 2021 at 11:33, François Ozog wrote: > > Hi Simon > > Le lun. 1 nov. 2021 à 17:58, Simon Glass a écrit : >> >> Hi Peter, >> >> On Mon, 1 Nov 2021 at 04:48, Peter Maydell wrote: >> > >> > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: >> > > >> > > Add this file, generated from qemu, so there is a reference devicetree >> > > in the U-Boot tree. >> > > >> > > Signed-off-by: Simon Glass >> > >> > Note that the dtb you get from QEMU is only guaranteed to work if: >> > 1) you run it on the exact same QEMU version you generated it with >> > 2) you pass QEMU the exact same command line arguments you used >> > when you generated it >> >> Yes, I certainly understand that. In general this is not safe, but in >> practice it works well enough for development and CI. > > You recognize that you hijack a product directory with development hack > facility. There is a test directory to keep things clear. There can be a > dev-dts or something similar for Dev time tools. > I have only seen push back on those fake dts files in the dts directory: I > guess that unless someone strongly favors a continuation of the discussion, > you may consider re-shaping the proposal to address concerns. As stated previously, I would like to have at least a sample DT in-tree for all boards. I cannot see another way to get the Kconfig options in line. If we are able to put these files somewhere else in the future and get them out of U-Boot, with perhaps just an overlay for development purposes, I'd be keen to see it. But for now, this is where we are, I believe. In this particular case, this is not just a dev hack. It is also for CI tests which need to use a devicetree. See for example here: https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-15-...@chromium.org/ https://patchwork.ozlabs.org/project/uboot/patch/20211101011734.1614781-24-...@chromium.org/ >> >> I am able to use >> QEMU versions that differ by two years, partly because I am not trying >> to do anything clever. >> >> I have sent a patch to add an indication of where the devicetree came >> from, to help with visibility on this. Regards, Simon
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Ilias,
On Mon, 1 Nov 2021 at 05:05, Ilias Apalodimas
wrote:
>
> Hi Simon,
>
> On Thu, 28 Oct 2021 at 05:51, Simon Glass wrote:
> >
> > Hi Ilias,
> >
> > On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
> > 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
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Hi Peter, On Mon, 1 Nov 2021 at 04:48, Peter Maydell wrote: > > On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote: > > > > Add this file, generated from qemu, so there is a reference devicetree > > in the U-Boot tree. > > > > Signed-off-by: Simon Glass > > Note that the dtb you get from QEMU is only guaranteed to work if: > 1) you run it on the exact same QEMU version you generated it with > 2) you pass QEMU the exact same command line arguments you used > when you generated it Yes, I certainly understand that. In general this is not safe, but in practice it works well enough for development and CI. I am able to use QEMU versions that differ by two years, partly because I am not trying to do anything clever. I have sent a patch to add an indication of where the devicetree came from, to help with visibility on this. Regards, Simon
[PATCH 14/31] arm: qemu: Add an SPL build
Add an SPL build for qemu so we can test the standard passage feature.
Include a binman definition so that SPL and U-Boot are in the same image.
For now this just boots to a prompt.
Signed-off-by: Simon Glass
---
arch/arm/dts/qemu-arm-u-boot.dtsi| 22 +
arch/arm/mach-qemu/Kconfig | 9
board/emulation/qemu-arm/Kconfig | 23 +++--
board/emulation/qemu-arm/MAINTAINERS | 1 +
board/emulation/qemu-arm/Makefile| 1 +
board/emulation/qemu-arm/spl.c | 27 +++
configs/qemu_arm_spl_defconfig | 72
doc/board/emulation/qemu-arm.rst | 38 +++
8 files changed, 189 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/dts/qemu-arm-u-boot.dtsi
create mode 100644 board/emulation/qemu-arm/spl.c
create mode 100644 configs/qemu_arm_spl_defconfig
diff --git a/arch/arm/dts/qemu-arm-u-boot.dtsi
b/arch/arm/dts/qemu-arm-u-boot.dtsi
new file mode 100644
index 000..2c5c7df62b4
--- /dev/null
+++ b/arch/arm/dts/qemu-arm-u-boot.dtsi
@@ -0,0 +1,22 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/ {
+ binman {
+ u-boot-spl {
+ size = <0x1>;
+ };
+
+ u-boot {
+ };
+ };
+
+ pl011@900 {
+ u-boot,dm-spl;
+ };
+
+};
diff --git a/arch/arm/mach-qemu/Kconfig b/arch/arm/mach-qemu/Kconfig
index 186c3582ebf..ab0651ce0b1 100644
--- a/arch/arm/mach-qemu/Kconfig
+++ b/arch/arm/mach-qemu/Kconfig
@@ -20,6 +20,15 @@ config TARGET_QEMU_ARM_32BIT
select CPU_V7A
select SYS_ARCH_TIMER
+config TARGET_QEMU_ARM_32BIT_SPL
+ bool "ARMv7-A, 32bit with SPL"
+ select ARCH_SUPPORT_PSCI
+ select BOARD_LATE_INIT
+ select CPU_V7A
+ select SYS_ARCH_TIMER
+ select SPL
+ select BINMAN
+
config TARGET_QEMU_ARM_64BIT
bool "ARMv8, 64bit"
select ARM64
diff --git a/board/emulation/qemu-arm/Kconfig b/board/emulation/qemu-arm/Kconfig
index 95dbefa78ba..85fbe7a9a35 100644
--- a/board/emulation/qemu-arm/Kconfig
+++ b/board/emulation/qemu-arm/Kconfig
@@ -1,12 +1,10 @@
-if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
-
-config SYS_TEXT_BASE
- default 0x
+if ARCH_QEMU
config BOARD_SPECIFIC_OPTIONS # dummy
def_bool y
select CMD_QFW
select QFW_MMIO
+ select SUPPORT_SPL
imply VIRTIO_MMIO
imply VIRTIO_PCI
imply VIRTIO_NET
@@ -14,6 +12,13 @@ config BOARD_SPECIFIC_OPTIONS # dummy
endif
+if TARGET_QEMU_ARM_32BIT || TARGET_QEMU_ARM_64BIT
+
+config SYS_TEXT_BASE
+ default 0x
+
+endif
+
if TARGET_QEMU_ARM_64BIT && !TFABOOT
config BOARD_SPECIFIC_OPTIONS
imply SYS_MTDPARTS_RUNTIME
@@ -21,3 +26,13 @@ config BOARD_SPECIFIC_OPTIONS
source "board/emulation/common/Kconfig"
endif
+
+if TARGET_QEMU_ARM_32BIT_SPL
+
+config SPL_TEXT_BASE
+ default 0x
+
+config SYS_TEXT_BASE
+ default 0x0001
+
+endif
diff --git a/board/emulation/qemu-arm/MAINTAINERS
b/board/emulation/qemu-arm/MAINTAINERS
index e757ffc64f1..b79d4ab85b2 100644
--- a/board/emulation/qemu-arm/MAINTAINERS
+++ b/board/emulation/qemu-arm/MAINTAINERS
@@ -4,4 +4,5 @@ S: Maintained
F: board/emulation/qemu-arm/
F: include/configs/qemu-arm.h
F: configs/qemu_arm_defconfig
+F: configs/qemu_arm_spl_defconfig
F: configs/qemu_arm64_defconfig
diff --git a/board/emulation/qemu-arm/Makefile
b/board/emulation/qemu-arm/Makefile
index a22d1237ff4..54635646e07 100644
--- a/board/emulation/qemu-arm/Makefile
+++ b/board/emulation/qemu-arm/Makefile
@@ -1,3 +1,4 @@
# SPDX-License-Identifier: GPL-2.0+
obj-y += qemu-arm.o
+obj-$(CONFIG_SPL_BUILD)+= spl.o
diff --git a/board/emulation/qemu-arm/spl.c b/board/emulation/qemu-arm/spl.c
new file mode 100644
index 000..785177a6c8d
--- /dev/null
+++ b/board/emulation/qemu-arm/spl.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright 2021 Google LLC
+ * Written by Simon Glass
+ */
+
+#include
+#include
+#include
+#include
+
+u32 spl_boot_device(void)
+{
+ return BOOT_DEVICE_BOARD;
+}
+
+static int spl_qemu_load_image(struct spl_image_info *spl_image,
+ struct spl_boot_device *bootdev)
+{
+ spl_image->name = "U-Boot";
+ spl_image->load_addr = spl_get_image_pos();
+ spl_image->entry_point = spl_get_image_pos();
+ flush_cache(spl_image->load_addr, spl_get_image_size());
+
+ return 0;
+}
+SPL_LOAD_IMAGE_METHOD("QEMU", 0, BOOT_DEVICE_BOARD, spl_qemu_load_image);
diff --git a/configs/qemu_arm_spl_defconfig b/configs/qemu_arm_spl_defconfig
new file mode 100644
index 000..a6950584542
--- /dev/null
+++ b/configs/qemu_arm_spl_defconfig
@@ -0,0 +1,72 @@
+CONFIG_ARM=y
+CONFIG_SYS_I
[PATCH 00/31] passage: Define a standard for firmware data flow
This series adds a standard way of passing information between different firmware phases. This already exists in U-Boot at a very basic level, in the form of a bloblist containing an spl_handoff structure, but the intent here is to define something useful across projects. The need for this is growing as firmware fragments into multiple binaries each with its own purpose. Without any run-time connection, we must rely on build-time settings which are brittle and painful to keep in sync. This feature is named 'standard passage' since the name is more unique than many others that could be chosen, it is a passage in the sense that information is flowing from one place to another and it is standard, because that is what we want to create. The implementation is simply a pointer to a bloblist in a register, with an extra register to point to a devicetree, for more complex data, if one is present in the bloblist. This should cover all cases (small memory footprint as well as complex data flow) and be easy enough to implement on all architectures. The core bloblist code is relicensed to BSD-3-Clause in case it is useful in non-GPL projects but there is no requirement to use the same code. This series includes tweaks to the bloblist implementation in U-Boot to make it more suitable for the task, including: - Allocate tags explicitly in the enum - Put the magic number first - Define a process for adding tags The emphasis is on enabling open communcation between binaries, not enabling passage of secret, undocumented data, although this is possible in a private environment. This series is built on the OF_BOARD series It is available at u-boot-dm/pass-working or: https://source.denx.de/u-boot/custodians/u-boot-dm/-/commit/073b5c156f222c69a98b8ebcaa563d1ff10eb217 Simon Glass (31): Makefile: Correct TPL rule for OF_REAL kconfig: Add support for conditional values dm: core: Allow getting some basic stats stddef: Avoid warning with clang with offsetof() fdt: Drop SPL_BUILD macro bloblist: Put the magic number first bloblist: Rename the SPL tag bloblist: Drop unused tags bloblist: Use explicit numbering for the tags bloblist: Support allocating the bloblist bloblist: Use LOG_CATEGORY to simply logging bloblist: Use 'phase' consistently for bloblists bloblist: Refactor Kconfig to support alloc or fixed arm: qemu: Add an SPL build bloblist: Add functions to obtain base address and size passage: Support an incoming passage passage: Support a control devicetree passage: arm: Accept a passage from the previous phase passage: spl: Support adding the dtb to the passage bloblist passage: spl: Support passing the passage to U-Boot passage: Record where the devicetree came from passage: Report the devicetree source passage: Add a qemu test for ARM bloblist: doc: Bring in the API documentation bloblist: Relicense to allow BSD-3-Clause sandbox: Add a way of checking structs for standard passage passage: Add documentation passage: Add docs for spl_handoff x86: Move Intel GNVS file into the common include directory passage: Add checks for pre-existing blobs WIP: RFC: Add a gitlab test .gitlab-ci.yml| 6 + MAINTAINERS | 10 + Makefile | 2 +- arch/arm/cpu/armv7/start.S| 7 +- arch/arm/dts/qemu-arm-u-boot.dtsi | 22 ++ arch/arm/lib/crt0.S | 4 + arch/arm/mach-qemu/Kconfig| 9 + arch/sandbox/cpu/spl.c| 2 +- arch/x86/cpu/apollolake/acpi.c| 2 +- arch/x86/cpu/broadwell/cpu_from_spl.c | 4 +- arch/x86/cpu/intel_common/acpi.c | 2 +- .../include/asm/arch-apollolake/global_nvs.h | 2 +- arch/x86/lib/spl.c| 2 +- arch/x86/lib/tpl.c| 2 +- board/emulation/qemu-arm/Kconfig | 23 +- board/emulation/qemu-arm/MAINTAINERS | 1 + board/emulation/qemu-arm/Makefile | 1 + board/emulation/qemu-arm/spl.c| 27 ++ board/google/chromebook_coral/coral.c | 2 +- board/sandbox/Makefile| 3 +- board/sandbox/stdpass_check.c | 107 ++ cmd/bdinfo.c | 2 + common/Kconfig| 161 - common/bloblist.c | 124 +-- common/board_f.c | 48 ++- common/board_r.c | 18 + common/spl/spl.c | 74 +++- configs/qemu_arm_spl_defconfig| 78 + doc/board/emulation/qemu-arm.rst | 38 +++ doc/develop/bloblist.rst | 28 +- doc/develop/index.rst | 1 + doc/develop/std_passage.rst
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi François,
On Thu, 28 Oct 2021 at 08:50, François Ozog wrote:
>
> Hi Simon
>
> Le jeu. 28 oct. 2021 à 16:30, Simon Glass a écrit :
>>
>> Hi François,
>>
>> On Thu, 28 Oct 2021 at 02:21, François Ozog wrote:
>> >
>> > Hi Simon,
>> >
>> > Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit :
>> >>
>> >> Hi Ilias,
>> >>
>> >> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> >> 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 *
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi François,
On Thu, 28 Oct 2021 at 02:21, François Ozog wrote:
>
> Hi Simon,
>
> Le jeu. 28 oct. 2021 à 04:51, Simon Glass a écrit :
>>
>> Hi Ilias,
>>
>> On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
>> 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 intern
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Ilias,
On Tue, 26 Oct 2021 at 00:46, Ilias Apalodimas
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
Re: [PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
Hi all, On Wed, 27 Oct 2021 at 08:56, Tom Rini wrote: > > On Wed, Oct 27, 2021 at 03:44:08PM +0100, Alex Bennée wrote: > > > > François Ozog 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
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi François, On Wed, 27 Oct 2021 at 09:14, François Ozog wrote: > > > > On Wed, 27 Oct 2021 at 16:08, Simon Glass wrote: >> >> Hi François, >> >> On Tue, 26 Oct 2021 at 00:07, François Ozog wrote: >> > >> > Hi Simon >> > >> > Position unchanged on this series: adding fake dts for boards that >> > generate their device tree in the dts directory is not good. If you have >> > them in documentation the it is acceptable. >> >> I think we are going to have to disagree on this one. I actually used >> the qemu one in testing/development recently. We have to have a way to >> develop in-tree with U-Boot. It does not impinge on any of your use >> cases, so far as I know. > > I am not the only one in disagreement... You just saw Alex Bénée from Qemu > saying the same thing. > I understand the advanced debug/development scenario you mention. > But locating the DT files in the dts directory is mis-leading the > contributors to think that they need to compile the DT for the targeted > platforms. > For your advanced scenario, you can still have the dts in the documentation > area, or whatever directory (except dts). compile it and supply to U-Boot. We have this situation with rpi 1, 2 and 3 and I don't believe anyone has noticed. U-Boot handles the build automatically. If you turn off OF_BOARD, it will use the U-Boot devicetree always so you know what is going on. We can add a message to U-Boot indicating where the devicetree came from, perhaps? That might be useful given everything that is going on. As in this case, quite often in these discussions I struggle to understand what is behind the objection. Is it that your customers are demanding that devicetrees become private, secret data, not included in open-source projects? Or is it just the strange case of QEMU that is informing your thinking? I know of at least one project where the first-stage bootloader produces a devicetree and no one has the source for it. I believe TF-A was created for licensing reasons...so can you be a bit clearer about what the problem actually is? If a board is in-tree in U-Boot I would like it to have a devicetree there, at least until we have a better option. At the very least, it MUST be discoverable and it must be possible to undertake U-Boot development easily without a lot of messing around. >> >> >> But trying to do any driver / core work for a board where you don't >> have the devicetree is currently not possible. The devicetree is a >> core component and being unable to modify it is simply not practical. >> We are talking here about an option that can be enabled or disabled. >> In my case I am able to disable it locally and do my development work. >> >> >> BTW I've got the bloblist handoff working with a devicetree inside it, >> for qemu_arm. I need to try it on a real board to figure out what the >> difference is. >> > That's great news and much needed for stabilizing the inbound ABI from prior > loader to U-Boot. Let's create another thread to discuss this important topic. >> My scenario is not all that advanced and I am using qemu_arm to test the bloblist handoff stuff and include it in CI, with a suitable devicetree and a binman node. Regards, Simon >> > >> > Cheers >> > >> > FF >> > >> > Le mar. 26 oct. 2021 à 02:24, Simon Glass a écrit : >> >> >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> >> there are only three ways to obtain a devicetree: >> >> >> >>- OF_SEPARATE - the normal way, where the devicetree is built and >> >> appended to U-Boot >> >>- OF_EMBED - for development purposes, the devicetree is embedded in >> >> the ELF file (also used for EFI) >> >>- OF_BOARD - the board figures it out on its own >> >> >> >> The last one is currently set up so that no devicetree is needed at all >> >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> >> don't even provide instructions on how to boot on the board. >> >> >> >> The problems with this approach are documented in another patch in this >> >> series: "doc: Add documentation about devicetree usage" >> >> >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> >> can obtain its devicetree at runtime, even it is has a devicetree built >> >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> >> caller may have a better idea about the hardware avai
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Mark, On Wed, 27 Oct 2021 at 09:11, Mark Kettenis wrote: > > > From: François Ozog > > Date: Wed, 27 Oct 2021 15:15:01 +0200 > > > > Hi, > > > > On Wed, 27 Oct 2021 at 14:48, Tom Rini 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 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 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.o...@linaro.org> wrote: > > > > > > > > > > > > > > > > > > Hi Simon > > > > > > > > > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass > > > a écrit : > > > > > > > > >> > > > > > > > > >> Hi Tom, Bin,François, > > > > > > > > >> > > > > > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini > > > 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 < > > > s...@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. > > > > > > > > >> > > > > > > > > > > > >> > &g
Re: [PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
Hi François, On Tue, 26 Oct 2021 at 00:07, François Ozog wrote: > > Hi Simon > > Position unchanged on this series: adding fake dts for boards that generate > their device tree in the dts directory is not good. If you have them in > documentation the it is acceptable. I think we are going to have to disagree on this one. I actually used the qemu one in testing/development recently. We have to have a way to develop in-tree with U-Boot. It does not impinge on any of your use cases, so far as I know. But trying to do any driver / core work for a board where you don't have the devicetree is currently not possible. The devicetree is a core component and being unable to modify it is simply not practical. We are talking here about an option that can be enabled or disabled. In my case I am able to disable it locally and do my development work. BTW I've got the bloblist handoff working with a devicetree inside it, for qemu_arm. I need to try it on a real board to figure out what the difference is. Regards, Simon > > > Cheers > > FF > > Le mar. 26 oct. 2021 à 02:24, Simon Glass a écrit : >> >> With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so >> there are only three ways to obtain a devicetree: >> >>- OF_SEPARATE - the normal way, where the devicetree is built and >> appended to U-Boot >>- OF_EMBED - for development purposes, the devicetree is embedded in >> the ELF file (also used for EFI) >>- OF_BOARD - the board figures it out on its own >> >> The last one is currently set up so that no devicetree is needed at all >> in the U-Boot tree. Most boards do provide one, but some don't. Some >> don't even provide instructions on how to boot on the board. >> >> The problems with this approach are documented in another patch in this >> series: "doc: Add documentation about devicetree usage" >> >> In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board >> can obtain its devicetree at runtime, even it is has a devicetree built >> in U-Boot. This is because U-Boot may be a second-stage bootloader and its >> caller may have a better idea about the hardware available in the machine. >> This is the case with a few QEMU boards, for example. >> >> So it makes no sense to have OF_BOARD as a 'choice'. It should be an >> option, available with either OF_SEPARATE or OF_EMBED. >> >> This series makes this change, adding various missing devicetree files >> (and placeholders) to make the build work. >> >> Note: If board maintainers are able to add their own patch to add the >> files, some patches in this series can be dropped. >> >> It also provides a few qemu clean-ups discovered along the way. >> >> Note: This breaks the qemu-riscv64_spl test, which still needs >> investigation. >> >> [1] >> https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ >> >> Changes in v5: >> - Bring into the OF_BOARD series >> - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed >> - Refer to the 'control' DTB in the first paragraph >> - Use QEMU instead of qemu >> - Merge RISC-V and ARM patches since they are similar >> - Add new patches to clean up fdtdec_setup() and surrounds >> >> Changes in v3: >> - Clarify the 'bug' refered to at the top >> - Reword 'This means that there' paragraph to explain U-Boot-specific things >> - Move to doc/develop/devicetree now that OF_CONTROL is in the docs >> >> Changes in v2: >> - Fix typos per Sean (thank you!) and a few others >> - Add a 'Use of U-Boot /config node' section >> - Drop mention of dm-verity since that actually uses the kernel cmdline >> - Explain that OF_BOARD will still work after these changes (in >> 'Once this bug is fixed...' paragraph) >> - Expand a bit on the reason why the 'Current situation' is bad >> - Clarify in a second place that Linux and U-Boot use the same devicetree >> in 'To be clear, while U-Boot...' >> - Expand on why we should have rules for other projects in >> 'Devicetree in another project' >> - Add a comment as to why devicetree in U-Boot is not 'bad design' >> - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' >> - Rewrite 'Devicetree generated on-the-fly in another project' to cover >> points raised on v1 >> - Add 'Why does U-Boot have its nodes and properties?' >> - Add 'Why not have two devicetree
[PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
(no changes since v1)
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 7ab8b145f3f..e70293bb849 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1153,7 +1153,7 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) +=
imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
-dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb qemu-arm64.dtb
targets += $(dtb-y)
diff --git a/arch/arm/dts/qemu-arm64.dts b/arch/arm/dts/qemu-arm64.dts
new file mode 100644
index 000..7590e49cc84
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm64
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0xc405>;
+ cpu_on = <0xc403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0xc401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ 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;
+ i
[PATCH v5 07/26] riscv: qemu: Add devicetree files for qemu_riscv32/64
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass
---
(no changes since v1)
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++
arch/riscv/dts/qemu-virt64.dts | 217 +++
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@1010 {
+ dma-coherent;
+ reg = <0x00 0x1010 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@2000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x2000 0x00 0x200
+ 0x00 0x2200 0x00 0x200>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@1000";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x00 0x8000 0x00 0x800>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@1000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <
[PATCH v5 04/26] arm: riscv: qemu: Explain how to extract the generated dt
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Also explain how to merge it to produce a devicetree with the U-Boot features included. Signed-off-by: Simon Glass --- Changes in v5: - Merge RISC-V and ARM patches since they are similar doc/board/emulation/qemu-arm.rst | 3 ++ doc/board/emulation/qemu-riscv.rst | 3 ++ doc/develop/devicetree/dt_qemu.rst | 48 ++ doc/develop/devicetree/index.rst | 1 + 4 files changed, 55 insertions(+) create mode 100644 doc/develop/devicetree/dt_qemu.rst diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 97b6ec64905..a39df046fc3 100644 --- a/doc/board/emulation/qemu-arm.rst +++ b/doc/board/emulation/qemu-arm.rst @@ -21,6 +21,9 @@ The 'virt' platform provides the following as the basic functionality: Additionally, a number of optional peripherals can be added to the PCI bus. +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. + Building U-Boot --- Set the CROSS_COMPILE environment variable as usual, and run: diff --git a/doc/board/emulation/qemu-riscv.rst b/doc/board/emulation/qemu-riscv.rst index 4b8e104a215..3409fff8117 100644 --- a/doc/board/emulation/qemu-riscv.rst +++ b/doc/board/emulation/qemu-riscv.rst @@ -13,6 +13,9 @@ The QEMU virt machine models a generic RISC-V virtual machine with support for the VirtIO standard networking and block storage devices. It has CLINT, PLIC, 16550A UART devices in addition to VirtIO and it also uses device-tree to pass configuration information to guest software. It implements RISC-V privileged + +See :doc:`../../develop/devicetree/dt_qemu` for information on how to see +the devicetree actually generated by QEMU. architecture spec v1.10. Building U-Boot diff --git a/doc/develop/devicetree/dt_qemu.rst b/doc/develop/devicetree/dt_qemu.rst new file mode 100644 index 000..1392a2cae97 --- /dev/null +++ b/doc/develop/devicetree/dt_qemu.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Devicetree in QEMU +== + +For QEMU on ARM, RISC-V and one PPC target, the devicetree is created on the +fly by QEMU. It is intended for use in Linux but can be used by U-Boot also, +so long as any nodes/properties needed by U-Boot are merged in. + +When `CONFIG_OF_BOARD` is enabled + + +Obtaining the QEMU devicetree +- + +Where QEMU generates its own devicetree to pass to U-Boot tou can use +`-dtb u-boot.dtb` to force QEMU to use U-Boot's in-tree version. + +To obtain the devicetree that qemu generates, add `-machine dumpdtb=qemu.dtb`, +e.g.:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-aarch64 -machine virt -machine dumpdtb=qemu.dtb + +qemu-system-riscv64 -machine virt -machine dumpdtb=qemu.dtb + + +Merging in U-Boot nodes/properties +-- + +Various U-Boot features require nodes and properties in the U-Boot devicetree +and at present QEMU is unaware of these. To use these you must manually merge +in the appropriate pieces. + +One way to do this is with dtc. This command runs dtc on each .dtb file in turn, +to produce a text file. It drops the duplicate header on the qemu one. Then it +joins them up and runs them through dtc to compile the output:: + +qemu-system-arm -machine virt -machine dumpdtb=qemu.dtb +cat <(dtc -I dtb qemu.dtb) <(dtc -I dtb u-boot.dtb |grep -v /dts-v1/) |dtc - -o merged.dtb + +You can then run qemu with the merged devicetree, e.g.:: + +qemu-system-arm -machine virt -nographic -bios u-boot.bin -dtb merged.dtb + +Note that there seems to be a bug in some versions of qemu where the output of +dumpdtb does not quite match what is provided to U-Boot. diff --git a/doc/develop/devicetree/index.rst b/doc/develop/devicetree/index.rst index b5b33dfea0f..fc2fb41b1bb 100644 --- a/doc/develop/devicetree/index.rst +++ b/doc/develop/devicetree/index.rst @@ -12,3 +12,4 @@ build-time and runtime configuration. intro control dt_update + dt_qemu -- 2.33.0.1079.g6e70778dc9-goog
[PATCH v5 05/26] arm: qemu: Add a devicetree file for qemu_arm
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
(no changes since v1)
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 a88aecc5bd9..7ab8b145f3f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -1153,6 +1153,8 @@ dtb-$(CONFIG_TARGET_IMX8MM_CL_IOT_GATE_OPTEE) +=
imx8mm-cl-iot-gate-optee.dtb
dtb-$(CONFIG_TARGET_EA_LPC3250DEVKITV2) += lpc3250-ea3250.dtb
+dtb-$(CONFIG_ARCH_QEMU) += qemu-arm.dtb
+
targets += $(dtb-y)
# Add any required device tree compiler flags here
diff --git a/arch/arm/dts/qemu-arm.dts b/arch/arm/dts/qemu-arm.dts
new file mode 100644
index 000..fed558ced98
--- /dev/null
+++ b/arch/arm/dts/qemu-arm.dts
@@ -0,0 +1,402 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0x8405>;
+ cpu_on = <0x8403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0x8401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ 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&
[PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented in another patch in this series: "doc: Add documentation about devicetree usage" In practice, OF_BOARD is not really distinct from OF_SEPARATE. Any board can obtain its devicetree at runtime, even it is has a devicetree built in U-Boot. This is because U-Boot may be a second-stage bootloader and its caller may have a better idea about the hardware available in the machine. This is the case with a few QEMU boards, for example. So it makes no sense to have OF_BOARD as a 'choice'. It should be an option, available with either OF_SEPARATE or OF_EMBED. This series makes this change, adding various missing devicetree files (and placeholders) to make the build work. Note: If board maintainers are able to add their own patch to add the files, some patches in this series can be dropped. It also provides a few qemu clean-ups discovered along the way. Note: This breaks the qemu-riscv64_spl test, which still needs investigation. [1] https://patchwork.ozlabs.org/project/uboot/patch/20210919215111.3830278-3-...@chromium.org/ Changes in v5: - Bring into the OF_BOARD series - Rebase to master and drop mention of OF_PRIOR_STAGE, since removed - Refer to the 'control' DTB in the first paragraph - Use QEMU instead of qemu - Merge RISC-V and ARM patches since they are similar - Add new patches to clean up fdtdec_setup() and surrounds Changes in v3: - Clarify the 'bug' refered to at the top - Reword 'This means that there' paragraph to explain U-Boot-specific things - Move to doc/develop/devicetree now that OF_CONTROL is in the docs Changes in v2: - Fix typos per Sean (thank you!) and a few others - Add a 'Use of U-Boot /config node' section - Drop mention of dm-verity since that actually uses the kernel cmdline - Explain that OF_BOARD will still work after these changes (in 'Once this bug is fixed...' paragraph) - Expand a bit on the reason why the 'Current situation' is bad - Clarify in a second place that Linux and U-Boot use the same devicetree in 'To be clear, while U-Boot...' - Expand on why we should have rules for other projects in 'Devicetree in another project' - Add a comment as to why devicetree in U-Boot is not 'bad design' - Reword 'in-tree U-Boot devicetree' to 'devicetree source in U-Boot' - Rewrite 'Devicetree generated on-the-fly in another project' to cover points raised on v1 - Add 'Why does U-Boot have its nodes and properties?' - Add 'Why not have two devicetrees?' Ilias Apalodimas (1): sandbox: Remove OF_HOSTFILE Simon Glass (25): doc: Add documentation about devicetree usage arm: qemu: Mention -nographic in the docs arm: riscv: qemu: Explain how to extract the generated dt arm: qemu: Add a devicetree file for qemu_arm arm: qemu: Add a devicetree file for qemu_arm64 riscv: qemu: Add devicetree files for qemu_riscv32/64 arm: rpi: Add a devicetree file for rpi_4 arm: vexpress: Add a devicetree file for juno arm: xenguest_arm64: Add a fake devicetree file arm: octeontx: Add a fake devicetree file arm: xilinx_versal_virt: Add a devicetree file arm: bcm7xxx: Add a devicetree file arm: qemu-ppce500: Add a devicetree file arm: highbank: Add a fake devicetree file fdt: Make OF_BOARD a bool option Drop CONFIG_BINMAN_STANDALONE_FDT doc: Update info on devicetree update fdt: Move MULTI_DTB_FIT handling out of fdtdec_setup() fdt: Drop #ifdefs with MULTI_DTB_FIT fdt: Drop CONFIG_SPL_BUILD check in fdtdec_setup() fdt: Drop #ifdef around board_fdt_blob_setup() fdt: Use if() for fdtcontroladdr check fdt: Drop OF_CONTROL check in fdtdec_setup() fdt: Drop remaining preprocessor macros in fdtdec_setup() fdt: Don't call board_fdt_blob_setup() without OF_BOARD Makefile |7 +- 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 +
[PATCH v5 03/26] arm: qemu: Mention -nographic in the docs
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass --- (no changes since v1) doc/board/emulation/qemu-arm.rst | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/doc/board/emulation/qemu-arm.rst b/doc/board/emulation/qemu-arm.rst index 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.1079.g6e70778dc9-goog
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi all, On Thu, 14 Oct 2021 at 09:28, Tom Rini 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 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 > > > > wrote: > > > > > > > > > > Hi Simon > > > > > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit > > > > > : > > > > >> > > > > >> Hi Tom, Bin,François, > > > > >> > > > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 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 > > > > >> > > 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 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 a
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi François, On Thu, 14 Oct 2021 at 12:13, François Ozog wrote: > > > > Le mer. 13 oct. 2021 à 20:06, Simon Glass a écrit : >> >> Hi François, >> >> On Wed, 13 Oct 2021 at 11:35, François Ozog wrote: >> > >> > Hi Simon >> > >> > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : >> >> >> >> Hi Tom, Bin,François, >> >> >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 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 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 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 us
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Tom, On Thu, 14 Oct 2021 at 08:56, Tom Rini 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 > > wrote: > > > > > > Hi Simon > > > > > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : > > >> > > >> Hi Tom, Bin,François, > > >> > > >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 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 > > >> > > 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 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_ST
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi François, On Wed, 13 Oct 2021 at 11:35, François Ozog wrote: > > Hi Simon > > Le mer. 13 oct. 2021 à 16:49, Simon Glass a écrit : >> >> Hi Tom, Bin,François, >> >> On Tue, 12 Oct 2021 at 19:34, Tom Rini 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 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 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-...@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 abov
Re: [PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
Hi François, On Tue, 12 Oct 2021 at 19:20, François Ozog wrote: > > > > Le mer. 13 oct. 2021 à 03:02, Simon Glass a écrit : >> >> QEMU currently generates a devicetree for use with U-Boot. Explain how to >> obtain it. >> >> Signed-off-by: Simon Glass >> --- >> >> 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=0x900 >> 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
Re: [PATCH 00/16] fdt: Make OF_BOARD a boolean option
Hi Tom, Bin,François, On Tue, 12 Oct 2021 at 19:34, Tom Rini 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 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 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-...@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 sup
[PATCH 02/16] arm: qemu: Explain how to extract the generate devicetree
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass --- 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=0x900 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
[PATCH 04/16] arm: qemu: Add a devicetree file for qemu_arm
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
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 000..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 = <0x8405>;
+ cpu_on = <0x8403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0x8401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001200 {
+ 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
[PATCH 03/16] riscv: qemu: Explain how to extract the generate devicetree
QEMU currently generates a devicetree for use with U-Boot. Explain how to obtain it. Signed-off-by: Simon Glass --- 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
[PATCH 01/16] arm: qemu: Mention -nographic in the docs
Without this option QEMU appears to hang. Add it to avoid confusion. Signed-off-by: Simon Glass --- 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
[PATCH 06/16] riscv: qemu: Add devicetree files for qemu_riscv32/64
Add these files, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Split the existing qemu-virt into two, since we need a different
devicetree for 32- and 64-bit machines.
Signed-off-by: Simon Glass
---
arch/riscv/dts/Makefile | 2 +-
arch/riscv/dts/qemu-virt.dts | 8 -
arch/riscv/dts/qemu-virt32.dts | 217 +++
arch/riscv/dts/qemu-virt64.dts | 217 +++
configs/qemu-riscv32_defconfig | 1 +
configs/qemu-riscv32_smode_defconfig | 1 +
configs/qemu-riscv32_spl_defconfig | 2 +-
configs/qemu-riscv64_defconfig | 1 +
configs/qemu-riscv64_smode_defconfig | 1 +
configs/qemu-riscv64_spl_defconfig | 2 +-
10 files changed, 441 insertions(+), 11 deletions(-)
delete mode 100644 arch/riscv/dts/qemu-virt.dts
create mode 100644 arch/riscv/dts/qemu-virt32.dts
create mode 100644 arch/riscv/dts/qemu-virt64.dts
diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
index b6e9166767b..90d3f35e6e3 100644
--- a/arch/riscv/dts/Makefile
+++ b/arch/riscv/dts/Makefile
@@ -2,7 +2,7 @@
dtb-$(CONFIG_TARGET_AX25_AE350) += ae350_32.dtb ae350_64.dtb
dtb-$(CONFIG_TARGET_MICROCHIP_ICICLE) += microchip-mpfs-icicle-kit.dtb
-dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt.dtb
+dtb-$(CONFIG_TARGET_QEMU_VIRT) += qemu-virt32.dtb qemu-virt64.dtb
dtb-$(CONFIG_TARGET_OPENPITON_RISCV64) += openpiton-riscv64.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNLEASHED) += hifive-unleashed-a00.dtb
dtb-$(CONFIG_TARGET_SIFIVE_UNMATCHED) += hifive-unmatched-a00.dtb
diff --git a/arch/riscv/dts/qemu-virt.dts b/arch/riscv/dts/qemu-virt.dts
deleted file mode 100644
index fecff542b91..000
--- a/arch/riscv/dts/qemu-virt.dts
+++ /dev/null
@@ -1,8 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0+
-/*
- * Copyright (C) 2021, Bin Meng
- */
-
-/dts-v1/;
-
-#include "binman.dtsi"
diff --git a/arch/riscv/dts/qemu-virt32.dts b/arch/riscv/dts/qemu-virt32.dts
new file mode 100644
index 000..3c449413523
--- /dev/null
+++ b/arch/riscv/dts/qemu-virt32.dts
@@ -0,0 +1,217 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2021, Bin Meng
+ */
+
+/dts-v1/;
+
+#include "binman.dtsi"
+
+/ {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "riscv-virtio";
+ model = "riscv-virtio,qemu";
+
+ fw-cfg@1010 {
+ dma-coherent;
+ reg = <0x00 0x1010 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ flash@2000 {
+ bank-width = <0x04>;
+ reg = <0x00 0x2000 0x00 0x200
+ 0x00 0x2200 0x00 0x200>;
+ compatible = "cfi-flash";
+ };
+
+ chosen {
+ bootargs = [00];
+ stdout-path = "/soc/uart@1000";
+ };
+
+ memory@8000 {
+ device_type = "memory";
+ reg = <0x00 0x8000 0x00 0x800>;
+ };
+
+ cpus {
+ #address-cells = <0x01>;
+ #size-cells = <0x00>;
+ timebase-frequency = <0x989680>;
+
+ cpu@0 {
+ phandle = <0x01>;
+ device_type = "cpu";
+ reg = <0x00>;
+ status = "okay";
+ compatible = "riscv";
+ riscv,isa = "rv32imafdcsu";
+ mmu-type = "riscv,sv32";
+
+ interrupt-controller {
+ #interrupt-cells = <0x01>;
+ interrupt-controller;
+ compatible = "riscv,cpu-intc";
+ phandle = <0x02>;
+ };
+ };
+
+ cpu-map {
+
+ cluster0 {
+
+ core0 {
+ cpu = <0x01>;
+ };
+ };
+ };
+ };
+
+ soc {
+ #address-cells = <0x02>;
+ #size-cells = <0x02>;
+ compatible = "simple-bus";
+ ranges;
+
+ rtc@101000 {
+ interrupts = <0x0b>;
+ interrupt-parent = <0x03>;
+ reg = <0x00 0x101000 0x00 0x1000>;
+ compatible = "google,goldfish-rtc";
+ };
+
+ uart@1000 {
+ interrupts = <0x0a>;
+ interrupt-parent = <0x03>;
+ clock-frequency = <0x384000>;
+
[PATCH 05/16] arm: qemu: Add a devicetree file for qemu_arm64
Add this file, generated from qemu, so there is a reference devicetree
in the U-Boot tree.
Signed-off-by: Simon Glass
---
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 000..7590e49cc84
--- /dev/null
+++ b/arch/arm/dts/qemu-arm64.dts
@@ -0,0 +1,381 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/*
+ * Sample device tree for qemu_arm64
+
+ * Copyright 2021 Google LLC
+ */
+
+/dts-v1/;
+
+/ {
+ interrupt-parent = <0x8001>;
+ #size-cells = <0x02>;
+ #address-cells = <0x02>;
+ compatible = "linux,dummy-virt";
+
+ psci {
+ migrate = <0xc405>;
+ cpu_on = <0xc403>;
+ cpu_off = <0x8402>;
+ cpu_suspend = <0xc401>;
+ method = "hvc";
+ compatible = "arm,psci-0.2\0arm,psci";
+ };
+
+ memory@4000 {
+ reg = <0x00 0x4000 0x00 0x800>;
+ device_type = "memory";
+ };
+
+ platform@c00 {
+ interrupt-parent = <0x8001>;
+ ranges = <0x00 0x00 0xc00 0x200>;
+ #address-cells = <0x01>;
+ #size-cells = <0x01>;
+ compatible = "qemu,platform\0simple-bus";
+ };
+
+ fw-cfg@902 {
+ dma-coherent;
+ reg = <0x00 0x902 0x00 0x18>;
+ compatible = "qemu,fw-cfg-mmio";
+ };
+
+ virtio_mmio@a00 {
+ dma-coherent;
+ interrupts = <0x00 0x10 0x01>;
+ reg = <0x00 0xa00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000200 {
+ dma-coherent;
+ interrupts = <0x00 0x11 0x01>;
+ reg = <0x00 0xa000200 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000400 {
+ dma-coherent;
+ interrupts = <0x00 0x12 0x01>;
+ reg = <0x00 0xa000400 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000600 {
+ dma-coherent;
+ interrupts = <0x00 0x13 0x01>;
+ reg = <0x00 0xa000600 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000800 {
+ dma-coherent;
+ interrupts = <0x00 0x14 0x01>;
+ reg = <0x00 0xa000800 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000a00 {
+ dma-coherent;
+ interrupts = <0x00 0x15 0x01>;
+ reg = <0x00 0xa000a00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000c00 {
+ dma-coherent;
+ interrupts = <0x00 0x16 0x01>;
+ reg = <0x00 0xa000c00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a000e00 {
+ dma-coherent;
+ interrupts = <0x00 0x17 0x01>;
+ reg = <0x00 0xa000e00 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ virtio_mmio@a001000 {
+ dma-coherent;
+ interrupts = <0x00 0x18 0x01>;
+ reg = <0x00 0xa001000 0x00 0x200>;
+ compatible = "virtio,mmio";
+ };
+
+ 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&
[PATCH 00/16] fdt: Make OF_BOARD a boolean option
With Ilias' efforts we have dropped OF_PRIOR_STAGE and OF_HOSTFILE so there are only three ways to obtain a devicetree: - OF_SEPARATE - the normal way, where the devicetree is built and appended to U-Boot - OF_EMBED - for development purposes, the devicetree is embedded in the ELF file (also used for EFI) - OF_BOARD - the board figures it out on its own The last one is currently set up so that no devicetree is needed at all in the U-Boot tree. Most boards do provide one, but some don't. Some don't even provide instructions on how to boot on the board. The problems with this approach are documented 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-...@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 mod
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Wed, 29 Sept 2021 at 03:10, Peter Maydell wrote: > > On Wed, 29 Sept 2021 at 04:01, Simon Glass wrote: > > On Tue, 28 Sept 2021 at 03:21, Peter Maydell > > wrote: > > > So what *is* this patch doing? The subject says "Allow additions to > > > the generated device tree", and the patch adds an option to > > > "Merge a device tree binary (dtb) file into the generated device tree". > > > That sounds exactly like "combine two bits of dtb" -- the one the > > > user provides to the -dtbi option and the one QEMU generates > > > internally. > > > > Yes that's right, but as you say one of them is generated by QEMU. It > > is fixing a problem caused by QEMU's generation of the device tree, > > since it provides no wat to augment the device tree without my patch. > > You can augment it in the guest if you need to add guest-specific stuff. This was also discussed, see below. > > > > > The only current working option is to just pass the U-Boot dtb through > > > > and not use QEMU's on-the-fly-generated dtb at all. But I am assuming > > > > there is a reason why QEMU generates that dtb, so that would not be > > > > desirable? > > > > > > QEMU generates the dtb to tell the guest what hardware is > > > present and where it is. We don't guarantee that that hardware > > > arrangement is necessarily stable between QEMU versions (in > > > practice there are generally additions and not deletions or > > > moves, but in theory there might be). All the guest is supposed > > > to assume is the location of RAM and flash; everything else it > > > must look in the dtb to determine. > > > > Yes, so that is going to severely limit the usefulness of the virtio > > support, for example. But we can just ignore it for CI, I suppose, > > since we can use fixed parameters to QEMU, if you don't want to allow > > more control of the device tree. > > virtio-mmio devices should already be correctly indicated in the > device tree. virtio-pci devices can be found by probing the PCI > bus in the usual way (and you can find out where the PCI controller > is by looking in the dtb). Which device tree? The one generated by QEMU or the one we would actually use, in U-Boot? > > > This patch is really just augmenting what QEMU is already doing and > > solving a problem that it has. I don't see it as creating a new boot > > mechanism or being a weird tweak. If anything, it puts the tweaking in > > the hands of the user. It seems like something you would be keen on, > > from that POV. > > I absolutely see it as a weird tweak. It's something that > only u-boot seems to care about, and it's adding an extra > user-facing command line option that is basically > "if you need to boot u-boot you need this". The user should > not need to "control" the dtb, because QEMU should already > be creating a dtb which describes the hardware it is exposing > to the guest. I don't even know how to respond to that. Anything that uses devicetree for control will need to have its bindings respected. It is QEMU that is confused here, with its idea that if it just creates whatever it feels like, it will be suitable for the payload. It may be suitable for linux because it was coded up that way, but it is not suitable in general. Each project can have its own device tree bindings, yes? See for example barebox which has the same problem: https://www.barebox.org/doc/latest/devicetree/bindings/barebox/barebox,environment.html > > > > Guest software running on the "virt" board needs to know it is > > > running on the "virt" board and deal with the interface and > > > information that QEMU provides. (For instance, Arm Trusted > > > Firmware and UEFI both have done this.) > > > > Well unfortunately this is in conflict, based on what you have said in > > this thread. We can either have virtio support (use QEMU-generated > > device tree) or have U-Boot work correctly (use -dtb). Do you have any > > other ideas? > > I've already suggested what I think you should do: have u-boot > combine the dtb it gets from QEMU with the dtb-extras stuff > it wants for its own purposes, with the latter supplied in > any of a bunch of workable ways (extra file loaded in memory, > concatenate the dtb blob with the u-boot binary at compile > time, whatever; rough analogy with however u-boot gets the > full dtb on hardware platforms where there is none). Unfortunately this is not practical for reasons I explained previously. To recap: - this is not how
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Tue, 28 Sept 2021 at 03:21, Peter Maydell wrote: > > On Mon, 27 Sept 2021 at 21:12, Simon Glass wrote: > > I think you are misunderstanding my patch and that may be the problem here. > > > > Where QEMU is provided with a dtb (-dtb) it uses that and passes it > > on. This is absolutely fine and I have tested that this works well > > with U-Boot. No issues. > > > > Where QEMU creates its own dtb on the fly the -dtb parameter is > > actually ignored and there is no way to adjust what QEMU passes on, > > without recompiling QEMU. It is quite inflexible, actually. Even just > > creating a new device for development purposes is not possible. That > > is the problem I am trying to solve. > > > > There is certainly no intent to combine two bits of dtb with my patch. > > We could easily do that externally to QEMU. > > So what *is* this patch doing? The subject says "Allow additions to > the generated device tree", and the patch adds an option to > "Merge a device tree binary (dtb) file into the generated device tree". > That sounds exactly like "combine two bits of dtb" -- the one the > user provides to the -dtbi option and the one QEMU generates > internally. Yes that's right, but as you say one of them is generated by QEMU. It is fixing a problem caused by QEMU's generation of the device tree, since it provides no wat to augment the device tree without my patch. > > > The only current working option is to just pass the U-Boot dtb through > > and not use QEMU's on-the-fly-generated dtb at all. But I am assuming > > there is a reason why QEMU generates that dtb, so that would not be > > desirable? > > QEMU generates the dtb to tell the guest what hardware is > present and where it is. We don't guarantee that that hardware > arrangement is necessarily stable between QEMU versions (in > practice there are generally additions and not deletions or > moves, but in theory there might be). All the guest is supposed > to assume is the location of RAM and flash; everything else it > must look in the dtb to determine. Yes, so that is going to severely limit the usefulness of the virtio support, for example. But we can just ignore it for CI, I suppose, since we can use fixed parameters to QEMU, if you don't want to allow more control of the device tree. > > > One more question...other than dtb, does QEMU typically add support > > for data structures needed by particular projects or groups of > > projects? It looks like dtb was supported for ARM Linux originally? I > > am looking at supporting bloblist as a way of communicating > > information between firmware (basically a simple way of packaging > > multiple blobs). > > The answer here is essentially "no, as far as possible". We > ideally would not have special case support for any particular > guest code. We do have special handling for "directly boot the > Linux kernel" for a combination of historical reasons (we've > always supported it) and it being a massive use case. But even > that is painful to maintain (it starts off seeming easy but > gradually requires more weird tweaks and handling as CPU > architectures evolve). I really strongly don't want to add > additional categories of guests that QEMU has special case > support for, which is the main driver behind why I'm so negative > about this patchset. This patch is really just augmenting what QEMU is already doing and solving a problem that it has. I don't see it as creating a new boot mechanism or being a weird tweak. If anything, it puts the tweaking in the hands of the user. It seems like something you would be keen on, from that POV. > > Guest software running on the "virt" board needs to know it is > running on the "virt" board and deal with the interface and > information that QEMU provides. (For instance, Arm Trusted > Firmware and UEFI both have done this.) Well unfortunately this is in conflict, based on what you have said in this thread. We can either have virtio support (use QEMU-generated device tree) or have U-Boot work correctly (use -dtb). Do you have any other ideas? Regards, Simon
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Mon, 27 Sept 2021 at 10:50, Peter Maydell wrote: > > On Mon, 27 Sept 2021 at 17:04, Simon Glass wrote: > > On Mon, 27 Sept 2021 at 09:46, Peter Maydell > > wrote: > > > > My take is that this is u-boot doing weird custom things with > > > the DTB that aren't "describe the hardware". You should be able > > > to boot u-boot by putting those custom DTB extra things in a > > > separate blob and having u-boot combine that with the > > > actual DTB when it starts. > > > > Well this is how U-Boot works. Since it doesn't have a user-space > > program to provide configuration / policy, nor a command line to > > provide parameters (except with sandbox[1]), device tree is what it > > uses. All of its driver model and configuration comes from there The > > 'describe the hardware' thing has been discussed to death but U-Boot > > needs board- and arch-specific policy information about the hardware > > so it can actually boot successfully on real systems. > > > > It has been like this since U-Boot started using device tree, some 9 > > years ago! I can't imagine it changing. > > > As to a separate blob, isn't that what I am suggesting with this > > patch? QEMU doesn't support passing two separate dtb blobs to U-Boot, > > nor is there an API for that. > > You're suggesting "QEMU should have machinery for taking two > blobs and combining them and passing one blob to the guest". > I'm suggesting "the guest should combine them" (and the second > blob could be provided via several different existing mechanisms > that amount to 'QEMU provides some ways to load data into guest > ROM or RAM'), because as far as I know no other guest has this > "combine two different bits of dtb for me" requirement. I think you are misunderstanding my patch and that may be the problem here. Where QEMU is provided with a dtb (-dtb) it uses that and passes it on. This is absolutely fine and I have tested that this works well with U-Boot. No issues. Where QEMU creates its own dtb on the fly the -dtb parameter is actually ignored and there is no way to adjust what QEMU passes on, without recompiling QEMU. It is quite inflexible, actually. Even just creating a new device for development purposes is not possible. That is the problem I am trying to solve. There is certainly no intent to combine two bits of dtb with my patch. We could easily do that externally to QEMU. The only current working option is to just pass the U-Boot dtb through and not use QEMU's on-the-fly-generated dtb at all. But I am assuming there is a reason why QEMU generates that dtb, so that would not be desirable? > > > Even if we did that it would require > > code very early in U-Boot to process, which would make it infeasible > > for anything other than QEMU. Ideally QEMU should work the same way as > > other boards. > > Well, real hardware doesn't provide device tree blobs of any > form to u-boot, right? u-boot is just compiled into flash, or > perhaps launched from some other boot ROM, as I understand it. > Where does it get its dtb from then ? The dtb is compiled as part of the U-Boot build. but exists as a separate file. The mechanism for providing the dtb to U-Boot at runtime is somewhat board-specific and we are working on standardising it more. On the rpi for example, it is provided by a FAT file system and first-stage firmware loads that and passes it along to U-Boot. Some systems use TF-A which does a similar thing. Some use U-Boot as a first-stage loader in which case SPL may select a DTB (out of many built by the build) to pass to U-Boot proper. There is also a tool called binman which packages the firmware as it is getting quite complicated: https://u-boot.readthedocs.io/en/latest/develop/package/binman.html > > > As a related point, I am looking at how we pass things between > > firmware components. If we wanted to pass in some initiate state in > > some sort of blob, is it possible to set that up in memory (along with > > the binary) for when QEMU starts emulating? The code and RAM might be > > quite a long way apart so using a single image would involve a lot of > > zeroes. > > The generic-loader is quite good for this sort of thing: > https://qemu-project.gitlab.io/qemu/system/generic-loader.html > You can load raw data files to specific addresses; or you can > load ELF files (which can have multiple segments which get loaded > as the ELF header specifies). You can specify -device generic-loader,... > as many times as you need to to load multiple blobs. OK great, thank you, that looks very useful. One more question...other than dtb, does QEMU typically add support for data structures needed by particular projects or groups of projects? It looks like dtb was supported for ARM Linux originally? I am looking at supporting bloblist as a way of communicating information between firmware (basically a simple way of packaging multiple blobs). https://github.com/ni/u-boot/blob/master/doc/README.bloblist Regards, Simon
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Mon, 27 Sept 2021 at 09:46, Peter Maydell wrote: > > On Mon, 27 Sept 2021 at 16:18, Simon Glass wrote: > > On Mon, 27 Sept 2021 at 02:48, Peter Maydell > > wrote: > > > So what is missing in the QEMU-provided DTB that it needs? > > > > Quite a lot. Here are some examples: > > > > U-Boot has limited pre-relocation memory so tries to avoid > > binding/probing devices that are not used before relocation: > > > > https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support > > It's up to u-boot to decide what it wants to touch and > what it does not. QEMU tells u-boot what all the available > devices are; I don't think we should have extra stuff saying > "and if you are u-boot, do something odd". Do you have familiarity with U-Boot and the space constraints of embedded systems? > > > There is a configuration node (which is likely to change form in > > future releases, but will still be there) > > > > https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt > > I think u-boot should be storing this kind of thing somewhere > else (e.g. as part of the binary blob that is u-boot itself, > or stored in flash or RAM as a separate blob). > > > Then there are various features which put things in U-Boot's control > > dtb, such as verified boot, which adds public keys during signing: > > > > https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135 > > > > More generally, the U-Boot tree has hundreds of files which add > > properties for each board, since we try to keep the U-Boot-specific > > things out of the Linux tree: > > > > $ find . -name *u-boot.dtsi |wc -l > > 398 > > If any of this is actual information about the hardware then you > should sort out getting the bindings documented officially > (which I think is still in the Linux tree), and then QEMU can > provide them. > > > Quite a bit of this is to do with SPL and so far it seems that QEMU > > mostly runs U-Boot proper only, although I see that SPL is starting to > > creep in too in the U-Boot CI. > > > > So at present QEMU is not able to support U-Boot fully. > > My take is that this is u-boot doing weird custom things with > the DTB that aren't "describe the hardware". You should be able > to boot u-boot by putting those custom DTB extra things in a > separate blob and having u-boot combine that with the > actual DTB when it starts. Well this is how U-Boot works. Since it doesn't have a user-space program to provide configuration / policy, nor a command line to provide parameters (except with sandbox[1]), device tree is what it uses. All of its driver model and configuration comes from there The 'describe the hardware' thing has been discussed to death but U-Boot needs board- and arch-specific policy information about the hardware so it can actually boot successfully on real systems. It has been like this since U-Boot started using device tree, some 9 years ago! I can't imagine it changing. As to a separate blob, isn't that what I am suggesting with this patch? QEMU doesn't support passing two separate dtb blobs to U-Boot, nor is there an API for that. Even if we did that it would require code very early in U-Boot to process, which would make it infeasible for anything other than QEMU. Ideally QEMU should work the same way as other boards. As a related point, I am looking at how we pass things between firmware components. If we wanted to pass in some initiate state in some sort of blob, is it possible to set that up in memory (along with the binary) for when QEMU starts emulating? The code and RAM might be quite a long way apart so using a single image would involve a lot of zeroes. Regards, Simon [1] https://u-boot.readthedocs.io/en/latest/arch/sandbox.html
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Mon, 27 Sept 2021 at 02:48, Peter Maydell wrote: > > On Sun, 26 Sept 2021 at 19:55, Simon Glass wrote: > > In the case of U-Boot at least, it uses the devicetree for > > configuration (it is a boot loader, so there is no user space to > > provide configuration). So the current setup is not sufficient to boot > > it correctly in all cases. On the other hand, the 'virt' feature is > > very useful for testing U-Boot, so it would be great to be able to > > support this. > > So what is missing in the QEMU-provided DTB that it needs? Quite a lot. Here are some examples: U-Boot has limited pre-relocation memory so tries to avoid binding/probing devices that are not used before relocation: https://u-boot.readthedocs.io/en/latest/develop/driver-model/design.html#pre-relocation-support There is a configuration node (which is likely to change form in future releases, but will still be there) https://github.com/u-boot/u-boot/blob/master/doc/device-tree-bindings/config.txt Then there are various features which put things in U-Boot's control dtb, such as verified boot, which adds public keys during signing: https://github.com/u-boot/u-boot/blob/master/doc/uImage.FIT/signature.txt#L135 More generally, the U-Boot tree has hundreds of files which add properties for each board, since we try to keep the U-Boot-specific things out of the Linux tree: $ find . -name *u-boot.dtsi |wc -l 398 Quite a bit of this is to do with SPL and so far it seems that QEMU mostly runs U-Boot proper only, although I see that SPL is starting to creep in too in the U-Boot CI. So at present QEMU is not able to support U-Boot fully. It would be great to add this as we use QEMU heavily in CI testing, e.g. see the second column here: https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/9260 Regards, Simon
Re: [PATCH] hw/arm/virt: Allow additions to the generated device tree
Hi Peter, On Sun, 26 Sept 2021 at 12:47, Peter Maydell wrote: > > On Sun, 26 Sept 2021 at 19:34, Simon Glass wrote: > > > > At present qemu creates a device tree automatically with the 'virt' generic > > virtual platform. This is very convenient in most cases but there is not > > much control over what is generated. > > > > Add a way to provide a device tree binary file with additional properties > > to add before booting. This provides flexibility for situations where > > Linux needs some tweak to operate correctly. It also allows configuration > > information to be passed to U-Boot, supporting verified boot, for example. > > So, I'm strongly inclined to say "nope" here. The device > tree virt generates is supposed to entirely describe the > virtual hardware we pass to the guest. If a guest doesn't > work with that, then either we're generating bogus dtb info > or the guest is not handling the dtb we pass it, and one > or the other should be fixed. Thanks for the response. In the case of U-Boot at least, it uses the devicetree for configuration (it is a boot loader, so there is no user space to provide configuration). So the current setup is not sufficient to boot it correctly in all cases. On the other hand, the 'virt' feature is very useful for testing U-Boot, so it would be great to be able to support this. I also forgot to ask about testing, but am happy to add a test if you can give me some pointers. Regards, Simon
[PATCH] hw/arm/virt: Allow additions to the generated device tree
At present qemu creates a device tree automatically with the 'virt' generic
virtual platform. This is very convenient in most cases but there is not
much control over what is generated.
Add a way to provide a device tree binary file with additional properties
to add before booting. This provides flexibility for situations where
Linux needs some tweak to operate correctly. It also allows configuration
information to be passed to U-Boot, supporting verified boot, for example.
The term 'merge' is used here to avoid confusion with device tree overlays,
which are a particular type of format.
Signed-off-by: Simon Glass
---
docs/system/arm/virt.rst | 13 +++-
hw/arm/virt.c| 135 +++
hw/core/machine.c| 20 ++
include/hw/boards.h | 1 +
qemu-options.hx | 8 +++
softmmu/vl.c | 3 +
util/qemu-config.c | 5 ++
7 files changed, 183 insertions(+), 2 deletions(-)
diff --git a/docs/system/arm/virt.rst b/docs/system/arm/virt.rst
index 850787495b..3191e6eebf 100644
--- a/docs/system/arm/virt.rst
+++ b/docs/system/arm/virt.rst
@@ -146,8 +146,17 @@ Hardware configuration information for bare-metal
programming
The ``virt`` board automatically generates a device tree blob ("dtb")
which it passes to the guest. This provides information about the
addresses, interrupt lines and other configuration of the various devices
-in the system. Guest code can rely on and hard-code the following
-addresses:
+in the system.
+
+The optional ``-dtbi`` argument is used to specify a device tree blob to merge
+with this generated device tree, to add any properties required by the guest
but
+not included by qemu. Properties are merged after the generated device tree is
+created, so take precedence over generated properties. This can be useful for
+overriding the ``stdout-path`` for Linux, for example, or to add configuration
+information needed by U-Boot. This is intended for simple nodes and properties
+and does not support use of phandles or device tree overlays.
+
+Guest code can rely on and hard-code the following addresses:
- Flash memory starts at address 0x_
diff --git a/hw/arm/virt.c b/hw/arm/virt.c
index 1d59f0e59f..1d5c9a911a 100644
--- a/hw/arm/virt.c
+++ b/hw/arm/virt.c
@@ -43,6 +43,7 @@
#include "hw/vfio/vfio-calxeda-xgmac.h"
#include "hw/vfio/vfio-amd-xgbe.h"
#include "hw/display/ramfb.h"
+#include
#include "net/net.h"
#include "sysemu/device_tree.h"
#include "sysemu/numa.h"
@@ -292,6 +293,135 @@ static void create_fdt(VirtMachineState *vms)
}
}
+
+/*
+ * From U-Boot v2021.07 (under BSD-2-Clause license)
+ *
+ * This does not use the qemu_fdt interface because that requires node names.
+ * Here we are using offsets.
+ *
+ * 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;
+}
+
+/* Merge nodes and properties into fdt from fdto */
+static int merge_fdt(void *fdt, void *fdto)
+{
+int err;
+
+err = overlay_apply_node(fdt, 0, fdto, 0);
+
