Direct DMA - Revision history

JavierRojas: /* Notes/bugs/etc */

2008-07-25T15:55:51Z

Notes/bugs/etc

← Older revision		Revision as of 15:55, 25 July 2008
Line 57:		Line 57:

	== Notes/bugs/etc ==		== Notes/bugs/etc ==
	* Every once in a while the reading of the <tt>/dev/dma_test</tt> fails. It is still not clear why this happens. ~~As far as what~~ the driver ~~can see~~, it is ~~not receiving any interruption~~ from the FPGA, and ~~therefore it hangs. In other tries~~ the ~~kernel crashes~~.		* Every once in a while the reading of the <tt>/dev/dma_test</tt> fails. It is still not clear why this happens. The failure doesn't seem to be related to the amount of times the device is read. Tracking the driver execution with printk shows that the system hangs when writing to the FPGA (when passing the DMA address).
			#define MEM_CSP4_START (0x20000000)
			#define MEM_NON_CACHEABLE (0x80000000)
			...
			volatile unsigned long *fpga;
			...
			... (on module (driver) inititialization)
			fpga = ioremap(MEM_CSP4_START\|MEM_NON_CACHEABLE, 8192);
			... (on device reading)
			printk("Yadda Yadda\n");
			fpga[0x84] = dmabuf_phys_addr;
			The last thing heard from the kernel (on the serial port) is the "Yadda Yadda" message. No kernel dumps/oops/etc.
			We have also made tests with and without interruptions from the FPGA, and the problem arises on both cases.
	* There seem to be issues with the frequency used. So far a frequency of 100Mhz is needed for the data transfer to work properly. Higher frequencies (e.g. 160Mhz) lead to problems when the FPGA writes the data to the DMA buffer, and sometimes to problems when passing the address of the DMA buffer to the FPGA (which makes the FPGA fill some random location of the memory with a nice sequence). It is important to note that since the SDRAM memory works with at most 130Mhz, the FPGA uses a fake clock of half the frequency, so it works with the SDRAM memory at, at most, 80Mhz.		* There seem to be issues with the frequency used. So far a frequency of 100Mhz is needed for the data transfer to work properly. Higher frequencies (e.g. 160Mhz) lead to problems when the FPGA writes the data to the DMA buffer, and sometimes to problems when passing the address of the DMA buffer to the FPGA (which makes the FPGA fill some random location of the memory with a nice sequence). It is important to note that since the SDRAM memory works with at most 130Mhz, the FPGA uses a fake clock of half the frequency, so it works with the SDRAM memory at, at most, 80Mhz.

	== Files ==		== Files ==
	[[Media:Dma-driver.tar.gz]]		[[Media:Dma-driver.tar.gz]]

JavierRojas at 21:27, 24 July 2008

2008-07-24T21:27:07Z

← Older revision		Revision as of 21:27, 24 July 2008
Line 59:		Line 59:
	* Every once in a while the reading of the <tt>/dev/dma_test</tt> fails. It is still not clear why this happens. As far as what the driver can see, it is not receiving any interruption from the FPGA, and therefore it hangs. In other tries the kernel crashes.		* Every once in a while the reading of the <tt>/dev/dma_test</tt> fails. It is still not clear why this happens. As far as what the driver can see, it is not receiving any interruption from the FPGA, and therefore it hangs. In other tries the kernel crashes.
	* There seem to be issues with the frequency used. So far a frequency of 100Mhz is needed for the data transfer to work properly. Higher frequencies (e.g. 160Mhz) lead to problems when the FPGA writes the data to the DMA buffer, and sometimes to problems when passing the address of the DMA buffer to the FPGA (which makes the FPGA fill some random location of the memory with a nice sequence). It is important to note that since the SDRAM memory works with at most 130Mhz, the FPGA uses a fake clock of half the frequency, so it works with the SDRAM memory at, at most, 80Mhz.		* There seem to be issues with the frequency used. So far a frequency of 100Mhz is needed for the data transfer to work properly. Higher frequencies (e.g. 160Mhz) lead to problems when the FPGA writes the data to the DMA buffer, and sometimes to problems when passing the address of the DMA buffer to the FPGA (which makes the FPGA fill some random location of the memory with a nice sequence). It is important to note that since the SDRAM memory works with at most 130Mhz, the FPGA uses a fake clock of half the frequency, so it works with the SDRAM memory at, at most, 80Mhz.

			== Files ==
			[[Media:Dma-driver.tar.gz]]

JavierRojas at 21:03, 24 July 2008

2008-07-24T21:03:51Z

@@ Line 13: / Line 13: @@
 like the interruption line, they must be removed from the kernel, because to do proper DMA we need to be able to handle the interruption issued when the FPGA finishes the data transfer.
