Hi everyone,
TFM manifest files allow to specify priority for the partition. FFM 1.0 and FFM 1.1 specify that there are 3 possible values for this field: Low, NORMAL, HIGH.
This field is used in several template files to generate needed for SPM information. From what I see there are several problems with current implementation:
1. In secure_fw/spm/cmsis_func/tfm_spm_db_func.inc.template priority field is used to generate .partition_priority filed of spm_partition_static_data_t structure. It uses TFM_PRIORITY() macro to convert priority to numeric value. The problem is that this field is actually never used, instead all priority checking is done using .flags field of partition_{{manifest.name|lower}}_load_info_t structure (tools/templates/partition_load_info.template file).
2. .flags field uses PARTITION_PRI_ macro to convert priority to numeric value. Possible values for TFM_PRIORITY() are: LOW, NORMAL, HIGH, but PARTITION_PRI_ macro has: LOWES, LOW, NORMAL, HIGH, HIGHEST priorities. More over priorities with same names for these 2 macros have different numeric values (e.g. PARTITION_PRI_LOW is 0x7F while TFM_PRIORITY_LOW is 0xFF)
3. Scatter files does not account for HIGHEST priority (see code herehttps://git.trustedfirmware.org/TF-M/trusted-firmware-m.git/tree/platform/ext/common/armclang/tfm_isolation_l3.sct.template#n74). This is a problem for all toolchains including both common scatter files (L1 and L2) and scatter files templates for L3
So I have several questions on this topic:
1. Are LOWEST and HIGHEST priorities system reserved? Because for now they cant be used in manifest files as TFM_PRIORITY() does not have support them.
2. Should TFM_PRIORITY() macro and .partition_priority filed of spm_partition_static_data_t structure be removed? This will mean that if LOWEST and HIGHEST priorities are system reserved then validation of value for "priority" manifest field should be added to tfm_parse_manifest_list.py
3. Should scatter files be fixed to account for HIGHEST priority?
4. secure_fw/partitions/ns_agent_tz/load_info_ns_agent_tz.c for NS agent TZ specifies (PARTITION_PRI_LOWEST - 1) for a .flags filed. Higher priority numeric values is lower real priority, which means that TZ NS agent partition priority is between LOW and LOWEST priority. This seems like a hack to me, maybe we should introduce One more named priority?
5. In secure_fw/partitions/CMakeLists.txt idle partition is included when IPC backend is used. Idle partition is used to retrigger scheduling before going into WFI state (just to be sure that higher priority partitions were executed and there is not pending request). I can see how this partition is useful for MULTICORE case, to have kind of sleep state. But for TZ case TZ ns agent is always RUNNABLE and have higher priority that IDLE partition so it does not look like IDLE partition will ever be scheduled in TZ case. In such case condition in this Cmake file should be changed from "if (CONFIG_TFM_SPM_BACKEND_IPC)" to "if (TFM_PARTITION_NS_AGENT_MAILBOX)" Am I wrong somewhere?
Sorry, I know that is a lot of questions, but this scheduling stuff is really hard to wrap a head around.
Regards, Bohdan Hunko
Cypress Semiconductor Ukraine Engineer CSUKR CSS ICW SW FW Mobile: +38099 50 19 714 Bohdan.Hunko@infineon.commailto:Bohdan.Hunko@infineon.com