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.

[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.

[Genadi Zawidowski]

Hello.

One of peoples share with me internal file from Linux package... with same address for loading image and starting address...

In case of infinity loop of code VBAR does not matter?

C:\user\SVN\hftrx\build\stm32mp157axx>stm32image.exe -i u-boot-spl.stm32

Image Type  : ST Microelectronics STM32 V1.0

Image Size  : 120012 bytes

Image Load  : 0x2ffc2500

Entry Point : 0x2ffc2500

Checksum    : 0x0088c3b5

Option    : 0x00000001

Version   : 0x00000000

[PatrickF]

Please note that load address is ignored for FSBL and 0x2FFc2400 is always used.

After changing the entry point to 0x2ffc2500, I successfully flashed your binary in the NOR of EV1 board using CubeProgrammer.

I'm able to see that it is running an infinite loop at 0x2ffc2500

STM32MP_SigningTool_CLI.exe -bin stm32mp157axx_app.bin -la 0x2ffc2400 -ep 0x2ffc2500 -t fsbl -o stm32mp157axx_app_signed.bin -pubk publicKey.pem -prvk privateKey.pem -pwd STM32 -iv 1

You could use the following TSV file with CubeProgrammer:

#Opt   Id   Name   Type   IP   Offset   Binary

-   0x01   fsbl1-boot   Binary   none   0x0   tf-a-stm32mp157c-ev1-trusted.stm32

-   0x03   ssbl-boot   Binary   none   0x0   u-boot-stm32mp157c-ev1-trusted.stm32

P   0x04   fsbl1   Binary   nor0   0x00000000   stm32mp157axx_app_signed.bin

P   0x05   fsbl2   Binary   nor0   0x00040000   stm32mp157axx_app_signed.bin

PE   0x06   ssbl   Binary   nor0   0x00080000   none

PE   0x20   env      Binary   nor0   0x00280000   none

PE   0x10   empty   Binary   nor0   0x002C0000   none

[Genadi Zawidowski]

You mean: I can not use something like 0x2FFC2800 as load address and entry point? Exactly 0x2ffc2500 ?

[PatrickF · Accepted solution]

Load address is ALWAYS 0x2FFC2400 for FSBL, whatever you put in the header (it is ignored for FSBL).

Entry point in the header could be anywhere after the header (i.e. 0x2FFC2500) and the end of the SYSRAM

I recommend to compile your FSBL SW to fit with a region starting from 0x2FFC2500 (with a size of max 247KB minus 256 for header).

Entry point will depend on your SW startup.s construction, it is not always at the very first address.

[Genadi Zawidowski]

0x2FFC2500 is a right value...

Code is execute as expected....

Little question: For access some of RCC and GPIO bits should I properly select 255-th byte in header?

Now I use 0x10, but previously working code simply has no results on GPIO.

Brief of my code:

	RCC->TZCR &= ~ (RCC_TZCR_TZEN | RCC_TZCR_MCKPROT);
	{
		// LED blinking test
		//const uint_fast32_t mask = (1uL << 14);	// PA14 - GREEN LED LD5 on DK1/DK2 MB1272.pdf
		const uint_fast32_t maskd = (1uL << 14);	// PD14 - LED on small board
		const uint_fast32_t maskg = (1uL << 13);	// PG13 - LCD_R0
		arm_hardware_piod_outputs(maskd, 1 * maskd);
		arm_hardware_piog_outputs(maskg, 1 * maskg);
		for (;;)
		{
			(GPIOD)->BSRR = BSRR_S(maskd);
			(GPIOG)->BSRR = BSRR_S(maskg);
			__DSB();
			(GPIOD)->BSRR = BSRR_C(maskd);
			(GPIOG)->BSRR = BSRR_C(maskg);
			__DSB();
 
		}
	}

Without details: GPIO inits work file...

[Genadi Zawidowski]

My GPIO problems was because I am use RCC_MC_AHB4ENSETR instead of RCC_MP_AHB4ENSETR.

Because.... only RCC_MC_AHB4ENSETR values are defined.