• State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 6 subscribers
  • Views 898 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Corstone 1000 Cortex M0+

Bharath Kumar

Hi,

I have small query on this

https://tf-m-user-guide.trustedfirmware.org/design_docs/booting/bl1.html  --> here document says that bl1 is split into bl1_1 and bl1_2

https://tf-m-user-guide.trustedfirmware.org/platform/arm/corstone1000/readme.html  -->  here the doc says there is only bl1.

So when i do git clone for TFM, there is bl1_1 and bl1_2 code, i am confused here, in the below link

https://corstone1000.docs.arm.com/en/latest/software-architecture.html  looking at the diagram under secure boot chain

there is only bl1 and bl2.

So is it ok to use bl1 alone? How many bootloaders are present in cortex MO+?

Is it mandatory to use bl1_1 and bl1_2 as it is? Since we are dealing with ROM do we face any issues if we do not split the bl1 to bl1_1 and bl1_2?

Kindly please help me on this understanding Thanks a lot.

Regards,

Bharath

Parents
  • 0

    Hello Bharath,

    Sorry for the confusion, the [1] and [2] documents are not fully updated on the boot sequence part yet. This will be fixed shortly.

    Regarding your questions:

    The Corstone-1000 TF-M port follows the [3] design document, so there is a separate BL1_1, BL1_2 and BL2 for the Cortex-M0+ core in the Corstone-1000 platform.

    It is not mandatory to separate BL1_1 and BL1_2 but it is strongly advised if you want to provide more functionality in BL1. The BL1_1 should go into the ROM and should have minimal functionality because it is really expensive to change it, as the photolithography masks have to be modified for that. The BL1_1 should validate the next BL1_2 stage, which can be in any kind of non-volatile memory. This BL1_2 will be easier to change so it can have more functionality.
    As the BL1_1 code has minimal features, it has a smaller footprint and can fit in smaller ROM thus reducing the ROM size requirement.

    So it is suggested that the BL1_1 is located in a ROM and it only does the provisioning and the validation of the next bootstage (BL1_2). The BL1_2 can be either in OTP memory (so it can be changed during provisioning) or any kind of non-volatile memory. In Corstone-1000 case, the BL1_2's code is provisioned into the OTP memory on the first boot. (See tf-m/platform/ext/target/arm/corstone1000/bl1/provisioning.c +76)

    Please note that the current Corstone-1000 TF-M port has some limitations at the moment:
    The provisioning bundle that contains the BL1_2 binary is also located in a ROM region. This is not optimal because this way the BL1_2 is also permanent and cannot be changed during provisioning.

    Let me know if you have any follow up questions!

    [1] tf-m-user-guide.trustedfirmware.org/.../readme.html
    [2] corstone1000.docs.arm.com/.../software-architecture.html
    [3] tf-m-user-guide.trustedfirmware.org/.../bl1.html

Reply
  • 0

    Hello Bharath,

    Sorry for the confusion, the [1] and [2] documents are not fully updated on the boot sequence part yet. This will be fixed shortly.

    Regarding your questions:

    The Corstone-1000 TF-M port follows the [3] design document, so there is a separate BL1_1, BL1_2 and BL2 for the Cortex-M0+ core in the Corstone-1000 platform.

    It is not mandatory to separate BL1_1 and BL1_2 but it is strongly advised if you want to provide more functionality in BL1. The BL1_1 should go into the ROM and should have minimal functionality because it is really expensive to change it, as the photolithography masks have to be modified for that. The BL1_1 should validate the next BL1_2 stage, which can be in any kind of non-volatile memory. This BL1_2 will be easier to change so it can have more functionality.
    As the BL1_1 code has minimal features, it has a smaller footprint and can fit in smaller ROM thus reducing the ROM size requirement.

    So it is suggested that the BL1_1 is located in a ROM and it only does the provisioning and the validation of the next bootstage (BL1_2). The BL1_2 can be either in OTP memory (so it can be changed during provisioning) or any kind of non-volatile memory. In Corstone-1000 case, the BL1_2's code is provisioned into the OTP memory on the first boot. (See tf-m/platform/ext/target/arm/corstone1000/bl1/provisioning.c +76)

    Please note that the current Corstone-1000 TF-M port has some limitations at the moment:
    The provisioning bundle that contains the BL1_2 binary is also located in a ROM region. This is not optimal because this way the BL1_2 is also permanent and cannot be changed during provisioning.

    Let me know if you have any follow up questions!

    [1] tf-m-user-guide.trustedfirmware.org/.../readme.html
    [2] corstone1000.docs.arm.com/.../software-architecture.html
    [3] tf-m-user-guide.trustedfirmware.org/.../bl1.html

Children