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
