Hi all,

 

I faced the problem that mailbox configuration of secure image differs from one provided for non-secure. It’s because I’m using a split-build but a little bit different that is prepared for v2.0. I think we can minimize dependencies and unexpected impacts between different images when common data structures will have less customization.

 

Currently we have three options that can change mailbox structures:

  1. NUM_MAILBOX_QUEUE_SLOT – number of mailbox slots
  2. TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD – defines which NS client implementation is selected.
  3. TFM_MULTI_CORE_TEST – specify whether NS multi-core test suite is built.

 

There is requirement that NUM_MAILBOX_QUEUE_SLOT must be set to 1 if NS bare metal environment is used. But this limitation is excessive. Because it’s important that secure side is not using slots that are not used by non-secure side. It can be possible to use NS bare metal client even if mailbox queue size is more than one, it’s just the waste of resources in such case. But it can bring a benefit that it’s possible to build secure image with default settings (aka 4 mailbox slots) and there is no need to rebuild it if there will be decision to switch from RTOS to bare metal environment which can be useful for some end-user use cases.

More flexible update will be to pass number of allocated slots from NS side to TF-M during initialization, it’s just important to validate that number of slots doesn’t not exceed maximum supported by design.

 

TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD is another problem, because mailbox_reply_t allocates data that are not shared but used by non-secure side only. Which means that it’s important to decide which NS client implementation is going to be used when TF-M is built. I see two different solutions for this problem:

  1. Use union to allocate space for both of them and let decide NS client implementation which on to use. Something like this:

struct mailbox_reply_t {

    union

    {

//#ifdef TFM_MULTI_CORE_NS_OS_MAILBOX_THREAD

    uint8_t    *woken_flag;                 /* Indicate that owner task has been

                                             * or should be woken up, after the

                                             * reply is received.

                                             */

//#else

    bool        is_woken;                   /* Indicate that owner task has been

                                             * or should be woken up, after the

                                             * reply is received.

                                             */

//#endif

    };

};

  1. Redesign mailbox by separating data that are used by NS client from data that are shared between cores. So, it will be much easier to update non-secure client without touching secure image.

 

It looks like there is data needed for test suite only (nr_tx and nr_used_slots fields of ns_mailbox_queue_t) defined by TFM_MULTI_CORE_TEST. I think we can allocate it in test suite only, so there will be no need to allocate this data in shared structure and there will not be the case when location of is_full field of ns_mailbox_queue_t accessed by both cores have different location if TFM_MULTI_CORE_TEST configuration is not applied the same way for both secure and non-secure images.

 

Regards,

Roman.