> Hello,
>
> Based on the information at
>
> http://omappedia.org/wiki/Android_Debugging#OProfile_on_OMAP4
>
> it seems the Oprofile infrastructure is working fine on OMAP4/
> pandaboard in Android, but I can't seem to get it to cooperate
> in Angstrom and Ubuntu.
>
> I'm currently running with kernel-omap4-ti-2.6.35-omap4-L24.11-p5
> kernel, configured to enable Oprofile, and with the newest CVS
> Oprofile userland. I can successfully list the counters, can
> configure events, etc., but get no counter data. I'm fairly familiar
> with Oprofile, and have used it for getting counter information on
> Beagle-xM, and several other platforms.
>
> On pandaboard however, it seems Oprofile fails internally, since I
> see the following in syslog:
>
> hw perfevents: unable to reserve pmu
>
> It seems the PMU is not correctly getting configured in arch/arm/
> mach-
> omap2/devices.c, with no omap4 case for initializing the PMU in the
> kernel. (BTW, anyone know what the omap4 init is in mach-omap2?!!).
> I found a reference to similar questions in a discussion between 'mru'
> and 'robclark' on IRC:
>
> http://pandaboard.org/pbirclogs/index.php?date=2010-10-31
>
> Anyone have any ideas what the problem might be?
The cross-trigger interrupts need to be configured. Unfortunately,
the public TRM does not reveal how to do this.
--
Måns Rullgård
ma...@mansr.com
> The cross-trigger interrupts need to be configured. Unfortunately,
> the public TRM does not reveal how to do this.
I think necessary bits for GP-device are incorporated in patches referenced on wiki. Secure devices also need a debug firewall dropped.
After asking around it seems the actual routing matches the ARM examples which can be found in public ARM Coresight docs. I'll attach more info below which can speed up understanding + ARM docs.
From emulation designer:
------------------------
TI has done nothing special. It is exactly done per ARM specs and ARM specs are the ones to follow.
The PMUIRQ (CPU_0) is routed via CTI_0 TRIGIN[1] to CTI. This can be routed via any CTI channel (0..3) to TRIGOUT[6] which is the MA_IRQ_1 seen by GIC.
The PMUIRQ(CPU_1) is routed via CTI_1 TRIGIN[1]. This can be routed via any CTI channel (0..3) to TRIGOUT[6] which is the MA_IRQ_2 seen by GIC.
CTI0 (Cortex_A9_0) : Base address is 0x54148000 (App view)
CTI1 (Cortex-A9-1): Base address is 0x54149000 (App view)
Step:0 CTIx : unlock the module so application writes can go through (x = 0 and 1)
*(base + 0xFB0) = 0xC5ACCE55
Step 1: Use channel 2 on CTI0 to map TRIGIN[1] to TRIGOUT[6] (channel 2 is just an example by the way)
--- Enable TRIGIN[1] to go to channel 2
*(base + 0x024) |= (1 << 2)
--- Enable channel 2 to go to TRIGOUT[6]
*(base + 0B8) |= (1 << 2)
--- Global enable for CTIx module
*(base) = 0x1
This will cause the interrupt to be generated to the GIC - GIC will have to be configured per interrupt table in Chiron spec for the CTI0
Interrupt source.
To clear the interrupt in ISR;
Disable interrupt source in PMU (need to review PMU documentation in case this is needed)
Clear the interrupt in CTI (do a SW acknowledge)
*(base + 0x10) |= (1 << 6) // CTI Interrupt acknowledge register
Step 2: Use channel 3 on CTI1 to map TRIGIN[1] to TRIGOUT[6[ (channel 3 is just an example also)
Picking two different channels may avoid issues. Alternatively you could pick same channel and use CTIGATE register to prevent channel propagation from CTIx to CTM to CTIx+1 (x=0).
--- Enable TRIGIN[1] to go to channel 3
*(base + 0x024) |= (1 << 3)
-- Enable channel 3 to go to TRIGOUT[6]
*(base + 0x0B8) |= (1 << 3)
------------------------------------
Hope that clears it up some. I think this info was passed on to TRM team to supplement TI TRM.
Regards,
Richard W.
please let me know if you need the patch.
I have to come back to my desk to see the number. Please send updated number and I will dial in.
Vikas