October 2021 - U-Boot

[PATCH v5 00/26] fdt: Make OF_BOARD a boolean option
by Simon Glass 04 Nov '21

04 Nov '21

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-s… 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 ++++ 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 +++ arch/sandbox/cpu/cpu.c | 21 +- arch/sandbox/include/asm/u-boot-sandbox.h | 8 - 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/sandbox64_defconfig | 2 +- configs/sandbox_defconfig | 2 +- configs/sandbox_flattree_defconfig | 2 +- configs/sandbox_noinst_defconfig | 2 +- configs/sandbox_spl_defconfig | 2 +- configs/tools-only_defconfig | 2 +- configs/vexpress_aemv8a_juno_defconfig | 1 + configs/xenguest_arm64_defconfig | 1 + configs/xilinx_versal_virt_defconfig | 1 + doc/board/emulation/qemu-arm.rst | 10 +- doc/board/emulation/qemu-riscv.rst | 3 + doc/develop/devicetree/control.rst | 7 +- doc/develop/devicetree/dt_qemu.rst | 48 + doc/develop/devicetree/dt_update.rst | 498 ++++++ doc/develop/devicetree/index.rst | 2 + dts/Kconfig | 37 +- include/asm-generic/global_data.h | 8 + include/fdtdec.h | 21 +- lib/fdtdec.c | 116 +- scripts/Makefile.spl | 4 +- tools/binman/binman.rst | 20 - 59 files changed, 5560 insertions(+), 164 deletions(-) create mode 100644 arch/arm/dts/bcm2711-rpi-4-b.dts create mode 100644 arch/arm/dts/bcm7xxx.dts create mode 100644 arch/arm/dts/highbank.dts create mode 100644 arch/arm/dts/juno-r2.dts create mode 100644 arch/arm/dts/octeontx.dts create mode 100644 arch/arm/dts/qemu-arm.dts create mode 100644 arch/arm/dts/qemu-arm64.dts create mode 100644 arch/arm/dts/xenguest-arm64.dts create mode 100644 arch/arm/dts/xilinx-versal-virt.dts create mode 100644 arch/powerpc/dts/qemu-ppce500.dts delete mode 100644 arch/riscv/dts/qemu-virt.dts create mode 100644 arch/riscv/dts/qemu-virt32.dts create mode 100644 arch/riscv/dts/qemu-virt64.dts create mode 100644 doc/develop/devicetree/dt_qemu.rst create mode 100644 doc/develop/devicetree/dt_update.rst -- 2.33.0.1079.g6e70778dc9-goog

7 95

[PATCH v2 1/5] rockchip: rk3188-cru-common: sync clock dt-binding header from Linux
by Johan Jonker 04 Nov '21

04 Nov '21

In order to update the DT for rk3066 and rk3188 sync the clock dt-binding header. This is the state as of v5.12 in Linux. Signed-off-by: Johan Jonker <jbx6244(a)gmail.com> Reviewed-by: Heiko Stuebner <heiko(a)sntech.de> --- include/dt-bindings/clock/rk3188-cru-common.h | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/include/dt-bindings/clock/rk3188-cru-common.h b/include/dt-bindings/clock/rk3188-cru-common.h index 1e7931da0c..afad90680f 100644 --- a/include/dt-bindings/clock/rk3188-cru-common.h +++ b/include/dt-bindings/clock/rk3188-cru-common.h @@ -1,4 +1,4 @@ -/* SPDX-License-Identifier: GPL-2.0+ */ +/* SPDX-License-Identifier: GPL-2.0-or-later */ /* * Copyright (c) 2014 MundoReader S.L. * Author: Heiko Stuebner <heiko(a)sntech.de> @@ -59,12 +59,14 @@ #define ACLK_LCDC1 196 #define ACLK_GPU 197 #define ACLK_SMC 198 -#define ACLK_CIF 199 +#define ACLK_CIF1 199 #define ACLK_IPP 200 #define ACLK_RGA 201 #define ACLK_CIF0 202 #define ACLK_CPU 203 #define ACLK_PERI 204 +#define ACLK_VEPU 205 +#define ACLK_VDPU 206 /* pclk gates */ #define PCLK_GRF 320 @@ -125,8 +127,12 @@ #define HCLK_NANDC0 467 #define HCLK_CPU 468 #define HCLK_PERI 469 +#define HCLK_CIF1 470 +#define HCLK_VEPU 471 +#define HCLK_VDPU 472 +#define HCLK_HDMI 473 -#define CLK_NR_CLKS (HCLK_PERI + 1) +#define CLK_NR_CLKS (HCLK_HDMI + 1) /* soft-reset indices */ #define SRST_MCORE 2 -- 2.11.0

