May 2022 - U-Boot

[PATCH v2 0/2] Add support for dynamic overriding of default SF bus
by Vaishnav Achath 31 May '22

31 May '22

Currently the SPI flash to load from is defined through the compile time config CONFIG_SF_DEFAULT_BUS and CONFIG_SF_DEFAULT_CS, this prevents the loading of binaries from different SPI flash using the same build. This series adds support for choosing the flash device based on the selected boot device thus allowing platforms to override the SF_BUS and SF_CS to load from the desired flash. Changes tested on J721E for OSPI and QSPI boot. V1->V2: * drop unnecessary Kconfig option for SF bus override, suggested by Heiko Schocher. Vaishnav Achath (2): common: spl: spl_spi: add support for dynamic override of sf bus arm: k3: j721e: add dynamic sf bus override support for j721e arch/arm/mach-k3/j721e_init.c | 17 +++++++++++++++++ arch/arm/mach-k3/sysfw-loader.c | 4 ++-- common/spl/spl_spi.c | 16 +++++++++++++--- include/spl.h | 16 ++++++++++++++++ 4 files changed, 48 insertions(+), 5 deletions(-) -- 2.17.1

3 6

[PATCH v2] board: gateworks: venice: add GW7903 PMIC
by Tim Harvey 31 May '22

31 May '22

The GW7903 has a BD71847 PMIC on I2C1. Adjust the model compare strings to add it. Signed-off-by: Tim Harvey <tharvey(a)gateworks.com> Reviewed-by: Fabio Estevam <festevam(a)denx.de> --- v2: fixed typo in commit log and added Fabio's rb tag --- board/gateworks/venice/spl.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/board/gateworks/venice/spl.c b/board/gateworks/venice/spl.c index 7e3e91e1d9cc..ae460296cb99 100644 --- a/board/gateworks/venice/spl.c +++ b/board/gateworks/venice/spl.c @@ -175,11 +175,12 @@ static int power_init_board(void) } else if ((!strncmp(model, "GW7901", 6)) || - (!strncmp(model, "GW7902", 6))) { - if (!strncmp(model, "GW7901", 6)) - ret = uclass_get_device_by_seq(UCLASS_I2C, 1, &bus); - else + (!strncmp(model, "GW7902", 6)) || + (!strncmp(model, "GW7903", 6))) { + if (!strncmp(model, "GW7902", 6)) ret = uclass_get_device_by_seq(UCLASS_I2C, 0, &bus); + else + ret = uclass_get_device_by_seq(UCLASS_I2C, 1, &bus); if (ret) { printf("PMIC : failed I2C2 probe: %d\n", ret); return ret; -- 2.17.1

2 1

[PATCH 00/10] board: sl28: various updates
by Michael Walle 30 May '22

30 May '22

This is an update for the sl28 board which adds support for - 8 GiB memory variant - different boot sources, like eMMC, SD-card - dynamic prompts - various cleanups Michael Walle (10): armv8: layerscape: add missing RCW source defines armv8: layerscape: spl: mark OCRAM as non-secure board: sl28: set CPO value board: sl28: remove unneeded ddr config parameter board: sl28: support 8 GiB memory board: sl28: rename include guard macro board: sl28: implement additional bootsources board: sl28: add user friendly names for the boot sources board: sl28: support dynamic prompts board: sl28: remove COUNTER_FREQUENCY_REAL arch/arm/cpu/armv8/fsl-layerscape/spl.c | 11 ++++ .../asm/arch-fsl-layerscape/immap_lsch3.h | 4 ++ board/kontron/sl28/common.c | 22 ++++++++ board/kontron/sl28/ddr.c | 12 ++++- board/kontron/sl28/sl28.c | 43 +++++++++++++++ board/kontron/sl28/sl28.h | 16 ++++++ board/kontron/sl28/spl.c | 54 ++++++++++++++++++- configs/kontron_sl28_defconfig | 6 ++- include/configs/kontron_sl28.h | 8 ++- 9 files changed, 167 insertions(+), 9 deletions(-) create mode 100644 board/kontron/sl28/sl28.h -- 2.30.2

