ERROR: Partition ssbl not found from TF-A

[CErik.1]

I am trying to boot U-boot as SSBL on a simple board with an eMMC flash.

I flash the partitions using the embedded DFU ROMboot with STM32CubeProgrammer using the following Flash Layout

#Opt   Id Name   Type   IP Offset Binary

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

-  0x03   ssbl-boot  Binary none   0x0 u-boot.stm32

P  0x02   fsbl1  Binary mmc0   boot1  tf-a-stm32mp157c-dk2.stm32

P  0x04   fsbl2  Binary mmc0   boot2  tf-a-stm32mp157c-dk2.stm32

P  0x03   ssbl   Binary mmc0   0x00080000 u-boot.stm32

The partitions are written successfully and when I run 'mmc part' in the U-boot DFU I see the partition as follows

STM32MP> mmc part           

Partition Map for MMC device 0 --  Partition Type: EFI

Part   Start LBA      End LBA        Name

       Attributes

       Type GUID

       Partition GUID

 1    0x00000400     0x01d59bff     "ssbl"

       attrs: 0x0000000000000000

       type:  8da63339-0007-60c0-c436-083ac8230908

       guid:  8ef917d1-2c6f-4bd0-a5b2-331a19f91cb2

Upon reset the board boots the TF-A and gives me

NOTICE: CPU: STM32MP157C?? Rev.?

NOTICE: Model: Simple Board

ERROR:  Partition ssbl not found

PANIC at PC : 0x2ffdb261

Any ideas what I could be doing wrong?

Update

TF-A fails the check

/* Check MBR boot signature. */
   if ((mbr_sector[PARTITION_BLOCK_SIZE - 2] != MBR_SIGNATURE_FIRST) ||
       (mbr_sector[PARTITION_BLOCK_SIZE - 1] != MBR_SIGNATURE_SECOND)) {
       return -ENOENT;
   }

in load_mbr_header()

"Load the first sector that carries MBR header.

 The MBR boot signature should be always valid whether it's MBR or GPT."

I am missing something in the FlashLayout?

[Emmanuel COMBETTE DE RYMON]

Hello ,

Trusted image has to be used with the ecosystem 2.0 , on which board are you testing , which ecosystem ?

Can you check with FlashLayout_emmc_stm32mp157c-ev1-trusted.tsv that is intended for eMMC on evaluation boards ?

#Opt Id Name Type IP Offset Binary

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

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

P 0x04 fsbl1 Binary mmc1 boot1 tf-a-stm32mp157c-ev1-trusted.stm32

P 0x05 fsbl2 Binary mmc1 boot2 tf-a-stm32mp157c-ev1-trusted.stm32

PD 0x06 ssbl Binary mmc1 0x00080000 u-boot-stm32mp157c-ev1-trusted.stm32

Regards,

Emmanuel

[CErik.1]

Hello Emmanuel,

Thanks.

I am using a custom board, very vanilla with an eMMC (OSD32 + USB + eMMC). I booted with my TF-A -> Uboot via DFU to RAM where I could write my TF-A and U-boot to the EMMC. When trying to boot from the eMMC I got the above from the TF-A. I have read and printed the data around where it expects the GPT to be and I get nothing like a GPT header or GPT signature. It is like it is reading from something else, almost empty (0x00). The CPU is rev Z btw. The TF-A does not find "EFI PART" and thus stops looking before it prints the message ERROR:  Partition ssbl not found. There is nothing there. Where could it be since the U-boot booted in RAM can read the partition table? It is a trusted chain (sp_min, else I would not be able to boot into RAM and program the flash).

I have used https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#e-E2-80-A2MMC as template for the FlashLayout file. Also tried multiple different variations of it without a difference. TF-A is never able to read a GPT partition table (or anything useful for that matter).

TF-A from https://github.com/STMicroelectronics/arm-trusted-firmware 69cc28c5a1b877cf67def7f94dece087f3917b1c

U-Boot from https://github.com/STMicroelectronics/u-boot v2018.11-stm32mp-r4.3

BR

[CErik.1 · Accepted solution]

I got it working by running a newer TF-A! 46f31fb8e5db9b7b8506da40a8a4acc49e549c8c worked for me specifically.

[Emmanuel COMBETTE DE RYMON]

Hello

Thanks for your clear explanation

Good new. So the TF-A was from ecosystem 2.0 and Uboot from ecosystem 1.2 presumably.

Just for information , I picked up this interesting information that GPT is not generated if a "P" is missing in one of the lines in the .tsv.

In this case TFA could have been in fsbl1 partition (not see by GPT on eMMC) and loaded by the ROM code and when TFA would have looked

to GPT header he will not have found it since not created by CubeProgrammer.

"On the block devices (SD card or e•MMC), the GPT partitioning is performed if all partitions of the device are selected with P."

https://wiki.st.com/stm32mpu/wiki/STM32CubeProgrammer_flashlayout#Field1-_Options

Regards,

Emmanuel