3 10

[PATCH v4 0/4] Enhance Measured Boot
by Masahisa Kojima 04 Nov '21

04 Nov '21

This patch series add the following measurement mandated in the TCG PC Client PFP Specification. - SMBIOS tables - GPT disk partition topology - AuditMode and Deployed mode Masahisa Kojima (4): efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: simplify tcg2_measure_secure_boot_variable() efi_loader: add DeployedMode and AuditMode variable measurement include/blk.h | 3 + include/efi_loader.h | 5 +- include/efi_tcg2.h | 27 +++ include/smbios.h | 17 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_boottime.c | 4 +- lib/efi_loader/efi_device_path.c | 27 +++ lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c | 309 ++++++++++++++++++++++++++----- lib/smbios-parser.c | 152 ++++++++++++++- 10 files changed, 487 insertions(+), 60 deletions(-) -- 2.17.1

3 9

Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE
by Rick Chen 04 Nov '21

04 Nov '21

Hi Bin, > From: Bin Meng <bmeng.cn(a)gmail.com> > Sent: Tuesday, October 19, 2021 4:55 PM > To: Alexandre Ghiti <alexandre.ghiti(a)canonical.com> > Cc: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com>; Tom Rini <trini(a)konsulko.com>; Leo Yu-Chi Liang(梁育齊) <ycliang(a)andestech.com>; Rick Jian-Zhi Chen(陳建志) <rick(a)andestech.com>; Pragnesh Patel <pragnesh.patel(a)sifive.com>; Dimitri John Ledkov <dimitri.ledkov(a)canonical.com>; Zong Li <zong.li(a)sifive.com>; Green Wan <green.wan(a)sifive.com>; U-Boot Mailing List <u-boot(a)lists.denx.de> > Subject: Re: [PATCH 1/1] board: sifive: unmatched: enlarge CONFIG_SYS_SPL_MALLOC_SIZE > > On Tue, Oct 19, 2021 at 4:32 PM Alexandre Ghiti <alexandre.ghiti(a)canonical.com> wrote: > > > > Hi, > > > > On Fri, Oct 1, 2021 at 5:35 PM Bin Meng <bmeng.cn(a)gmail.com> wrote: > > > > > > Hi Heinrich, > > > > > > On Fri, Oct 1, 2021 at 7:37 PM Heinrich Schuchardt > > > <heinrich.schuchardt(a)canonical.com> wrote: > > > > > > > > Avoid an error like > > > > > > > > Could not get FIT buffer of 1725952 bytes > > > > check CONFIG_SYS_SPL_MALLOC_SIZE > > > > No device tree specified in SPL image > > > > ### ERROR ### Please RESET the board ### > > > > > > > > Signed-off-by: Heinrich Schuchardt > > > > <heinrich.schuchardt(a)canonical.com> > > > > --- > > > > include/configs/sifive-unmatched.h | 2 +- > > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > > diff --git a/include/configs/sifive-unmatched.h > > > > b/include/configs/sifive-unmatched.h > > > > index f8ad2cce1f..8d3deabdd3 100644 > > > > --- a/include/configs/sifive-unmatched.h > > > > +++ b/include/configs/sifive-unmatched.h > > > > @@ -18,7 +18,7 @@ > > > > #define CONFIG_SPL_BSS_MAX_SIZE 0x00100000 > > > > #define CONFIG_SYS_SPL_MALLOC_START (CONFIG_SPL_BSS_START_ADDR + \ > > > > CONFIG_SPL_BSS_MAX_SIZE) > > > > -#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00100000 > > > > +#define CONFIG_SYS_SPL_MALLOC_SIZE 0x00200000 > > > > > > > > #define CONFIG_SPL_STACK (0x08000000 + 0x001D0000 - \ > > > > GENERATED_GBL_DATA_SIZE) > > > > > > What caused this? > > > > > > Last time this was seen on Ax25-AE350, CONFIG_SPL_SYS_MALLOC_F_LEN > > > was increased, instead of CONFIG_SYS_SPL_MALLOC_SIZE which the error > > > messages point to > > > > > > https://lists.denx.de/pipermail/u-boot/2021-May/449447.html > > > > > > > I fell into the same issue this morning and increasing > > CONFIG_SYS_SPL_MALLOC_SIZE fixed it, though I had to increase it even > > more than Heinrich. > > Is this default build that caused Unmatched boot failure? > > @Rick Chen can you comment on why CONFIG_SPL_SYS_MALLOC_F_LEN was needed on AE350? It is needed for limited memory cases on AE350 platforms. Thanks, Rick > > Regards, > Bin

