Identify conflicts to prepare for merging feature-twincpu back to master branch
Open, Needs TriagePublic


The feature-twincpu and master may have significant divergences which will cause merge conflicts. It may be complex and inefficient to solve the conflicts on feature branch and then push it back to master.

This task tries to identify the conflicts.
If it is more smooth to fix the conflicts prior to formal merge process, propose fix patches to master branch or feature branch.

davidhuziji moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.
davidhuziji added a comment.EditedAug 19 2019, 6:58 AM

The conflicts in source code include but not limited to the following list

  1. TF-M secure data section size overflow in current PSoC 6 Flash layout. In the very first try, GCC report Flash section overflow in ConfigRegressionIPC config. It could be worse with more test cases enabled.
/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld: ../unit_test/tfm_s.axf section `.TFM_DATA' will not fit in region `FLASH'
/opt/gcc-arm-none-eabi-7-2018-q2-update/bin/../lib/gcc/arm-none-eabi/7.3.1/../../../../arm-none-eabi/bin/ld: region `FLASH' overflowed by 544 bytes
  1. Code structure adjustment on master branch:
  2. Changes to align with PSA spec on master branch:
    • Additional type parameter in psa_call()
    • Default return error code of psa_connect() is changed to TFM_ERROR_CONNECTION_BUSY
    • Default return error code in RPC should be changed to TFM_ERROR_GENERIC
  3. Test selection on master branch.
    • IRQ test
      • IRQ test is enabled by default on Isolation Level 1. Need an option to disable IRQ tests until IRQ support is ready on multi-core. A patch is merged on master branch:
      • Several IRQ handling HAL APIs are added. They require dummy functions on PSoC 6.
    • Peripheral Access test case in Core test service on Isolation Level 2, which just switches on and off LEDs. It requires platform to implement two LED control APIs but actually doesn't verify any secure requirements.
      • The two LED control APIs are for that test case only but the test case will check the return value to see if LED status is the same as expected. Rather than adding dummy functions to play a trick on static variable, I'd prefer to propose a patch to add a preprocessor flag to select that Peripheral Access test case. It is either unnecessary to port the whole GPIO/LED drivers from PSoC 6, just to pass such a test case. (Patch under review:
      • The best solution is to select this test case in manifest. However, current PSA spec doesn't specify a field to deselect a test case. The only way to remove a test case from final manifest is to provide another manifest, which will definitely asset another problem of manifests management on diverse platforms. Thus the current plan is to just select this test case via preprocessor flag during compiling.
  4. Changes in boot
  5. NS interface in multi-core topology
    • NS side OS wrapper on master branch. OS wrappers are added into abstract the mutex/semaphore and other common ops from RTOSs. NS part in feature-twincpu needs some refactor to fit latest master branch implementation
      • mutex wrappers in multi-core PSA client call
      • Additional topology specific implementations, such as tfm_ns_interface_init() and NS lock. I'd prefer to keep multi-core specific implementation of NS interface since multi-core NS interface may require different lock mechanism than that in single-core platform.
    • Additional type parameter in psa_call()
  6. Changes to TF-M Core on master branch
    • Potential changes to key structures and exception handler may affect Armv6-M/Armv7-M arch support.
    • Structure names changes, such as spm_partition_desc_t
  7. Some platform HAL APIs return code change to enum tfm_plat_err_t
    • tfm_spm_hal_set_secure_irq_priority()
    • tfm_spm_hal_init_isolation_hw()
    • tfm_spm_hal_setup_isolation_hw()
  8. master branch adds some platform specific APIs in tfm_core_init(). It requires dummy functions to fulfill those APIs declarations. However, it concerns me if it is really necessary to split a whole platform_hw_init() into so many small steps.
    • tfm_spm_hal_enable_fault_handlers()
    • tfm_spm_hal_system_reset_cfg()
    • tfm_spm_hal_init_debug()
  9. Memory check process
    • master branch already splits the single core memory check process from other general secure operations in tfm_secure_api.c/.h ( but feature-twincpu still keep them together in tfm_secure_api.c/.h. Thus, feature-twincpu currently implements some duplicated code to keep decoupled to single memory check and the whole tfm_secure_api.c/.h. After rebasing, feature-twincpu should remove those duplicated code and re-use those general ops from tfm_secure_api.c/.h
  10. mmio_region in test secure service manifest. Latest test secure services on master branch include mmio_region in manifest. Although these secure services are general, the mmio_region is actually bound to platform specific HW resource information. It requires PSoC 6 to add dummy definitions in platform_peripherals_def.h to fit the files in mmio_region. It is impractical to bound a general secure partition manifest with platform specific HW setting. Need to confirm with PSA FF spec writer.

Changes to build environment after rebasing/merging

  1. mbed-crypto
  2. CMSIS 5.5
curl -s |sudo bash
sudo apt-get install git-lfs
git lfs install
cd CMSIS_5
git-lfs pull
  1. Generate auto-generated manifest files
    • The auto-generated manifest files should be updated as well. But it is recommended to generate the manifest files via Python tool before first use. Please double check if any modification is not included in generated manifest file.
davidhuziji moved this task from Restricted Project Column to Restricted Project Column on the Restricted Project board.Fri, Sep 6, 5:14 AM