July 2021 - U-Boot

Help with TI-U-BOOT
by Antoine Naud 24 Jul '21

24 Jul '21

Hi, I don't know if I will join someone, but I try anyway ! Can I ask a question about an error I have while compiling the bootloader ? Thanks, Antoine

3 6

[PATCH v5 0/8] common: Introduce crypt-style password support
by Steffen Jaeckel 23 Jul '21

23 Jul '21

This patchset introduces support for crypt-style passwords to unlock the console in autoboot mode. The implementation of crypt-sha256 and crypt-sha512 originate from libxcrypt at https://github.com/besser82/libxcrypt.git Version v4.4.17 Git commit hash 6b110bc I didn't re-format those two files to make diffing to the original versions from libxcrypt easier, which leads to a huge load of checkpatch.pl warnings&errors. Please advise on whether they should be re-formatted or can be kept as is. The remaining warnings from checkpatch.pl are intentional resp. open for discussion. A sandbox defconfig with password entry has been added. I'm not sure whether this should be kept or not, it's just there as an example. Cheers, Steffen Changes in v5: Take review comments into account Changes in v4: Fix depends for unit-tests Take review comments into account Add another test with `bootstopusesha256` unset Changes in v3: Add unit-tests for autoboot Introduce `bootstopusesha256` to allow fallback to plain SHA256-based hashing Add AUTOBOOT_FLUSH_STDIN option Drop the changes to bcm963158_ram_defconfig Changes in v2: Update Kconfig way of enabling, setting hashes etc. Changes in v1: Added unit-tests of crypt_compare() Wrapped crypt functions to encapsulate errno Steffen Jaeckel (8): lib: add crypt subsystem lib: wrap crypt API to hide errno usage common: integrate crypt-based passwords common: Rename macro appropriately common: allow disabling of timeout for password entry common: add AUTOBOOT_FLUSH_STDIN option common: add support to fallback to plain SHA256 test: add first autoboot unit tests common/Kconfig.boot | 65 ++++++- common/autoboot.c | 136 ++++++++++++-- common/console.c | 5 + configs/sandbox_defconfig | 13 +- include/console.h | 17 ++ include/crypt.h | 14 ++ include/test/common.h | 15 ++ include/test/suites.h | 1 + lib/Kconfig | 1 + lib/Makefile | 1 + lib/crypt/Kconfig | 28 +++ lib/crypt/Makefile | 7 + lib/crypt/alg-sha256.h | 11 ++ lib/crypt/alg-sha512.h | 11 ++ lib/crypt/crypt-port.h | 30 +++ lib/crypt/crypt-sha256.c | 336 ++++++++++++++++++++++++++++++++++ lib/crypt/crypt-sha512.c | 351 ++++++++++++++++++++++++++++++++++++ lib/crypt/crypt.c | 76 ++++++++ test/Kconfig | 10 + test/Makefile | 1 + test/cmd_ut.c | 1 + test/common/Makefile | 3 + test/common/cmd_ut_common.c | 22 +++ test/common/test_autoboot.c | 90 +++++++++ test/lib/Makefile | 1 + test/lib/test_crypt.c | 64 +++++++ 26 files changed, 1287 insertions(+), 23 deletions(-) create mode 100644 include/crypt.h create mode 100644 include/test/common.h create mode 100644 lib/crypt/Kconfig create mode 100644 lib/crypt/Makefile create mode 100644 lib/crypt/alg-sha256.h create mode 100644 lib/crypt/alg-sha512.h create mode 100644 lib/crypt/crypt-port.h create mode 100644 lib/crypt/crypt-sha256.c create mode 100644 lib/crypt/crypt-sha512.c create mode 100644 lib/crypt/crypt.c create mode 100644 test/common/Makefile create mode 100644 test/common/cmd_ut_common.c create mode 100644 test/common/test_autoboot.c create mode 100644 test/lib/test_crypt.c -- 2.32.0

2 16

[PATCH v4 0/3] Add reboot mode support
by Nandor Han 23 Jul '21

23 Jul '21

