November 2021 - U-Boot

Re: [PATCH v2 0/2] env: setenv add resolve value option
by Art Nikpal 22 Nov '21

22 Nov '21

On Sat, Nov 20, 2021 at 8:36 PM Wolfgang Denk <wd(a)denx.de> wrote: > > Dear Artem, > > In message <CAKaHn9KZg13r=pGCo=Lv69pBP-s-EW4uxjBVuH9veT+o5j9v+g(a)mail.gmail.com> you wrote: > > > > next examples just demonstrate how its works for already defined env > > variables which contain other variables (like storred env variables) > > Which next examples? Usage examples (from commit message): => setenv a hello; setenv b world; setenv c '${a} ${b}' => setenv -r d '${c}! ${a}...' => printenv d d=hello world! hello... > > > sure I know about this ! see my prev message please . > > Which exact message are you referring to here? > > > Why not have this new opportunity ? > > I think the suggested code is adding more problems than it solves. > > > > have in mind, as you speak of "deep resolve". But then, I'm first > > > missing an explanation (and documentation) of what "deep resolve" > > > > recurrent resolving for variables > > Your implementation of recursion has an arbiotrary and undocumented > depth limit. Also, I cannot see a way to prevent resolving in case I > want to keep something like "$foo" in the result. > > But that's to be expected from such a non-standard way. > > Why don't you stick with what "eval" in a standard shell does? > > > > actually means in this context, i. e. how many levels down you > > > evaluat. Oh... the code has "int max_loop = 32;" - this is a > > > > i think its will be enough > > It is a reallybad habt to implement code with arbitrary limits, as > it will blow into your face (or more likely that of an innocent > user) rather sooner than later. It's even worse that this limit is > nowhere documented. > > > 1) this option did not broke any exist compatibilities > > 2) there we talk not only about uboot shell, same time will be useful > > to have env_resolve for internal c usage, because env_set dont have > > this feature > > I did not say that an "eval" like construct would not be useful. > But uncontrolled recursion with an undocumented depth limit is > a problem. > > > yes i'm informed about this plans (and think its happens not so > > soon - but i provide some simple elegant solution already) > > but again we dont have env_resolve for internal c usage which must be > > very useful > > On the CLI, we use the "run" command to get the desired effect. Yes, > this is neither perfect nor elegant. But you can use that in C code > as well. > > > will be easy get useful features via simple solution ( deep resolve > > all vars by one line ) > > I understand what you want, but this is not a good way to solve the > problem. I'd really rather see such efforts invested in helping > Francis with the hush update - which will make such code unnecessary. > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd(a)denx.de > Success in marriage is not so much finding the right person as it is > being the right person.

2 2

[PATCH 0/5] meson64_android: add support for vim3/vim3l boards
by Mattijs Korpershoek 22 Nov '21

22 Nov '21

The VIM3 and VIM3L boards are well supported in the Android Open Source project via the yukawa [1] platform. Their U-Boot version, despite being public [2] is not in mainline. [1] https://android.googlesource.com/device/amlogic/yukawa [2] https://gitlab.com/baylibre/amlogic/atv/u-boot/-/tree/u-boot/v2021.07/integ Add defconfigs for both vim3, vim3l to support traditional and A/B booting/partitioning schemes. Mattijs Korpershoek (5): configs: meson64_android: add board specific env settings configs: prepare khadas-vim3{l}_android for AOSP support boards: meson: add khadas vim3{l} android support configs: prepare khadas-vim3{l}_ab_android for AOSP support configs: khadas-vim3{l}_android_ab: enable A/B support board/amlogic/vim3/MAINTAINERS | 4 + configs/khadas-vim3_android_ab_defconfig | 109 ++++++++++++++++++++++ configs/khadas-vim3_android_defconfig | 107 +++++++++++++++++++++ configs/khadas-vim3l_android_ab_defconfig | 109 ++++++++++++++++++++++ configs/khadas-vim3l_android_defconfig | 107 +++++++++++++++++++++ include/configs/khadas-vim3_android.h | 50 ++++++++++ include/configs/khadas-vim3l_android.h | 50 ++++++++++ include/configs/meson64_android.h | 17 ++++ 8 files changed, 553 insertions(+) create mode 100644 configs/khadas-vim3_android_ab_defconfig create mode 100644 configs/khadas-vim3_android_defconfig create mode 100644 configs/khadas-vim3l_android_ab_defconfig create mode 100644 configs/khadas-vim3l_android_defconfig create mode 100644 include/configs/khadas-vim3_android.h create mode 100644 include/configs/khadas-vim3l_android.h -- 2.32.0