2 4

[PATCH v3 00/35] efi: Improvements to U-Boot running on top of UEFI
by Simon Glass 04 Nov '21

04 Nov '21

At present U-Boot can be built as an EFI app, but it is really just for testing, with very few features. Instead, the payload build is used for booting on top of UEFI, where U-Boot takes over the machine immediately and supplies its own drivers. But the app could be made more useful. This series provides access to EFI block devices and the video console within U-Boot. It also restructures the app to make it possible to boot a kernel, although further work is needed to implement this. This can be thought of as making U-Boot perform a little like 'grub', in that it runs purely based on UEFI-provided services. Of course a lot more work is required, but this is a start. Note: It would be very useful to include qemu tests of the app and stub in CI. This is available at u-boot-dm/efi-working Changes in v3: - Add new patch to show the system-table revision - Default to 256MB of RAM for U-Boot instead of 32MB - Drop comments that confuse sphinx - Fix 'complicating' typo - Move device_path path change to its own patch - Update minimum RAM to 256MB! - s/qemu/QEMU/ Changes in v2: - Add MAINTAINERS entry - Add a better boot command too - Add a note that EFI_GRAPHICS_OUTPUT_PROTOCOL is used - Add a sentence about what the patch does - Add a work-around to avoid a toolchain crash - Add new patch to drop the OF_EMBED warning for EFI - Add new patch to enable DM_ETH for the app - Add new patch to support the efi command in the app - Add support for creating a partition table with a filesystem inside - Add support for running qemu with just a serial console (no display) - Drop mention of partitions from the commit message - Expand the commit message to make things clearer - Fix 'as' typo - Show the correct interface type with 'part list' - Update documentation - Update the commit message to explain things better - Use log_info() instead of printf() Simon Glass (35): efi: Add a script for building and testing U-Boot on UEFI efi: Enable DM_ETH for the app efi: Drop the OF_EMBED warning for EFI x86: Create a 32/64-bit selection for the app efi: Create a 64-bit app x86: Don't duplicate global_ptr in 64-bit EFI app efi: Add a way to obtain boot services in the app efi: Add video support to the app efi: Add EFI uclass for media efi: Add a media/block driver for EFI block devices efi: Locate all block devices in the app patman: Use a ValueError exception if tools.Run() fails binman: Report an error if test files fail to compile binman: Support reading the offset of an ELF-file symbol binman: Allow timeout to occur in the image or its section binman: Tidy up comments on _DoTestFile() binman: Support updating the dtb in an ELF file efi: serial: Support arrow keys bloblist: Support allocating the bloblist x86: Allow booting a kernel from the EFI app x86: Don't process the kernel command line unless enabled x86: efi: Add room for the binman definition in the dtb efi: Drop device_path from struct efi_priv efi: Add comments to struct efi_priv efi: Fix ll_boot_init() operation with the app efi: Add a few comments to the stub efi: Share struct efi_priv between the app and stub code efi: Move exit_boot_services into a function efi: Check for failure when initing the app efi: Mention that efi_info_get() is only used in the stub efi: Show when allocated pages are used efi: Allow easy selection of serial-only operation efi: Update efi_get_next_mem_desc() to avoid needing a map efi: Support the efi command in the app efi: Show the system-table revision MAINTAINERS | 7 + Makefile | 10 +- arch/sandbox/dts/test.dts | 4 + arch/x86/cpu/efi/payload.c | 17 +- arch/x86/cpu/intel_common/Makefile | 2 +- arch/x86/cpu/u-boot-64.lds | 2 + arch/x86/cpu/x86_64/Makefile | 4 + arch/x86/cpu/x86_64/cpu.c | 32 +- arch/x86/cpu/x86_64/misc.c | 41 +++ arch/x86/dts/Makefile | 2 +- arch/x86/dts/efi-x86_app.dts | 4 + arch/x86/lib/bootm.c | 11 +- arch/x86/lib/zimage.c | 13 +- board/efi/Kconfig | 15 +- board/efi/efi-x86_app/Kconfig | 6 +- board/efi/efi-x86_app/MAINTAINERS | 11 +- cmd/Makefile | 2 +- cmd/efi.c | 78 +++-- common/Kconfig | 15 +- common/bloblist.c | 16 +- common/board_f.c | 8 +- ..._app_defconfig => efi-x86_app32_defconfig} | 3 +- configs/efi-x86_app64_defconfig | 39 +++ disk/part.c | 5 +- doc/develop/bloblist.rst | 16 + doc/develop/uefi/u-boot_on_efi.rst | 74 ++++- drivers/block/Kconfig | 33 +++ drivers/block/Makefile | 4 + drivers/block/blk-uclass.c | 2 +- drivers/block/efi-media-uclass.c | 15 + drivers/block/efi_blk.c | 115 ++++++++ drivers/block/sb_efi_media.c | 20 ++ drivers/serial/serial_efi.c | 11 +- drivers/video/Kconfig | 2 +- drivers/video/efi.c | 45 ++- include/configs/efi-x86_app.h | 31 +- include/dm/uclass-id.h | 1 + include/efi.h | 121 +++++++- include/efi_api.h | 15 + include/init.h | 2 +- lib/efi/Kconfig | 34 ++- lib/efi/efi.c | 106 +++++++ lib/efi/efi_app.c | 276 +++++++++++++++++- lib/efi/efi_stub.c | 95 +++--- scripts/build-efi.sh | 193 ++++++++++++ test/dm/Makefile | 1 + test/dm/efi_media.c | 24 ++ tools/binman/binman.rst | 36 +++ tools/binman/cmdline.py | 2 + tools/binman/control.py | 11 + tools/binman/elf.py | 74 ++++- tools/binman/elf_test.py | 45 ++- tools/binman/ftest.py | 91 +++++- tools/binman/test/Makefile | 13 +- tools/binman/test/bss_data.c | 2 +- tools/binman/test/embed_data.c | 16 + tools/binman/test/embed_data.lds | 23 ++ tools/binman/test/u_boot_binman_embed.c | 13 + tools/binman/test/u_boot_binman_embed.lds | 29 ++ tools/binman/test/u_boot_binman_embed_sm.c | 13 + tools/patman/tools.py | 2 +- 61 files changed, 1746 insertions(+), 207 deletions(-) create mode 100644 arch/x86/cpu/x86_64/misc.c rename configs/{efi-x86_app_defconfig => efi-x86_app32_defconfig} (94%) create mode 100644 configs/efi-x86_app64_defconfig create mode 100644 drivers/block/efi-media-uclass.c create mode 100644 drivers/block/efi_blk.c create mode 100644 drivers/block/sb_efi_media.c create mode 100755 scripts/build-efi.sh create mode 100644 test/dm/efi_media.c create mode 100644 tools/binman/test/embed_data.c create mode 100644 tools/binman/test/embed_data.lds create mode 100644 tools/binman/test/u_boot_binman_embed.c create mode 100644 tools/binman/test/u_boot_binman_embed.lds create mode 100644 tools/binman/test/u_boot_binman_embed_sm.c -- 2.33.0.1079.g6e70778dc9-goog

