i.MX53QSB port + IOmem access

Adam Lackorzynski 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[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 at os.inf.tu-dresden.de
  Lackorzynski         http://os.inf.tu-dresden.de/~adam/

More information about the l4-hackers mailing list