CMSIS Zone (MPU support) in Keil RTX

Hi Jonatan,

Thanks a lot for the information!

Can you already provide any rough time schedule for the release of the enhancements in RTX5, regarding MPU support?

Best regards,

Jussy

Hi Jussy,

unfortunately not. Do you have an expectation about it?

Best,

Jonatan

Hi Jonatan,

end of Q3 / 2018 in maximum.

Best,

Jussy

Hi Jussy,

that should work. Our current idea is to have a first draft available in Q1/2018 (Embedded World). It might take an additional quarter to incorporate the community feedback. So its likely to have something final until Q3/2018.

Best,

Jonatan

Hi Jonatan,

thanks a lot, I will communicate that to our team.

Best regards,

Jussy

Hello Jonatan,

How is the status of the MPU support in RTX5?

You told me that you will have a released version at the end of Q3/2018.

Can you provide any preliminary documentation to get an understanding of the usage and the features?

Best regards, Jussy

Hi Jussy,

Unfortunately we have no further progress compared to the draft stated earlier. We are focused on getting the non-MPU version of RTX5 ready for functional safety, first.

The usage/features we have in mind is sketched as part of CMSIS-Zone. We intend to introduce the concept of processes for RTX5, which is an arbitrary grouping of threads with shared memory access privileges. This concept is very similar what is used on Windows/Linux when talking about processes and threads. The scheduler of RTX5 shall provide a mechanism to change the MPU configuration whenever a thread switch (from one process to another) occurs. With a proper memory layout (partitioning) a segregation between processes can be achieved. 

The latest release of CMSIS already contains the basic functionality to put all this together on your own. RTX5 (compiled with the define MPU_LOAD) calls the scheduler hook osRtxMpuLoad. Core(M) contains a couple of functions to load MPU configurations from a predefined table. I expect the final solution to be basically implemented that way.

Of course there are many issues we need to solve in order to make the MPU protection applicable to a wide range of requirements. We need to further discuss how to handle privilege escalation for instance.

Best,

Jonatan

Hi,

I am trying to use the osRtxMpuLoad hook as a proof of concept. It seems the hook body is not defined anywhere, just the symbol name is kept as a placeholder in the irq_armv8mbl.s file. Since I can't find any documentation, I have a few basic questions:

1) Will simply adding a .c file with the function definition to the non-secure project be enough? Also, adding

MPU_LOAD

to the preprocessor symbol defines in the C/C++ dialog box under options for target work to ensure that the code works?

2) It seems that the osRtxMpuLoad takes in one parameter. From the assembly file, I think the parameter is a pointer to the next thread to run's info correct? (osRtxThread_t * type). So would that allow me to use the thread ID as the offset to the MPU configuration table and load the correct MPU configuration (using ARM_MPU_Load_NS)?

I apologize the if the questions are too basic but I don't have any other resource to figure this out.

Thanks

Hi Ghantaz,

I apologize that this MPU feature in RTX5 is not yet finally documented. We decided not to add it to the official documentation as long as its in beta stage. Please be aware that the hook might change in a future release of RTX5.

In the current implementation is a simply function you can implement anywhere in your use code. This function, as you already mentioned correctly, is called in RTX5 scheduler context right before jumping back to thread mode and executing the next threads code. The parameter given to that hook function is the thread id aka osRtxThread_t* (pointer to the next threads control block). You can use it to identify the thread that will be executed. Its up to you to configure the MPU accordingly.

Please be aware that in Armv8-M devices you have two separate MPUs, one for secure and one for non-secure mode. Typically I expect you to run RTX5 for non-secure mode. Hence you should implement the hook to reconfigure the non-secure MPU using ARM_MPU_Load function for instance. The ARM_MPU_Load_NS function can only be used in secure mode to reconfigure the non-secure MPU.

Does this make sense to you?

Cheers,

Jonatan

Hi,

Thank you. I figured that out and it seems to work. The current issue I am facing is that I get a hard fault while enabling the MPU (I think at __ISB()) if I don't set the PRIVDEFENA bit. I noticed the FreeRTOS implementation seems to always set it when enabling the MPU. Is their any reason why this needs to be done?

Thanks

Hi,

that depends on your MPU configuration. The PRIVDEFENA allows privileged access to all memory without specific region definition. If you don't enable that bit you would need to add specific region configuration for all your (privileged) code/data, explicitly. In CMSIS this decision is not made implicitly like it might be done in FreeRTOS. You rather need to set this bis explicitly during MPU enable if you want to.

Cheers,

Jonatan

Hi Jonatan,

I realise this thread is a few years old, but I was wondering if the "osRtxMpuLoad" hook is a supported feature of FuSa RTX RTOS? Are there any plans to extend the MPU support in FuSa RTX?

Many thanks

Peter