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
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.commailto:soufian.elmajdoub@lauterbach.com johannes.boch@lauterbach.commailto:johannes.boch@lauterbach.com johannes.boch@lauterbach.commailto: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.orgmailto:zhang.chunyan@linaro.org> wrote:
Hi Nicolas,
On 8 December 2016 at 16:07, Nicolas GUION <nicolas.guion@st.commailto: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.githttp://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:part4.8F114497.75B08DAF@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 <nicolas.guion@st.commailto: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-li...
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
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.commailto: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.commailto:soufian.elmajdoub@lauterbach.com johannes.boch@lauterbach.commailto:johannes.boch@lauterbach.com johannes.boch@lauterbach.commailto: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.orgmailto:zhang.chunyan@linaro.org> wrote:
Hi Nicolas,
On 8 December 2016 at 16:07, Nicolas GUION <nicolas.guion@st.commailto: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.githttp://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.comnicolas.guion@st.commailto: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-li...
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 )
-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.
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.commailto: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.commailto:soufian.elmajdoub@lauterbach.com johannes.boch@lauterbach.commailto:johannes.boch@lauterbach.com johannes.boch@lauterbach.commailto: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.orgmailto:zhang.chunyan@linaro.org> wrote:
Hi Nicolas,
On 8 December 2016 at 16:07, Nicolas GUION <nicolas.guion@st.commailto: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.githttp://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.comnicolas.guion@st.commailto: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-li...
Hi,
Couple of comments below re the register and sync operations.
Regards
Mike
-
Mathieu Poirier -
Mike Leach -
Nicolas GUION