From: Jeffrey E. <jea...@al...> - 2013-04-01 18:26:23
|
Hi All, I am trying to get the ARM CA9 PMU working with the Linux kernel (version 3.7.0) I have the PMU partially setup by adding the PMU to the device tree with the core sight interrupt numbers. I see access to the PMU registers with oprofile via DS-5 (ARM debugger) when I run some code to profile such as a benchmark. However, I still can't get sample data back. The PMU interrupt numbers below in the device tree snippet are the CoreSight interrupts, however when I check the General Interrupt Controller (GIC registers) to see if the interrupts are enabled it shows that they are not (all zeros). I now realize that I need to setup the Cross-Trigger-Interface (CTI) and Cross Trigger Module/Matrix (CTM) to get the interrupts working with the GIC. I am seeing some great community support for ARM/Oprofile that wasn't there a few years ago. So I was wondering if there was easier way to configure the kernel code to enable the CTI/CTM? I saw some device tree mapping in ARM's versatile express kernel pushes that may suggest that there is an easy way to map CTI/CTM to the GIC? Thanks for your time and help. Jeff ________________________________ Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. |
From: Maynard J. <may...@us...> - 2013-04-02 20:02:03
|
On 04/01/2013 01:11 PM, Jeffrey Eastlack wrote: > Hi All, > > > > I am trying to get the ARM CA9 PMU working with the Linux kernel (version 3.7.0) I have the PMU partially setup by adding the PMU to the device tree with the core sight interrupt numbers. I see access to the PMU registers with oprofile via DS-5 (ARM debugger) when I run some code to profile such as a benchmark. > > > > However, I still can't get sample data back. The PMU interrupt numbers below in the device tree snippet are the CoreSight interrupts, > > however when I check the General Interrupt Controller (GIC registers) to see if the interrupts are enabled it shows that they are not (all zeros). > > > > I now realize that I need to setup the Cross-Trigger-Interface (CTI) and Cross Trigger Module/Matrix (CTM) to get the interrupts working with the GIC. > > > > I am seeing some great community support for ARM/Oprofile that wasn’t there a few years ago. So I was wondering if there was easier way to configure the kernel code to enable the CTI/CTM? I saw some device tree mapping in ARM’s versatile express kernel pushes that may suggest that there is an easy way to map CTI/CTM to the GIC? > > > > Thanks for your time and help. *Will*, this is all Greek to me. Can you provide any help to Jeff? -Maynard > > > > Jeff > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------! --- > Confidentiality Notice. > This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. > > > ------------------------------------------------------------------------------ > Own the Future-Intel® Level Up Game Demo Contest 2013 > Rise to greatness in Intel's independent game demo contest. > Compete for recognition, cash, and the chance to get your game > on Steam. $5K grand prize plus 10 genre and skill prizes. > Submit your demo by 6/6/13. http://p.sf.net/sfu/intel_levelupd2d > > > > _______________________________________________ > oprofile-list mailing list > opr...@li... > https://lists.sourceforge.net/lists/listinfo/oprofile-list |
From: Will D. <wil...@ar...> - 2013-04-03 11:34:24
|
Hello, On Tue, Apr 02, 2013 at 09:01:47PM +0100, Maynard Johnson wrote: > On 04/01/2013 01:11 PM, Jeffrey Eastlack wrote: > > I am trying to get the ARM CA9 PMU working with the Linux kernel (version 3.7.0) I have the PMU partially setup by adding the PMU to the device tree with the core sight interrupt numbers. I see access to the PMU registers with oprofile via DS-5 (ARM debugger) when I run some code to profile such as a benchmark. > > > > > > > > However, I still can't get sample data back. The PMU interrupt numbers below in the device tree snippet are the CoreSight interrupts, > > > > however when I check the General Interrupt Controller (GIC registers) to see if the interrupts are enabled it shows that they are not (all zeros). > > > > > > > > I now realize that I need to setup the Cross-Trigger-Interface (CTI) and Cross Trigger Module/Matrix (CTM) to get the interrupts working with the GIC. > > > > > > > > I am seeing some great community support for ARM/Oprofile that wasn’t there a few years ago. So I was wondering if there was easier way to configure the kernel code to enable the CTI/CTM? I saw some device tree mapping in ARM’s versatile express kernel pushes that may suggest that there is an easy way to map CTI/CTM to the GIC? > > > > > > > > Thanks for your time and help. > *Will*, this is all Greek to me. Can you provide any help to Jeff? Unfortunately, configuring the PMU interrupts over CTI is really platform-specific, so I can't offer any insight here. Jeff: are you using an OMAP4 board by any chance? If so, I think people *did* get the PMU working there, and I can loop in some of the OMAP guys if it helps... Will |
From: Jeffrey E. <jea...@al...> - 2013-04-03 17:48:59
|
Hi Will / Maynard, Thanks for your comments, I ended up finding some stuff out there on the kernel mailing list and much of it looked to be from TI engineers. We got this working with Altera's 2XCA9 SoC-FPGA. The hard part (for me anyway) was figuring out the coupling between the PMU and CoreSight blocks, they are intertwined and share the same interrupt number. Another issue was mapping the interrupt through CTI/CTM module. I think the procedure should be standard if the implementer follows ARM's guidelines regarding how they hardwire said blocks. The differences should be in 1) CoreSight interrupt numbers that are hardwired to the GIC and 2) The base addresses of the CTI blocks which map the PMU interrupts to the GIC. For 1) we defined the CoreSIght interrupts in the device tree blob, and 2) found the two CTI base addresses in our memory map so that we can setup the cross trigger channels, etc in /arch/arm/mach-socfpga/socfpga.c. I found some good information here: https://groups.google.com/forum/?fromgroups=#!searchin/pandaboard/oprofile$20pmu/pandaboard/dKv12vov1uI/lZ-9h-Ydk1QJ One thing that I didn't see in this link was implementing an interrupt acknowledge to the PMU. Without it the PMU will continuously fire interrupts and overflow the GIC to where the kernel disables the interrupt numbers and I think it was even disabling the CLI blocks. You can add this via a helper function in cti.h. Thanks for your response, Jeff -----Original Message----- From: Will Deacon [mailto:wil...@ar...] Sent: Wednesday, April 03, 2013 6:34 AM To: Maynard Johnson Cc: Jeffrey Eastlack; 'opr...@li...' Subject: Re: Oprofile - ARM Cortex-A9 Woes Hello, On Tue, Apr 02, 2013 at 09:01:47PM +0100, Maynard Johnson wrote: > On 04/01/2013 01:11 PM, Jeffrey Eastlack wrote: > > I am trying to get the ARM CA9 PMU working with the Linux kernel (version 3.7.0) I have the PMU partially setup by adding the PMU to the device tree with the core sight interrupt numbers. I see access to the PMU registers with oprofile via DS-5 (ARM debugger) when I run some code to profile such as a benchmark. > > > > > > > > However, I still can't get sample data back. The PMU interrupt > > numbers below in the device tree snippet are the CoreSight > > interrupts, > > > > however when I check the General Interrupt Controller (GIC registers) to see if the interrupts are enabled it shows that they are not (all zeros). > > > > > > > > I now realize that I need to setup the Cross-Trigger-Interface (CTI) and Cross Trigger Module/Matrix (CTM) to get the interrupts working with the GIC. > > > > > > > > I am seeing some great community support for ARM/Oprofile that wasn’t there a few years ago. So I was wondering if there was easier way to configure the kernel code to enable the CTI/CTM? I saw some device tree mapping in ARM’s versatile express kernel pushes that may suggest that there is an easy way to map CTI/CTM to the GIC? > > > > > > > > Thanks for your time and help. > *Will*, this is all Greek to me. Can you provide any help to Jeff? Unfortunately, configuring the PMU interrupts over CTI is really platform-specific, so I can't offer any insight here. Jeff: are you using an OMAP4 board by any chance? If so, I think people *did* get the PMU working there, and I can loop in some of the OMAP guys if it helps... Will Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. |
From: Jeffrey E. <jea...@al...> - 2013-04-08 19:23:24
|
Hi Will, Do you know if anyone has ever accessed the L2 performance counters on a Cortex-A9? The events that are counted by the PMU are CA9 specific and the L2 are not considered to be a part of the CA9 core. I think most CA9 vendors use ARM's "Corelink L2 Cache controller L2C-310" on the CA9 which as the following events available in an internal monitoring unit. Thanks, Jeff CO Eviction, CastOUT, of a line from the L2 cache. DRHIT Data read hit in the L2 cache. DRREQ Data read lookup to the L2 cache. Subsequently results in a hit or miss. DWHIT Data write hit in the L2 cache. DWREQ Data write lookup to the L2 cache. Subsequently results in a hit or miss. DWTREQ Data write lookup to the L2 cache with Write-Through attribute. Subsequently results in a hit or miss. EPFALLOC Prefetch hint allocated into the L2 cache. EPFHIT Prefetch hint hits in the L2 cache. EPFRCVDS0 Prefetch hint received by slave port S0. EPFRCVDS1 Prefetch hint received by slave port S1. IPFALLOC Allocation of a prefetch generated by L2C-310 into the L2 cache. IRHIT Instruction read hit in the L2 cache. IRREQ Instruction read lookup to the L2 cache. Subsequently results in a hit or miss. SPNIDEN Secure privileged non-invasive debug enable. SRCONFS0 Speculative read confirmed in slave port S0. SRCONFS1 Speculative read confirmed in slave port S1. SRRCVDS0 Speculative read received by slave port S0. SRRCVDS1 Speculative read received by slave port S1. WA Allocation into the L2 cache caused by a write, with Write-Allocate attribute, miss. -----Original Message----- From: Jeffrey Eastlack Sent: Wednesday, April 03, 2013 12:34 PM To: Will Deacon; Maynard Johnson Cc: 'opr...@li...' Subject: RE: Oprofile - ARM Cortex-A9 Woes Hi Will / Maynard, Thanks for your comments, I ended up finding some stuff out there on the kernel mailing list and much of it looked to be from TI engineers. We got this working with Altera's 2XCA9 SoC-FPGA. The hard part (for me anyway) was figuring out the coupling between the PMU and CoreSight blocks, they are intertwined and share the same interrupt number. Another issue was mapping the interrupt through CTI/CTM module. I think the procedure should be standard if the implementer follows ARM's guidelines regarding how they hardwire said blocks. The differences should be in 1) CoreSight interrupt numbers that are hardwired to the GIC and 2) The base addresses of the CTI blocks which map the PMU interrupts to the GIC. For 1) we defined the CoreSIght interrupts in the device tree blob, and 2) found the two CTI base addresses in our memory map so that we can setup the cross trigger channels, etc in /arch/arm/mach-socfpga/socfpga.c. I found some good information here: https://groups.google.com/forum/?fromgroups=#!searchin/pandaboard/oprofile$20pmu/pandaboard/dKv12vov1uI/lZ-9h-Ydk1QJ One thing that I didn't see in this link was implementing an interrupt acknowledge to the PMU. Without it the PMU will continuously fire interrupts and overflow the GIC to where the kernel disables the interrupt numbers and I think it was even disabling the CLI blocks. You can add this via a helper function in cti.h. Thanks for your response, Jeff -----Original Message----- From: Will Deacon [mailto:wil...@ar...] Sent: Wednesday, April 03, 2013 6:34 AM To: Maynard Johnson Cc: Jeffrey Eastlack; 'opr...@li...' Subject: Re: Oprofile - ARM Cortex-A9 Woes Hello, On Tue, Apr 02, 2013 at 09:01:47PM +0100, Maynard Johnson wrote: > On 04/01/2013 01:11 PM, Jeffrey Eastlack wrote: > > I am trying to get the ARM CA9 PMU working with the Linux kernel (version 3.7.0) I have the PMU partially setup by adding the PMU to the device tree with the core sight interrupt numbers. I see access to the PMU registers with oprofile via DS-5 (ARM debugger) when I run some code to profile such as a benchmark. > > > > > > > > However, I still can't get sample data back. The PMU interrupt > > numbers below in the device tree snippet are the CoreSight > > interrupts, > > > > however when I check the General Interrupt Controller (GIC registers) to see if the interrupts are enabled it shows that they are not (all zeros). > > > > > > > > I now realize that I need to setup the Cross-Trigger-Interface (CTI) and Cross Trigger Module/Matrix (CTM) to get the interrupts working with the GIC. > > > > > > > > I am seeing some great community support for ARM/Oprofile that wasn’t there a few years ago. So I was wondering if there was easier way to configure the kernel code to enable the CTI/CTM? I saw some device tree mapping in ARM’s versatile express kernel pushes that may suggest that there is an easy way to map CTI/CTM to the GIC? > > > > > > > > Thanks for your time and help. > *Will*, this is all Greek to me. Can you provide any help to Jeff? Unfortunately, configuring the PMU interrupts over CTI is really platform-specific, so I can't offer any insight here. Jeff: are you using an OMAP4 board by any chance? If so, I think people *did* get the PMU working there, and I can loop in some of the OMAP guys if it helps... Will Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. ------------------------------------------------------------------------------ Minimize network downtime and maximize team effectiveness. Reduce network management and security costs.Learn how to hire the most talented Cisco Certified professionals. Visit the Employer Resources Portal http://www.cisco.com/web/learning/employer_resources/index.html _______________________________________________ oprofile-list mailing list opr...@li... https://lists.sourceforge.net/lists/listinfo/oprofile-list Confidentiality Notice. This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments, is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you. |
From: MohammadSadegh S. <mam...@ho...> - 2013-04-08 21:29:18
|
Hi Jeff,I access the L2 performance counters on my Cortex-A9 system. however, not with oprofile. On my ARM A9 MPCore system , I run oprofile with a separate driver which I have developed myself in parallel. The driver is responsible for configuring the PL310 L2 Cache Controller Performance Monitoring unit and enabling required events and reading back their values. As of the tests I performed, there is no event (in the list of events that oprofile shows "opcontrol --list-events") to count accesses to L2. Regards. > From: jea...@al... > To: wil...@ar...; may...@us... > Date: Mon, 8 Apr 2013 12:08:01 -0700 > Subject: RE: Oprofile - ARM Cortex-A9 Woes > CC: opr...@li... > > Hi Will, > > Do you know if anyone has ever accessed the L2 performance counters on a Cortex-A9? The events that are counted by the PMU are CA9 specific and the L2 are not considered to be a part of the CA9 core. I think most CA9 vendors use ARM's "Corelink L2 Cache controller L2C-310" on the CA9 which as the following events available in an internal monitoring unit. > > Thanks, > > Jeff > > > CO Eviction, CastOUT, of a line from the L2 cache. > DRHIT Data read hit in the L2 cache. > DRREQ Data read lookup to the L2 cache. Subsequently results in a hit or miss. > DWHIT Data write hit in the L2 cache. > DWREQ Data write lookup to the L2 cache. Subsequently results in a hit or miss. > DWTREQ Data write lookup to the L2 cache with Write-Through attribute. Subsequently results in a hit or miss. > EPFALLOC Prefetch hint allocated into the L2 cache. > EPFHIT Prefetch hint hits in the L2 cache. > EPFRCVDS0 Prefetch hint received by slave port S0. > EPFRCVDS1 Prefetch hint received by slave port S1. > IPFALLOC Allocation of a prefetch generated by L2C-310 into the L2 cache. > IRHIT Instruction read hit in the L2 cache. > IRREQ Instruction read lookup to the L2 cache. Subsequently results in a hit or miss. > SPNIDEN Secure privileged non-invasive debug enable. > SRCONFS0 Speculative read confirmed in slave port S0. > SRCONFS1 Speculative read confirmed in slave port S1. > SRRCVDS0 Speculative read received by slave port S0. > SRRCVDS1 Speculative read received by slave port S1. > WA Allocation into the L2 cache caused by a write, with Write-Allocate attribute, miss. > > |
From: Will D. <wil...@ar...> - 2013-04-09 08:11:31
|
On Mon, Apr 08, 2013 at 08:08:01PM +0100, Jeffrey Eastlack wrote: > Hi Will, Hi Jeff, > Do you know if anyone has ever accessed the L2 performance counters on a Cortex-A9? The events that are counted by the PMU are CA9 specific and the L2 are not considered to be a part of the CA9 core. I think most CA9 vendors use ARM's "Corelink L2 Cache controller L2C-310" on the CA9 which as the following events available in an internal monitoring unit. Mark [CC'd] did some work on this a while back, but the patches really need rebasing/reworking before they can be considered for mainline: https://git.kernel.org/cgit/linux/kernel/git/will/linux.git/log/?h=perf/l2x0 It would also only interface to perf, afaict. Will |