Re: i.MX53QSB port + IOmem access
Adam Lackorzynski <[email protected]>
| Newsgroups | gmane.comp.micro-kernel.l4.devel |
|---|---|
| Message-ID | <[email protected]> |
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 -- Adam [email protected] Lackorzynski http://os.inf.tu-dresden.de/~adam/