Description ----------- Add support for reboot-mode configuration using GPIOs and RTC SRAM as back-end. Testing ------- Tested on a Zynq based board where device tree was configured to contain the reboot-mode configuration: &amba { status = "okay"; reboot-mode-gpio { compatible = "reboot-mode-gpio"; gpios = <&gpio0 47 GPIO_ACTIVE_LOW>; mode-test = <0x1>; }; reboot-mode-rtc { compatible = "reboot-mode-rtc"; rtc = <&rtc_0>; reg = <0x14 4>; mode-test = <0x21969147>; }; }; In addition to this and not part of this patchset is a change to board.c where GPIO or RTC SRAM backed is selected dynamically at runtime. 1. Test that the reboot mode configured in user-space is read in U-Boot and environment configured: PASS Userspace ~ # reboot test .... [ 177.335936] reboot: Restarting system with command 'test' U-Boot SPL 2019.01 (Mar 29 2019 - 10:44:22 +0000) ... U-Boot> print reboot-mode reboot-mode=test 2. Reset the system using the reset command and stop in U-Boot. 3. Verify that reboot-mode env variable is not configured anymore: PASS U-Boot> print reboot-mode ## Error: "reboot-mode" not defined 4. Toggle the GPIO configured for test mode to active and reset the system with command reset. 5. Stop in U-Boot and check that reboot-mode env variable is configured:PASS U-Boot> print reboot-mode reboot-mode=test 6. Verify that unit-tests are successful: PASS ``` localhost /u-boot-latest (wip-reboot-mode)> ./test/py/test.py --bd sandbox --build -k ut_dm_reboot_mode -v ... test/py/tests/test_ut.py::test_ut[ut_dm_reboot_mode_gpio] PASSED [ 50%] test/py/tests/test_ut.py::test_ut[ut_dm_reboot_mode_rtc] PASSED [100%] ========================================================== 2 passed, 759 deselected in 0.40 seconds ========================================================== ``` Changes since v1: ---------------- - rebased Changes since v2: ---------------- - unit-tests added Changes since v3: ---------------- - rebased - fix the struct udevice and struct driver incompatibilities Nandor Han (3): reboot-mode: add support for reboot mode control reboot-mode: read the boot mode from GPIOs status reboot-mode: read the boot mode from RTC memory arch/sandbox/dts/test.dts | 18 +++ configs/sandbox_defconfig | 3 + .../reboot-mode/reboot-mode-gpio.txt | 20 +++ .../reboot-mode/reboot-mode-rtc.txt | 22 +++ drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/reboot-mode/Kconfig | 36 +++++ drivers/reboot-mode/Makefile | 9 ++ drivers/reboot-mode/reboot-mode-gpio.c | 128 +++++++++++++++++ drivers/reboot-mode/reboot-mode-rtc.c | 127 +++++++++++++++++ drivers/reboot-mode/reboot-mode-uclass.c | 134 ++++++++++++++++++ include/dm/uclass-id.h | 1 + include/reboot-mode/reboot-mode-gpio.h | 32 +++++ include/reboot-mode/reboot-mode-rtc.h | 16 +++ include/reboot-mode/reboot-mode.h | 56 ++++++++ test/dm/Makefile | 1 + test/dm/reboot-mode.c | 71 ++++++++++ 17 files changed, 677 insertions(+) create mode 100644 doc/device-tree-bindings/reboot-mode/reboot-mode-gpio.txt create mode 100644 doc/device-tree-bindings/reboot-mode/reboot-mode-rtc.txt create mode 100644 drivers/reboot-mode/Kconfig create mode 100644 drivers/reboot-mode/Makefile create mode 100644 drivers/reboot-mode/reboot-mode-gpio.c create mode 100644 drivers/reboot-mode/reboot-mode-rtc.c create mode 100644 drivers/reboot-mode/reboot-mode-uclass.c create mode 100644 include/reboot-mode/reboot-mode-gpio.h create mode 100644 include/reboot-mode/reboot-mode-rtc.h create mode 100644 include/reboot-mode/reboot-mode.h create mode 100644 test/dm/reboot-mode.c -- 2.26.3

3 12

[PATCH] board: fsl_validate: Fix resource leak issue
by Kshitiz Varshney 23 Jul '21

23 Jul '21

