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 soufian.elmajdoub@lauterbach.com johannes.boch@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 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
*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 http://www.96boards.org/forums/topic/dragonboard-not-working -after-failed-linux-instalation/#post-18901&gsc.tab=0
