September 2021 - U-Boot

[PATCH v2] ARM: Prevent the compiler from using NEON registers
by Samuel Holland 03 Sep '21

03 Sep '21

For ARMv8-A, NEON is standard, so the compiler can use it even when no special target flags are provided. For example, it can use stores from NEON registers to zero-initialize large structures. GCC 11 decides to do this inside the DRAM init code for the Allwinner H6. However, GCC 11 has a bug where it generates misaligned NEON register stores even with -mstrict-align. Since the MMU is not enabled this early in SPL, the misaligned store causes an exception and breaks booting. Work around this issue by restricting the compiler to using GPRs only, not vector registers. This prevents any future surprises relating to NEON use as well. Signed-off-by: Samuel Holland <samuel(a)sholland.org> --- Changes in v2: - Updated commit message to describe problem more precisely arch/arm/config.mk | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 16c63e12667..964c6b026ec 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -25,6 +25,7 @@ endif PLATFORM_RELFLAGS += -fno-common -ffixed-r9 PLATFORM_RELFLAGS += $(call cc-option, -msoft-float) \ + $(call cc-option,-mgeneral-regs-only) \ $(call cc-option,-mshort-load-bytes,$(call cc-option,-malignment-traps,)) # LLVM support -- 2.31.1

3 2

[PATCH] Revert "configs: synquacer: Make U-Boot binary position independent"
by Masami Hiramatsu 03 Sep '21

03 Sep '21

This reverts commit f7e16bb0c5362c9b01d7e6e96bf6c77fd6b3d89e, since the U-Boot doesn't boot if it is booted directly from SPI-NOR with CONFIG_POSITION_INDEPENDENT=y. Unless fixing this issue, it is better to revert this change. Signed-off-by: Masami Hiramatsu <masami.hiramatsu(a)linaro.org> --- configs/synquacer_developerbox_defconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/configs/synquacer_developerbox_defconfig b/configs/synquacer_developerbox_defconfig index 13736a4f03..338eb9b288 100644 --- a/configs/synquacer_developerbox_defconfig +++ b/configs/synquacer_developerbox_defconfig @@ -1,7 +1,6 @@ CONFIG_ARM=y -CONFIG_POSITION_INDEPENDENT=y CONFIG_ARCH_SYNQUACER=y -CONFIG_SYS_TEXT_BASE=0x00000000 +CONFIG_SYS_TEXT_BASE=0x08200000 CONFIG_ENV_SIZE=0x30000 CONFIG_ENV_OFFSET=0x300000 CONFIG_ENV_SECT_SIZE=0x10000

2 1

[PATCH v2 1/2] arm: mach-snapdragon: misc: Initialize eMMC if necessary
by Stephan Gerhold 03 Sep '21

03 Sep '21

At the moment U-Boot produces an empty MAC address (02:00:00:00:00:00) if the eMMC is not used by anything in U-Boot (e.g. with CONFIG_ENV_IS_NOWHERE=y instead of having the environment on eMMC). This happens because then there is nothing that actually initializes the eMMC and reads the "cid" that is later accessed. To fix this, call mmc_init() to ensure the eMMC is initialized. There is no functional difference if the eMMC is already initialized since then mmc_init() will just return without doing anything. Reviewed-by: Ramon Fried <rfried.dev(a)gmail.com> Signed-off-by: Stephan Gerhold <stephan(a)gerhold.net> --- (no changes since v1) arch/arm/mach-snapdragon/misc.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/mach-snapdragon/misc.c b/arch/arm/mach-snapdragon/misc.c index 985625a548..fbd5f4d051 100644 --- a/arch/arm/mach-snapdragon/misc.c +++ b/arch/arm/mach-snapdragon/misc.c @@ -33,6 +33,9 @@ u32 msm_board_serial(void) if (!mmc_dev) return 0; + if (mmc_init(mmc_dev)) + return 0; + return UNSTUFF_BITS(mmc_dev->cid, 16, 32); } -- 2.32.0

3 4

