AM6548: TISCI processor boot management request fails from processor in TrustZone secure world

Ian Willats

Part Number: AM6548

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

4 months ago

0 Hong Guan64 3 months ago

TI__Guru 57645 points

Let's use Linux SDK boot flow as an example
software-dl.ti.com/.../UG-General-Info.html
where boot sequence on A53: ATF -> OPTEE -> A53-SPL/u-boot/kernel...
I'd recommend refering to ATF/OPTEE calling examples on PSCI/TISCI for your design...
- ATF on PSCI/TISCI
git.ti.com/.../k3_psci.c
git.ti.com/.../ti_sci.c
- OPTEE on TISCI
git.ti.com/.../ti_sci.c

A good reference on ATF
trustedfirmware-a.readthedocs.io/.../firmware-design.html

Best,
-Hong

0 Ian Willats 3 months ago in reply to Hong Guan64

Prodigy 240 points

Thanks for your reply. I'm familiar with the normal start-up flow and the Arm Trusted Firmware/PSCI implementation for AM6548 which is based on the TISCI requests I mentioned in my question. Apologies for not pointing out that we do not have Arm Trusted Firmware on the system I'm working on.

Tha main point of my question is to ask why the TISCI boot processor management requests are NAKed when issued from an A53 core in TrustZone secure world, and what needs to be done to make them work as they do when issued from non-secure world.

0 Andreas Dannenberg 3 months ago

TI__Guru 55516 points

Hi Ian,

Ian Willats said:
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.).

I suppose you have already experimented with all different host ID settings for A53?

https://software-dl.ti.com/tisci/esd/20_04_01/5_soc_doc/am65x_sr2/hosts.html

Regards, Andreas

0 Ian Willats 3 months ago in reply to Andreas Dannenberg

Prodigy 240 points

In my tests, any TISCI request from the secure A53 gets no response at all if the secure A53 uses a host ID other than 10, so I presume 10 is the correct host ID.

If I'm missing your point please would you clarify what you had in mind.

It would be most helpful if you could please specify what conditions cause the system firmware to NAK the TISCI_MSG_PROC_REQUEST when it is issued by an A53 core in secure world, and how this can be avoided.

Thanks.

0 Hong Guan64 3 months ago in reply to Ian Willats

TI__Guru 57645 points

Here is how HOST_ID = 10 (secure) is used in ATF caling TISCI API calls.
github.com/.../ti_sci.c
github.com/.../platform_def.h
Best,
-Hong

0 Ian Willats 3 months ago in reply to Hong Guan64

Prodigy 240 points

As I said already, other TISCI requests from the secure A53 are successful. My question specifically relates to the TISCI_MSG_PROC_REQUEST (and the others mentioned in my original post). To repeat once again: why does the system firmware NAK this request when it is issued by an A53 in secure world (using host ID 10) and what is needed to make this request succeed?

0 Hong Guan64 3 months ago in reply to Ian Willats

TI__Guru 57645 points

https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/hosts.html#introduction
"Additionally, one of the key reasons why HostID is tied in with Secure Proxy channels is because it prevents spoofing. When a message is received by System Firmware, the Secure Proxy channel tied to the HostID in the message is verified against the Secure Proxy channel on which the message was received. Specifically, only the HostID listed in the “Host Name” column can use the Secure Proxy channel associated with it."
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/hosts.html#enumeration-of-host-ids
https://software-dl.ti.com/tisci/esd/latest/5_soc_doc/am65x_sr2/sec_proxy.html#secure-proxy-thread-allocation-for-main-sec-proxy0
The example in ATF code on "Secure Proxy Thread ID" associated with "Host ID" = 10
https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/ti/k3/common/drivers/sec_proxy/sec_proxy.h#L26-L30

Best,
-Hong

0 Ian Willats 3 months ago in reply to Hong Guan64

Prodigy 240 points

Sorry if I am missing something, but as far as I can see nothing in your reply applies specifically to the TISCI_MSG_PROC_REQUEST as opposed to other TISCI requests such as enabling clocks, allocating resources, and controlling power domains. As I pointed out, those other TISCI requests work normally when issued from the secure A53 host (because the code I am working with already uses host ID 10 and the proper secure proxy channels).

What I have seen before is that if the host ID, secure proxy channel, etc. are wrong, then the DMSC/system firmware simply does not respond to the message.

That is not what I see when I issue the TISCI_MSG_PROC_REQUEST; in that case I get a NAK response when the request comes from the secure A53 core (host id 10).

This makes me suspect that there is some logic in the system firmware which is rejecting the request for some other reason - perhaps to do with board configuration or rules about which host ID can manage the A53 core I am trying to start. That logic is what I would like someone to explain, preferably with a suggestion for how to make the requests conform to what the system firmware will accept (e.g. by changing the board configuration).

0 Hong Guan64 3 months ago in reply to Ian Willats

TI__Guru 57645 points

https://software-dl.ti.com/tisci/esd/latest/2_tisci_msgs/security/PROC_BOOT.html#access-control-definition

"Access control is enforced via the Book keeping APIs. The basic definition of access is as follows:
We identify a requester (just like rest of TISCI) using Host ID (or plain Host).
By default, we permit all processors to be controlled by any other Host (no policing).
Board configuration provides: per PROC_ID, a limited list of “permitted host IDs” which are permitted to control a processor. BUT with the following conditions:
- Only one host can control a processor at a time
- A host(with control) can hand over control of a processor to another host in the permitted list.
- “recovery master” host id is identified in board cfg and this host can override the ownership already established."

Can we capture SYSFW trace log to check if the "TISCI_MSG_PROC_REQUEST" API call follows the above sequencing...

Best,
-Hong

0 Ian Willats 3 months ago in reply to Hong Guan64

Prodigy 240 points

Thank you Hong, that gives me something to work with...

0 Ian Willats 3 months ago in reply to Ian Willats

Prodigy 240 points

Hello Hong,

The board configuration in our system includes the secure A53 (host ID 10) in the permitted master list for the core I'm trying to start with the TISCI requests. However, the MCU firmware which initially has control over the A53 cores needs to explicitly hand over control of the "secondary" cores to the secure A53 (host ID 10). With that change in place, the TISCI processor management requests complete normally. That's consistent with what you described above although it took some time to find out where the hand-over needs to take place.

Thanks for your help; I think this thread can be closed now.

Processors

Processors forum

AM6548: TISCI processor boot management request fails from processor in TrustZone secure world