Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Dennis,

You are correct that the write command is missing the offset.

In the setenv command, the read is correct. The steps are to read the image from flash into memory and then load the memory image into the fpga. Two things to note about the setenv example though.

1. The name of the variable was incorrect. Instead of loadfpga, the variable should be named bootfpga.
2. When doing the setenv with multiple commands, the commands need to be in single quotes.

The wiki page has been updated to reflect all of these changes.

Thanks for the feedback and sorry for any inconvenience.

John

Should the "done" LED light up if the FPGA was programmed correctly?

Yes, the "done" LED should light up when the FPGA is programmed correctly.

Can you include the set of commands you are sending and having trouble with?

Thanks.

I did tftp: 0xC0700000 192.168.1.118:fpga.bin
got the ### marks
Did
loadfpga 0xC07000000
no light, message "Loading FPGA Done"
Did (again)
sf probe 0
sf erase 0x580000 0x80000
sf write 0xC0700000 0x58000 ${filesize}
no light, no message

Tried on a second board, same behavior.

On the tftp, what is the reported size of the transfer? Something like 0x71544 is expected. If the data is not the right size, the load will not be successful.

This is probably just a typo, but on the tftp, you have "0xc0700000" and on the loadfpga you have "0xc07000000". There is an extra 0.

On the sf write, the address shown above is different from on the sf erase. (0x580000 vs 0x58000) These should be the same(0x580000). The sf write is writing the image from memory to the flash, it won't do anything to the fpga so this should not change the light.

Hope this helps.

Sorry about the typo-s. My email/web machine doesn't have a serial port so I've got an old laptop running the hyperterm and have to copy stuff by hand.

tftp:
Load address: 0xc0700000
Loading: #####....
done
Bytes transferred = 454196 (71544 hex)

sf write: double checked the printout on the screen, they are all 0x580000.

If you are using the Industrial I/O board Critical Link provided, try using the file attached below. This file is known to load correctly with your setup. This will eliminate any issues with the FPGA image. The image should be "safe" for that board if there is nothing connected to the expansion headers.

-Mike

Yes it is an industrial i/o board. That file did load, the light did come on. I need to tell the fpga guys they gave me a bad file. Thank you for the help. I'd recommend posting IndustrialIO.bin on the wiki so your user's can run that test before they bother you.

Has anybody tried the online procedure "Using Linux drivers to load the FPGA?" I get an infinite printf loop after reset is commanded as follows:

1. cat /proc/modules

fpga_ctrl is displayed with live status

1. echo "1" > /sys/devices/fpga_ctrl/cmd

This causes an infinite loop similarly to the following:

Shutting down spurious 0,13!
enable_irq_vector (0,13,0)

Let me know what else to try,
David Kasper

Hi David,

Currently, there is a bug in the fpga_ctrl.ko driver that could result in spurious interrupts if you re-program the FPGA a second time (after issuing a "3" / probing command to /sys/devices/fpga_ctrl/cmd). This is due to the fact that when you reset the FPGA, all of the I/O's tristate and the INT lines may then fire. The driver needs to shut down / unregister for the INT0 interrupts prior to pulling the init pin low for a reset cycle.

On the first program, the interrupt handles / interrupt lines have not been installed yet, so you don't shouldn't see the problem for a single pass through the programming cycle. This should only happen the "second time around" the programming cycle, i.e. after you've already issued an 'echo "3" > /sys/devices/fpga_ctrl/cmd'. If it is happening on the initial program cycle under linux, then this may be a different problem, but one I haven't seen at CL.... please let me know if that is the case.

Apologies, it's on our todo list to correct. I'll try to elevate the issue here, or if you're up to it you might be able to fix it in the fpga_ctrl.c driver code.

-Mike

Mike,

I have built fpga_ctrl.ko from the source snapshot and am using program_fpga.sh to load the Xilinx FPGA. I have two questions below:

1) DONE is asserted if I load IndustrialIO.bin; however the DONE LED isn't asserted if I use the custom image provided by my FPGA designer. Note that I am able to successfully load the custom image via JTAG (.bit format). Have you have encountered this anomaly before or do you have any suggestions on what I should check?

2) I have built the Linux kernel from sources and am running the same uImage on the Critical Link evaluation board and our custom board. Using the CriticalLink board Linux automatically loads the fpga_ctrl.ko driver and loads the FPGA image during boot. This doesn't occur for our custom board. I checked inittab and rc files on the file system of the CriticalLink evaluation board's file system but couldn't find anything that performs the load. Maybe a board configuration file expects the driver in a particular folder. Can you tell me how I can get our custom board to automatically load the FPGA?

Thank you,
David Kasper

Hi David,

On 1), I suspect that the FPGA bin image may not be getting generated correctly. If you have a bit file, you can run the command referenced on this page of our wiki to ensure that the bits are being swapped correctly in the image generation process. Please try regenerating the bin file from your bit file with the command referenced and let me know if you are still having problems.

