Profling on arm Cortex_A8

I want to do profiling for my application on ARM processor. I found the oprofile doesn't work. Someone used the following code to test a few years ago. the cyclic counter does work, the performance monitor counter still doesn't work. I tested it again, it is same. For following code, I got cycle count: 2109, performance monitor count: 0. I have searched by google, so far, I have not found a solution. Has someone fixed this issue?

    uint32_t value = 0
    uint32_t count = 0;
    struct timeval tv;
    struct timezone tz;

    // enable all counters
    __asm__ __volatile__ ("mcr p15, 0, %0, c9, c12, 1" ::"r" (0x8000000f));

    // select counter 0,
    __asm__ __volatile__("mcr p15, 0, %0, c9, c12, 5" ::"r" (0x0));
    // select event
    __asm__ __volatile__ ("mcr p15, 0, %0, c9, c13, 1" ::"r"(0x57));

    // reset all counters to ero and enable all counters
    __asm__ __volatile__ ("mrc p15, 0, %0, c9, c12, 0" : "=r" (value));
    value |= 0xF;
    __asm__ __volatile__ ("mcr p15, 0, %0, c9, c12, 0" :: "r" (value));

    gettimeofday(&tv, &tz);

    __asm__ __volatile__("mrc p15, 0, %0, c9, c13, 0" : "=r" (count));
    printf("cycle count: %d", count);

    __asm__ __volatile__ ("mrc P15, 0, %0, c9, c13, 2": "=r" (count));
    printf("performance monitor count: %d", count);

I just ran into the same issue, and in my case it was due to the NIDENm signal being pulled low.

From the ARM documentation:

The PMU only counts events when non-invasive debug is enabled, that is, when either DBGENm or NIDENm inputs are asserted. The Cycle Count (PMCCNTR) Register is always enabled regardless of whether non-invasive debug is enabled, unless the DP bit of the PMCR register is set.

That NIDENm signal is an input to the ARM core, so exactly how it is controlled will depend on the parts of the processor external to the core. In my case, I found a register controlling NIDEN. In your case, it may be a register, or a pin, or (possibly) the signal is just pulled low and you can't use the feature.

Also from the ARM documentation:

The values of the DBGENm and NIDENm signals can be determined by polling DBGDSCR[17:16], DBGDSCR[15:14], or the DBGAUTHSTATUS.

So, if you can read one of those, you can confirm that the problem is NIDENm.