i.MX53QSB port + IOmem access

[Andy Wagner]

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 ?

thanks,
   Andy

On Fri Aug 03, 2012 at 19:22:24 -0700, Andy Wagner wrote:
 > We have a minimal fiasco/l4re/l4linux port running on Freescale i.MX53QSB.
 > Uart (console), tzic, epit and wdog appear to be working.
 >
 > We are now proceeding to port migrate some native drivers (eg., FEC) for QSB into
 > l4linux.
 >
 > We have run into an issue with access to IO regions:
 > - aips1 region is defined in IO map and virtual to physical mappings are handled via callback in mach_setup <similar to dmamem_cb>.
 > - virtual memory is apparently being assigned.
 > We have attempted IO with varying size map/requests down to 4k page. Results are similar
 > regardless of size of requested region.
 >
 > Attempt to read from IO region at  assigned virtual location causes the kernel to hang.
 > Escaping to debugger <esc> and checking both virtual and physical address for IO area reveal same contents -- which suggests that the mapping exists.
 >
 > The question is why does the kernel hang ?
 >
 > Part of boot log below:
 > Calling predefined callback for device 'aips1'.
 > IO      | new iomem region: p=53c00000 v=c00000 s=400000 (bmb=0x3650)
 > IO      | map mem: p=53f00000 v=f00000 s=100000: done
 > aips1 mem phys at 53f00000 - 53ffffff
 > aips1 mem virt at 08500000 - 085fffff
 > Added static device 'aips2' with 1 resources.
 > Calling predefined callback for device 'dmamem'.
 > DMA mem phys at 703be000 - 70bbdfff
 > DMA mem virt at 10900000 - 110fffff
 > dmamem_cb: dma_alloc_coherent: va: 10900000 phys: 703be000
 > init_l4: about to read(va): 085d4018
 >
 > VA 85d4018/53fd4018 is CCM_CBCMR <a clock control register, several of
 > which need to be set up by initialisation code in order to bring up
 > devices such as FEC>.

I supposed that reading any other register such as CCM_CCR also hangs?
Does access to this area works from within the kernel?

 > We have confirmed that writes/read for dmamem virtual addresses appear
 > in physical equivalent.
 >
 > l4linux is configured as arm7; fiasco as cortex/a8.
 >
 > The entire aips1 region has been mapped by fiasco as well -- because
 > fiasco only maps 1M segments and requires access to aips1 <etc> in
 > order to have uart, clock, tzic. Does fiasco page create a conflict
 > for IO ?

No, that's not a problem.

 > We also tried to map physical memory transparently to native imx53
 > layout using create_mapping(). Access via mappings established this
 > way result in unresolved page faults. Drivers and IO maps will not
 > port without significant hassle unless we are able to specify
 > virt/phys mappings.
 >
 > Behaviour of the kernel suggests that page faults are not being handled.

You mean the Linux original virtual addresses? Those are above 3G and
thus this cannot work. So the figures would have to be changed anyway.
create_mapping also will not create an L4 mapping. Specifying a virtual
address will work with l4io_request_iomem_region().



Adam
-- 
Adam                 adam at os.inf.tu-dresden.de
   Lackorzynski         http://os.inf.tu-dresden.de/~adam/