[PATCH v2 0/2] armv7: Add Position Independent Execution support
by Chia-Wei Wang 03 Sep '21

03 Sep '21

Add PIE support for ARMv7 platform. v2: - Fix Kconfig option dependices using Kconfig language Chia-Wei Wang (2): arm: Fix option dependency with Kconfig language armv7: Add Position Independent Execution support arch/arm/Kconfig | 9 ++++---- arch/arm/cpu/armv7/start.S | 43 ++++++++++++++++++++++++++++++++++++++ arch/arm/lib/crt0.S | 11 ++++++++++ arch/arm/lib/relocate.S | 35 ++++++++++++++++++++++--------- 4 files changed, 84 insertions(+), 14 deletions(-) -- 2.17.1

2 4

[PATCH] lib/rsa: Remove support for OpenSSL < 1.1.0 and libressl < 2.7.0
by Alexandru Gagniuc 02 Sep '21

02 Sep '21

Older OpenSSL and libressl versions have a slightly different API. This require #ifdefs to support. However, we still can't support it because the ECDSA path does not compile with these older versions. These #ifdefs are truly a vestigial appendage. Alternatively, the ECDSA path could be updated for older libraries, but this requires significant extra code, and #ifdefs. Those libraries are over three years old, and there concerns whether it makes sense to build modern software for real world use against such old libraries. Thusly, remove #ifdefs and code for old OpenSSL and LibreSSL support. Signed-off-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> --- I would appreciate if somebody tested the RSA signing functionality with this patch applied, as I am not equipped to test this comprehensively. lib/rsa/rsa-sign.c | 76 +++------------------------------------------- 1 file changed, 4 insertions(+), 72 deletions(-) diff --git a/lib/rsa/rsa-sign.c b/lib/rsa/rsa-sign.c index deff936fef..e6527c2610 100644 --- a/lib/rsa/rsa-sign.c +++ b/lib/rsa/rsa-sign.c @@ -19,24 +19,6 @@ #include <openssl/evp.h> #include <openssl/engine.h> -#if OPENSSL_VERSION_NUMBER >= 0x10000000L -#define HAVE_ERR_REMOVE_THREAD_STATE -#endif - -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) -static void RSA_get0_key(const RSA *r, - const BIGNUM **n, const BIGNUM **e, const BIGNUM **d) -{ - if (n != NULL) - *n = r->n; - if (e != NULL) - *e = r->e; - if (d != NULL) - *d = r->d; -} -#endif - static int rsa_err(const char *msg) { unsigned long sslErr = ERR_get_error(); @@ -314,24 +296,11 @@ static int rsa_init(void) { int ret; -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - ret = SSL_library_init(); -#else ret = OPENSSL_init_ssl(0, NULL); -#endif if (!ret) { fprintf(stderr, "Failure to init SSL library\n"); return -1; } -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - SSL_load_error_strings(); - - OpenSSL_add_all_algorithms(); - OpenSSL_add_all_digests(); - OpenSSL_add_all_ciphers(); -#endif return 0; } @@ -346,8 +315,7 @@ static int rsa_engine_init(const char *engine_id, ENGINE **pe) e = ENGINE_by_id(engine_id); if (!e) { fprintf(stderr, "Engine isn't available\n"); - ret = -1; - goto err_engine_by_id; + return -1; } if (!ENGINE_init(e)) { @@ -370,29 +338,9 @@ err_set_rsa: ENGINE_finish(e); err_engine_init: ENGINE_free(e); -err_engine_by_id: -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - ENGINE_cleanup(); -#endif return ret; } -static void rsa_remove(void) -{ -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - CRYPTO_cleanup_all_ex_data(); - ERR_free_strings(); -#ifdef HAVE_ERR_REMOVE_THREAD_STATE - ERR_remove_thread_state(NULL); -#else - ERR_remove_state(0); -#endif - EVP_cleanup(); -#endif -} - static void rsa_engine_remove(ENGINE *e) { if (e) { @@ -465,12 +413,7 @@ static int rsa_sign_with_key(EVP_PKEY *pkey, struct padding_algo *padding_algo, goto err_sign; } - #if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - EVP_MD_CTX_cleanup(context); - #else - EVP_MD_CTX_reset(context); - #endif + EVP_MD_CTX_reset(context); EVP_MD_CTX_destroy(context); debug("Got signature: %d bytes, expected %zu\n", *sig_size, size); @@ -502,7 +445,7 @@ int rsa_sign(struct image_sign_info *info, if (info->engine_id) { ret = rsa_engine_init(info->engine_id, &e); if (ret) - goto err_engine; + return ret; } ret = rsa_get_priv_key(info->keydir, info->keyname, info->keyfile, @@ -517,7 +460,6 @@ int rsa_sign(struct image_sign_info *info, EVP_PKEY_free(pkey); if (info->engine_id) rsa_engine_remove(e); - rsa_remove(); return ret; @@ -526,8 +468,6 @@ err_sign: err_priv: if (info->engine_id) rsa_engine_remove(e); -err_engine: - rsa_remove(); return ret; } @@ -675,12 +615,8 @@ int rsa_add_verify_data(struct image_sign_info *info, void *keydest) ret = rsa_get_pub_key(info->keydir, info->keyname, e, &pkey); if (ret) goto err_get_pub_key; -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - rsa = EVP_PKEY_get1_RSA(pkey); -#else + rsa = EVP_PKEY_get0_RSA(pkey); -#endif ret = rsa_get_params(rsa, &exponent, &n0_inv, &modulus, &r_squared); if (ret) goto err_get_params; @@ -750,10 +686,6 @@ done: if (ret) ret = ret == -FDT_ERR_NOSPACE ? -ENOSPC : -EIO; err_get_params: -#if OPENSSL_VERSION_NUMBER < 0x10100000L || \ - (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 0x02070000fL) - RSA_free(rsa); -#endif EVP_PKEY_free(pkey); err_get_pub_key: if (info->engine_id) -- 2.31.1

