We are looking for console options( output only) for the SCP(system control processor)cores in our SOC other than UART and was considering STM as an option.

Something like this,

SCP ----> STM ---> ETR ---> DDR <--- Linux

On the Linux system, some user space scripts can retrieve the ETR trace buffers and move it to a file on a periodic basis.

Do you see any basic issue with this approach or have better alternatives to suggest ?

It's an option, although an alternative for a Cortex-M SCP would be ITM. And whether you use ITM or STM, you could have a replicator immediately downstream of the trace source, routing to an alternative trace sink like an ETB or external trace port, as an alternative to ETR.

Few issues we could think of,

1. SCP wont be able to route the messages to the STM -> ETR path until those

are initialized by the Linux user space. Hence any messages until Linux comes up need to be buffered in the SCP local memory and should get flushed once the STM

• ETR path is ready.

Or if there was a dedicated ETB, they could be buffered there, and retrieved from Linux once it's booted. You could even have a second ETR, and have the SCP program that one for boot-time messages, and then switch to the one that Linux manages.

2. Possible message loss due to buffer overwrite We might have to reserve the

ETR trace buffers only to the SCP and keep sufficiently large buffers to reduce the message loss.

That's always a risk if the SCP is competing with other (much higher bandwidth) trace sources. If they are separate trace sources (like CPU ETE, or ELA-600) then maybe they could be routed to a different ETR, but if they are other users of the same STM then they'll be going to the same trace sink as the SCP messages, and if they are much higher bandwidth they might overwrite the SCP messages.

You'd probably also need to decide if SCP would use "guaranteed" or "invariant timing" STM stimulus ports. If you use "invariant timing" then you risk losing messages (or random fragments of messages) from backpressure in the ATB network; if you use "guaranteed" then a problem with ATB might end up stalling the SCP (i.e. the AXI write might hang), and that could be a serious problem. With ITM on the other hand, software can poll the ITM FIFO state and only write messages if the FIFO is non-full, so it might be unable to write messages, but it won't stall.

Assume that reserving a STM port for use by an external core can be achieved from the Linux STM sysfs interface.

STM already partitions the STP channel space between Secure and Non-Secure, so if the writes from the SCP are Secure, they will be distinct from Non-Secure STM writes from kernel or userspace.

If you want to reserve STM channels for Non-Secure writes from other cores, you might want to do that by partitioning the software stimulus space and only describing part of it to Linux - rather than describing the whole of it to Linux and relying on using sysfs to manage channels.

Al

Thanks, Linu Cherian. _______________________________________________ CoreSight mailing list -- coresight@lists.linaro.org To unsubscribe send an email to coresight-leave@lists.linaro.org