1 10

Serial Download Boot on i.MX8MN EVK Board
by Thomas Schaefer 30 May '22

30 May '22

Hi all, We are trying to boot our i.MX8MNano UltraLite DDR3L EVK via USB using Serial Download Mode. We are using u-boot v2022.04-rc3 with patches to support DDR3L memory on this eval system. ATF firmware used is built using imx_5.4.47_2.2.0 branch of imx-atf firmware. In addition we are using ddr3_[di]mem_1d_201810.bin DDR training images from firmware-imx-8.10 package. When copying the resulting flash.bin image on SD card or eMMC, the board is booting fine to linux prompt. But when trying to boot that same image via USB when the board is in Serial Download Mode, the board hangs up when ATF firmware (bl31.bin) has finished (I have added some debug prints to BL31 to verify this). Are the DDR4/LPDDR4 variants of the i.MX8MNano eval kit known to boot in serial download mode? Best regards, Thomas Thomas Schäfer SW Design Engineer Kontron Europe GmbH Heinrich-Barth-Straße 1-1a | 66115 Saarbrücken | Germany thomas.schaefer(a)kontron.com

2 3

[RFC PATCH v2 0/8] Build Rockchip final images using binman
by Andrew Abbott 29 May '22

29 May '22

My original goal was to produce SPI images for Rockchip platforms (specifically for me, ROCKPro64, and in the future ROCK64). Looking into it, it seemed nicer to just switch the SD/MMC image generation over to binman as well in the process. This is my attempt to move Rockchip final full image generation to binman, adding the option to make full SPI images as well. Other questions: - I noticed that ATF generation for ARM64 Rockchip is done via a Python script instead of binman. I don't currently know how to change that over to binman, but is that something worth pursuing as part of this? Please give me your feedback! Changes in v2: - Revert u-boot-rockchip-sdmmc.bin name to u-boot-rockchip.bin, to keep the name the same as before. - Fix whitespace issues. - Remove note from docs about different offsets in SPI flash for different SoCs - this was a bad assumption on my part, it doesn't work this way. - Update name of SD/MMC image in the docs from u-boot-rockchip-sdmmc.bin to u-boot-rockchip.bin. Andrew Abbott (8): binman: mkimage: Support ':'-separated inputs rockchip: Add binman definitions for final images soc: rockchip: Include common U-Boot dtsi file board: rockchip: Move SPI U-Boot offset to config rockchip: Remove obsolete Makefile targets rockchip: Enable binman for ARM64 doc: rockchip: Update for new binman image generation board: rockpro64: Enable building SPI image Kconfig | 4 +- Makefile | 31 ++---------- arch/arm/Kconfig | 2 +- arch/arm/dts/rk3308-u-boot.dtsi | 2 + arch/arm/dts/rk3328-u-boot.dtsi | 2 + arch/arm/dts/rk3368-lion-haikou-u-boot.dtsi | 1 - arch/arm/dts/rk3368-u-boot.dtsi | 1 + arch/arm/dts/rk3399-pinebook-pro-u-boot.dtsi | 4 -- arch/arm/dts/rk3399-puma-haikou-u-boot.dtsi | 1 - arch/arm/dts/rk3399-roc-pc-u-boot.dtsi | 4 -- arch/arm/dts/rk3399-rockpro64-u-boot.dtsi | 4 -- arch/arm/dts/rk3568-u-boot.dtsi | 2 + arch/arm/dts/rockchip-u-boot.dtsi | 53 ++++++++++++++++++-- arch/arm/mach-rockchip/Kconfig | 7 ++- arch/arm/mach-rockchip/rk3399/Kconfig | 1 + configs/lion-rk3368_defconfig | 1 + configs/pinebook-pro-rk3399_defconfig | 1 + configs/puma-rk3399_defconfig | 2 +- configs/roc-pc-rk3399_defconfig | 1 + configs/rockpro64-rk3399_defconfig | 1 + doc/board/rockchip/rockchip.rst | 29 +++-------- tools/binman/etype/mkimage.py | 33 +++++++----- 22 files changed, 100 insertions(+), 87 deletions(-) -- 2.36.0