2 44

[PATCH 2/2] dt-bindings: u-boot: Add an initial binding for config
by Simon Glass 04 Nov '21

04 Nov '21

U-Boot makes use of the devicetree for its driver model. Devices are bound based on the hardware description in the devicetree. Since U-Boot is not an operating system, it has no command line or user space to provide configuration and policy information. This must be made available in some other way. Therefore U-Boot uses devicetree for configuration and run-time control and has done for approximately 9 years. This works extremely well in the project and is very flexible. However the bindings have never been incorporated in the devicetree bindings in the Linux tree. This could be a good time to start this work as we try to create standard bindings for communicating between firmware components. Add an initial binding for this node, covering just the config node, which is the main requirement. It is similar in concept to the chosen node, but used for passing information between firmware components, instead of from firmware to operating system. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- Please be kind in your review. Some words about why this is needed are included in the description in config.yaml file. The last attempt to add just one property needed by U-Boot went into the weeds 6 years ago, with what I see as confusion about the role of the chosen node in devicetree[1]. I am trying again in the hope of reaching resolution rather than just going around in circles with the 'devicetree is a hardware description' argument :-) Quoting from the introduction to latest devicetree spec[2]: >>> To initialize and boot a computer system, various software components interact. Firmware might perform low-level initialization of the system hardware before passing control to software such as an operating system, bootloader, or hypervisor. Bootloaders and hypervisors can, in turn, load and transfer control to operating systems. Standard, consistent interfaces and conventions facilitate the interactions between these software components. In this document the term boot program is used to generically refer to a software component that initializes the system state and executes another software component referred to as a client program. <<< This clearly envisages multiple software components in the firmware domain and in fact that is the case today. They need some way to communicate configuration data such as memory setup, runtime-feature selection and developer conveniences. Devicetree seems ideal, at least for components where the performance / memory requirements of devicetree are affordable. I hope that the Linux community (which owns the devicetree bindings) finds this initiative valuable and acceptable. [1] https://lists.denx.de/pipermail/u-boot/2015-July/218585.html [2] https://github.com/devicetree-org/devicetree-specification/releases/tag/v0.3 .../devicetree/bindings/u-boot/config.yaml | 137 ++++++++++++++++++ 1 file changed, 137 insertions(+) create mode 100644 Documentation/devicetree/bindings/u-boot/config.yaml diff --git a/Documentation/devicetree/bindings/u-boot/config.yaml b/Documentation/devicetree/bindings/u-boot/config.yaml new file mode 100644 index 00000000000000..336577a17fdf5a --- /dev/null +++ b/Documentation/devicetree/bindings/u-boot/config.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/u-boot/config.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot configuration node + +maintainers: + - Simon Glass <sjg(a)chromium.org> + +description: | + The config node does not represent a real device, but serves as a place + for passing data between firmware elements, like memory maps. Data in the + config node does not represent the hardware. It is ignored by operating + systems. + + Purpose of config node + ---------------------- + + A common problem with firmware is that many builds are needed to deal with the + slight variations between different, related models. For example, one model + may have a TPM and another may not. Devicetree provides an excellent solution + to this problem, in that the devicetree to actually use on a platform can be + injected in the factory based on which model is being manufactured at the time. + + A related problem causing build proliferation is dealing with the differences + between development firmware, developer-friendly firmware (e.g. with all + security features present but with the ability to access the command line), + test firmware (which runs tests used in the factory), final production + firmware (before signing), signed firmware (where the signatures have been + inserted) and the like. Ideally all or most of these should use the same + U-Boot build, with just some options to determine the features available. For + example, being able to control whether the UART console or JTAG are available, + on any image, is a great debugging aid. + + When the firmware consists of multiple parts (various U-Boot phases, TF-A, + OP-TEE), it is helpful that all operate the same way at runtime, regardless of + how they were built. This can be achieved by passing the runtime configuration + (e.g. 'enable UART console', 'here are your public keys') along the chain + through each firmware stage. It is frustrating to have to replicate a bug on + production firmware which does happen on developer firmware, because they are + completely different builds. + + The config node provides useful functionality for this. It allows the different + controls to be 'factored out' of the U-Boot binary, so they can be controlled + separately from the initial source-code build. The node can be easily updated + by a build or factory tool and can control various features in U-Boot. It is + similar in concept to a Kconfig option, except that it can be changed after + U-Boot is built. + + The config node is similar in concept to /chosen (see chosen.txt) except that + it is for passing information *into* and *between) firmware components, + instead of from firmware to the Operating System. Also, while operating + systems typically have a (sometimes extremely long) command line, U-Boot does + not support this, except with sandbox. The devicetree provides a more + structured approach in any case. + +properties: + + compatible: + enum: + - "u-boot,config" + + bootcmd: + $ref: /schemas/types.yaml#/definitions/string + description: | + Allows overwriting of the boot command used by U-Boot on startup. If + present, U-Boot uses this command instead. Note that this feature can + work even if loading the environment is disabled, e.g. for security + reasons. See also bootsecure. + + bootdelay: + $ref: /schemas/types.yaml#/definitions/int32 + description: | + Allows selecting of the U-Boot bootdelay, to control whether U-Boot + waits on boot or for how long. This allows this option to be configured + by the build system or by a previous-stage binary. For example, if the + images is being packed for testing or a user holds down a button, it may + allow a delay, but disable it for production. + + If this property is not present, a default value is used instead. + + Values: + + -1: no bootdelay and the user cannot interrupt boot + 0: no bootdelay but use user can still interrupt boot by holding down a + key, if enabled + >= 1: delay for this many seconds + + + bootsecure: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Controls the execution of the boot command in U-Boot, e.g. selecting + between using a special function to run commands, or the normal CLI. This + can be used in production images, to restrict the amount of parsing done + or the options available, to cut back on the available surface for + security attacks. + + Values: + + 0: normal boot using CLI (default if not present) + 1: use secure boot mechanism instead to parse and run commands + other values are reserved for future use + 2: use simplified command line (e.g. avoid hush) + 3... reserved + + silent-console: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + This allows the console to be silenced by default on boot. This can allow + easy disabling of console output on a production build, for example. When + suppressed, the console is still active. This feature only suppresses the + console output itself, on all output devices. + + Values: + + 0: console output appears as normal (default) + 1: console output is suppressed but console recording still operates (if + enabled) + 2: console output is suppressed and not recorded + +required: + - compatible + +additionalProperties: false + +examples: + - | + u-boot,config { + compatible = "u-boot,config"; + bootcmd = "vboot go auto"; + bootdelay = <(-1)>; + bootsecure = <1>; + silent-console = <1>; + }; -- 2.33.0.800.g4c38ced690-goog

