Get stuck in TF-A boot - BL2: Failed to load image - STM32MP1

[KDehm]

Hi,

I'm trying to build a Yocto-Linux for an specific STM32MP157 board. I was working with "thud", but now "dunfell" is required, as it is supposed to be long term stable.

The system is built after ST's manual:

https://wiki.st.com/stm32mpu/wiki/How_to_create_your_own_machine

tf-a-stm32mp-2.2

u-boot-stm32mp-2020.01

The Device Tree was adapted and Bitbake is compiling it. But now system get stuck while it executes the TF-A Boot (from SD).

Is there any way to debug or get the reason for image load fail?

When I try to flash it via STProgrammer a "Panic at PC" appears.

Thanks in advance for any advise!

Kai

NOTICE: CPU: STM32MP157AAD Rev.B
NOTICE: Model: STMicroelectronics custom STM32CubeMX board
WARNING: VDD unknownINFO: Reset reason (0x17):
INFO: Power-on Reset (rst_por)
INFO: Using SDMMC
INFO: Instance 1
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.2-r1.0(debug):v2.2-dirty
NOTICE: BL2: Built : 13:36:23, Oct 22 2019
INFO: Using crypto library 'stm32_crypto_lib'
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 528Mhz K4B4G1646E (v1,1066-7-7-7,cal)
INFO: Memory size = 0x20000000 (512 MB)
INFO: BL2 runs SP_MIN setup
INFO: BL2: Loading image id 4
INFO: Loading image id=4 at address 0x2ffed000
INFO: Image id=4 loaded: 0x2ffed000 - 0x2ffff000
INFO: BL2: Loading image id 5
INFO: Loading image id=5 at address 0xc0100000
INFO: STM32 Image size : 857547
INFO: Image id=5 loaded: 0xc0100000 - 0xc01d15cb
ERROR: BL2: Failed to load image (-80)

[PatrickD]

Hi,

https://wiki.st.com/stm32mpu/wiki/TF-A_-_How_to_debug

some entry points:

arm-trusted-firmware/bl2/bl2_image_load_v2.c:73: ERROR("BL2: Failed to load image id %d (%i)\n",

arm-trusted-firmware/drivers/st/io/io_stm32image.c:240: INFO("STM32 Image size : %lu\n", (unsigned long)*length);

it seens image with stm32 header is correctly detected "STM32 Image size : 857547"

but error occur after..... but he error seens strange

./arm-trusted-firmware/include/lib/libc/errno.h

#define EAUTH 80 /* Authentication error */

Patrick

[KDehm]

Thanks for the answer!

So the error is probably an authentication problem?

I haven't signed the binaries, is that mandatory, related to this →

https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Authentication_processing

?

The OTP on the board is filled from reg 24 to 31 with value "ffffffff"

[PatrickD]

​Yes but this error it is strange....

if it working for "thud", that can't be a authentification issue.....

I assume that any TF-A read error cause this issue.....

But the the STM32 header is correctly loaded / detected as the trace"STM32 Image size : 857547" is displayed

Something failed between header load and full image load....

or the U-Boot wasn't fully write on SDMMC and a checsum error is detected ?

You need to dig to found where the error occurs.

Patrick

[KDehm]

Yes, I tried to give some additional space for U-boot on SDMMC, but stil no success.

How can i read/debug the header in .stm32 file?

Should i search for possible errors in Devie Tree files for TF-A?

Even in Debug-Mode of TF-A there is not more information about this error message.

[AMurr.2282]

Hi

I am getting the exact same error. Building a distribution with thud worked fine, but since we upgraded to dunfell we get this error:

NOTICE: CPU: STM32MP153AAB Rev.B
NOTICE: Model: STMicroelectronics custom STM32CubeMX board
WARNING: VDD unknownINFO: Reset reason (0x14):
INFO: Pad Reset from NRST
INFO: PMIC version = 0x21
INFO: Using USB
INFO: Instance 2
INFO: Boot used partition fsbl1
NOTICE: BL2: v2.2-r1.0(debug):v2.2-dirty
NOTICE: BL2: Built : 12:04:19, Sep 14 2020
INFO: Using crypto library 'stm32_crypto_lib'
INFO: BL2: Doing platform setup
INFO: RAM: DDR3-DDR3L 16bits 533000Khz
INFO: Memory size = 0x10000000 (256 MB)
INFO: BL2 runs SP_MIN setup
INFO: BL2: Loading image id 4
INFO: Loading image id=4 at address 0x2ffed000
INFO: Image id=4 loaded: 0x2ffed000 - 0x2ffff000
INFO: BL2: Loading image id 5
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 0
INFO: address 0x2ffe7988
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 0
INFO: address 0x2ffe7988
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: Start Download partition 0 to address 0xc0000000 length 0
INFO: USB : DFU : end of download partition : 0
INFO: Loading image id=5 at address 0xc0100000
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 3
INFO: address 0x2ffe7988
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: receive request 6
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 3
INFO: address 0x2ffe7988
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: usb_partition_size: partition size : 0xce9cf
INFO: Start Download partition 3 to address 0xc0100000 length 846287
INFO: USB : DFU : end of download partition : 3
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: UPLOAD :
INFO: Phase ID : 0
INFO: address 0xffffffff
INFO: Send detach request
INFO: GETSTATUS :
INFO: DFU_STATE_IDLE
INFO: Receive Detach
INFO: Image id=5 loaded: 0xc0100000 - 0xc01ce9cf
ERROR: BL2: Failed to load image (-80)

[KDehm]

I had a look on the headers of TF-A und U-boot binaries (.stm32) and compared them to the working ones.

TF-A header:

magic_number = 53 54 4d 32 
 image_signature = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 image_checksum = d7 06 e3 20 
 header_version = 00 00 01 00 
 image_length = 40 b0 03 00 
 image_entry_point = 00 60 fd 2f 
 reserved1 = 00 00 00 00 
 load_address = 00 25 fc 2f 
 reserved2 = 00 00 00 00
 version_number = 00 00 00 00 
 option_flags = 01 00 00 00 
 ecdsa_algorithm = 01 00 00 00
 ecdsa_public_key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 padding = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 binary_type = 00 00 00 10

and U-Boot:

magic_number = 53 54 4d 32 
 image_signature = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 image_checksum = 4f c9 a5 04 
 header_version = 00 00 01 00 
 image_length = 2a 16 0d 00 
 image_entry_point = 00 00 10 c0 
 reserved1 = 00 00 00 00 
 load_address = 00 00 10 c0 
 reserved2 = 00 00 00 00
 version_number = 00 00 00 00 
 option_flags = 01 00 00 00 
 ecdsa_algorithm = 01 00 00 00
 ecdsa_public_key = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 padding = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 binary_type = 00 00 00 00

The option_flag is set to 01, which means that there is no signature verification.

But Image_checksum is used to check the downloaded image integrity, according to this: https://wiki.st.com/stm32mpu/wiki/STM32_header_for_binary_files

Is there a way to check if image_checksum in U-boot-binary is correctly compared in FSBL1?

Although I'm not thinking, that a checksum error causes this problem.

It looks like TF-A version 2.2 has an option for TRUSTED_BOARD_BOOT which was not in version 2.0. Setting TRUSTED_BOARD_BOOT=0 looks like it disables the verification for development purposes

https://github.com/STMicroelectronics/arm-trusted-firmware/blob/v2.2-stm32mp/plat/st/stm32mp1/platform.mk#L16

[KDehm]

That was doing the trick. Thanks! The FSBL jumps now into SSBL (u-boot) with the following statements:

INFO: STM32 Image size : 845770
INFO: Image id=5 loaded: 0xc0100000 - 0xc01ce7ca
NOTICE: BL2: Booting BL32
INFO: Entry point address = 0x2ffed000
INFO: SPSR = 0x1d3
INFO: Cannot find st,stpmic1 node in DT
NOTICE: SP_MIN: v2.2-r1.0(debug):devtool-patched-dirty
NOTICE: SP_MIN: Built : 08:18:51, Sep 28 2020
INFO: ARM GICv2 driver initialized
INFO: ETZPC: UART1 (3) could be non secure
INFO: ETZPC: SPI6 (4) could be non secure
INFO: ETZPC: I2C6 (12) could be non secure
INFO: SP_MIN: Initializing runtime services
INFO: SP_MIN: Preparing exit to normal world
 
U-Boot 2020.01-stm32mp-r1 (Jan 06 2020 - 20:56:31 +0000)

[Olivier GALLIEN]

Hi @KDehm​ , @drew​ ,

Sorry guys I had to remove "Best answer" from solution you have found.

It's actually a simple workaround of the real problem.

Root cause of issue you have faced is likely the miss of &nvmem_layout node in your DT.

This node is providing pkh_otp read by TF-A ( even if no signature requested ).

We are working to enhance this situation and put this layout properties at soc level in order to be more robust to the miss.

Olivier