4 6

[PATCH v3 0/7] vpl: Introduce a verifying program loader
by Simon Glass 02 Sep '21

02 Sep '21

U-Boot provides a verified-boot feature based around FIT, but there is no standard way of implementing it for a board. At present the various required pieces must be built up separately, to produce a working implementation. In particular, there is no built-in support for selecting A/B boot or recovery mode. This series introduces VPL, a verified program loader. Its purpose is to run the verified-boot process and decide which SPL binary should be run. Adding VPL into the boot flow provides a standard way of implementing verified boot. So far, only the phase itself is added along with some Kconfig options. The next step is to create a build for sandbox. Changes in v3: - Move VPL Kconfig options to a separate patch - Add full build support for VPL Changes in v2: - Add some more VPL Kconfig options Simon Glass (7): doc: Convert SPL documentation to ReST doc: Expand SPL docs to explain the phase and config test: Tidy up test building with SPL spl: Move TPL_HASH_SUPPORT down next to other TPL options binman: Add VPL support Introduce Verifying Program Loader (VPL) vpl: Add Kconfig options for VPL Kconfig | 10 + Makefile | 15 +- arch/sandbox/Kconfig | 8 + common/Kconfig | 67 ++++++ common/spl/Kconfig | 226 +++++++++++++++++++-- common/spl/spl.c | 25 ++- doc/develop/index.rst | 1 + doc/{README.SPL => develop/spl.rst} | 99 +++++---- drivers/clk/Kconfig | 10 + drivers/core/Makefile | 2 +- drivers/gpio/Kconfig | 11 + drivers/i2c/Kconfig | 11 + drivers/misc/Kconfig | 19 ++ drivers/pinctrl/Kconfig | 18 +- drivers/rtc/Kconfig | 9 + drivers/serial/Kconfig | 20 ++ drivers/sysreset/Kconfig | 10 + drivers/timer/Kconfig | 10 + include/bootstage.h | 2 + include/linux/kconfig.h | 3 + include/spl.h | 20 +- lib/Kconfig | 62 ++++++ scripts/Kbuild.include | 4 + scripts/Makefile.autoconf | 12 ++ scripts/Makefile.build | 4 + scripts/Makefile.lib | 5 + scripts/Makefile.spl | 37 +++- test/test-main.c | 2 +- tools/binman/etype/u_boot_vpl.py | 42 ++++ tools/binman/etype/u_boot_vpl_bss_pad.py | 44 ++++ tools/binman/etype/u_boot_vpl_dtb.py | 28 +++ tools/binman/etype/u_boot_vpl_expanded.py | 45 ++++ tools/binman/etype/u_boot_vpl_nodtb.py | 42 ++++ tools/binman/ftest.py | 110 ++++++++-- tools/binman/state.py | 3 +- tools/binman/test/082_fdt_update_all.dts | 2 + tools/binman/test/201_u_boot_vpl.dts | 11 + tools/binman/test/202_u_boot_vpl_nodtb.dts | 13 ++ tools/binman/test/203_fdt_incl_vpl.dts | 13 ++ tools/binman/test/204_vpl_bss_pad.dts | 17 ++ 40 files changed, 997 insertions(+), 95 deletions(-) rename doc/{README.SPL => develop/spl.rst} (61%) create mode 100644 tools/binman/etype/u_boot_vpl.py create mode 100644 tools/binman/etype/u_boot_vpl_bss_pad.py create mode 100644 tools/binman/etype/u_boot_vpl_dtb.py create mode 100644 tools/binman/etype/u_boot_vpl_expanded.py create mode 100644 tools/binman/etype/u_boot_vpl_nodtb.py create mode 100644 tools/binman/test/201_u_boot_vpl.dts create mode 100644 tools/binman/test/202_u_boot_vpl_nodtb.dts create mode 100644 tools/binman/test/203_fdt_incl_vpl.dts create mode 100644 tools/binman/test/204_vpl_bss_pad.dts -- 2.32.0.93.g670b81a890-goog

