STM32MP157AAB failed to boot from NOR QSPI (bare-metal)

[Genadi Zawidowski]

Hello.

Can someone explain problem by this diagnostics:

----------------------------------------

bootfailed

S-00000001C040CFFE

NS-0000000000000000

°----------------------------------------

bootfailed

S-00000001C040CFFE

NS-0000000000000000

№----------------------------------------

My board say these lines to PA13 pin (9600-8N1) after power up.

Flash memory contain [may be] properly formed first stage bootloader file with only infinite loop at starting point.

Binary in attachment.

[PatrickF]

See https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Debug_and_Error_messages

(I also send you a message)

[PatrickF]

some thinks to look for:

• check that the QSPI is connected on the right default pin (see AN5031 or this page)
• Did you have tested with DDR tuning tool (i.e. uBoot SPL running) ? the DK2 uboot SPL provided in starter package is likely to work as-is on your board (as you are using single DDR3L and PMIC), could be loaded with CubeProgrammer with UART connection. see https://wiki.st.com/stm32mpu/wiki/U-Boot_SPL:_DDR_interactive_mode
• Did you programmed the Flash using CubeProgrammer ? https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Basic_boot_chain_support
• Did your binary contain the right header (required even if no secure boot). See https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Image_signing

[Genadi Zawidowski]

Yes, QSPI connected right (if I erase memory or corrupt STM2 signature, I can connect trough serial boot)

No, I not use DDR in my "bootloader" - just infinite loop

No, I use own flash programming tool - in this case Altera's USB byte blaster, CubeProgrammer can not do anything (looks like expecting SD card or something like).

Yes, you can examine my binary by downloading form 1-st message in this topic.

[Genadi Zawidowski]

Manual say:

Traces can be downloaded from address range 0x2ffc1c00-0x2ffc2404

But, area from 0x2ffc2400 declared as used for bootloader. Should I move my code?

[Genadi Zawidowski]

Can someone place here compiled "DK2 uboot SPL" - I can flashing this file and connect trough.... Serial port? What pins/speed?

[PatrickF]

seems your binary has wrong size declared somewhere (maybe in the header) as if I try to flash it on the Serial-NOR of an STM32MP157C-EV1 board, I get

Message from Embedded Flash Loader : fsbl1: Bad size requested for partition 1 = 0x4000000 <> 0x40000

As the FSBL is loaded in SYSRAM, size is limited to 0x2ffc2400 to 0x2fffffff, so must always fit into a (fixed size) partition of 0x40000

[Genadi Zawidowski]

Size form 2ffc2400 to end of this region is 247 KB - it is 0x3DC00‬, not 0x40000. I use seriously less size:

Image Type : ST Microelectronics STM32 V1.0
Image Size : 46832 bytes
Image Load : 0x2ffc2400
Entry Point : 0x2ffc2400
Checksum : 0x004f969d
Option : 0x00000001
Version : 0x00000001

Image Type  : ST Microelectronics STM32 V1.0

Image Size  : 46832 bytes

Image Load  : 0x2ffc2400

Entry Point : 0x2ffc2400

Checksum    : 0x004f969d

Option    : 0x00000001

Version   : 0x00000001‬

[Genadi Zawidowski]

Can you form right image header for this sample file?

Loading address and entry point - same value 0x2ffc2400

[PatrickF]

Your binary sound well formed.

Note that there is a typo in the wiki (not so important), you should read : Traces can be downloaded from address range 0x2ffc1c00-0x2ffc23ff

Could you explain the following sentence you wrote "Yes, QSPI connected right (if I erase memory or corrupt STM2 signature, I can connect trough serial boot)"

This mean your binary is loaded and started, right ?

[Genadi Zawidowski]

No. I mean:

If I try to power-on, I see error messages and can not connect trough USB for example.

Then I corrupt image signature - I no see error messages and can connect oved USB DFU.

[PatrickF]

Hello,

your issue puzzled me, and after some internal discussion, I found that the full binary including header is copied in SYSRAM, so, in your case, you should put entry point to 0x2ffc2500 (as header size is 0x100, your code is offset), but still putting load address to 0x2ffc2400 (please note that load address is ignored for FSBL and 0x2FFc2400 is always used) .

Your issue is explained because by executing at 0x2ffc2400, you get bad code (header values), which end up to generate an exception (e.g undefined instruction, abort, etc..). As at this point of time, as exception table base address (VBAR) has not been changed by your own code, the exceptions are catch by BootROM, which loop to a FAIL state.