cancel
Showing results for 
Search instead for 
Did you mean: 

TFA boot failed with emmc flash

SChen.11
Associate III

Hi, I has two custom boards. There are have same stm32mp157 ic and ddr. The difference is emmc flash, A's from micron and B is THGBMNG5D1LBAIL.

Basic chain:

The A and B are bootup success.

Trusted chain(TF-A + U-Boot)

The A is bootup success.

The B is bootup failed when TFA running. Below is failed message

NOTICE:  CPU: STM32MP157AAA Rev.B
NOTICE:  Model: Test Board
INFO:    Reset reason (0x14):
INFO:      Pad Reset from NRST
INFO:    Using EMMC
INFO:      Instance 2
INFO:    Boot used partition fsbl1
INFO:    BootROM: 252928 (0x3dc00) bytes copied from eMMC
WARNING: Failed to access image id=28 (-2)
ERROR:   Partition ssbl not found
PANIC at PC : 0x2ffdb96f
 
Exception mode=0x00000016 at: 0x2ffda000

I try to use USB or dd command in linux to write TFA and U-boot binary file into mmcblk1boot0 and /dev/mmcblk1p1 device. It's all failed.

1 ACCEPTED SOLUTION

Accepted Solutions
PatrickF
ST Employee

Hello,

Notice that for silicon Rev.B, as you could see in the latest Errata Sheet, there is restriction of using only Toshiba or Kingston eMMC (any density/models of these brand should work, but only few has been tested). This limitation is removed on silicon Rev.Z which is in production now (there could still be some Rev.B in stock at distributors, so you should ask before placing order).

Nevertheless, this limitation for Micron should be blocking at BootROM level and TF-A should not load (and BootROM fallback to DFU mode).

It seems you use Micron references which are not affected by this bug as you see TF-A loaded.

Did you check if your HW (eMMC supply, pull-up, decoupling, etc...) and TF-A settings (clocks, device speed support) are ok with this Micron device ?

Are you sure the eMMC programming was ok (this is related to uBoot settings).

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

View solution in original post

4 REPLIES 4
SChen.11
Associate III

Next, I debug the TFA source code. I found the error caused by check LBA0 boot sigature(0x55aa) isn't correct. So, I add print code and use command to check that flag.

Below is use mmc read and md to check boot flag of LBA0 of mmc1(emmc)

STM32MP> mmc read 0xc4000000 0 200
 
MMC read: dev # 1, block # 0, count 512 ... 512 blocks read: OK
STM32MP> md.b 0xc4000000 200
c4000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000110: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000120: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000130: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000140: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000150: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000160: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000170: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c4000190: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40001a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40001b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40001c0: 00 00 ee 00 00 00 01 00 00 00 ff ff 75 00 00 00    ............u...
c40001d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40001e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00    ................
c40001f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa    ..............U.

The boot flag 0x55aa is correct.

The below log from TFA. It's read boot flag is 0x15aa. But I wasn't known why the TFA read wrong value.

NOTICE:  CPU: STM32MP157AAA Rev.B
NOTICE:  Model: Test Board
INFO:    Reset reason (0x14):
INFO:      Pad Reset from NRST
INFO:    Using EMMC
INFO:      Instance 2
INFO:    Boot used partition fsbl1
INFO:    BootROM: 252928 (0x3dc00) bytes copied from eMMC
WARNING: read data 15, aa
WARNING: 4 Failed to access image id=28 (-2)
ERROR:   Partition ssbl not found
PANIC at PC : 0x2ffdb96f
 
Exception mode=0x00000016 at: 0x2ffda000

PatrickF
ST Employee

Hello,

Notice that for silicon Rev.B, as you could see in the latest Errata Sheet, there is restriction of using only Toshiba or Kingston eMMC (any density/models of these brand should work, but only few has been tested). This limitation is removed on silicon Rev.Z which is in production now (there could still be some Rev.B in stock at distributors, so you should ask before placing order).

Nevertheless, this limitation for Micron should be blocking at BootROM level and TF-A should not load (and BootROM fallback to DFU mode).

It seems you use Micron references which are not affected by this bug as you see TF-A loaded.

Did you check if your HW (eMMC supply, pull-up, decoupling, etc...) and TF-A settings (clocks, device speed support) are ok with this Micron device ?

Are you sure the eMMC programming was ok (this is related to uBoot settings).

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
PatrickF
ST Employee

Maybe with CubeProgrammer loading TF-A and uBoot, try to stop at uBoot (any key on console once uBoot start) and check the eMMC content using uBoot commands.

A simplified .tsv could avoid any reprogramming if you don't stop at uBoot.

e.g.

#Opt   Id   Name   Type   IP   Offset   Binary
-   0x01   fsbl1-boot   Binary   none   0x0   tf-a-stm32mp157c-xxxx-trusted.stm32
-   0x03   ssbl-boot   Binary   none   0x0   u-boot-stm32mp157c-xxxx-trusted.stm32
PE   0x04   fsbl1   Binary   mmc1   boot1   none
PE   0x05   fsbl2   Binary   mmc1   boot2   none
PE   0x06   ssbl   Binary   mmc1   0x00080000   none

In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.

Thanks for your quick response. The A board use micro MTFC4GACAJCN-4M model. Yes, I had already saw that emmc issue on errate sheet. So, I am confuse about that. These two board use same PCB and component, just soldering difference emmc flash.