Possibility of using Coresight STM - ETR as console for System Control Processor

[Al Grant]

> 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 at lists.linaro.org To unsubscribe send an email to
> coresight-leave at lists.linaro.org