2 9

[PATCH 1/4] arm: stm32mp: bsec: Update OTP shadow registers in SPL
by Patrick Delaunay 22 Nov '21

22 Nov '21

Currently the upper OTP (after 57) are shadowed in U-Boot proper, when TFABOOT is not used. This choice cause an issue when U-Boot is not executed after SPL, so this BSEC initialization is moved in SPL and no more executed in U-Boot, so it is still executed only one time. After this patch this BSEC initialization is done in FSBL: SPL or TF-A. To force this initialization in all the case, the probe of the BSEC driver is forced in SPL in the arch st32mp function: spl_board_init(). Even if today BSEC driver is already probed in STM32MP15x clock driver clk_stm32mp1.c because get_cpu_type() is called in stm32mp1_get_max_opp_freq() function. Reported-by: Alexandru Gagniuc <mr.nuke.me(a)gmail.com> Signed-off-by: Patrick Delaunay <patrick.delaunay(a)foss.st.com> --- It is updated version of proposed Alexandru patch: [v2,06/11] arm: stm32mp: bsec: Update OTP shadow registers in SPL http://patchwork.ozlabs.org/project/uboot/patch/20210907235933.2798330-7-mr… arch/arm/mach-stm32mp/bsec.c | 5 ++--- arch/arm/mach-stm32mp/cpu.c | 8 ++++++++ 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/arch/arm/mach-stm32mp/bsec.c b/arch/arm/mach-stm32mp/bsec.c index fe39bd80cf..e517acdd01 100644 --- a/arch/arm/mach-stm32mp/bsec.c +++ b/arch/arm/mach-stm32mp/bsec.c @@ -503,10 +503,9 @@ static int stm32mp_bsec_probe(struct udevice *dev) /* * update unlocked shadow for OTP cleared by the rom code - * only executed in U-Boot proper when TF-A is not used + * only executed in SPL, it is done in TF-A for TFABOOT */ - - if (!IS_ENABLED(CONFIG_TFABOOT) && !IS_ENABLED(CONFIG_SPL_BUILD)) { + if (IS_ENABLED(CONFIG_SPL_BUILD)) { plat = dev_get_plat(dev); for (otp = 57; otp <= BSEC_OTP_MAX_VALUE; otp++) diff --git a/arch/arm/mach-stm32mp/cpu.c b/arch/arm/mach-stm32mp/cpu.c index eb79f3ffd2..0263ffe96a 100644 --- a/arch/arm/mach-stm32mp/cpu.c +++ b/arch/arm/mach-stm32mp/cpu.c @@ -174,7 +174,15 @@ static void dbgmcu_init(void) void spl_board_init(void) { + struct udevice *dev; + int ret; + dbgmcu_init(); + + /* force probe of BSEC driver to shadow the upper OTP */ + ret = uclass_get_device_by_driver(UCLASS_MISC, DM_DRIVER_GET(stm32mp_bsec), &dev); + if (ret) + log_warning("BSEC probe failed: %d\n", ret); } #endif /* !defined(CONFIG_SPL) || defined(CONFIG_SPL_BUILD) */ -- 2.25.1

3 8

serial download on imx8mp
by Rasmus Villemoes 22 Nov '21

22 Nov '21