-To remove these parts, you'll have to edit the file elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile so it looks like this
+To remove these parts, you'll have to edit the file <tt>elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile</tt> so it looks like this
   obj-$(CONFIG_ETRAX_ELPHEL353)        += fpga_common.o
   obj-$(CONFIG_ETRAX_ELPHEL353)        += fpgajtag.o
@@ Line 33: / Line 31: @@
   #obj-$(CONFIG_ETRAX_ELPHEL353)        += stream.o
   #obj-$(CONFIG_ETRAX_ELPHEL_MT9X001)   += mt9x001.o
   #obj-$(CONFIG_ETRAX_ELPHEL347)        += ???.o
@@ Line 39: / Line 36: @@
   #obj-$(CONFIG_ETRAX_ELPHEL_KAI16000)  += ???.o
 == Driver compilation ==
 == Testing DMA ==

JavierRojas: /* Kernel recompilation */

2008-07-24T19:35:51Z

Kernel recompilation

@@ Line 15: / Line 15: @@
 To remove these parts, you'll have to edit the file elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile so it looks like this
+ obj-$(CONFIG_ETRAX_ELPHEL353)        += fpga_common.o
-#obj-$(CONFIG_ETRAX_ELPHEL_MT9X001)   += mt9x001.o
+ obj-$(CONFIG_ETRAX_ELPHEL353)        += fpgajtag.o
-#obj-$(CONFIG_ETRAX_ELPHEL347)        += ???.o
+ obj-$(CONFIG_ETRAX_ELPHEL353)        += fpgaclocks.o
-#obj-$(CONFIG_ETRAX_ELPHEL_KAI11002)  += ???.o
+ obj-$(CONFIG_ETRAX_ELPHEL353)        += fpga_sdram.o
-#obj-$(CONFIG_ETRAX_ELPHEL_KAI16000)  += ???.o
+ #obj-$(CONFIG_ETRAX_ELPHEL353)        += fpga_io.o
-</nowiki>
+ #obj-$(CONFIG_ETRAX_ELPHEL353)        += fpgactrl.o
 == Driver compilation ==
 == Testing DMA ==

JavierRojas: /* Kernel recompilation */

2008-07-24T19:22:23Z

Kernel recompilation

← Older revision		Revision as of 19:22, 24 July 2008
Line 14:		Line 14:

	To remove these parts, you'll have to edit the file elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile so it looks like this		To remove these parts, you'll have to edit the file elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile so it looks like this

	<nowiki>		<nowiki>
	obj-$(CONFIG_ETRAX_ELPHEL353) += fpga_common.o		obj-$(CONFIG_ETRAX_ELPHEL353) += fpga_common.o

JavierRojas at 19:20, 24 July 2008

2008-07-24T19:20:52Z

New page

= Direct DMA =
This is an implementation of DMA between the FPGA and the main memory of an Elphel 353 camera.
== Requirements/preparation ==
We used the 7.1.7.26 version of the Elphel software. To use this driver you will have to recompile the kernel
(and because of this, also reflash the camera), and create a proper device file.

Since we will be using a new device (file in /dev), we'll have to create it as well; but, since the /dev filesystem is read-only, this must be done when creating the camera image (and therefore requires reflashing the camera).

Needless to say, you can recompile the kernel and arrange for the creation of the device at the same time so you will only have to reflash the camera once to apply both changes.

=== Kernel recompilation ===
The original Elphel drivers are compiled inside of the kernel (i.e., not as modules). Since they use resources
like the interruption line, they must be removed from the kernel, because to do proper DMA we need to be able to handle the interruption issued when the FPGA finishes the data transfer.

To remove these parts, you'll have to edit the file elphel353/os/linux-2.6/arch/cris/arch-v32/drivers/elphel/Makefile so it looks like this
<nowiki>
obj-$(CONFIG_ETRAX_ELPHEL353) += fpga_common.o
obj-$(CONFIG_ETRAX_ELPHEL353) += fpgajtag.o
obj-$(CONFIG_ETRAX_ELPHEL353) += fpgaclocks.o
obj-$(CONFIG_ETRAX_ELPHEL353) += fpga_sdram.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += fpga_io.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += fpgactrl.o

#obj-$(CONFIG_ETRAX_ELPHEL353) += cc3x3.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += cxi2c.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += cxsdram.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += cxdma.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += hist.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += ext353.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += circbuf.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += exif353.o
#obj-$(CONFIG_ETRAX_ELPHEL353) += stream.o

#obj-$(CONFIG_ETRAX_ELPHEL_MT9X001) += mt9x001.o
#obj-$(CONFIG_ETRAX_ELPHEL347) += ???.o
#obj-$(CONFIG_ETRAX_ELPHEL_KAI11002) += ???.o
#obj-$(CONFIG_ETRAX_ELPHEL_KAI16000) += ???.o
</nowiki>

== Driver compilation ==

== Testing DMA ==