Mathieu and all,

Firstly happy new year 2017 to linaro coresight team.

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 )

-Formatter and Flush Control
Write 0x1042
Write 0x2
Write 0x102
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.


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> 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>
johannes.boch@lauterbach.com <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> wrote:

Hi Nicolas,

On 8 December 2016 at 16:07, Nicolas GUION <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  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


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 <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