October 2022 - U-Boot

[PATCH v2] imx8mn-ddr4-evk-u-boot: Fix broken boot
by Fabio Estevam 04 Oct '22

04 Oct '22

When the imx8mn.dtsi file was pulled in from Linux, the UARTs were moved into an spba sub-node which wasn't being included in the SPL device tree. This meant the references to the UART weren't being handled properly and when booting the system would constantly reboot. Fix this by adding the spba node to the spl device tree to restore normal booting. Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot board. Fixes: 4e5114daf9eb ("imx8mn: synchronise device tree with linux") Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v1: - Fix typo in commit log: imx8mm.dtsi--> imx8mn.dtsi Hi Tom and Stefano, I know today is release day. Could this one be applied directly? It fixes a boot regression. Thanks arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi index 78773c198e..3a9ba8b8c9 100644 --- a/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi +++ b/arch/arm/dts/imx8mn-ddr4-evk-u-boot.dtsi @@ -26,6 +26,10 @@ u-boot,dm-spl; }; +&spba1 { + u-boot,dm-spl; +}; + &clk { u-boot,dm-spl; u-boot,dm-pre-reloc; -- 2.25.1

4 8

[ANN] U-Boot v2022.10 released
by Tom Rini 03 Oct '22

03 Oct '22

Hey all, It's release day and so here's v2022.10. As I often remind, there are DM migration deadlines that are both approaching and have passed. If you see these messages while building your platform please speak up if there's problems with doing the migration work needed. In terms of a changelog, git log --merges v2022.10-rc5..v2022.10 contains what I've pulled since the last RC or: git log --merges v2022.07..v2022.10 for changes since the last full release. As always, more details in pull requests (or the tags referenced by them) will result in more details here. And now the merge window continues to be open and I'll merge next in to master shortly. v2023.01 is scheduled for release on Monday, January 9th 2023 and the merge window closes on October 24th. Thanks all! -- Tom

1 0

[PATCH v2] imx8mn-venice-u-boot: Fix broken boot
by Fabio Estevam 03 Oct '22

03 Oct '22

When the imx8mn.dtsi file was pulled in from Linux, the UARTs were moved into an spba sub-node which wasn't being included in the SPL device tree. This meant the references to the UART weren't being handled properly and when booting the system would constantly reboot. Fix this by adding the spba node to the spl device tree to restore normal booting. Based on the patch from Adam Ford for the imx8mn-beacon-kit-u-boot board. Fixes: 4e5114daf9eb ("imx8mn: synchronise device tree with linux") Signed-off-by: Fabio Estevam <festevam(a)denx.de> --- Changes since v1: - Fix typo in commit log: imx8mm.dtsi--> imx8mn.dtsi Hi Tim, Could you please test this patch? It fixes boot regression on imx8mn-evk and imx8mn-beacon. arch/arm/dts/imx8mn-venice-u-boot.dtsi | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm/dts/imx8mn-venice-u-boot.dtsi b/arch/arm/dts/imx8mn-venice-u-boot.dtsi index 9fb3871452..9debf9675d 100644 --- a/arch/arm/dts/imx8mn-venice-u-boot.dtsi +++ b/arch/arm/dts/imx8mn-venice-u-boot.dtsi @@ -20,6 +20,10 @@ u-boot,dm-spl; }; +&spba1 { + u-boot,dm-spl; +}; + &clk { u-boot,dm-spl; u-boot,dm-pre-reloc; -- 2.25.1

2 1

Testing v2022.10-rc5 on mt7621
by Sven F. 03 Oct '22

03 Oct '22

Dear readers, I have a mt7621 spi nor with 256MB DDR board, and I am trying to get an open source software suite on it. IE : u-boot 2022.10 and open wrt v22.03.0 I follow instruction and build u-boot with : export CROSS_COMPILE=mipsel-linux-gnu- make mrproper && make O=build mt7621_rfb_defconfig && \ make O=build -j$(nproc) 2>&1 | tee ../uboot.build.log.mt7621_rfb_defconfig The output file looks ok but the last part of LZMA is not recognized fully. $ binwalk ./build/u-boot-mt7621.bin DECIMAL HEXADECIMAL DESCRIPTION -------------------------------------------------------------------------------- 2156 0x86C uImage header, header size: 64 bytes, header CRC: 0x3D774D5C, created: 2022-09-21 13:56:55, image size: 3 8828 bytes, Data Address: 0x80100000, Entry Point: 0x80100000, data CRC: 0x38979001, OS: Firmware, CPU: MIPS, \ image type: Standalone Program, compression type: none, image name: "MT7621 U-Boot SPL" 41048 0xA058 uImage header, header size: 64 bytes, header CRC: 0x18B75518, created: 2022-09-21 13:56:49, image size: 1 45331 bytes, Data Address: 0x80200000, Entry Point: 0x80200000, data CRC: 0xB39FB0D8, OS: Firmware, CPU: MIPS, \ image type: Standalone Program, compression type: lzma, image name: "U-Boot 2022.10-rc4 for mt7621 bo" 41112 0xA098 LZMA compressed data, properties: 0x5D, dictionary size: 67108864 bytes, uncompressed size: -1 bytes Remark on the build process, only one warning: /home/toor/2022/official/bootloader/u-boot/build/../scripts/dtc/pylibfdt/setup.py:21 DeprecationWarning: \ The distutils package is deprecated and slated for removal in Python 3.12. Use setuptools or check PEP 632 for potential alternatives I think it would sensible to put some checksum of the online binaries file for the `DDR initialization binary blob` + 1dda68aa089f0ff262e01539b990dea478952e9fb68bcc0a8cd6f76f0135c62e ./mt7621_stage_sram.bin + 8ee419275144fc298e9444d413d98e965a55d283152a74ea6a1f8de79eb516b6 ./mt7621_stage_sram_noprint.bin and the CROSS_COMPILE define may be signal `mipsel-linux-gnu-` in https://github.com/u-boot/u-boot/blob/master/doc/board/mediatek/mt7621.rst Before burning the ROM , I would like to validate the build somehow since it is very hard to recover from a bad bootloader ! `Burn the u-boot-mt7621.bin to the SPI-NOR` is a bit drastic. Is it possible to boot one of those from memory using the `go` command to check if the build looks ok 1990a6e661e450d944ff69c103cb0ca7 ./build/u-boot-dtb.img 1990a6e661e450d944ff69c103cb0ca7 ./build/u-boot.img d025641feb8aeb423c5bb829a989ddd4 ./build/u-boot-lzma.img 27b67fb29c11ea542405e25829df00ee ./build/u-boot-spl-ddr.img 0c7d7fa983b3e7b7c9cd202e89f6cb07 ./build/mt7621_stage_sram.bin d1ee76fe3750386e4ec5de3cb0599c8f ./build/u-boot.bin d1ee76fe3750386e4ec5de3cb0599c8f ./build/u-boot-dtb.bin be651a79adc284ee3aac5edfc873eacc ./build/u-boot-mt7621.bin 6fa3b83a89174c828b4af8c53beeece6 ./build/u-boot-nodtb.bin d7d4fd33c9c2bdeeb074d3367b09cf10 ./build/u-boot-spl-ddr.bin 980971dba7452050a975398324d771e1 ./build/u-boot Is it possible to do something similar ? please advice => bootp 0x80010000 u-boot-nodtb.bin => go 0x80010000 Thank you for reading that far. PS: some board data. => bdinfo boot_params = 0x8FEB1160 memstart = 0x80000000 memsize = 0x10000000 flashstart = 0x00000000 flashsize = 0x00000000 flashoffset = 0x00000000 ethaddr = (not set) IP addr = 192.168.1. baudrate = 115200 bps relocaddr = 0x8FFB0000 reloc off = 0x0FDB0000 >> Initializing DDR3 >> Applying AC timing parameters (try 1) Expected DRAM size: 128MB >> Setting DDR/CPU PLL ... Using 3PLL mode with External loopback DDR/CPU clock will be set to 1200MHz/880MHz >> Starting DDR PLL calibration ... DDR PLL2/3/4 feedback delay: 23/13/18 DDR 3PLL mode calibration passed >> Starting DQS Gating Window Delay calibration 0 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 ---------------------------------------------------------------- 0000:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0001:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0002:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0003:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0004:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0005:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0006:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0007:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0008:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0009:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000E:| 0 0 0 0 0 0 0 0 0 0 1 1 0 1 1 1 000F:| 0 0 0 0 0 1 1 0 1 1 1 0 1 1 0 0 0010:| 1 1 1 1 1 0 1 1 1 1 0 0 0 0 0 0 0011:| 1 1 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0012:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0013:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0014:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0015:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0016:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0017:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0018:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0019:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001E:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001F:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Found coarse/fine delay value: 16/32 >> Starting DLE calibration 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ---------------------------------------------------------------- 0000:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Failed to find optimal DQS factor >> Got DRAM size 0MB Retrying ... >> Applying AC timing parameters (try 2) Expected DRAM size: 256MB >> Setting DDR/CPU PLL ... Using 3PLL mode with External loopback DDR/CPU clock will be set to 1200MHz/880MHz >> Starting DDR PLL calibration ... DDR PLL2/3/4 feedback delay: 23/13/18 DDR 3PLL mode calibration passed >> Starting DQS Gating Window Delay calibration 0 8 16 24 32 40 48 56 64 72 80 88 96 104 112 120 ---------------------------------------------------------------- 0000:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0001:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0002:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0003:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0004:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0005:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0006:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0007:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0008:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0009:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 000E:| 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 000F:| 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0010:| 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0011:| 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0012:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0013:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0014:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0015:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0016:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0017:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0018:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0019:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001A:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001B:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001C:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001D:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001E:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 001F:| 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Found coarse/fine delay value: 15/80 >> Starting DLE calibration 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ---------------------------------------------------------------- 0000:| 0 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 Optimal DQS factor: 9 >> Starting RX DQ per-bit delay calibration Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ---------------------------------------------------------------- Delay 11 11 11 12 9 11 9 9 7 7 9 8 9 10 8 10 >> Starting DQS delay calibration Bit ( Range ) Center -------------------- 0 ( 1~ 62) 31 1 ( 1~ 61) 31 2 ( 1~ 60) 30 3 ( 1~ 62) 31 4 ( 0~ 62) 31 5 ( 1~ 63) 32 6 ( 1~ 61) 31 7 ( 1~ 63) 32 DQS0 input delay: 32 Bit ( Range ) Center -------------------- 8 ( 1~ 59) 30 9 ( 1~ 58) 29 10 ( 1~ 59) 30 11 ( 1~ 58) 29 12 ( 2~ 60) 31 13 ( 1~ 59) 30 14 ( 1~ 59) 30 15 ( 1~ 60) 30 DQS1 input delay: 31 >> Final DQ delay value Bit 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 ---------------------------------------------------------------- Delay 12 12 13 13 10 11 10 9 8 9 10 10 9 11 9 11 >> Starting TX DQ/QDS per-byte calibration Byte 0: (DQS,DQ)=(8,8) Byte 1: (DQS,DQ)=(8,8) DDR calibration passed >> Got DRAM size 256MB DRAM initialization succeeded U-Boot SPL 2018.09-svn35 (Mar 11 2021 - 19:17:36 +0800) Trying to boot from NOR U-Boot 2018.09-svn35 (Mar 11 2021 - 19:17:36 +0800) CPU: MediaTek MT7621AT ver 1, eco 3 Clocks: CPU: 880MHz, DDR: 1200MHz, Bus: 220MHz, XTAL: 40MHz Model: MediaTek MT7621 reference board DRAM: 256 MiB Loading Environment from SPI Flash... SF: Detected w25q128bv with page size 256 Bytes, erase size 64 KiB, total 16 MiB *** Warning - bad CRC, using default environment In: uartlite0@1e000c00 Out: uartlite0@1e000c00 Err: uartlite0@1e000c00 Net: Warning: eth@1e100000 (eth0) using random MAC address - 5e:69:c8:f8:cf:5b eth0: eth@1e100000 Hit any key to stop autoboot: 0 *** U-Boot Boot Menu *** 1. Startup system (Default) 2. Upgrade firmware 3. Upgrade bootloader 4. Upgrade bootloader (advanced mode) 5. Load image 0. U-Boot console

1 1

[PATCH v3 0/3] riscv: Fix build against binutils 2.38
by Heinrich Schuchardt 03 Oct '22

03 Oct '22

Binutils 2.37 and 2.38 are based on different revisions of the "RISC-V Unprivileged Specification" and there fore require different -march parameters for GCC. We support both 32bit and 64bit RISC-V boards. Buildman uses a 64bit toolchain for both which leads to build failures with -march=rv32imac_zicsr_zifencei. The first patch install the riscv32 toolchain in the Docker image. Only after rebuilding and uploading the Docker image we can proceed with the other patches. The next patch let's buildman choose the correct tool chain. The final patch which has already been posted previously corrects the -march parameter for binutils 2.38+. The series pass Gitlab CI: https://source.denx.de/u-boot/custodians/u-boot-efi/-/pipelines/13658 Alexandre Ghiti (1): riscv: Fix build against binutils 2.38 Heinrich Schuchardt (2): docker: install riscv32 toolchain buildman: differentiate between riscv32, riscv64 arch/riscv/Makefile | 11 ++++++++++- tools/buildman/boards.py | 11 +++++++++++ tools/docker/Dockerfile | 1 + 3 files changed, 22 insertions(+), 1 deletion(-) -- 2.37.2

3 10

[PATCH v10 00/15] FWU: Add FWU Multi Bank Update feature support
by Sughosh Ganu 03 Oct '22

03 Oct '22

The patchset adds support for the FWU Multi Bank Update[1] feature. Certain aspects of the Dependable Boot[2] specification have also been implemented. The FWU multi bank update feature is used for supporting multiple sets(also called banks) of firmware image(s), allowing the platform to boot from a different bank, in case it fails to boot from the active bank. This functionality is supported by keeping the relevant information in a structure called metadata, which provides information on the images. Among other parameters, the metadata structure contains information on the currect active bank that is being used to boot image(s). Functionality is being added to work with the UEFI capsule driver in u-boot. The metadata is read to gather information on the update bank, which is the bank to which the firmware images would be flashed to. On a successful completion of the update of all components, the active bank field in the metadata is updated, to reflect the bank from which the platform will boot on the subsequent boots. Currently, the feature is being enabled on the STM32MP157C-DK2 and Synquacer boards. The DK2 board boots a FIP image from a uSD card partitioned with the GPT partioning scheme, while the Synquacer board boots a FIP image from a MTD partitioned SPI NOR flash device. This feature also requires changes in a previous stage of bootloader, which parses the metadata and selects the bank to boot the image(s) from. Support has being added in tf-a(BL2 stage) for the STM32MP157C-DK2 board to boot the active bank images. These changes have been merged to the upstream tf-a repository. The patch for adding a python test for the feature has been developed, and was sent in the version 5 of the patches[3]. However, the test script depends on adding support for the feature on MTD SPI NOR devices, and that is being done as part of the Synquacer patches. Hence these set of patches do not have the test script for the feature. That will be added through the patches for adding support for the feauture on Synquacer platform. [1] - https://developer.arm.com/documentation/den0118/a [2] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24… [3] - https://lists.denx.de/pipermail/u-boot/2022-June/485992.html Changes since V9: * Add a helper function fwu_get_dev_mdata() to get the FWU metadata device and read the metadata. * Rename fwu_get_image_alt_num() as fwu_get_image_image_index() based on suggestion from Takahiro. * s/formated/formatted in the commit message * Add a '\n' character in the log message * Remove the check board_is_stm32mp15x_dk2() as suggested by Etienne * Remove unneeded braces as suggested by Ilias * Change the fwu_plat_get_bootidx() function to take an uint * as the function parameter instead of the void * as suggested by Etienne. * Add a comment to indicate where the event notification will be called, as suggested by Simon. * Remove the unused variable active_idx, as suggested by Etienne * Move the global variables into local variables as suggested by Ilias. * Change fwu_get_image_alt_num() name to fwu_get_image_image_index() as suggested by Takahiro. * Allow capsule updates to be called from efi_init_obj_list() with the FWU feature enabled, as suggested by Takahiro. * Enable EFI_CAPSULE_ON_DISK_EARLY as an imply with the FWU feature enabled. * Define the FWU feature related functions as __maybe_unused to allow for compilation with the FWU feature disabled. * Add a document for the command * Change the fwu_plat_get_bootidx() function to take an uint * as the function parameter instead of the void * as suggested by Etienne. Sughosh Ganu (15): dt/bindings: Add bindings for GPT based FWU Metadata storage device FWU: Add FWU metadata structure and driver for accessing metadata FWU: Add FWU metadata access driver for GPT partitioned block devices stm32mp1: dk2: Add a node for the FWU metadata device stm32mp1: dk2: Add image information for capsule updates FWU: Add helper functions for accessing FWU metadata FWU: STM32MP1: Add support to read boot index from backup register event: Add an event for main_loop FWU: Add boot time checks as highlighted by the FWU specification FWU: Add support for the FWU Multi Bank Update feature FWU: cmd: Add a command to read FWU metadata test: dm: Add test cases for FWU Metadata uclass mkeficapsule: Add support for generating empty capsules mkeficapsule: Add support for setting OEM flags in capsule header FWU: doc: Add documentation for the FWU feature arch/arm/dts/stm32mp157c-dk2-u-boot.dtsi | 7 + arch/arm/mach-stm32mp/include/mach/stm32.h | 5 + arch/sandbox/Kconfig | 6 + arch/sandbox/dts/test.dts | 7 +- board/sandbox/sandbox.c | 8 + board/st/stm32mp1/stm32mp1.c | 44 ++ cmd/Kconfig | 6 + cmd/Makefile | 1 + cmd/fwu_mdata.c | 79 +++ common/board_r.c | 3 + common/event.c | 3 + configs/sandbox64_defconfig | 5 +- doc/develop/uefi/fwu_updates.rst | 165 +++++ doc/develop/uefi/index.rst | 1 + doc/develop/uefi/uefi.rst | 2 + .../firmware/fwu-mdata-gpt.yaml | 32 + doc/mkeficapsule.1 | 33 +- doc/usage/cmd/fwu_mdata.rst | 43 ++ doc/usage/index.rst | 1 + drivers/Kconfig | 2 + drivers/Makefile | 1 + drivers/fwu-mdata/Kconfig | 16 + drivers/fwu-mdata/Makefile | 8 + drivers/fwu-mdata/fwu-mdata-uclass.c | 107 ++++ drivers/fwu-mdata/gpt_blk.c | 378 ++++++++++++ include/configs/stm32mp15_common.h | 4 + include/dm/uclass-id.h | 1 + include/event.h | 3 + include/fwu.h | 302 +++++++++ include/fwu_mdata.h | 67 ++ lib/Kconfig | 6 + lib/Makefile | 1 + lib/efi_loader/efi_capsule.c | 243 +++++++- lib/efi_loader/efi_setup.c | 1 + lib/fwu_updates/Kconfig | 33 + lib/fwu_updates/Makefile | 7 + lib/fwu_updates/fwu.c | 577 ++++++++++++++++++ lib/fwu_updates/fwu_gpt.c | 114 ++++ test/dm/Makefile | 1 + test/dm/fwu_mdata.c | 149 +++++ test/dm/fwu_mdata_disk_image.h | 112 ++++ .../test_capsule_firmware_fit.py | 1 - .../test_capsule_firmware_signed_fit.py | 1 - tools/Makefile | 2 +- tools/eficapsule.h | 8 + tools/mkeficapsule.c | 109 +++- 46 files changed, 2679 insertions(+), 26 deletions(-) create mode 100644 cmd/fwu_mdata.c create mode 100644 doc/develop/uefi/fwu_updates.rst create mode 100644 doc/device-tree-bindings/firmware/fwu-mdata-gpt.yaml create mode 100644 doc/usage/cmd/fwu_mdata.rst create mode 100644 drivers/fwu-mdata/Kconfig create mode 100644 drivers/fwu-mdata/Makefile create mode 100644 drivers/fwu-mdata/fwu-mdata-uclass.c create mode 100644 drivers/fwu-mdata/gpt_blk.c create mode 100644 include/fwu.h create mode 100644 include/fwu_mdata.h create mode 100644 lib/fwu_updates/Kconfig create mode 100644 lib/fwu_updates/Makefile create mode 100644 lib/fwu_updates/fwu.c create mode 100644 lib/fwu_updates/fwu_gpt.c create mode 100644 test/dm/fwu_mdata.c create mode 100644 test/dm/fwu_mdata_disk_image.h -- 2.34.1

6 63

[PATCH 0/2] efi_driver: fix error handling
by Heinrich Schuchardt 03 Oct '22

03 Oct '22

Fix the error handling in the start() method of the EFI block device driver. Heinrich Schuchardt (2): efi_loader: function to unlink udevice and handle efi_driver: fix error handling include/efi_driver.h | 2 +- include/efi_loader.h | 1 + lib/efi_driver/efi_block_device.c | 60 +++++++++++++++++-------------- lib/efi_driver/efi_uclass.c | 23 ++++++------ lib/efi_loader/efi_helper.c | 19 ++++++++++ 5 files changed, 66 insertions(+), 39 deletions(-) -- 2.37.2

2 6

[PATCH] test/py: efi_secboot: Remove unnecessary cert-to-efi-hash-list option
by Masahisa Kojima 03 Oct '22

03 Oct '22

'cert-to-efi-hash-list -t 0' does not work as expected, it produces indeterminate timestamp. $ cert-to-efi-hash-list -t 0 -s 256 db.crt dbx_hash.crl TimeOfRevocation is 0-113-0 00:00:255 If we need the CRL revoked for all the time, just don't specify '-t' option. $ cert-to-efi-hash-list -s 256 db.crt dbx_hash.crl TimeOfRevocation is 0-0-0 00:00:00 Signed-off-by: Masahisa Kojima <masahisa.kojima(a)linaro.org> --- test/py/tests/test_efi_secboot/conftest.py | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/test/py/tests/test_efi_secboot/conftest.py b/test/py/tests/test_efi_secboot/conftest.py index db6b8d301f..f2f914f617 100644 --- a/test/py/tests/test_efi_secboot/conftest.py +++ b/test/py/tests/test_efi_secboot/conftest.py @@ -77,17 +77,17 @@ def efi_boot_env(request, u_boot_config): % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) # dbx_hash (digest of TEST_db certificate) - check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 256 db.crt dbx_hash.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash.crl dbx_hash.auth' + check_call('cd %s; %scert-to-efi-hash-list -g %s -s 256 db.crt dbx_hash.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash.crl dbx_hash.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) - check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 384 db.crt dbx_hash384.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash384.crl dbx_hash384.auth' + check_call('cd %s; %scert-to-efi-hash-list -g %s -s 384 db.crt dbx_hash384.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash384.crl dbx_hash384.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) - check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 512 db.crt dbx_hash512.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash512.crl dbx_hash512.auth' + check_call('cd %s; %scert-to-efi-hash-list -g %s -s 512 db.crt dbx_hash512.crl; %ssign-efi-sig-list -t "2020-04-05" -c KEK.crt -k KEK.key dbx dbx_hash512.crl dbx_hash512.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) # dbx_hash1 (digest of TEST_db1 certificate) - check_call('cd %s; %scert-to-efi-hash-list -g %s -t 0 -s 256 db1.crt dbx_hash1.crl; %ssign-efi-sig-list -t "2020-04-06" -c KEK.crt -k KEK.key dbx dbx_hash1.crl dbx_hash1.auth' + check_call('cd %s; %scert-to-efi-hash-list -g %s -s 256 db1.crt dbx_hash1.crl; %ssign-efi-sig-list -t "2020-04-06" -c KEK.crt -k KEK.key dbx dbx_hash1.crl dbx_hash1.auth' % (mnt_point, EFITOOLS_PATH, GUID, EFITOOLS_PATH), shell=True) # dbx_db (with TEST_db certificate) -- 2.17.1

2 1

Re: [PATCH v3 3/3] riscv: Fix build against binutils 2.38
by Rick Chen 03 Oct '22

03 Oct '22

> From: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Sent: Sunday, October 02, 2022 10:21 AM > To: Tom Rini <trini(a)konsulko.com>; Leo Yu-Chi Liang(梁育齊) <ycliang(a)andestech.com>; Rick Jian-Zhi Chen(陳建志) <rick(a)andestech.com>; Simon Glass <sjg(a)chromium.org> > Cc: u-boot(a)lists.denx.de; Alexandre Ghiti <alexandre.ghiti(a)canonical.com>; Aurelien Jarno <aurelien(a)aurel32.net>; Bin Meng <bmeng.cn(a)gmail.com>; Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com>; Heiko Stuebner <heiko(a)sntech.de>; Christian Stewart <christian(a)paral.in> > Subject: [PATCH v3 3/3] riscv: Fix build against binutils 2.38 > > From: Alexandre Ghiti <alexandre.ghiti(a)canonical.com> > > The following description is copied from the equivalent patch for the Linux Kernel proposed by Aurelien Jarno: > > >From version 2.38, binutils default to ISA spec version 20191213. This > means that the csr read/write (csrr*/csrw*) instructions and fence.i instruction has separated from the `I` extension, become two standalone > extensions: Zicsr and Zifencei. As the kernel uses those instruction, this causes the following build failure: > > arch/riscv/cpu/mtrap.S: Assembler messages: > arch/riscv/cpu/mtrap.S:65: Error: unrecognized opcode `csrr a0,scause' > arch/riscv/cpu/mtrap.S:66: Error: unrecognized opcode `csrr a1,sepc' > arch/riscv/cpu/mtrap.S:67: Error: unrecognized opcode `csrr a2,stval' > arch/riscv/cpu/mtrap.S:70: Error: unrecognized opcode `csrw sepc,a0' > > Signed-off-by: Alexandre Ghiti <alexandre.ghiti(a)canonical.com> > Reviewed-by: Bin Meng <bmeng.cn(a)gmail.com> > Tested-by: Heinrich Schuchardt <heinrich.schuchardt(a)canonical.com> > Tested-by: Heiko Stuebner <heiko(a)sntech.de> > Tested-by: Christian Stewart <christian(a)paral.in> > --- > v3: > no change > --- > arch/riscv/Makefile | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) Reviewed-by: Rick Chen <rick(a)andestech.com>

1 0

[u-boot][PATCH 0/3] Introduce TI GPMC memory controller driver
by Roger Quadros 03 Oct '22

03 Oct '22

Hi, The GPMC is a unified memory controller dedicated for interfacing with external memory devices like - Asynchronous SRAM-like memories and ASICs - Asynchronous, synchronous, and page mode burst NOR flash - NAND flash - Pseudo-SRAM devices This driver will take care of setting up the GPMC based on the settings specified in the Device tree and then probe its children. cheers, -roger Roger Quadros (3): scripts: Makefile.spl: Enable memory drivers to be built for SPL dt/bindings: memory: Add bindings for TI GPMC driver memory: Add TI GPMC driver .../memory/ti,gpmc-child.yaml | 252 ++++ doc/device-tree-bindings/memory/ti,gpmc.yaml | 190 +++ drivers/memory/Kconfig | 16 + drivers/memory/Makefile | 1 + drivers/memory/ti-gpmc.c | 1237 +++++++++++++++++ drivers/memory/ti-gpmc.h | 298 ++++ include/linux/mtd/omap_gpmc.h | 3 + scripts/Makefile.spl | 1 + 8 files changed, 1998 insertions(+) create mode 100644 doc/device-tree-bindings/memory/ti,gpmc-child.yaml create mode 100644 doc/device-tree-bindings/memory/ti,gpmc.yaml create mode 100644 drivers/memory/ti-gpmc.c create mode 100644 drivers/memory/ti-gpmc.h -- 2.17.1

3 17