Data Abort MMU exception on mapped IO register read
robjsstewart at ...196...
Mon Apr 13 14:41:41 CEST 2015
I'm running with 15.02, base-hw on a TI AM3359 processor. I've
successfully created device drivers for most of the devices on the
peripheral bus without issue. Accessing the the final device i need a
driver for, is causing me fits.
I attached the IO device register space with the usual creation of a
Attached_io_mem_dataspace based object which also uses the very useful
MMIO utility object. I also tried it without MMIO and just accessed the
space through local_addr<void>.
When I try to read an address in the mapped space I get an "unknown MMU
exception". When I write to the same address no error occurs (I'm
assuming for now it's failing silently). Putting PDBG's in the arm
thread code shows that the error on the read is is being caused by a
DATAT_ABORT. Peeking at the data fault status register (dfsr) shows
0x805 which according the the the ARM7 technical reference manual
decodes to a translation table error.
The virtual address created when the io device is mapped is 0x81B0_0000
(the load_addr<void>), but I see no section table entry being created
for 0x8100_0000. Only one is created at 0x8000_0000. If I'm remembering
correctly sections are 16 MB is size for this architecture. I'm
instrumenting short_translation_table.h to see what translation table
entries are being created. I also don't seen any short translation table
entries being created in the 0x81bxx_xxxx region.
My platform support code does include the physical address and size for
the region containing the device I'm trying to access.
The only physical difference with this device and the others I've
successfully created drivers for, is that is runs of the L4
interconnection whereas the others were on the L3 interconnect. In this
SoC the L4 is bridged to the L3 interconnect and runs at half the speed
of the L3 bus. But I doubt that this would make any difference to the
mapping of the device. This device is also much higher in memory that
the other devices.
Any hints at further debugging of this issue would be greatly appreciated.
More information about the users