i.MX53QSB port + IOmem access
adam at os.inf.tu-dresden.de
Mon Aug 6 21:27:51 CEST 2012
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
> The fiasco kernel does have read access;
> Aips1: 77777777
> Aips1: 77777777
> MXC_CCM_CCR: 000016ff
> Aips1 and Aips1 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 at os.inf.tu-dresden.de
More information about the l4-hackers