Hi I'm having trouble getting serial download to work on an imx8mp evk. I'm building on top of v2021.10. The SPL + U-Boot proper that I build work fine when I write them to an SD card and boot from that, also boot from eMMC with the same binaries works fine. I can also succesfully get the SPL to load and run via USB, and I can _partially_ load the u-boot.itb; in the sense that I can see that bl31.bin runs: I get the lines NOTICE: BL31: v2.4(release):lf-5.10.52-2.1.0-rc1-39-gbb4957067 NOTICE: BL31: Built : 04:45:39, Sep 8 2021 on the serial console (same as when happens when booting via sd or emmc), but then the board just hangs. Now, extracting the u-boot.itb from the imx-boot-imx8mpevk-sd.bin-flash_evk file I found inside LF_v5.10.52-2.1.0_images_IMX8MPEVK.zip, I can actually get _that_ u-boot.itb to run on top of the SPL that I built, so I think my SPL is alright (after all, it does manages to hand control over to BL31). That u-boot.itb is U-Boot 2021.04-lf_v2021.04+g1c0116f3da Vanilla v2021.04 shows the same symptoms of being unable to boot via serial download. So I did a bisect between v2021.04 and 1c0116f3da. That bisect lands at commit 3a053a1bd6bc03eaffe82648a318b065d70d1bd0 (refs/bisect/boots) Author: Ye Li <ye.li(a)nxp.com> Date: Tue Apr 21 20:14:29 2020 -0700 MLK-23574-39 imx8mp_evk: Update iMX8MP EVK board codes so I suppose _something_ in that commit fixed it, but unfortunately board/freescale/imx8mp_evk/imx8mp_evk.c | 332 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++- board/freescale/imx8mp_evk/spl.c | 79 ++++++++++++------------- configs/imx8mp_evk_defconfig | 66 +++++++++++++++++++-- include/configs/imx8mp_evk.h | 156 ++++++++++++++++++++++++++++++++++++++++++------- 4 files changed, 561 insertions(+), 72 deletions(-) means I have no idea what part of it is missing in mainline, or if there are more bits and pieces scattered around that are prerequisites for getting it to work. But it's really odd, because once the entire image has been downloaded, the components of the FIT have been loaded to the proper addresses and control handed over to BL31, I don't see how U-Boot proper (the very same binary that's used when booting from sd or emmc) can fail, and U-Boot shouldn't really need to know or care about where it was loaded from. Rasmus

3 2

mxc_nand lacking support?
by Wouter Vanhauwaert 22 Nov '21

22 Nov '21

Is it just me, or is mxc_nand (nand for imx53) lacking quiet some things? It does not support ONFI (READID on address 0x20 is just ignoring the address and reading from 0, so returning the normal ID) It does not support 4k flashes (largepage is just 2k, no oob for 4k available) I want to support MT29F8G08ABABAWP, which is a 4k-paged 1GiB flash. And even after adding it to the nand list manually and being detected, it spits out tons of ECC errors

1 0

[PATCH] test: address some pylint warnings
by Heinrich Schuchardt 22 Nov '21

22 Nov '21

* remove unused variables * module description must precede import statements * fix inconsistent return values Signed-off-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> --- test/py/tests/test_efi_loader.py | 10 +++++----- test/py/tests/test_efi_selftest.py | 6 ++---- 2 files changed, 7 insertions(+), 9 deletions(-) diff --git a/test/py/tests/test_efi_loader.py b/test/py/tests/test_efi_loader.py index fc8d6b8655..85473a9049 100644 --- a/test/py/tests/test_efi_loader.py +++ b/test/py/tests/test_efi_loader.py @@ -6,9 +6,6 @@ # Test efi loader implementation -import pytest -import u_boot_utils - """ Note: This test relies on boardenv_* containing configuration values to define which network environment is available for testing. Without this, the parts @@ -50,6 +47,9 @@ env__efi_loader_helloworld_file = { } """ +import pytest +import u_boot_utils + net_set_up = False def test_efi_pre_commands(u_boot_console): @@ -80,7 +80,7 @@ def test_efi_setup_dhcp(u_boot_console): env_vars = u_boot_console.config.env.get('env__net_static_env_vars', None) if not env_vars: pytest.skip('No DHCP server available') - return None + return u_boot_console.run_command('setenv autoload no') output = u_boot_console.run_command('dhcp') @@ -193,7 +193,7 @@ def test_efi_grub_net(u_boot_console): check_smbios = u_boot_console.config.env.get('env__efi_loader_check_smbios', False) if check_smbios: u_boot_console.wait_for('grub>') - output = u_boot_console.run_command('lsefisystab', wait_for_prompt=False, wait_for_echo=False) + u_boot_console.run_command('lsefisystab', wait_for_prompt=False, wait_for_echo=False) u_boot_console.wait_for('SMBIOS') # Then exit cleanly diff --git a/test/py/tests/test_efi_selftest.py b/test/py/tests/test_efi_selftest.py index 63218efbc2..0161a6ea24 100644 --- a/test/py/tests/test_efi_selftest.py +++ b/test/py/tests/test_efi_selftest.py @@ -73,8 +73,7 @@ def test_efi_selftest_text_input(u_boot_console): This function calls the text input EFI selftest. """ u_boot_console.run_command(cmd='setenv efi_selftest text input') - output = u_boot_console.run_command(cmd='bootefi selftest', - wait_for_prompt=False) + u_boot_console.run_command(cmd='bootefi selftest', wait_for_prompt=False) m = u_boot_console.p.expect([r'To terminate type \'x\'']) if m != 0: raise Exception('No prompt for \'text input\' test') @@ -143,8 +142,7 @@ def test_efi_selftest_text_input_ex(u_boot_console): This function calls the extended text input EFI selftest. """ u_boot_console.run_command(cmd='setenv efi_selftest extended text input') - output = u_boot_console.run_command(cmd='bootefi selftest', - wait_for_prompt=False) + u_boot_console.run_command(cmd='bootefi selftest', wait_for_prompt=False) m = u_boot_console.p.expect([r'To terminate type \'CTRL\+x\'']) if m != 0: raise Exception('No prompt for \'text input\' test') -- 2.32.0

1 0

[PATCH v3 1/2] nvme: Enable FUA
by Jon Lin 22 Nov '21

22 Nov '21

Most NVME devcies maintain data in internal cache for an uncertain times, and u-boot has no method to force NVME to flush cache. So this patch adds FUA to avoid data loss caused by power off after data programming. Signed-off-by: Jon Lin <jon.lin(a)rock-chips.com> Reviewed-by: Stefan Agner <stefan(a)agner.ch> --- Changes in v3: Only enable FUA when vwc is enabled drivers/nvme/nvme.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/nvme/nvme.c b/drivers/nvme/nvme.c index 3c529a2fce..9623c896a1 100644 --- a/drivers/nvme/nvme.c +++ b/drivers/nvme/nvme.c @@ -762,6 +762,10 @@ static ulong nvme_blk_rw(struct udevice *udev, lbaint_t blknr, c.rw.appmask = 0; c.rw.metadata = 0; + /* Enable FUA for data integrity if vwc is enabled */ + if (dev->vwc) + c.rw.control |= NVME_RW_FUA; + while (total_lbas) { if (total_lbas < lbas) { lbas = (u16)total_lbas; -- 2.17.1

3 7

link error while u-boot-spl build : undefined ref to `printf` or `strcmp` etc.
by Chan Kim 22 Nov '21

22 Nov '21

Hello, When I build u-boot, I get this error at the end. (during u-boot-spl build). I've been fixing some link errors by adding config values but I can't figure out what is wrong with this. Below is the final command for u-boot-spl build and the error messages. Can any expert tell me what can be wrong here? ( cd spl && aarch64-none-elf-gcc -nostdlib -nostartfiles -fuse-linker-plugin -flto=28 -Wall -Wstrict-prototypes -Wno-format-security -fno-builtin -ffreestanding -std=gnu11 -fshort-wchar -fno-strict-aliasing -fno-PIE -Os -flto=28 -fno-stack-protector -fno-delete-null-pointer-checks -Wno-pointer-sign -Wno-stringop-truncation -Wno-zero-length-bounds -Wno-array-bounds -Wno-stringop-overflow -Wno-maybe-uninitialized -fmacro-prefix-map=./= -g -fstack-usage -Wno-format-nonliteral -Wno-address-of-packed-member -Wno-unused-but-set-variable -Werror=date-time -Wno-packed-not-aligned -ffunction-sections -fdata-sections -fno-stack-protector -D__KERNEL__ -D__UBOOT__ -DCONFIG_SPL_BUILD -D__ARM__ -mstrict-align -fno-common -ffixed-r9 -mgeneral-regs-only -fno-common -ffixed-x18 -pipe -march=armv8-a+crc -D__LINUX_ARM_ARCH__=8 -Ispl/include -Iinclude -I./arch/arm/include -include ./include/linux/kconfig.h -nostdinc -isystem /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/include -Wl,-T -Wl,u-boot-spl.lds -Wl,--gc-sections -Wl,-Bstatic -Wl,--gc-sections -Wl,--no-dynamic-linker -Wl,--build-id=none -Wl,-Ttext -Wl,0x4000000 arch/arm/cpu/armv8/start.o -Wl,--whole-archive arch/arm/cpu/armv8/built-in.o arch/arm/cpu/built-in.o arch/arm/lib/built-in.o board/etri/ab21m/built-in.o common/spl/built-in.o common/init/built-in.o common/built-in.o cmd/built-in.o env/built-in.o disk/built-in.o drivers/built-in.o dts/built-in.o fs/built-in.o keep-syms-lto.o -L /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1 -lgcc -Wl,--no-whole-archive -Wl,-Map,u-boot-spl.map -o u-boot-spl ) /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/../../../../aarch64-none-elf/bin/ld: /tmp/u-boot-spl.GeKfJh.ltrans0.ltrans.o: in function `alloc_simple': /home/ckim/U-BOOT/u-boot/spl/../common/malloc_simple.c:29: undefined reference to `printf' /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/../../../../aarch64-none-elf/bin/ld: /tmp/u-boot-spl.GeKfJh.ltrans0.ltrans.o: in function `device_bind_by_name': /home/ckim/U-BOOT/u-boot/spl/../drivers/core/lists.c:31: undefined reference to `strcmp' /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/../../../../aarch64-none-elf/bin/ld: /tmp/u-boot-spl.GeKfJh.ltrans0.ltrans.o: in function `board_init_r': /home/ckim/U-BOOT/u-boot/spl/../common/spl/spl.c:697: undefined reference to `timer_init' /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/../../../../aarch64-none-elf/bin/ld: /home/ckim/U-BOOT/u-boot/spl/../common/spl/spl.c:690: undefined reference to `hang' /opt/arm-toolchains/gcc-arm-10.2-2020.11-x86_64-aarch64-none-elf/bin/../lib/ gcc/aarch64-none-elf/10.2.1/../../../../aarch64-none-elf/bin/ld: /home/ckim/U-BOOT/u-boot/spl/../common/spl/spl.c:633: undefined reference to `printf' collect2: error: ld returned 1 exit status make[1]: *** [scripts/Makefile.spl:509: spl/u-boot-spl] Error 1 make: *** [Makefile:1984: spl/u-boot-spl] Error 2 Thank you. Chan Kim

2 2

Pull request for efi-2022-01-rc3
by Heinrich Schuchardt 20 Nov '21

20 Nov '21

Dear Tom, I am still trying to reproduce the usb_stop() issue on the sandbox, to understand what is wrong in DM. So your patch will go to next weeks pull request. But generally you are right that usb_stop() must be called before deleting the devices if at all. The following changes since commit 454a97485a1854d4ac4f3b7d408caf3b355beca0: Merge tag 'u-boot-amlogic-20211119' of https://source.denx.de/u-boot/custodians/u-boot-amlogic (2021-11-19 16:33:33 -0500) are available in the Git repository at: https://source.denx.de/u-boot/custodians/u-boot-efi.git efi-2022-01 for you to fetch changes up to 8bb8cde4f56ec45ac7b48fefc5bb0430b29e2878: efi_loader: startup the tpm device when installing the protocol (2021-11-20 10:27:56 +0100) Gitlab CI reported no issues: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/9925 ---------------------------------------------------------------- Pull request for efi-2022-01-rc3 Scripts: * Update spelling.txt LMB: * remove extern keyword in lmb.h * drop unused lmb_size_bytes() Test: * test truncation in snprintf() Documentation: * add include/lmb.h to HTML documentation UEFI: * reduce non-debug logging output for measured boot * fix use after free in measured boot * startup the tpm device when installing the protocol * implement EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES * record capsule result only if capsule is read ---------------------------------------------------------------- Heinrich Schuchardt (13): lmb: remove lmb_is_nomap() from include doc: add include/lmb.h to the HTML documentation lmb: remove extern keyword in lmb.h lmb: drop unused lmb_size_bytes() lmb: fix typo 'commun' test: test truncation in snprintf() configs: enable CMD_TPM on QEMU ARM scripts: update spelling.txt from upstream Linux doc: fix typos in trace.rst efi_loader: Sphinx comments in efi_api.h efi_loader: EFI_EVENT_GROUP_BEFORE_EXIT_BOOT_SERVICES efi_selftest: unit test for EFI_GROUP_BEFORE_EXIT_BOOT_SERVICE efi_loader: bump EFI_SPECIFICATION_VERSION to 2.9 Ilias Apalodimas (2): efi_loader: fix FinalEvents table if an EFI app invoked GetEventLog efi_loader: startup the tpm device when installing the protocol Masahisa Kojima (2): efi: add comment for efi_system_table and efi_configuration_table efi_loader: Reduce efi_tcg2 logging statement Masami Hiramatsu (1): efi_loader: capsule: Record capsule result only if capsule is read configs/qemu_arm64_defconfig | 1 + configs/qemu_arm_defconfig | 1 + doc/api/index.rst | 1 + doc/api/lmb.rst | 7 + doc/develop/trace.rst | 16 +- include/efi_api.h | 59 +++- include/lmb.h | 72 ++--- lib/Kconfig | 2 +- lib/efi_loader/efi_boottime.c | 13 + lib/efi_loader/efi_capsule.c | 6 +- lib/efi_loader/efi_tcg2.c | 110 +++++-- lib/efi_selftest/efi_selftest_exitbootservices.c | 67 ++++- scripts/spelling.txt | 365 ++++++++++++++++++++++- test/lib/lmb.c | 5 + test/print_ut.c | 18 ++ test/py/tests/test_tpm2.py | 1 + 16 files changed, 634 insertions(+), 110 deletions(-) create mode 100644 doc/api/lmb.rst

2 1

[PATCH] net: uclass: Save ethernet MAC address when generated
by Michal Simek 20 Nov '21

20 Nov '21

When MAC address is randomly generated it should be also saved to variables. This step is there when MAC address is passed via pdata but not when it is randomly generated. Signed-off-by: Michal Simek <michal.simek(a)xilinx.com> --- net/eth-uclass.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/net/eth-uclass.c b/net/eth-uclass.c index 0da0e85be031..58c308f33276 100644 --- a/net/eth-uclass.c +++ b/net/eth-uclass.c @@ -583,6 +583,8 @@ static int eth_post_probe(struct udevice *dev) net_random_ethaddr(pdata->enetaddr); printf("\nWarning: %s (eth%d) using random MAC address - %pM\n", dev->name, dev_seq(dev), pdata->enetaddr); + eth_env_set_enetaddr_by_index("eth", dev_seq(dev), + pdata->enetaddr); #else printf("\nError: %s address not set.\n", dev->name); -- 2.33.1

6 34