3 21

[PATCH] doc: sandbox: Add additional valgrind documentation
by Sean Anderson 29 May '22

29 May '22

This document some additional options which can be used with valgrind, as well as directions for future work. It also fixes up inline literals to actually be inline literals (and not italics). The content of this documentation is primarily adapted from [1]. [1] https://lore.kernel.org/u-boot/57cb4b49-fa30-1194-9ac3-faa53e8033bd@gmail.c… Signed-off-by: Sean Anderson <seanga2(a)gmail.com> --- doc/arch/sandbox.rst | 65 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 61 insertions(+), 4 deletions(-) diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index e1119492b4..cd5090be71 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -479,19 +479,76 @@ It is possible to run U-Boot under valgrind to check memory allocations:: valgrind ./u-boot -For more detailed results, enable `CONFIG_VALGRIND`. There are many false -positives due to `malloc` itself. Suppress these with:: +For more detailed results, enable ``CONFIG_VALGRIND``. There are many false +positives due to ``malloc`` itself. Suppress these with:: valgrind --suppressions=scripts/u-boot.supp ./u-boot If you are running sandbox SPL or TPL, then valgrind will not by default notice when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. To -fix this, use `--trace-children=yes`. To show who alloc'd some troublesome -memory, use `--track-origins=yes`. To uncover possible errors, try running all +fix this, use ``--trace-children=yes``. To show who alloc'd some troublesome +memory, use ``--track-origins=yes``. To uncover possible errors, try running all unit tests with:: valgrind --track-origins=yes --suppressions=scripts/u-boot.supp ./u-boot -Tc 'ut all' +Additional options +^^^^^^^^^^^^^^^^^^ + +The following options are useful in addition to the above examples: + +* ``--error-limit=no`` will enable printing more than 1000 errors in a + single session. +* ``--vgdb=yes --vgdb-error=0`` will let you use gdb to attach like:: + + gdb -ex "target remote | vgdb" u-boot + + This is very helpful for inspecting the program state when there is + an error. +* Passing ``-t cooked`` to U-Boot will keep the console in a sane state if you + terminate it early (instead of having to run tset). + +Future work +^^^^^^^^^^^ + +The biggest limitation to the current approach is that +supressions don't "un-taint" uninitialized memory accesses. Currently, I +have dlmalloc's reads its bookkeeping information marked as a "red +zone." This means that all reads to it are marked as illegal by +valgrind. This is fine for regular code, but dlmalloc really does need +to access this area, so we suppress its violations. However, if dlmalloc +then passes a result calculated from a "tainted" access, that result is +still tainted. So the first accessor will raise a warning. This means +that every construct like + +.. code-block:: + + foo = malloc(sizeof(*foo)); + if (!foo) + return -ENOMEM; + +will raise a warning when we check the result of malloc. Whoops. + +There are three ways (as I see it) to address this: + +* Don't mark dlmalloc bookkeeping information as a red zone. This is the + simplest solution, but reduces the power of valgrind immensely, since + we can no longer determine that (e.g.) access past the end of an array + is undefined. +* Implement red zones properly. This would involve growing every + allocation by a fixed amount (16 bytes or so) and then using that + extra space for a real red zone that neither regular code nor dlmalloc + needs to access. Unfortunately, this would probably some fairly + intensive surgery to dlmalloc to add/remove the offset appropriately. +* Mark bookkeeping information as valid before we use it in dlmalloc, + and then mark it invalid before returning. This would be the most + correct, but it would be very tricky to implement since there are so + many code paths to mark. I think it would be the most effort out of + the three options here. + +Until one of the above options are implemented, it will remain difficult +to sift through the massive amount of spurious warnings. + Testing ------- -- 2.35.1