3 16

[PATCH] doc: Add documentation about devicetree usage
by Simon Glass 02 Sep '21

02 Sep '21

At present some of the ideas and techniques behind devicetree in U-Boot are assumed, implied or unsaid. Add some documentation to cover how devicetree is build, how it can be modified and the rules about using the various CONFIG_OF_... options. Signed-off-by: Simon Glass <sjg(a)chromium.org> --- doc/develop/index.rst | 1 + doc/develop/package/devicetree.rst | 315 +++++++++++++++++++++++++++++ doc/develop/package/index.rst | 1 + 3 files changed, 317 insertions(+) create mode 100644 doc/develop/package/devicetree.rst diff --git a/doc/develop/index.rst b/doc/develop/index.rst index 83c929babda..d5ad8f9fe53 100644 --- a/doc/develop/index.rst +++ b/doc/develop/index.rst @@ -36,6 +36,7 @@ Packaging :maxdepth: 1 package/index + package/devicetree Testing ------- diff --git a/doc/develop/package/devicetree.rst b/doc/develop/package/devicetree.rst new file mode 100644 index 00000000000..fccbb182f3e --- /dev/null +++ b/doc/develop/package/devicetree.rst @@ -0,0 +1,315 @@ +.. SPDX-License-Identifier: GPL-2.0+ + +Updating the devicetree +======================= + +U-Boot uses devicetree for runtime configuration and storing required blobs or +any other information it needs to operate. It is possible to update the +devicetree separately from actually building U-Boot. This provides a good degree +of control and flexibility for firmware that uses U-Boot in conjunction with +other project. + +There are many reasons why it is useful to modify the devicetree after building +it: + +- Configuration can be changed, e.g. which UART to use +- A serial number can be added +- Public keys can be added to allow image verification +- Console output can be changed (e.g. to select serial or vidconsole) + +This section describes how to work with devicetree to accomplish your goals. + +See also :doc:`../devicetree/control` for a basic summary of the available +features. + + +Devicetree source +----------------- + +Every board in U-Boot must include a devicetree sufficient to build and boot +that board on suitable hardware (or emulation). This is specified using the +`CONFIG DEFAULT_DEVICE_TREE` option. + + +Current situation (August 2021) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +As an aside, at present U-Boot allows `CONFIG_DEFAULT_DEVICE_TREE` to be empty, +e.g. if `CONFIG_OF_BOARD` or `CONFIG_OF_PRIOR_STAGE` are used. This has +unfortunately created an enormous amount of confusion and some wasted effort. +This was not intended and this bug will be fixed soon. Specifically: + +- `CONFIG_OF_BOARD` was added in rpi_patch_ for Raspberry Pi, which does have + an in-tree devicetree, but this feature has since been used for boards that + don't +- `CONFIG_OF_PRIOR_STAGE` was added in bcm_patch_ as part of a larger Broadcom + change with a tag indicating it only affected one board, so the change in + behaviour was not noticed at the time. It has since been used by RISC-V qemu + boards. + +Once this bug is fixed, CONFIG_OF_BOARD and CONFIG_OF_PRIOR_STAGE will override +(at runtime) the devicetree suppled with U-Boot, but will otherwise use +CONFIG_OF_SEPARATE for the in-tree build. So these two will become options, +moving out of the 'choice' in `dts/Kconfig` + +Offending boards are: + +- bcm7260 +- bcm7445 +- qemu_arm64 +- qemu_arm +- qemu-ppce500 +- qemu-riscv32 +- qemu-riscv32_smode +- qemu-riscv64 +- qemu-riscv64_smode + +All of these need to have a devicetree added in-tree. This is targeted to be +fixed in the 2022.01 release. + + +Building the devicetree +----------------------- + +U-Boot automatically builds the devicetree for a board, from the +`arch/<arch>/dts` directory. The Makefile in those directories has rules for +building devicetree files. It is preferable to avoid target-specific rules in +those files: i.e. all boards for a particular SoC should be built at once, +where practical. Apart from simplifying the Makefile, this helps to efficiently +(and immediately) ensure that changes in one board's DT do not break others that +are related. Building devicetrees is fast, so performance is seldom a concern +here. + + +Overriding the default devicetree +--------------------------------- + +When building U-Boot, the `DEVICE_TREE` environment variable allows the +default devicetree file to be overridden at build time. This can be useful if +modifications have to be made to the in-tree devicetree file, for the benefit +of a downstream build system. Note that the in-tree devicetree must be +sufficient to build and boot, so this is not a way to bypass that requirement. + + +Modifying the devicetree after building +--------------------------------------- + +While it is generally painful and hacky to modify the code or rodata of a +program after it is built, in many cases it is useul to do so, e.g. to add +configuration information like serial numbers, enabling/disabling features, etc. + +Devicetree provides a very nice solution to these problems since it is +structured data and it is relatively easy to change it, even in binary form +(see fdtput). + +U-Boot takes care that the devicetree is easily accessible after the build +process. In fact it is placed in a separate file called `u-boot.dtb`. If the +build system wants to modify or replace that file, it can do so. Then all that +is needed is to run `binman update` to update the file inside the image. If +binman is not used, then `u-boot-nodtb.bin` and the new `u-boot.dtb` can simply +be concatenated to achieve the desired result. U-Boot happily copes with the +devicetree growing or shrinking. + +The `u-boot.bin` image contains both pieces. While it is possible to locate the +devicetree within the image using the signature at the start of the file, this +is a bit messy. + +This is why `CONFIG_OF_SEPARATE` should always be used when building U-Boot. +The `CONFIG_OF_EMBED` option embeds the devicetree somewhere in the U-Boot ELF +image as rodata, meaning that it is hard to find it and it cannot increase in +size. + +When modifying the devicetree, the different cases to consider are as follows: + +- CONFIG_OF_SEPARATE + This is easy, described above. Just change, replace or rebuild the + devicetree so it suits your needs, then rerun binman or redo the `cat` + operation to join `u-boot-nodtb.bin` and the new `u-boot.dtb` + +- CONFIG_OF_EMBD + This is tricky, since the devicetree cannot easily be located. If the EFL + file is available, then the _dtb_dt_begin and __dtb_dt_end symbols can be + examined to find it. While it is possible to contract the file, it is not + possible to expand the file since that would involve re-linking + +- CONFIG_OF_PRIOR_STAGE + In this case the devicetree must be modified in the project which provides + it, as described below + +- CONFIG_OF_BOARD + This is a board-specific situation, so needs to be considered on a + case-by-case base. The devicetree must be modified so that the correct + one is provided to U-Boot. How this is done depends entirely on the + implementation of this option for the board. It might require injecting the + changes into a different project somehow using tooling available there, or + it might involve merging an overlay file at runtime to obtain the desired + result. + + +Devicetree in another project +----------------------------- + +In some cases U-Boot receive its devicetree at runtime from a program that calls +it. For example ARM's Trusted Firmware A (`TF-A`_) may have a devicetree that it +passes to U-Boot. This overrides any devicetree build by U-Boot. When packaging +the firmware, the U-Boot devicetree may in fact be left out if it can be +guaranteed that it will receive one from another project. + +In this case, the devicetree in the other project must track U-Boot's use of +device tree. It must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the /config node. Note that the +U-Boot in-tree devicetree must be sufficient to build and boot, so this is not a +way to bypass that requirement. + +If binman is used, the in-tree U-Boot devicetree must contain the binman +definition so that a valid image can be build. + +If verified boot is used, the project must provide a way to inject a public key, +certificate or other material into the U-Boot devicetree so that it is available +to U-Boot at runtime. See `Signing with U-Boot devicetree`_. This may be +through tooling in the project itself or by making use of U-Boot's tooling. + + +Devicetree generated on-the-fly in another project +-------------------------------------------------- + +In some rare cases, another project may wish to create a devicetree for U-Boot +entirely on-the-fly, then pass it to U-Boot at runtime. The only known example +of this at the time of writing (2021) is qemu, for ARM (`QEMU ARM`_) and +RISC-V (`QEMU RISC-V`_). + +In this case, the devicetree in the other project must track U-Boot's use of +device tree, so that it remains compatible. If a particular version of the +project is needed for a particular version of U-Boot, that must be documented +in both projects. + +Further, it must provide a way to add configuration and other information to +the devicetree for use by U-Boot, such as the `/config` node. Note that the +U-Boot in-tree devicetree must be sufficient to build and boot, so this is not a +way to bypass that requirement. + +More specifically, tooling or command-line arguments must provide a way to +add a `/config` node or items within that node, so that U-Boot can receive a +suitable configuration. These options can then be used as part of the build +process, which puts the firmware image together. For binman, a way must be +provided to add the binman definition into the devicetree in the same way. + +One way to do this is to allow a .dtsi file to be merged in with the generated +devicetree. + + +Passing the devicetree through to Linux +--------------------------------------- + +Ideally U-Boot and Linux use the same devicetree source, even though it is +hosted in separate projects. U-Boot adds some extra pieces, such as the +`config/` node and tags like `u-boot,dm-spl`. Linux adds some extra pieces, such +as `linux,default-trigger` and `linux,code`. This should not interfere with +each other. + +In principle it is possible for U-Boot's control devicetree to be passed to +Linux. This is, after all, one of the goals of devicetree and the original +Open Firmware project, to have the firmware provide the hardware description to +the Operating System. + +For boards where this approach is used, care must be taken. U-Boot typically +needs to 'fix up' the devicetree before passing it to Linux, e.g. to add +information about the memory map, about which serial console is used, provide +the root hash for dm-verify or select whether the console should be silenced for +a faster boot. + +Fix-ups involve modifying the devicetree. If the control devicetree is used, +that means the control devicetree could be modified, while U-Boot is using it. +Removing a device and reinserting it can cause problems if the devicetree offset +has changed, for example, since the device will be unable to locates its +devicetree properties at the expected devicetree offset, which is a fixed +integer. + +To deal with this, it is recommended to employ one or more of the following +approaches: + +- Make a copy of the devicetree and 'fix up' the copy, leaving the control + devicetree alone +- Enable `CONFIG_OF_LIVE` so that U-Boot makes its own copy of the devicetree + during relocation; fixups then happen on the original flat tree +- Ensure that fix-ups happen after all loading has happened and U-Boot has + completed image verification + +In practice,the last point is typically observed, since boot_prep_linux() is +called just before jumping to Linux, long after signature verification, for +example. But it is important to make sure that this line is not blurred, +particularly if untrusted user data in involved. + + +Devicetree use cases that must be supported +------------------------------------------- + +Regardless of how the devicetree is provided to U-Boot at runtime, various +U-Boot features must be fully supported. This section describes some of these +features and the implications for other projects. + +If U-Boot uses its own in-tree devicetree these features are supported +automatically. + + +Signing with U-Boot devicetree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +U-Boot supports signing a payload so that it can be verified to have been +created by a party owning a private key. This is called verified boot in U-Boot +(see doc/uImage.FIT/verified-boot.txt). + +Typically this works by creating a FIT and then running the `mkimage` tool to +add signatures for particular images. As part of this process, `mkimage` writes +a public key to the U-Boot devicetree, although this can be done separately. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this public key into the +devicetree it passes to U-Boot. This could be via a tooling option, making use +of `mkimage`, or alowing a .dtsi file to be merged in with what is generated in +the other project. + + +Providing the binman image definition +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In complex systems U-Boot must locate and make use of other firmware components, +such as images for the user interface, files containing peripheral firmware, +multiple copies of U-Boot for use with A/B boot, etc. U-Boot uses +:doc:`Binman <binman>` as a standard way of putting an image together. + +Typically this works by running binman with the devicetree as an input, to +create the file image. Binman then outputs an updated devicetree which is +packed in the firmware image, so U-Boot can access the binman definition and +locate all the components. + +As with all configuration information, if another project is providing the +devicetree to U-Boot, it must provide a way to add this binman definition into +the devicetree it passes to U-Boot. This could be via a tooling option, making +use of `binman`, or alowing a .dtsi file to be merged in with what is generated +in the other project. + + +Protecting the devicetree +------------------------- + +U-Boot relies heavily on devicetree for correct operation. A corrupt or invalid +device can cause U-Boot to fail to start, behave incorrectly, crash (e.g. if +`CONFIG_OF_LIBFDT_ASSUME_MASK` is adjusted, or fail to boot an Operating System. +Within U-Boot, the devicetree is as important as any other part of the source +code. At ruuntime, the devicetree can be considered to be structured rodata. + +With secure systems, care must be taken that the devicetree is valid: + +- If the code / rodata has a hash or signature, the devicetree should also, if + they are packaged separately. +- If the code / rodata is write-protected when running, the devicetree should be + also. Note that U-Boot relocates its code and devicetree, so this is not as + simple as it sounds. U-Boot must write-protect these items after relocating. + + +.. _rpi_patch: https://patchwork.ozlabs.org/project/uboot/patch/20170402082520.32546-1-dey… +.. _bcm_patch: https://patchwork.ozlabs.org/project/uboot/patch/16fc0901f4521d3c399eac950c… +.. _`TF-A`: https://www.trustedfirmware.org/projects/tf-a +.. _`QEMU ARM`: https://github.com/qemu/qemu/blob/master/hw/arm/virt.c +.. _`QEMU RISC-V`: https://github.com/qemu/qemu/blob/master/hw/riscv/virt.c diff --git a/doc/develop/package/index.rst b/doc/develop/package/index.rst index 9374be2e62c..188c376950e 100644 --- a/doc/develop/package/index.rst +++ b/doc/develop/package/index.rst @@ -17,3 +17,4 @@ SPI flash. :maxdepth: 2 binman + devicetree -- 2.33.0.259.gc128427fd7-goog