3 11

[PATCH v3 0/3] Enhance Measured Boot
by Masahisa Kojima 04 Nov '21

04 Nov '21

This patch series add the following measurement mandated in the TCG PC Client PFP Specification. - SMBIOS tables - GPT disk partition topology - AuditMode and Deployed mode Masahisa Kojima (3): efi_loader: add SMBIOS table measurement efi_loader: add UEFI GPT measurement efi_loader: add DeployedMode and AuditMode variable measurement include/blk.h | 3 + include/efi_loader.h | 5 +- include/efi_tcg2.h | 27 +++ include/smbios.h | 17 +- lib/efi_loader/Kconfig | 1 + lib/efi_loader/efi_boottime.c | 4 +- lib/efi_loader/efi_device_path.c | 27 +++ lib/efi_loader/efi_smbios.c | 2 - lib/efi_loader/efi_tcg2.c | 297 ++++++++++++++++++++++++++++++- lib/smbios-parser.c | 152 ++++++++++++++-- 10 files changed, 518 insertions(+), 17 deletions(-) -- 2.17.1

4 20

Commit 76c2ff3e broke backlight on Chromebook snow
by Guillaume GARDET 03 Nov '21

03 Nov '21

Hi, Commit 76c2ff3e [0] broke backlight on Chromebook snow. A revert on top of 2021.10 restores the backlight. Not sure why it breaks on Chromebook snow yet. Dario, any idea how to fix this? Cheers, Guillaume

