• State Accepted Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 6 subscribers
  • Views 1645 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

Understanding Corstone 1000 Cortex M0+ booting process

Bharath Kumar

Hi,

Under TF-M code i can see two bootloaders in bl1 directory one is bl1_1 and bl1_2, but in the arm Corstone_SWArch document i can only see bl1 and bl2..

so for corstone 1000 does arm uses bl1_1 and bl1_2?? why bl1 is split into two directories again?

If possible any expert can please explain this in more detail with the code prospective.

Thanks,

Parents
  • 0 in reply to Stephen Theobald

    Hi Stephen,

    Thanks for the helpful information , one more doubt i have, i am going through the TFM code 

    ./secure_fw/spm/core/main.c  inside this main.c file how the transfer is happening from tfm to the non secure host?

    nsfptr_t -> after using this function pointer what will happen?

    could you please help me out in understanding this

    Thanks,

    Bharath

Reply
  • 0 in reply to Stephen Theobald

    Hi Stephen,

    Thanks for the helpful information , one more doubt i have, i am going through the TFM code 

    ./secure_fw/spm/core/main.c  inside this main.c file how the transfer is happening from tfm to the non secure host?

    nsfptr_t -> after using this function pointer what will happen?

    could you please help me out in understanding this

    Thanks,

    Bharath

Children
  • +1 Arm Employee Badge in reply to Bharath Kumar

    Hello Bharath,

    In Corstone-1000 case:
    The Cortex-M0+ core (Secure Enclave) in the system enables the Cortex-A35 core (Host).
    This can be seen in the tf-m/secure_fw/partitions/ns_agent_mailbox/ns_agent_mailbox.c file. The boot_ns_core() function calls the tfm_hal_boot_ns_cpu() platform-specific function, which is implemented in the tf-m/platform/ext/target/arm/corstone1000/tfm_hal_multi_core.c file. After this, the Host core will start booting, that part is out of the scope of TF-M.
    After this, the Secure Enclave will stay inside the ns_agent_mailbox_entry() function in tf-m/secure_fw/partitions/ns_agent_mailbox/ns_agent_mailbox.c, and it's going to wait for requests from the Host core.

    Note: in Corstone-1000 case the Secure Enclave does not have Non-Secure side, it only has the mailbox partition and other secure partitions.

    Regarding the nsfptr_t: I did not find it in the common code or in the arm platforms' code so I'm unsure how this is handled, but I think this is not a general thing.

    For other platforms that implement both S and NS world on the M core:
    In general the way of jumping to the NS at the end of the boot depends if SFN or IPC model is used:
    You can see that the BACKEND_SPM_INIT(); is called at the end of the main in tf-m/secure_fw/spm/core/main.c file, which in the end will jump to the NS entry point. If you are interested in this part, you can check the

    document, this explains the TF-M SPM implementation.

  • 0 in reply to Bence Balogh

    Hi Bence,

    Thanks a lot for the explanation.

    Thanks,

    Bharath