Hello,
I am working on an AMP system design using AM6548. As suggested by TI, one core of the AM6548 runs in TrustZone secure world, whereas other cores run in TrustZone non-secure world.
The secure (primary) core starts first and then needs to enable the other (secondary) cores. Since the system does not use Arm Trusted Firmware, code running on the secure primary core issues TISCI processor boot management requests (specifically, TISCI_MSG_PROC_REQUEST, TISCI_MSG_PROC_SET_CONFIG, TISCI_MSG_PROC_SET_CONTROL), and power management requests (specifically, TISCI_MSG_SET_DEVICE) to start each secondary core.
it seems that the system firmware on the DMSC is NAKing the TISCI_MSG_PROC_REQUEST, and therefore the remainder of the sequence to start the secondary cores fails.
For test purposes I can run the primary core in TrustZone non-secure state in which case the TISCI requests are all ACKed and the secondary cores are started normally using the same code sequence. Apart from the TrustZone security state, the only differences between the code in the two security states are:
- the host ID, secure proxy IDs and interrupt numbers
- presence or absence of additional TISCI message header
NOTE: In general, other TISCI requests are working correctly when issued from the secure core (for example, configuring clocks, power domains, requesting resources, etc.).
Is there a limitation in the system firmware which causes TISCI processor boot management requests from a secure core to fail? If so, how can I work around it? Otherwise, what might be causing this behaviour?
Thanks,
Ian