3 5

[PATCH] driver: gadget: fastboot: Link endpoint and descriptors
by qianfanguijin＠163.com 03 Nov '21

03 Nov '21

From: qianfan Zhao <qianfanguijin(a)163.com> If the downloading file size is equal to the partition size, "fastboot flash" can't work, at least in sunxi platform, because used an uninitalized point: ep->desc. Reproduce: fastboot flash loader1 spl/sunxi-spl.bin. Fix it. Signed-off-by: qianfan Zhao <qianfanguijin(a)163.com> --- drivers/usb/gadget/f_fastboot.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index 8ba55aab9f..45bb3aba66 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -319,13 +319,13 @@ static int fastboot_set_alt(struct usb_function *f, struct usb_composite_dev *cdev = f->config->cdev; struct usb_gadget *gadget = cdev->gadget; struct f_fastboot *f_fb = func_to_fastboot(f); - const struct usb_endpoint_descriptor *d; debug("%s: func: %s intf: %d alt: %d\n", __func__, f->name, interface, alt); - d = fb_ep_desc(gadget, &fs_ep_out, &hs_ep_out, &ss_ep_out); - ret = usb_ep_enable(f_fb->out_ep, d); + f_fb->out_ep->desc = fb_ep_desc(gadget, &fs_ep_out, &hs_ep_out, + &ss_ep_out); + ret = usb_ep_enable(f_fb->out_ep, f_fb->out_ep->desc); if (ret) { puts("failed to enable out ep\n"); return ret; @@ -339,8 +339,8 @@ static int fastboot_set_alt(struct usb_function *f, } f_fb->out_req->complete = rx_handler_command; - d = fb_ep_desc(gadget, &fs_ep_in, &hs_ep_in, &ss_ep_in); - ret = usb_ep_enable(f_fb->in_ep, d); + f_fb->in_ep->desc = fb_ep_desc(gadget, &fs_ep_in, &hs_ep_in, &ss_ep_in); + ret = usb_ep_enable(f_fb->in_ep, f_fb->in_ep->desc); if (ret) { puts("failed to enable in ep\n"); goto err; -- 2.17.1

