Skip to main content
U
UVV
Explorer
March 17, 2021
Solved

Not able to change eMMC boot partition

  • March 17, 2021
  • 2 replies
  • 5871 views

Hi there,

I have a custom CPU: STM32MP153CAB Rev.Z board and setting up a redundant bootloader setup on eMMC. In order for that to work I should be able to switch between boot partitions.

This is how I'm trying to do that in u-boot:

STM32MP> mmc partconf 1
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x1
PARTITION_ACCESS: 0x0

Then I've got expected output from TF-A:

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

When I switch to a second partition though:

STM32MP> mmc partconf 1 1 2 0
STM32MP> mmc partconf 1 
EXT_CSD[179], PARTITION_CONFIG:
BOOT_ACK: 0x1
BOOT_PARTITION_ENABLE: 0x2
PARTITION_ACCESS: 0x0

I still get the same message in TF-A:

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

What am I missing here? Is boot_context populated correctly by TF-A? Is second boot partition used at all by ROM?

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

    Hi Vyacheslav,

    I confirm my statements, when using eMMC, the BootROM only see one (and only one) single boot partition and has no way to know which boot partition is active (BootROM does not read any CSD nor issue any command to the eMMC, except a reset command).

    The choice for this 'boot active' partition is done by the application, not by the BootROM.

    I agree that using fsbl1 might be seen as wrong as during flashing of the two boot partitions, we name them fsbl1 and fsbl2. But for bootROM point of view, there is only one fsbl visible (named fsbl1, even if it could be fsbl2 in reality).

    There is no bug there, so nothing to fix (btw, BootROM content cannot be changed).

    The fsbl1/fsbl2 parameter context is useful only for other Flash boot (SLC NAND, SD-Card, Serial-NOR, Serial-NAND), but seen as useless for eMMC which has a very specific boot.

    This is stated in eMMC JEDEC standard (JESD84-B51 for instance)

    0693W000008xEdMQAU.png 

    For eMMC, a safe update on the FSBL could be done in following steps (example with #2 as current active partition in PARTITION_CONFIG):

    1. check (using PARTITION_CONFIG read) which partition is active for boot (e.g. #2)
    2. update content of the other partition (e.g. #1), carefully verify it
    3. update PARTITION_CONFIG to use the other partition (e.g. #1)

    In case of unwanted reboot (reset or power fail) at any time before step 3, the platform will restart cleanly from current active boot partition (e.g. #2). It is up to your update SW to manage this failure and restart the update process from the beginning.

    I think there is no need here to have a 'step 4' to refresh the 'old' partition (e.g. #2) as after step 3 there is no way to boot from it.

    Regards.

    2 replies

    P
    PatrickF
    Technical Moderator
    March 18, 2021

    Hi,

    BootROM (and probably TF-A) has no way to know which eMMC boot partition is used, this is inherent to eMMC way of working, only one boot partition is 'visible' for boot (named here fsbl1).

    Due to this, for eMMC boot, BootROM has no way to switch to the second partition in case of boot failure (which should not occur on eMMC in real life).

    Second partition on eMMC is only there to ensure safe update of one partition (e.g. to support reset or power failure during update) while boot is still selected on the previous valid one.

    To know which partition is used, SW need to read the PARTITION_CONFIG (EXT_CSD[179]) in the eMMC. But it is usually not needed.

    If you want to test you could try putting different binary (e.g. different version printout) in each boot partition.

    Regards.

    U
    UVVAuthor
    Explorer
    March 18, 2021

    Hi Patrick,

    Thanks for a quick response.

    Well, TF-A has a way of retrieving it. If you take a look at plat/st/stm32mp1/include/boot_api.h header file in TF-A, boot_api_context_t has a member boot_partition_used_toboot. This context is supposed be populated by ROM according to the official documentation https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Jump_to_FSBL . Moreover, if you go further down in the same article https://wiki.st.com/stm32mpu/wiki/STM32MP15_ROM_code_overview#Boot_from_e-E2-80-A2MMC-E2-84-A2 , you see that using another boot partition as active should be supported.

    So here's the question again. Can you please confirm that BootROM handles active boot partition properly?

    > To know which partition is used, SW need to read the PARTITION_CONFIG (EXT_CSD[179]) in the eMMC.

    That would allow me to get a partition that is configured (it didn't have to be used by the BootROM though). But I can do a quick test to see if BootROM actually uses a proper partition and it's just a boot context not populated properly (although TF-A source code suggests otherwise), or that BootROM always uses a first boot partition, which sounds like a bug to me.

    In the latter case, would there be a way to fix a BootROM on my board? Otherwise I can't implement the support of bootloader atomic/redundant update.

    Thanks,

    Vyacheslav

    P
    PatrickFAnswer
    Technical Moderator
    March 18, 2021

    Hi Vyacheslav,

    I confirm my statements, when using eMMC, the BootROM only see one (and only one) single boot partition and has no way to know which boot partition is active (BootROM does not read any CSD nor issue any command to the eMMC, except a reset command).

    The choice for this 'boot active' partition is done by the application, not by the BootROM.

    I agree that using fsbl1 might be seen as wrong as during flashing of the two boot partitions, we name them fsbl1 and fsbl2. But for bootROM point of view, there is only one fsbl visible (named fsbl1, even if it could be fsbl2 in reality).

    There is no bug there, so nothing to fix (btw, BootROM content cannot be changed).

    The fsbl1/fsbl2 parameter context is useful only for other Flash boot (SLC NAND, SD-Card, Serial-NOR, Serial-NAND), but seen as useless for eMMC which has a very specific boot.

    This is stated in eMMC JEDEC standard (JESD84-B51 for instance)

    0693W000008xEdMQAU.png 

    For eMMC, a safe update on the FSBL could be done in following steps (example with #2 as current active partition in PARTITION_CONFIG):

    1. check (using PARTITION_CONFIG read) which partition is active for boot (e.g. #2)
    2. update content of the other partition (e.g. #1), carefully verify it
    3. update PARTITION_CONFIG to use the other partition (e.g. #1)

    In case of unwanted reboot (reset or power fail) at any time before step 3, the platform will restart cleanly from current active boot partition (e.g. #2). It is up to your update SW to manage this failure and restart the update process from the beginning.

    I think there is no need here to have a 'step 4' to refresh the 'old' partition (e.g. #2) as after step 3 there is no way to boot from it.

    Regards.

    A
    alenik-mm
    Visitor II
    July 30, 2021

    Hi Vyacheslav,

    did you send the patch upstream, could you share the commits? What did you patch anyway, according to the comments there was nothing to fix or Im wrong?

    U
    UVVAuthor
    Explorer
    July 30, 2021

    Hi,

    The patch series is accepted upstream https://review.trustedfirmware.org/q/owner:uvv.mail%2540gmail.com

    ​

    It's about a config option to enable loading of SSBL from the same boot partition TF-A is stored in.

    ​

    Cheers,

    Vyacheslav​

    Terms & ConditionsAccessibility statement