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>.
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 ?
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.
Any help is appreciated.
thanks in advance,
Andy