Page MenuHomePhabricator

tfm_spm_hal_post_init functionality is broken
Closed, ResolvedPublic


The original idea of adding tfm_spm_hal_post_init was to let tfm do hardware (or any other) initialization that cannot be done in SystemInit() in asm startup code. One of the user-case scenarios is an initialization that creates variables and data structures that are used later in platform drivers. C library init wipes off these variables.

Please see the following changes for reference.

The patch that was merged recently ( messes things up: it moves isolation protection above the post init call. Instead of moving tfm_spm_hal_init_isolation_hw() above tfm_spm_hal_post_init, it had to take UART init out and move it below tfm_spm_hal_init_isolation_hw().

Essentially it brakes psoc64 target. We came up with some workarounds, but hopefully this issue can be addressed properly.

Event Timeline

ainh created this task.Jan 16 2020, 10:07 PM

Hi Andrei,

Looks like this caused the UART not working - are you using UART in the core? Just collecting feedback since we are check if we could remove UART logging from core (convert this to another logging mechanism).

And the prefix 'post' is going to be removed - The SystemInit is a CMSIS involved init which is out of core scope, for core, there is only one init for it.

I assume providing a new solution would need weeks (discussions and feedbacks), please create workarounds if you want to make it work asap before the new mechanism is decided.


ainh added a comment.Jan 22 2020, 1:15 AM

Hi Ken,
yes, we are using UART in core to print some info like protection status and boot progress.
For the hw initialization, SystemInit called from startup code is not sufficient enough as it cannot pass status and data to the rest of the platform code written in C. This was the main reason for adding post init function.

Close it as no follow-ups, assume it has been fixed.

KenLSoft closed this task as Resolved.Wed, Oct 14, 9:50 AM