Mity CPU Platforms » ARM9 Based QNX Platforms

Rob,

The Linux FPGA driver has not been ported to QNX yet. Any capability added would probably just be enough to reload the FPGA while QNX is running. Detecting the cores and creating devices for them is not planned for QNX.

When do you need this capability?

Thanks.

John

Hi John,

I'm not using the FPGA core detection feature in my design. All I require is the ability to load the FPGA and verify that the configuration is correct. Is that what you're planning?

Regards,
Rob

Rob,

The ability to do the basic fpga commands and load an image sounds like a good starting point and it seems to match with what you are looking for. What is your timeframe? I may not be able to get to this until the latter part of next week. Will this work or do you need it sooner?

Thanks.

John

That timeframe works fine for me, I'll keep loading via u-boot until then. Let me know when it's available...

Thanks,
Rob

Rob,

Will do.

By the way, it is possible to have uboot load the fpga image when it is booting. I have used this on boards where the fpga needed to be loaded in order to get ethernet access for uboot but you could use the same mechanism for anything else.

The important step is that there is an environment variable in uboot named "bootfpga" which is "run" when uboot is coming up. You can put whatever commands you want in the command. So you could have the command read the fpga image from NOR flash and then load it into the fpga.

For example, if you had done the following to store the fpga image into flash:

'tftpboot 0xc0000000 YourFPGAImage.bin; sf probe 0; sf erase 0x780000 0x80000; sf write 0xc0000000 0x780000 0x71544'

Then you could do the following to have it automatically loaded when uboot comes up:

setenv bootfpga 'sf probe 0; sf read 0xc0000000 0x780000 0x71544; loadfpga 0xc0000000 0x71544'

Hope this helps.

John

Rob,

I posted a new bsp which includes an fpga driver. See the http://support.criticallink.com/redmine/projects/arm9-qnx-platforms/wiki/Board_Support_Package wiki page for the new bsp and instructions on how to use the new fpga-omapl1xx driver.

Hope this helps.

John

I have the FPGA driver loaded, with the FPGA mapped into 0x66000000.
If I want to access the FPGA for a user application how do I map it in? Just use the h/w address? The FPGA devices seem specific to the 5 commands you've created. Should I create a new FPGA or EMIFA device that I can open and interface to, or is there some other method you'd recommend?

Mark,

The 5 fpga device files (cmd, image, state, version, and devices) are for loading an image into the fpga and getting information about that loaded image. Think of them as fpga administrative tools.

I think what you are asking is how to actually use the cores that are loaded as part of the image. That all depends on what the cores are doing. In general, you will probably need a QNX driver (i.e. resource manager) to work with the interface provided by the core. If the core provides a standard interface, then you may be able to use an existing QNX resource manager and just specify the starting address of the interface registers. If there is not an existing QNX resource manager, then you will need to write one of your own. The QNX documentation talks about how to do this and there are several examples in the BSP. The gpio driver is one, the fpga drivers is another, the source for the serial driver is another.

What do you mean that the FPGA is mapped into 0x66000000? Is this the starting address of your interface registers?

Thanks.

Understood. I have a memory block in the FPGA that I was able to examine using mmap_device_memory().
The offset was a reference to the startup script:
@ ####################################################################### ## FPGA - start the fpga driver #######################################################################
echo Starting the fpga driver
fpga-omapl1xx -b 0x01e26000 -f 0x66000000 &
@

Mark,

These is a mistake in the fpga driver as provided. It is printing out the virtual addresses for the cores in the fpga instead of the physical addresses. The virtual addresses are not real useful. The example in the wiki page shows:

# cat /dev/fpga/devices
Enumerating Devices
Found Device ID 00-Base Module (01.00) at 01801000
Found Device ID 23-ADS7843 Touch Screen (01.02) at 01801080
Found Device ID 07-I2C Interface (01.00) at 01801100
Found Device ID 02-LCD Settings Controller (01.00) at 01801180
Found Device ID 01-TFP410 DVI Controller (01.00) at 01801200

where the 01801000 address is actually a virtual address. A better output is:

# cat /dev/fpga/devices
Enumerating Devices
Found Device ID 00-Base Module (01.00) at 66000000
Found Device ID 23-ADS7843 Touch Screen (01.02) at 66000080
Found Device ID 07-I2C Interface (01.00) at 66000100
Found Device ID 02-LCD Settings Controller (01.00) at 66000180
Found Device ID 01-TFP410 DVI Controller (01.00) at 66000200
# 

which shows the addresses in the 0x66000000 address range.

I have attached a changed file for the fpga driver that causes the above addresses to be shown instead of the virtual addresses.

Tried that - now I'm having a very strange, possibly unrelated problem where the files created under /dev/fpga are created without the executable bit (e.g. 660 rather than 770). Even if I change the permissions they will not execute. No build errors, and I get the same behavior even when I roll back the change to fpga_main.c

Mark,

The files under /dev/fpga are not intended to be executed. They are intended to be opened and then read from or written to. They are created by the fpga-omapl1xx resource manager. As shown in the examples on the wiki page, you can read from them (use of "cat") or you can write to them (use of "echo"). You can not execute them.

Hope this helps.

I have posted a new BSP which has a fixed FPGA driver and fix to the timer routines so the clock period can be changed via ClockPeriod().

Please see http://support.criticallink.com/redmine/attachments/download/840/qnxbsp-20111103.zip under the files tab.