Data Abort MMU exception on mapped IO register read

[robjsstewart at ...196...]

Thanks Martin, your suggestions are very helpfull. My first assumption when I got this error was that it must be related to the L4 bus as all the other peripherals I attached to were on the L3 bus. But I found no mention of. L4 configurabilty  in the processors' TRM. Linux has a UIO driver for this particular peripheral but the only configuration that driver did was to enable the clock to the module, which a necessary step for most peripherals on this SoC.

As you can see from my reply to Stefan, the real error is related to bus access.

Bob

Sent from my android device.

-----Original Message-----
From: Martin Stein <martin.stein at ...1...>
To: Genode OS Framework Mailing List <genode-main at lists.sourceforge.net>
Sent: Tue, 14 Apr 2015 3:32 AM
Subject: Re: Data Abort MMU exception on mapped IO register read

Hi Bob,

On 13.04.2015 14:41, 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>.

To simplify the error case even further, you could manually create an
'Io_mem_connection($DEVICE_BASE) io' and access the return value of
'env()-attach(io->dataspace())'.

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

This looks fishy to me. "unknown MMU exception" is printed if the
'in_fault' function returns false. The implementation of this function
in [1] returns false only on Data Aborts if 'Dfsr::Fs' is neither 5
(section transl. fault) nor 7 (page transl. fault) but obviously it is 5
in your case.

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

This must not be a problem as the Region Manager in Core doesn't map
eager. Instead, Core gets contacted by the kernel as soon as the first
fault occurs on a region (this is what should happen next in your
scenario). Then, if the faulter is allowed to acces the region, Core
adds the mapping to the translation table and resumes the faulter with
its PC set to the instruction that caused the fault.

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

Although I assume the 'in_fault' inconsistency mentioned above to be the
problem: Have you checked wether there is an additional bridge or
bus-access controller for the L4? E.g. we had problems with such a
controller (AIPS) on our i.MX boards in the past. It prevented access to
some devices that were connected through one bus (IPS) while access to
devices at the another bus wasn't a problem. Thus, we configure the
controller in [2].

Cheers,
Martin

[1] base-hw/src/core/include/spec/arm/cpu_support.h
[2] base-hw/src/core/include/spec/imx/board_support.h

------------------------------------------------------------------------------
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/438473ce/attachment.html>