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.
https://review.trustedfirmware.org/c/trusted-firmware-m/+/1973
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2211
https://review.trustedfirmware.org/c/trusted-firmware-m/+/2212
The patch that was merged recently (https://review.trustedfirmware.org/c/trusted-firmware-m/+/3040) 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.