Am437x L2 cache performance issue running QNX

Hi,

This forum only supports Linux. I will forward this post to the factory experts in case they are able to offer some tips what might be the reason for this behavior.

Hi Datis
Can you do a more comprehensive compare of the A9 and PL310 registers? Perhaps you are still missing some A9/cache configuration beyond the registers you have listed?

Regards
Mukul

Hi Mukul, 

I have looked at all the registers listed on the Table 3-2 (offset 000 - 0xF80) of the "AMBA Level 2 Cache Controller (L2C-310) Revision: r3p1" TRM. The other registers were not set. 

Please let me know if you have a particular set I should check. 

Thanks,
Datis

Datis, you may want to check if you cache policies in your MMU table are setup the same way between both OSes. this can have a big impact on how the cache operates

regards,
James

JJD said:

Datis, you may want to check if you cache policies in your MMU table are setup the same way between both OSes. this can have a big impact on how the cache operates

regards,
James

Thanks James, we checked the startup code and for am437x we use our standard Cortex-A9 cache policy. A typical cacheable memory mapping would be cacheable, bufferable, and the TEX bits would 0x1, i.e. write-back/write-allocate + shared. That said I can add some debug in our kernel code to dump the pte bits to be 100% sure.

Actually the ARM & cache initialization for am437x is almost identical to the init for similar SOCs that also use Cortex-A9 MPCore + PL310 cache. The only difference I can see is that for am437x (and other TI SOCs) we never write to the CP15 Auxiliary Control register so we can't enable certain errata fixes like disabling prefetching.

Do you guys support a smc instruction to allow writes to the CP15 Auxiliary Control register? If so could you share some details or a Linux example?

Also is there anything else you can think of that would make am437x unique w.r.t ARM & cache init?

Thanks!

Mark

* EDIT * - we also have some custom L2 cache init for am437x which uses the smc instruction but as Datis mentioned earlier we read the L2 cache registers at runtime on QNX and Linux and all the values were the same.

Yes, there are smc instructions. Take a look at the initialization chapter. There is a section on Services for HLOS Support.

Steve K.

Hi Steve,

Thanks for the info.

We found that the CP15 ACTLR register coherency mode (bit [6] -- SMP) (Section 4.3.10 Auxiliary Control Register on the Cortex™-A9 Revision: r4p1 TRM) has to be set.

However, looking at TI code we are not sure how this is being set, could you please confirm if this is done on the boot ROM? Or point out the code section that enables this bit?

Thanks,
Datis  

One more question: 

Could you please confirm how the A9 erratas are applied? Would this has to be done thorough the secure call (smc) as well? 

As an example in the linux code I can see: 

(processor-sdk-linux/arch/arm/mm/proc-v7.S):

#ifdef CONFIG_ARM_ERRATA_742230

        cmp     r6, #0x22                       @ only present up to r2p2

        mrcle   p15, 0, r10, c15, c0, 1         @ read diagnostic register

        orrle   r10, r10, #1 << 4               @ set bit #4

        mcrle   p15, 0, r10, c15, c0, 1         @ write diagnostic register

But applying the same would freeze the board.  

Thanks & Regards,
Datis

Hi Steve, 

Any updates? 

I have one more question ;) 

Would you be able to please confirm the following errata apply to the AM437x (particularly, rev. MPCore r2p10):

From ARM® Cortex™ -A9 processors r2 releases Software Developers Errata Notice doc:

 

ID: 845369 – Under very rare timing circumstances, transitioning into streaming mode might create a data corruption (configurations affected: One processor if the ACP is present)

*Note: Checking the ARM437x TRM section: 3.3.1.7 Configuration Options: Accelerator Coherency Port (ACP) is included)

 

The problem we have is that we cannot access the Diagnostic register to set the errata workaround (due to no dedicated diagnostic control register).

TRM section 5.2.11 Services for HLOS Support – API (pg. 236) states: 

“This Cortex core restricts accesses to few ARM coprocessor registers to the secure mode only.

The services include:

• L2 cache set debug register

• L2 cache clean and invalidate range of physical address

• L2 cache set control register

• L2 cache set auxiliary control

• L2 cache get control

• L2 cache set latency”

 

The other erratas already implemented in our code don’t seem to affect the one processor configuration board we have: 

 

ID: 794072 – A short loop including a DMB instruction might cause a denial of service on another
processor which executes a CP15 broadcast operation (Configurations affected: MPCore processors with two or more processors.)
ID: 751472 - An interrupted ICIALLUIS operation might prevent the completion of a following broadcast operation (Configurations affected: configuration with two or more processors.)

ID: 743622 - Faulty logic in the Store Buffer might cause data corruption (Configurations affected: All r2 revisions)
*Note: Already implemented work around (setting bit 6 in boot ROM).

 

Thanks & Regards,
Datis

Datis, you should be able to search the kernel for each errata ID number to determine if a workaround was implemented and/or if each workaround is being used. If the ID cannot be found, then the errata is not addressed in the kernel.

Regards,
James