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,
My name is Stephen and I work at Arm. A colleague provided the following explanation:In general, the BL1 implementation in TFM is split up into BL1_1 and BL1_2. The reason for this is that the BL1_1 should be located in ROM. The BL1_2 can be placed in other type of non-volatile memory.In a real product, changing the ROM code is only possible by modifying the photo-lithography masks in the assembly line which is really expensive. This is why only a small amount of functionality is placed in the BL1_1. The others are placed in the BL1_2, which can be modified more easily.You can read about this more in-depth attf-m-user-guide.trustedfirmware.org/.../bl1.htmlIn theory the BL1_1 should do at least:- provision the device with keys and assets- validate the BL1_2 image and jump to that.Then BL1_2 can do additional initialization, calculations, then it should validate the next image in the bootflow and jump to that. In TF-M case, the next image is MCUBoot.The Corstone1000 slightly diverges from this. In Corstone1000 both the BL1_1 and BL1_2 are located in the ROM so the BL1_2 cannot be changed either, but with the separation the platform is prepared to move it elsewhere easily in the future. (Actually, since Corstone1000 is only for fpga and fvp, it isn't a problem to update things in the ROM because it's only an emulated ROM.)The common BL1 code is located in the tfm/bl1 folder, and it provides weak functions that can be implemented, those can be seen in the tfm/platform/ext/target/arm/corstone1000/bl1/boot_hal_bl1_1.c and tfm/platform/ext/target/arm/corstone1000/bl1/boot_hal_bl1_2.c.In the current implementation most of the things are done in the bl1_1: it sets up the firewall, mpu and handles the provisioning. Then it validates the BL1_2 image and jumps to that. The BL1_2 then validates the BL2 image and jumps to that.Hope this helps,Stephen
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
Bharath
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.
Hi Bence,
Thanks a lot for the explanation.