2 4

[PATCH v2 0/2] fix issues in bootmenu after adding efi entries
by Masahisa Kojima 29 May '22

29 May '22

This series fixes the issue in bootmenu after adding efi entries. Masahisa Kojima (2): bootmenu: use utf-8 for menu title bootmenu: U-Boot console is enabled as default boot/Kconfig | 7 +++++++ cmd/Kconfig | 10 ---------- cmd/bootmenu.c | 40 +++++++++++++++++++++++----------------- 3 files changed, 30 insertions(+), 27 deletions(-) -- 2.17.1

4 6

[PATCH v3 0/2] fix issues in bootmenu after adding efi entries
by Masahisa Kojima 29 May '22

29 May '22

This series fixes the issue in bootmenu after adding efi entries. Masahisa Kojima (2): bootmenu: use utf-8 for menu title bootmenu: U-Boot console is enabled as default boot/Kconfig | 7 +++++++ cmd/Kconfig | 10 ---------- cmd/bootmenu.c | 48 ++++++++++++++++++++++++++---------------------- 3 files changed, 33 insertions(+), 32 deletions(-) -- 2.17.1

1 2

Converting CONFIG_SPL_BOOT_DEVICE to Kconfig in U-Boot
by Tom Rini 29 May '22

29 May '22

Hey folks, As part of converting outstanding CONFIG symbols to Kconfig, I've run in to CONFIG_SPL_BOOT_DEVICE and while I think I see how to do it, it would be better I think if someone that has the hardware and can test the logic out, does it. In short, I believe we need to: - SPL_BOOT_SPI_NOR_FLASH / SPL_BOOT_SDIO_MMC_CARD become a choice section in arch/arm/mach-mvebu/Kconfig, guarded by !SECURED_MODE_IMAGE - KWB_CFG_SEC_BOOT_DEV in arch/arm/mach-mvebu/Makefile gets updated based on how the Kconfig logic now works. - In the case of CONFIG_SPL_BOOT_SDIO_MMC_CARD (or whatever it's named) and MMC_SDHCI we just have that value defined and drivers/mmc/sdhci.c is updated to check it for SPL. Or if this is possibly useful outside of SPL, we make use of CONFIG_VAL and have 'SPL_FIXED_SDHCI_ALIGNED_BUFFER' be set for the current case. - CONFIG_SPL_BOOT_DEVICE is removed I think that covers everything, but please let me know if I missed something or I got the logic wrong or something. Thanks! -- Tom

2 4

[PATCH v3 1/2] doc: sandbox: Add additional valgrind documentation
by Sean Anderson 28 May '22

28 May '22