2 1

[PATCH v2 0/6] Improved sysreset/watchdog uclass integration
by Samuel Holland 03 Nov '21

03 Nov '21

This series hooks up the watchdog uclass to automatically register watchdog devices for use with sysreset, doing a bit of minor cleanup along the way. The goal is for this to replace the sunxi board-level non-DM reset_cpu() function. I was surprised to find that the wdt_reboot driver requires its own undocumented device tree node, which references the watchdog device by phandle. This is problematic for us, because sunxi-u-boot.dtsi file covers 20 different SoCs with varying watchdog node phandle names. So it would have required adding a -u-boot.dtsi file for each board. Hooking things up automatically makes sense to me; this is what Linux does. However, I put the code behind a new option to avoid surprises for other platforms. Changes in v2: - Extend the "if SYSRESET" block to the end of the file. - Also make gpio_reboot_probe function static. - Rebase on top of 492ee6b8d0e7 (now handle all watchdogs). - Added patches 5-6 as an example of how the new option will be used. Samuel Holland (6): sysreset: Add uclass Kconfig dependency to drivers sysreset: Mark driver probe functions as static sysreset: watchdog: Move watchdog reference to plat data watchdog: Automatically register device with sysreset sunxi: Avoid duplicate reset_cpu with SYSRESET enabled sunxi: Use sysreset framework for poweroff/reset arch/arm/Kconfig | 3 +++ arch/arm/mach-sunxi/board.c | 2 ++ drivers/sysreset/Kconfig | 11 ++++++-- drivers/sysreset/sysreset_gpio.c | 2 +- drivers/sysreset/sysreset_resetctl.c | 2 +- drivers/sysreset/sysreset_syscon.c | 2 +- drivers/sysreset/sysreset_watchdog.c | 40 ++++++++++++++++++++++------ drivers/watchdog/wdt-uclass.c | 5 ++++ include/sysreset.h | 14 ++++++++++ 9 files changed, 68 insertions(+), 13 deletions(-) -- 2.32.0

3 10