Forums » Software Development »
Using the EMIFA interface on the Mitydsp-1810
Added by Mattias Ekstrom about 13 years ago
Hi,
I was wondering where in the linux source I should be looking to add changes if I wanted to use the EMIFA interface to communicate with an asic in 16-bit parallel, async mode. I assume there are pinmux and possibly chip select settings to consider?
Obviously you can't provide a complete solution here but where should I start looking?
We're using the mitydsp-1810 and the asic is connected to the EMA_A* and EMA_D* pins.
--
Mattias
Replies (4)
RE: Using the EMIFA interface on the Mitydsp-1810 - Added by Michael Williamson about 13 years ago
Hi,
We use the EMIFA (16 bits) to interface to our FPGA on SOMS including an FPGA. The pinmux and initial chip select settings for the EMIFA are configured, by default, out of the u-Boot application (see boards/davinci/mityomapl138/mityomapl138.c ). They may also be configured by the kernel (see the arch/arm/mach-davinci/da850* or board-mityomapl138) for more information on that.
Our FPGA drivers and EMIFA_Iface.vhdl code blocks in the board support package would provide some examples to interfacing.
-Mike
RE: Using the EMIFA interface on the Mitydsp-1810 - Added by Mattias Ekstrom about 13 years ago
Hi,
I was wondering which chip selects are unused by default? What I can see in the u-boot and linux source is that only CS2 and CS3 are used. We're using chip select 5 right now but we're having some issues and I'm not sure what's causing it. Is it occupied by something else that I'm missing? Your code for the fpga uses chip select 5, but as our SoM doesn't have a fpga it should be available to us?
I looked through your fpga source as suggested and mimicked the parts of the code that was relevant to me. E.g. the ioremap-stuff and file ops.
When I mmap the memory in my usermode program I can write and read from the memory and I see activity on the read/write and chip select pins as expected. What has me puzzled though is that there seems to be some conflict on the data pins, as the asic I'm interfacing with appears to want to raise some pins while something else his holding them down.
--
Mattias
RE: Using the EMIFA interface on the Mitydsp-1810 - Added by Michael Williamson about 13 years ago
Hi Mattias,
The only chip select used on the EMIFA by default is CS3 (used for the NAND). Our FPGA driver framework uses CS5, but if you don't load the modules for the drivers (e.g., fpga_ctrl.ko) then that CS should not be used during normal operation.
NAND transactions can take a fair amount of time, but I am assuming that you tri-state the EMA_D pins when CS5 or EMA_OE is de-asserted, so you shouldn't be colliding with them.
If you boot from NFS and disable the NAND in your kernel, then all EMIFA transactions should stop by default. You might want to try this and see if the NAND access is causing the conflicts. Is the contention occurring during a read or write cycle?
-Mike
RE: Using the EMIFA interface on the Mitydsp-1810 - Added by Mattias Ekstrom about 13 years ago
We changed chip select to CS4 and kept having the same issues. We've done some other measurements and tests and we now doubt it's some kind of contention, it is most likely some problem on the ASIC side rather than the arm side of things. Write cycles seem fine but the voltage rises too slowly on reads, a few pins are fine but some are not. Right now we're thinking the ASIC isn't seated properly and there is not a proper connection. Apparently they think that the slow voltage rise is due to the balancing of the port on the arm, even if there in fact is no connection to the corresponding pin on the ASIC. We were getting, for lack of a better word, sharkfins on the oscilloscope. I'm mostly a software guy so those kinds of things go a bit above my head though!
They are looking over the hardware right now. Should we not find a hardware issue I'll try the NFS boot with nand disabled.
Thanks for the help!
--
Mattias
