cancel
Showing results for 
Search instead for 
Did you mean: 

EMMC Bootarea selection Debugging

SimK
Associate II

Hi,

i implemented our TF-A update by using both bootareas:

1) checking EXTCSD for active bank

2) flashing opposite bank

3) after verification switching EXTCSD (mmc bootpart enable)

not failsafe but at least atomic / verified.

(btw, i'm missing the feature that the ROMCode does a fallback to the inactive bootarea in case the selected one is unbootable.)

The TF-A is not printing any information about the used partition. It's always showing:

INFO: Using EMMC
INFO: Instance 2
INFO: Boot used partition fsbl1

which is of course misleading, because there is no fsbl1 partition anywhere on the emmc. It's also "1" if i boot from second boot area ([PARTITION_CONFIG: 0x50]), so the bootcontext information for this seems only to be valid in case of booting from userarea, e.g. SDC?

Is there any (undocumented) information for that (reflecting used boot area) in the bootcontext i could use for a debug message? I ensured that the mechanism is working by selecting a bootpartition without content - nothing happens then, so it's working and bootstrapping is correct.

thanks,

Simon

2 REPLIES 2
PatrickF
ST Employee

Hi, @SimK ,

I agree not easy to understand the specificity of eMMC regarding boot partition.

The behavior is expected as BootROM only see a single eMMC boot partition (for eMMC, this mean no fall back to another FSBL from BootROM). So with eMMC, the BootROM always report this single FSBL as FSBL1.

As you mention, no way to distinguish without reading PARTITION_CONFIG (EXT_CSD[179]), I guess you could implement something custom in TF-A (or else) to check and print the PARTITION_CONFIG[5:3] (BOOT_PARTITION_ENABLE field)

  • 0x1 : Boot partition 1 enabled for boot
  • 0x2 : Boot partition 2 enabled for boot

Regards.

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.

Hi,

ok, then it's as I suspected.

if it is just as hard-connected with the EXT_CSD setting, then the register is enough for me to verify that it works like this.

thanks for the fast response!