Data Abort MMU exception on mapped IO register read

[Bob Stewart]

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 
ip=810006e0

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.
Bob

On 04/14/2015 07:27 AM, Stefan Kalkowski wrote:
> Hi Bob,
>
> On 04/13/2015 02:41 PM, Bob Stewart wrote:
>> Hi,
>>
>> 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
> populated.
>
> When you look at the corresponding lines of code:
>
>
> https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/include/spec/arm/cpu_support.h#L438
>
> and:
>
>
> https://github.com/genodelabs/genode/blob/master/repos/base-hw/src/core/spec/arm/kernel/thread.cc#L108
>
> 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.
>
> Regards
> Stefan
>
>> 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.
>>
>> Thanks,
>>               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_
>> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>> _______________________________________________
>> genode-main mailing list
>> genode-main at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/genode-main
>>
>
>
> ------------------------------------------------------------------------------
> 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_
> source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF
>
>
> _______________________________________________
> genode-main mailing list
> genode-main at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20150414/f8742ab9/attachment.html>