|
[Attachment(s) from mike ingle included below]
Rather than specifically adressing your issue, I am going to suggest a sequence of small steps to get you up and going. This builds on the existing TS kernel file system you have rather than making a newer kernel and file system for which you will find several threads in the group on that subject.
1. Determine your installed kernel version, and make sure you have the source for it.
in my case cat /proc/version gives:
Linux version 2.4.26-ts11 (gcc version 3.3.4) #13 Tue Aug 25 17:09:20 PDT 2009
2. Make sure you have your cross compiler set up to match the gcc used in your kernel as built. Note in my case that would be gcc 3.3.4
3. Create a makefile which references your cross tools etc. I have attached a working makefile for my system (QT Qmake generated). It should be trivial to edit the lines with the cross compiler location and to edit the sources section to get working makefile from this.
4. Test your make by making a userland hello world, and test on your board.
5. Are you sure you need a kernel module. Have you looked at the xdio api in the files section?
6. So you really need the kernel module, then download the adc-0.0.3.tar.gz from the files section.
7. Edit the adc... makefile so that you can compile it (specfically to point to the kernel source and crosstools). Make the module, and insmod the module you created use adc_debug=1 when loading. There will be a readme telling you what to do. run dmesg and see that the module loaded (or connect a serial port, and you will see the kernel debug as it happens. Work on this known working setup until you can get the module comiled and loaded sucessfully.
8. Now you have a sucessful cross build for userland applications ,and kernel modules. Edit the Makefile to process your kernel hello world source. compile, install, and view the results.
9. OK, now you could consider writing the HDL code to configure the fpga, and then write a driver. You have the schematics avail. I presume you have an fpga load utility somwhere (don't have 7390 myself). I would STRONGLY suggest that you start by writing userland application using mmap to test your fpga build in NON interrupt mode, until you get things sorted to a reasonable level, and can read and write some registers you created. Then you can attach a srFF to the interrupt pin via an enable. From the software side you have 3 bits.
Set interrupt bit
enable interrupt bit
reset interrupt. bit
Note, you should create a 1 clock cycle wide pulse from the set interrupt bit to set the srFF. Otherwise you will generate MANY interrupts, and lock up your system (at least it did mine)
Your software in user land would:
enable the interrupt by setting the appropriate bit.
set the interrupt
Your driver would reset the interrupt and perhaps print a debug message.
Again, I would not attempt any interrupt/driver related software until the fpga design is mature enough to pass register testing reliably (1 billion cycles no errors) from a userland application.
Please let us know how it works out using the lattice tools, I haven't yet used them, and am interested. I use altera and xilinx tools only for now.
Regards, Mike
On Sat, Sep 5, 2009 at 10:06 PM, anadig123 <> wrote:
|