Hi,

Couple of comments below re the register and sync operations.

Regards

Mike

Mike Leach

Principal Engineer, ARM Ltd.

Blackburn Design Centre. UK

On 2 January 2017 at 22:52, Mathieu Poirier <mathieu.poirier@linaro.org> wrote:

Hello Nicolas,

Please see comments below.

On Mon, Jan 02, 2017 at 10:46:05AM +0000, Nicolas GUION wrote:
> Mathieu and all,
>
> Firstly happy new year 2017 to linaro coresight team.

Likewise.

>
> Coming back to this old mail, certainly you will be disappointed, but we used all coresight components as it is in the upstream kernel.
> and this "stub" tpiu driver was not an issue to evacuate the trace output.
>
> Saying this, I checked if our DTC (Lauterbach T32) was processing some specific complementary commands,
> and except the read to Peripherals/Components ID it makes some write actions to this 3 registers :
> -Current port size set to 4 lines (we uses 4 data lines)
>
> -Formatter Synchronization Counter every 1024B a synchronisation packet will be done (not sure if our TPIU implements really this cause for me there is the same setting in our STM coresight STMSYNCR )
>

The sync in the STM will insert a sync packet into the STM trace stream.

The TPIU formatter packages incoming multiple trace streams (including the STM stream) into 16 byte trace frames. The capture device needs to know where the start of the 16 byte frames are - this is the purpose of these syncs in the TPIU which are known a frame syncs.

Devices such as ETB and ETR - i.e. on chip memory buffering of trace do not require the frame syncs as the memory is guaranteed to by a multiple of 16 bytes and the frames will always be aligned to the start of the memory area.

Thus an external capture device will synchronise to the first frame sync and start capturing the data. On analysis the decoder will strip out the frame syncs and split the frames into individual trace streams - the STM trace stream will then be sent to an appropriate second stage decoder which will then sync to the first STM sync packet

in the stream at which point STM decode will start.

> -Formatter and Flush Control
> Write 0x1042
> Write 0x2
> Write 0x102

This sequence forces a manual flush onto the TPIU and trace sub-system. This ensures that any uncaptured trace left over from a previous session is cleared and tracing can begin.

> Furthermore in the same time, I've arrived to the same conclusion the DTC tool processes some write actions to STM coresight block.
> As the final objective will be to use a "passive" DTC tool (which just collect/analyse datas and not configure any hardware coresight components) I will ask more informations to lauterbach arm coresight people to know if this actions are really mandatory, and afterward we can enhance the tpiu/stm driver to do the only missing ones.
>

Excellent - at least now we know how things happen and there is no more mystery.
The ultimate goal is indeed to have external tools be concerned with the
collection and analysis of the trace data rather than configuring CS components.

>From what I read above it should relatively trivial to enhance the TPIU and STM
driver with code that imitates what the DTC tool does. I'm eager to see the
patches that comes out of that excercise.

Thanks for the follow-up,
Mathieu

>
> br
> Nicolas
>
>
>
>
>
>
>
>
> On 12/15/2016 05:57 PM, Mathieu Poirier wrote:
> Hello Nicolas and friends,
>
> In my exchange with Olivier, I was referring to the TPIU driver itself. The one currently in the upstream kernel tree is a stub that doesn't do anything. In my opinion there would be a lot of value in pushing that upstream. From there we can start thinking about off system decoding of the traces, whether using the method you guys have developed or the openCSD library.
>
> Thanks,
> Mathieu
>

> On 15 December 2016 at 00:09, Nicolas GUION <nicolas.guion@st.com<mailto:nicolas.guion@st.com>> wrote:
> Hi Mathieu,
>
>
> Olivier reported me that you would like to get the TPIU driver used for the dev described below.
> Certainly there is a misunderstanding cause for coresight components,
> we used all what have been pushed by linaro team in recent kernel.
>
> In order to clarify, here is a patch set of commits dedicated to this feature not coming from a 4.8 kernel cherry-pick. (stm_ftrace_SOC_Accordo5.tar)
>
> Build compability with our old kernel 4.1 :
> 0001-pb-build-with-new-macro-from-kernel-4.1.patch
>
> Insert the coresight components in our Accordo5 machine :
> 0002-ARM-DT-sta1295-add-tpiu-stm-arm-coresight.patch
> 0003-coresight-stm-add-sta1x95-amba-ID.patch
>
> Fix one deadlock in coresighy-stm driver :
> 0004-coresight-stm-fix-endless-loop.patch
>
> Skip printk level for kernel log traces for the STM console
> 0005-printk-console-type-PRINTBUFFER-skips-printk-level.patch
>
> FTRACE-STM patch set (lead by Chunyan)
> 0006-Integration-of-function-trace-with-System-Trace-IP-b.patch
> 0007-Integration-of-function-trace-with-System-Trace-IP-b.patch
> 0008-Integration-of-function-trace-with-System-Trace-IP-b.patch
>
> defconfig
> 0039-FTRACE_STM_coresight_enabling.patch
>
> Accorodo5 Custo patch in coresight STM due to wrong AXI implemation of STM IP in Accorodo5 SOC
> 0040-coresight-stm-A5-hw-issue-to-differenciate-mater-A7_.patch
>
> Feel free to ask more if not enough clear
>
>
> *Concerning the DTC/DTS (T32), if you want to have more details about this solution (capture and decoding) of different trace stream (printk like/multi master/multi-channel/linux FTRACE format and symbol matching), you can contact this 2 peoples :
>