Free dynamically allocated memory before every return statement in calc_esbchdr_esbc_hash() function. Verified the secure boot changes using ls1046afrwy board. Signed-off-by: Kshitiz Varshney <kshitiz.varshney(a)nxp.com> --- board/freescale/common/fsl_validate.c | 25 ++++++++++++++++++------- 1 file changed, 18 insertions(+), 7 deletions(-) diff --git a/board/freescale/common/fsl_validate.c b/board/freescale/common/fsl_validate.c index 564a8b3b54..05d9a004e7 100644 --- a/board/freescale/common/fsl_validate.c +++ b/board/freescale/common/fsl_validate.c @@ -547,14 +547,18 @@ static int calc_esbchdr_esbc_hash(struct fsl_secboot_img_priv *img) ret = algo->hash_init(algo, &ctx); /* Copy hash at destination buffer */ - if (ret) + if (ret) { + free(ctx); return ret; + } /* Update hash for CSF Header */ ret = algo->hash_update(algo, ctx, (u8 *)&img->hdr, sizeof(struct fsl_secboot_img_hdr), 0); - if (ret) + if (ret) { + free(ctx); return ret; + } /* Update the hash with that of srk table if srk flag is 1 * If IE Table is selected, key is not added in the hash @@ -581,22 +585,29 @@ static int calc_esbchdr_esbc_hash(struct fsl_secboot_img_priv *img) key_hash = 1; } #endif - if (ret) + if (ret) { + free(ctx); return ret; - if (!key_hash) + } + if (!key_hash) { + free(ctx); return ERROR_KEY_TABLE_NOT_FOUND; + } /* Update hash for actual Image */ ret = algo->hash_update(algo, ctx, (u8 *)(*(img->img_addr_ptr)), img->img_size, 1); - if (ret) + if (ret) { + free(ctx); return ret; + } /* Copy hash at destination buffer */ ret = algo->hash_finish(algo, ctx, hash_val, algo->digest_size); - if (ret) + if (ret) { + free(ctx); return ret; - + } return 0; } -- 2.25.1

1 0

[PATCH] board: fsl_validate: Fix resource leak issue
by Kshitiz Varshney 23 Jul '21

23 Jul '21

Free dynamically allocated memory before every return statement in calc_img_key_hash() function. Verified the secure boot changes using ls1046afrwy board. Signed-off-by: Kshitiz Varshney <kshitiz.varshney(a)nxp.com> --- board/freescale/common/fsl_validate.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/board/freescale/common/fsl_validate.c b/board/freescale/common/fsl_validate.c index 564a8b3b54..d553bd88a0 100644 --- a/board/freescale/common/fsl_validate.c +++ b/board/freescale/common/fsl_validate.c @@ -498,8 +498,11 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv *img) return ret; ret = algo->hash_init(algo, &ctx); - if (ret) + if (ret) { + if (ctx) + free(ctx); return ret; + } /* Update hash for ESBC key */ #ifdef CONFIG_KEY_REVOCATION @@ -518,8 +521,11 @@ static int calc_img_key_hash(struct fsl_secboot_img_priv *img) /* Copy hash at destination buffer */ ret = algo->hash_finish(algo, ctx, hash_val, algo->digest_size); - if (ret) + if (ret) { + if (ctx) + free(ctx); return ret; + } for (i = 0; i < SHA256_BYTES; i++) img->img_key_hash[i] = hash_val[i]; -- 2.25.1

1 0

SAMA5D27 - UTMI issue?
by Tim 23 Jul '21

23 Jul '21

Hi, I have a custom board using the SAMA5D27 and basically have u-boot running now. The only issue I have is that because it uses a 24MHz crystal (like the SOM EV board) the UTMICKTRIM register needs to be set correctly (not just for USB - the CAN system runs best from the 480MHz UPLL clock). I can see code (a driver?) that does this but I don't believe it is being called (an inspection of the relevant register from the final user app that u-boot calls shows it has not been set, or not set correctly). I can see a patch 4 years ago that discusses this but I cannot for the life of me work out where or how from the myriad of Kconfig options, or anything else, that this would get called/set/used. Undoubtedly due to my inexperience with u-boot! Can someone please point me in the right direction? I don't think it's a bug/issue as such, I just need what is the magic CONFIG or board specific function/call, or whatever I need get the code called! Thanks, Tim.

1 0

[PATCH] net: remove CONFIG_NET_MULTI (again)
by Michal Simek 23 Jul '21

23 Jul '21

