Skip to main content
Visitor II
December 4, 2019
Solved

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

  • December 4, 2019
  • 14 replies
  • 5328 views

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.

    This topic has been closed for replies.
    Best answer by PatrickF

    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.

    14 replies

    Visitor II
    December 5, 2019

    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

    Technical Moderator
    December 5, 2019

    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

    Visitor II
    December 5, 2019

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

    PatrickFAnswer
    Technical Moderator
    December 5, 2019

    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.

    Visitor II
    December 5, 2019

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

    Visitor II
    December 7, 2019

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

    Because.... only RCC_MC_AHB4ENSETR values are defined.