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@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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main