Data Abort MMU exception on mapped IO register read
robjsstewart at ...196...
Tue Apr 14 13:56:57 CEST 2015
Thanks for the reply, Stefan. You were correct, I was grabbing the Dfsr
after the MMU message. Your patch produced the following:
unknown MMU exception (data-abort) DFSR=1008 IFSR=7 DFAR=8b000000
So it looks like its an external issue related to access on the L4 bus
to this particular peripheral.
There is little documentation on the L3/L4 interconnections in the TRM
for this processor, so I'll ask the Sitara community, which is generally
not very helpful.
Thank you very much for your help.
On 04/14/2015 07:27 AM, Stefan Kalkowski wrote:
> Hi Bob,
> On 04/13/2015 02:41 PM, Bob Stewart wrote:
>> 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.
> What make me wonder is that a DFSR value of 0x805, which means as you
> already stated a first-level translation fault, should never end in a
> "unknown MM exception" message. Getting this kind of translation fault
> is pretty normal, and normally leads to the translation tables being
> When you look at the corresponding lines of code:
> Actually when following the execution path you should never get the
> message with such a DFSR. Are you sure you examined the fault correctly?
> Do you print 'cpu_exception', and DFSR value directly inside the
> "unknown MMU exception" message scope?
>> 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.
> As being said, this is normal. You should not see any translation table
> entries before it is accessed the first time. It is populated lazily.
> Normally the exception you describe is the correct time to fill in the
> entries. The question is why the exception is not treated as an ordinary
> page-fault exception, but as an unusual type of MMU exception instead.
> I assume, you have examined the ordinary exception, but not the actual
> problematic MMU exception (which is probably an external data-abort -
> means bus error). Please try out the attached patch, and post the
> message results.
>> 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.
>> Bob Stewart
>> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
>> Develop your own process in accordance with the BPMN 2 standard
>> Learn Process modeling best practices with Bonita BPM through live exercises
>> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
> BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
> Develop your own process in accordance with the BPMN 2 standard
> Learn Process modeling best practices with Bonita BPM through live exercises
> http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
> genode-main mailing list
> genode-main at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users