CONFIG_NET_MULTI has been removed long time ago by commit 795428fc679f ("net: remove CONFIG_NET_MULTI") but 4 boards were added later which wasn't found. The patch is removing this reference from 4 boards. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- include/configs/SBx81LIFKW.h | 1 - include/configs/SBx81LIFXCAT.h | 1 - include/configs/ebisu.h | 1 - include/configs/xilinx_versal.h | 1 - 4 files changed, 4 deletions(-) diff --git a/include/configs/SBx81LIFKW.h b/include/configs/SBx81LIFKW.h index eaa6b9246c98..ded494cfa9b0 100644 --- a/include/configs/SBx81LIFKW.h +++ b/include/configs/SBx81LIFKW.h @@ -84,7 +84,6 @@ * Ethernet Driver configuration */ #ifdef CONFIG_CMD_NET -#define CONFIG_NET_MULTI /* specify more that one ports available */ #define CONFIG_MVGBE /* Enable kirkwood Gbe Controller Driver */ #define CONFIG_MVGBE_PORTS {1, 0} /* enable a single port */ #define CONFIG_PHY_BASE_ADR 0x01 diff --git a/include/configs/SBx81LIFXCAT.h b/include/configs/SBx81LIFXCAT.h index c0dc3d38c123..06bbd8642e3f 100644 --- a/include/configs/SBx81LIFXCAT.h +++ b/include/configs/SBx81LIFXCAT.h @@ -84,7 +84,6 @@ * Ethernet Driver configuration */ #ifdef CONFIG_CMD_NET -#define CONFIG_NET_MULTI /* specify more that one ports available */ #define CONFIG_MVGBE /* Enable kirkwood Gbe Controller Driver */ #define CONFIG_MVGBE_PORTS {1, 0} /* enable a single port */ #define CONFIG_PHY_BASE_ADR 0x01 diff --git a/include/configs/ebisu.h b/include/configs/ebisu.h index 19ec74fb588d..48d4c8a9480e 100644 --- a/include/configs/ebisu.h +++ b/include/configs/ebisu.h @@ -14,7 +14,6 @@ #include "rcar-gen3-common.h" /* Ethernet RAVB */ -#define CONFIG_NET_MULTI #define CONFIG_BITBANGMII_MULTI /* Generic Timer Definitions (use in assembler source) */ diff --git a/include/configs/xilinx_versal.h b/include/configs/xilinx_versal.h index 99d58835887e..62680ad2386c 100644 --- a/include/configs/xilinx_versal.h +++ b/include/configs/xilinx_versal.h @@ -51,7 +51,6 @@ /* Ethernet driver */ #if defined(CONFIG_ZYNQ_GEM) -# define CONFIG_NET_MULTI # define CONFIG_SYS_FAULT_ECHO_LINK_DOWN # define PHY_ANEG_TIMEOUT 20000 #endif -- 2.32.0

3 2

[PATCH] mux: correct prototype for mux_control_try_select()
by Patrick Wildt 23 Jul '21

23 Jul '21

The macro should be passed a state, which should be passed to the actual function. Otherwise using that macro would yield a build error. Signed-off-by: Patrick Wildt <patrick(a)blueri.se> --- include/mux.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/mux.h b/include/mux.h index 23844f480a..9f80991274 100644 --- a/include/mux.h +++ b/include/mux.h @@ -51,7 +51,7 @@ unsigned int mux_control_states(struct mux_control *mux); */ int __must_check mux_control_select(struct mux_control *mux, unsigned int state); -#define mux_control_try_select(mux) mux_control_select(mux) +#define mux_control_try_select(mux, state) mux_control_select(mux, state) /** * mux_control_deselect() - Deselect the previously selected multiplexer state. @@ -128,7 +128,7 @@ int __must_check mux_control_select(struct mux_control *mux, return -ENOSYS; } -#define mux_control_try_select(mux) mux_control_select(mux) +#define mux_control_try_select(mux, state) mux_control_select(mux, state) int mux_control_deselect(struct mux_control *mux) { -- 2.32.0

3 2

[PATCH] arm: vexpress64: juno: Enable distro_bootcmd functionality
by Andre Przywara 23 Jul '21

23 Jul '21