6 22

sandbox TPM
by Heinrich Schuchardt 02 Sep '21

02 Sep '21

The current TPM emulation in drivers/tpm/tpm(2)_tis_sandbox.c is not spec compliant. A TPM emulation as UNIX socket exists with https://github.com/stefanberger/swtpm.git. QEMU already uses this emulator. Couldn't the sandbox do the same? I think this is the fastest way to get a compliant sandbox TPM. Best regards Heinrich

4 5

Setting serverip from DHCP server
by Gregory Anders 02 Sep '21

02 Sep '21

(Re-sending now that I'm subscribed to the list) Hi all, I am running U-Boot on an embedded device that is connected via Ethernet to my workstation. The workstation is running dhcpd and U-Boot is able to successfully obtain an IP address via DHCP from the server. However, the `serverip` environment variable is not being set which prevents U-Boot from continuing to boot over the network. I have to manually enter `setenv serverip 10.0.10.1` each time. How do I get the DHCP server to set the serverip variable? My dhcpd.conf file is quite simple: subnet 10.0.10.0 netmask 255.255.255.0 { option routers 10.0.10.1; range 10.0.10.2; } I would have thought the 'option routers' line would do the trick, but apparently not. I've done a bit of searching online but haven't yet found anything helpful. Thanks, Greg

2 2

[PATCH v5 0/3] arm64: Add optimized memset/memcpy/memove functions
by Stefan Roese 02 Sep '21

02 Sep '21

On an NXP LX2160 based platform it has been noticed, that the currently implemented memset/memcpy functions for aarch64 are suboptimal. Especially the memset() for clearing the NXP MC firmware memory is very expensive (time-wise). This patchset now adds the optimized functions ported from this repository: https://github.com/ARM-software/optimized-routines As the optimized memset function make use of the dc opcode, which needs the caches to be enabled, an additional check is added and a simple memset version is used in this case. Please note that checkpatch.pl complains about some issue with this imported file: arch/arm/lib/asmdefs.h Since it's imported I did explicitly not make any changes here, to make potential future sync'ing easer. Here some numbers to see the speed improments: Current original version: ------------------------- memset() 32 Bytes, 16M times: time: 0.446 seconds memset() 16MiB, 256 times: time: 1.076 seconds memcpy() 512MiB: time: 0.224 seconds New optimized version: ---------------------- memset() 32 Bytes, 16M times: time: 0.287 seconds memset() 16MiB, 256 times: time: 0.292 seconds memcpy() 512MiB: time: 0.222 seconds Summary: The optimized memcpy is nearly identical to the original one. But the optimized memset is much faster, for small and big sizes. Small sizes factor ~1.6 and big sizes factor ~3.7. Note: These measurements were done on the NXP LX2160ARDB board. Thanks, Stefan Changes in v5: - memmove is now auto-selected (or deselected) with the memcpy Kconfig selection as it's entry is the same as memcpy for ARM64 Changes in v4: - Use macros instead of register names, following the optimized code - Add zero size check Changes in v3: - Add memmove alias, as this function also handles it optimized - Add memmove as well Changes in v2: - Add file names and locations and git commit ID from imported files to the commit message - New patch Stefan Roese (3): arm64: arch/arm/lib: Add optimized memset/memcpy/memmove functions arm64: memset-arm64: Use simple memset when cache is disabled arm64: Kconfig: Enable usage of optimized memset/memcpy/memmove arch/arm/Kconfig | 37 +++++- arch/arm/include/asm/string.h | 4 + arch/arm/lib/Makefile | 5 + arch/arm/lib/asmdefs.h | 98 ++++++++++++++ arch/arm/lib/memcpy-arm64.S | 242 ++++++++++++++++++++++++++++++++++ arch/arm/lib/memset-arm64.S | 148 +++++++++++++++++++++ 6 files changed, 528 insertions(+), 6 deletions(-) create mode 100644 arch/arm/lib/asmdefs.h create mode 100644 arch/arm/lib/memcpy-arm64.S create mode 100644 arch/arm/lib/memset-arm64.S -- 2.33.0

2 6