> Soufian ELMAJDOUB <soufian.elmajdoub@lauterbach.com><mailto:soufian.elmajdoub@lauterbach.com>
> johannes.boch@lauterbach.com<mailto:johannes.boch@lauterbach.com> <johannes.boch@lauterbach.com><mailto:johannes.boch@lauterbach.com>
>
>
>
>
> br
> Nicolas
> On 12/08/2016 04:44 PM, Mathieu Poirier wrote:
>
>
> On 8 December 2016 at 02:04, Chunyan Zhang <zhang.chunyan@linaro.org<mailto:zhang.chunyan@linaro.org>> wrote:
>
> Hi Nicolas,
>
> On 8 December 2016 at 16:07, Nicolas GUION <nicolas.guion@st.com<mailto:nicolas.guion@st.com>> wrote:
> Chunyan,
>
> No problem and it offers me the opportunity to inform you that this last months in ST I worked on ARM coresight trace.
>
> Several month ago I contacted Mathieu about ARM STM coresight feature. Actually this year we started a new SOC project Accorod5, around A7ss and of course with integration of ARM coresight components. Mathieu described me the status in january, the next steps and especially added me in the group for all patch dedicated to this topic.
>
>
> So I followed the progression of the patch set delivery in official linux stream, and in october I started the integration of this topic in our BSP (based form 4.1)
> -update the both components (stm_class/coresight) of hwtracing from recent kernel in our old kernel.
> -integrate the on-going ftrace patch (it was the version 6)
>
> So happy to know you have been following the progress of this patch series, Steven Rostedt has included these for next merge window, it's supposed to be merged into 4.10.
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git<http://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.gitfor-next> for-next
>
> One difference with the Linaro usage that your team usually describes is the capture way, instead to use the target itself
> we configure the stm to tpiu directly (skip ETF path) and use an external probe to capture the trace (Lauterbach tool),
> (to cover a long trace session, get the trace for kernel crash/deadlock...)
>
> As an assignee from Spreadtrum, I believe that Spreadtrum also would need this functionality.
>
>
> Hello Nicolas,
>
> First and foremost congratulation on the very good integration work. I have been adamant on that point many times before and today won't be different - ST has really good tracing technology and knowledge. You guys have been working on this for a very long time and the results are there.
>
> Au plaisir,
> Mathieu
>
>
>
>
> Here is a view of the T32 output with 2 masters (Cortex A7 and Cortex M3), and 2 STM client for A7 part (Kernel log and FTRACE)
>
> That's amazing, but I haven't seen the snapshot you mentioned here :)
>
> this snaphot is not the last version, now the Timestamp are correctly handled and the differentiation between the both A7 CPUs has been deported on STMchannel due to a regression of our SOC
> (our SOC didn't implement correctly the AHB link between the both A7 master to STM, so I used the even channel for A7_0 and odd channel for A7_1, it was more or less the only modification from your patch)
>
>
> Thanks for sharing,
> Chunyan
>
> [cid:part8.9B4A1930.D27EB409@st.com]
>
>
> Great Job for all this coresight trace development!
>
>
> br
>
> Nicolas
>
>
>
> On 12/08/2016 08:30 AM, Chunyan Zhang wrote:
>
>
> On 8 December 2016 at 15:04, Nicolas GUION <<mailto:nicolas.guion@st.com>nicolas.guion@st.com<mailto:nicolas.guion@st.com>> wrote:
> Hi Chunyan,
>
> Are you sure that you pointed the correct Nicolas, cause I'm really far to know the Dragonboard 410c board?
>
> Ah, my mistake, thanks for telling me :)
>
> Chunyan
>
> I'm working in STMicroelectronics and not usual with other boards than ST ones.
>
> br
> Nicolas
>
>
> On 12/08/2016 07:24 AM, Chunyan Zhang wrote:
> Hi Nicolas,
>
> I noticed on 96boards forum, some person reported a similar problem "Dragonboard not working after failed linux instalation" [1] which has been annoying me recently.
>
> I posted some details on that page the day before yesterday. Could you give me some suggestion on how to retrieve my Dragon board?
>
> Many thanks,
> Chunyan
>
>
> [1] <http://www.96boards.org/forums/topic/dragonboard-not-working-after-failed-linux-instalation/#post-18901&gsc.tab=0> <http://www.96boards.org/forums> http://www.96boards.org/forums/topic/dragonboard-not-working-after-failed-linux-instalation/#post-18901&gsc.tab=0
>
>
>
>
>
>
>
>

_______________________________________________
CoreSight mailing list
CoreSight@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/coresight