The ARM Juno boards can be used as somewhat decent machines to run off-the-shelf distributions, with USB, SATA, GBit Ethernet and 8GB of DRAM. With stable DTs in the board's NOR flash this would work really nicely, however the default boot command is to fetch a kernel and an initrd from the on-board NOR flash, which sounds somewhat embedded. Include the config_distro_bootcmd.h header and define the available devices (starting with USB, to catch USB installer sticks) to make distributions and UEFI work out of the box. The NOR flash kernel functionality is still preserved as the last resort, should all other methods fail. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- include/configs/vexpress_aemv8a.h | 58 ++++++++++++++++++------------- 1 file changed, 34 insertions(+), 24 deletions(-) diff --git a/include/configs/vexpress_aemv8a.h b/include/configs/vexpress_aemv8a.h index 7318fb6c585..54b5967a89d 100644 --- a/include/configs/vexpress_aemv8a.h +++ b/include/configs/vexpress_aemv8a.h @@ -126,6 +126,39 @@ /* Initial environment variables */ #ifdef CONFIG_TARGET_VEXPRESS64_JUNO +/* Copy the kernel and FDT to DRAM memory and boot */ +#define BOOTENV_DEV_AFS(devtypeu, devtypel, instance) \ + "bootcmd_afs=" \ + "afs load ${kernel_name} ${kernel_addr_r} ;"\ + "if test $? -eq 1; then "\ + " echo Loading ${kernel_alt_name} instead of ${kernel_name}; "\ + " afs load ${kernel_alt_name} ${kernel_addr_r};"\ + "fi ; "\ + "afs load ${fdtfile} ${fdt_addr_r} ;"\ + "if test $? -eq 1; then "\ + " echo Loading ${fdt_alt_name} instead of ${fdtfile}; "\ + " afs load ${fdt_alt_name} ${fdt_addr_r}; "\ + "fi ; "\ + "fdt addr ${fdt_addr_r}; fdt resize; " \ + "if afs load ${ramdisk_name} ${ramdisk_addr_r} ; "\ + "then "\ + " setenv ramdisk_param ${ramdisk_addr_r}; "\ + "else "\ + " setenv ramdisk_param -; "\ + "fi ; " \ + "booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}\0" +#define BOOTENV_DEV_NAME_AFS(devtypeu, devtypel, instance) "afs " + +#define BOOT_TARGET_DEVICES(func) \ + func(USB, usb, 0) \ + func(SATA, sata, 0) \ + func(SATA, sata, 1) \ + func(PXE, pxe, na) \ + func(DHCP, dhcp, na) \ + func(AFS, afs, na) + +#include <config_distro_bootcmd.h> + /* * Defines where the kernel and FDT exist in NOR flash and where it will * be copied into DRAM @@ -139,30 +172,7 @@ "fdtfile=board.dtb\0" \ "fdt_alt_name=juno\0" \ "fdt_addr_r=0x80000000\0" \ - -#ifndef CONFIG_BOOTCOMMAND -/* Copy the kernel and FDT to DRAM memory and boot */ -#define CONFIG_BOOTCOMMAND "afs load ${kernel_name} ${kernel_addr_r} ;"\ - "if test $? -eq 1; then "\ - " echo Loading ${kernel_alt_name} instead of "\ - "${kernel_name}; "\ - " afs load ${kernel_alt_name} ${kernel_addr_r};"\ - "fi ; "\ - "afs load ${fdtfile} ${fdt_addr_r} ;"\ - "if test $? -eq 1; then "\ - " echo Loading ${fdt_alt_name} instead of "\ - "${fdtfile}; "\ - " afs load ${fdt_alt_name} ${fdt_addr_r}; "\ - "fi ; "\ - "fdt addr ${fdt_addr_r}; fdt resize; " \ - "if afs load ${ramdisk_name} ${ramdisk_addr_r} ; "\ - "then "\ - " setenv ramdisk_param ${ramdisk_addr_r}; "\ - " else setenv ramdisk_param -; "\ - "fi ; " \ - "booti ${kernel_addr_r} ${ramdisk_param} ${fdt_addr_r}" -#endif - + BOOTENV #elif CONFIG_TARGET_VEXPRESS64_BASE_FVP #define CONFIG_EXTRA_ENV_SETTINGS \ -- 2.17.5

4 3

[PATCH] distro_boot: Fix block device after DHCP boot sequence
by Andre Przywara 23 Jul '21

23 Jul '21

The generic distro boot sequence iterates over several types of devices, trying one after another. In doing do, it starts with setting the "devtype" variable, then uses this later in more generic commands. Now most (block) device types use a local variable for that, but DHCP puts the type into the environment, where it shadows any local variables. As a consequence any boot attempt after bootcmd_dhcp has been run fails: =========================== VExpress64# run bootcmd_dhcp ... VExpress64# run bootcmd_sata0 SATA#0: (3.0 Gbps) SATA#1: (No RDY) Device 0: Model: 16GB SATA Flash Drive .... ... is now current device Couldn't find partition dhcp 0:1 =========================== This problem typically doesn't show, because DHCP is mostly the last command to try, but is a problem when this order is different, or when distro_bootcmd or bootcmd_xxx are run separately or multiple times. Let bootcmd_dhcp use a local variable, as the other kids do, to make the order of boot commands irrelevant, and allow repeated calls. Signed-off-by: Andre Przywara <andre.przywara(a)arm.com> --- include/config_distro_bootcmd.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/config_distro_bootcmd.h b/include/config_distro_bootcmd.h index 2627c2a6a54..e70423f25dd 100644 --- a/include/config_distro_bootcmd.h +++ b/include/config_distro_bootcmd.h @@ -375,7 +375,7 @@ #endif #define BOOTENV_DEV_DHCP(devtypeu, devtypel, instance) \ "bootcmd_dhcp=" \ - "setenv devtype " #devtypel "; " \ + "devtype=" #devtypel "; " \ BOOTENV_RUN_NET_USB_START \ BOOTENV_RUN_PCI_ENUM \ "if dhcp ${scriptaddr} ${boot_script_dhcp}; then " \ -- 2.17.5

3 2