On 2), it's possible that the initial board is loading the FPGA during the u-Boot stage. This is a simpler approach and has the advantage of the FPGA being initialized prior to the kernel initializing, so for example you can see console output during boot up if you are routing LCD video data through the FPGA on your design. You can check this by looking at the environment settings in uboot (printenv). See Programming the FPGA for details about that. We don't normally install the FPGA drivers here at factor or load an FPGA file as we don't know what the end-user requires, so I suspect that the CL board was configured by your team there to load the FPGA.

Hope this helps.

-Mike

Mike,

Thanks for your response. I didn't configure the board to load the FPGA and it isn't performed during u-boot. It appears to be performed during Linux INIT runlevel 5, see boot messages below. Any thoughts?

Thanks,
Dave

INIT: Entering runlevel: 5
Starting system message bus: dbus.
Starting Dropbear SSH server: dropbear.
Starting syslogd/klogd: done
 * Starting Avahi mDNS/DNS-SD Daemon: avahi-daemon
[ ok ]
Loading FPGA module and file IndustrialIO.bin
fpga (null): loading the fpga_ctrl module.
input: ADS7843 Touchscreen as /devices/fpga_ctrl/1/input/input0
fpga fpga_ctrl: enable_irq_vector (0,0,1)

.-------.
|       |                  .-.
|   |   |-----.-----.-----.| |   .----..-----.-----.
|       |     | __  |  ---'| '--.|  .-'|     |     |
|   |   |  |  |     |---  ||  --'|  |  |  '  | | | |
'---'---'--'--'--.  |-----''----''--'  '-----'-'-'-'
                -'  |
                '---'

The Angstrom Distribution mityomapl138 ttyS1

Angstrom 2010.4-test-20100508 mityomapl138 ttyS1

mityomapl138 login:

Ok,

Perhaps CL helped someone out there with this. The scripts for loading at runlevel 5 should be contained in /etc/rc5.d. Try searching there. This is how we recommend loading up the fpga (at runlevel 5), but we don't ship units with any such script installed.

Can you check and see if there is a load script at /etc/rc5.d?

-Mike

Mike,

The file "/etc/rc5.d" is present but empty. Let me know if you have any other suggestions.

Thanks,
Dave

Hi Dave,

"/etc/rc5.d" should be a directory. It should not be empty. Below is a listing of this directory for a unit I have here. It includes several key startup scripts...

root@mityomap:/etc/rc5.d$ ls -ltr
total 0
lrwxrwxrwx 1 root root 19 2010-10-19 12:58 S99rmnologin -> ../init.d/rmnologin
lrwxrwxrwx 1 root root 16 2010-10-19 12:58 S20syslog -> ../init.d/syslog
lrwxrwxrwx 1 root root 18 2010-10-19 12:58 S10dropbear -> ../init.d/dropbear
lrwxrwxrwx 1 root root 16 2010-10-19 13:01 S02dbus-1 -> ../init.d/dbus-1
lrwxrwxrwx 1 root root 22 2010-10-19 13:01 S21avahi-daemon -> ../init.d/avahi-daemon

Are there other files in there?

-Mike

Mike,

You are correct and it looks like I have everything that I need.

Thank Again!
Dave

Directory /etc/rc5.d contained the following link:

lrwxrwxrwx 1 root root 14 May 8 20:58 S22fpga -> ../init.d/fpga

Script /etc/init.d/fpga contains the following:

1. /etc/init.d/fpga: Load the fpga bus driver and board-specific bit file #
   SETUPDIR=/home/root/setup
   FPGAFILE=IndustrialIO.bin

test -d ${SETUPDIR} -a -x ${SETUPDIR}/load_fpga || exit 0

case "$1" in
start|restart|force-reload)
echo "Loading FPGA module and file ${FPGAFILE}"
startdir=${PWD}
cd ${SETUPDIR}
./load_fpga ${FPGAFILE}
cd ${startdir}
;;
stop)
echo "stop does not compute!"
;;

*)
      echo "Usage: /etc/init.d/fpga {start|stop|restart|force-reload}" 
      exit 1
    ;;
esac

exit 0

Also, the driver and image existed in /home/root/setup as follows:

rwx----- 1 root root 464196 May 8 21:27 IndustrialIO.bin
rw-r--r- 1 root root 9862 May 8 21:19 ads7843.ko
rw-r--r- 1 root root 16801 May 8 21:19 evdev.ko
rw-r--r- 1 root root 16956 May 8 21:19 fpga_ctrl.ko
rw-r--r- 1 root root 8164 May 8 21:19 fpga_i2c.ko
-rwxr-xr-x 1 root root 218 May 8 21:20 load_fpga

Mike,

The other issue is now resolved; our HW designer rebuilt the Xilinx image per your instructions which fixed the problem. We are now able to load our custom .bit images.

Thanks,
Dave