Hi,
On Sun Aug 05, 2012 at 19:12:16 -0700, Andy Wagner wrote:
Many thanks for your response.
Yes, reading valid addresses from l4linux within the aips1 region hangs including CCM_CCR.
The fiasco kernel does have read access; Aips1[0]: 77777777 Aips1[1]: 77777777 MXC_CCM_CCR: 000016ff Aips1[0] and Aips1[1] contain the mprot fields for the 16 bus masters reachable via Aips1. The values 0x77777777 for both fields are set by u-boot (reset value according to imx53RM 0x0700000/0x00000000).
Additional information from the debugger <latter part of kc output>: Control Register: 00c5387d Auxiliary Control Register: 00000000 Coprocessor Access Control Reg: 00f00000 Secure Configuration Register: 00000000 Secure Debug Enable Register: 00000000 Non-Secure Access Control Reg: 00000000 Translation Table Base Reg 0: 7006c000 Translation Table Base Reg 1: 00000000 Translation Table Base Control Reg: 00000000 Domain Access Control Register: 00000001 Data Fault Status Register: 00001008 Instruction Fault Status Register: 00000007 Fault Address Register: 109d4000 Instruction Fault Address Register: a8008ddc
Interesting to note that the FAR contains the VA for the read that hangs. I'm not sure where the instruction lies -- it would be great if we were able to get at kallsyms at runtime to obtain symbol <entry point/function id>. Data fault status register suggests "precise external abort" if I'm interpreting the bitmap correctly according to ARM RM.
Are there any particular flags to the IO allocation request that should be used other than non-cacheable ?
I'd guess that access from user-mode is the 'problem' here. Could you check the setting of AIPSTZ_OPACR21 and possibly adapt accordingly?
Adam