This documents some additional options which can be used with valgrind, as well as directions for future work. It also fixes up inline literals to actually be inline literals (and not italics). The content of this documentation is primarily adapted from [1]. [1] https://lore.kernel.org/u-boot/57cb4b49-fa30-1194-9ac3-faa53e8033bd@gmail.c… Signed-off-by: Sean Anderson <seanga2(a)gmail.com> --- Changes in v3: - Fix some spelling errors - Reword ut all docs for clarity Changes in v2: - Reworked most documentation to address Heinrich's feedback doc/arch/sandbox.rst | 90 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 82 insertions(+), 8 deletions(-) diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index e1119492b4..79bcef4f5e 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -479,18 +479,92 @@ It is possible to run U-Boot under valgrind to check memory allocations:: valgrind ./u-boot -For more detailed results, enable `CONFIG_VALGRIND`. There are many false -positives due to `malloc` itself. Suppress these with:: +However, this does not give very useful results. The sandbox allocates a memory +pool via mmap(). U-Boot's internal malloc() and free() work on this memory pool. +Custom allocators and deallocators are invisible to valgrind by default. To +expose U-Boot's malloc() and free() to valgrind, enable ``CONFIG_VALGRIND``. +Enabling this option will inject placeholder assembler code which valgrind +interprets. This is used to annotate sections of memory as safe or unsafe, and +to inform valgrind about malloc()s and free()s. There are currently no standard +placeholder assembly sequences for RISC-V, so this option cannot be enabled on +that architecture. + +Malloc's bookkeeping information is marked as unsafe by default. However, this +will generate many false positives when malloc itself accesses this information. +These warnings can be suppressed with:: valgrind --suppressions=scripts/u-boot.supp ./u-boot -If you are running sandbox SPL or TPL, then valgrind will not by default -notice when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. To -fix this, use `--trace-children=yes`. To show who alloc'd some troublesome -memory, use `--track-origins=yes`. To uncover possible errors, try running all -unit tests with:: +Additionally, you may experience false positives if U-Boot is using a smaller +pointer size than your host architecture. This is because the pointers used by +U-Boot will only contain 32 bits of addressing information. When interpreted as +64-bit pointers, valgrind will think that they are not initialized properly. To +fix this, enable ``CONFIG_SANDBOX64`` (such as via ``sandbox64_defconfig``) +when running on a 64-bit host. - valgrind --track-origins=yes --suppressions=scripts/u-boot.supp ./u-boot -Tc 'ut all' +Additional options +^^^^^^^^^^^^^^^^^^ + +The following options are useful in addition to the above examples: + +* ``--trace-childen=yes`` will tell valgrind to keep tracking subprocesses, such + as when U-Boot jumps from TPL to SPL, or from SPL to U-Boot proper. +* ``--track-origins=yes`` will (for a small overhead) tell valgrind to keep + track of who allocated some troublesome memory. +* ``--error-limit=no`` will enable printing more than 1000 errors in a + single session. +* ``--vgdb=yes --vgdb-error=0`` will let you use gdb to attach like:: + + gdb -ex "target remote | vgdb" u-boot + + This is very helpful for inspecting the program state when there is + an error. +* Passing ``-Tc 'ut all'`` to U-Boot will run unit tests automatically. Note + that not all unit tests will succeed in the default configuration. +* Passing ``-t cooked`` to U-Boot will keep the console in a sane state if you + terminate it early (instead of having to run tset). + +Future work +^^^^^^^^^^^ + +The biggest limitation to the current approach is that supressions don't +"un-taint" uninitialized memory accesses. Currently, dlmalloc's bookkeeping +information is marked as a "red zone." This means that all reads to that zone +are marked as illegal by valgrind. This is fine for regular code, but dlmalloc +really does need to access this area, so we suppress its violations. However, if +dlmalloc then passes a result calculated from a "tainted" access, that result is +still tainted. So the first accessor will raise a warning. This means that every +construct like + +.. code-block:: + + foo = malloc(sizeof(*foo)); + if (!foo) + return -ENOMEM; + +will raise a warning when we check the result of malloc. Whoops. + +There are at least four possible ways to address this: + +* Don't mark dlmalloc bookkeeping information as a red zone. This is the + simplest solution, but reduces the power of valgrind immensely, since we can + no longer determine that (e.g.) access past the end of an array is undefined. +* Implement red zones properly. This would involve growing every allocation by a + fixed amount (16 bytes or so) and then using that extra space for a real red + zone that neither regular code nor dlmalloc needs to access. Unfortunately, + this would probably some fairly intensive surgery to dlmalloc to add/remove + the offset appropriately. +* Mark bookkeeping information as valid before we use it in dlmalloc, and then + mark it invalid before returning. This would be the most correct, but it would + be very tricky to implement since there are so many code paths to mark. I + think it would be the most effort out of the three options here. +* Use the host malloc and free instead of U-Boot's custom allocator. This will + eliminate the need to annotate dlmalloc. However, using a different allocator + for sandbox will mean that bugs in dlmalloc will only be tested when running + on read (or emulated) hardware. + +Until one of the above options are implemented, it will remain difficult +to sift through the massive amount of spurious warnings. Testing ------- -- 2.35.1

2 2