I am working with Sasebo GII board that has two FPGAs on it:
Xilinx Spartan and Xilinx Virtex5 (and the board has several separate JTAG interfaces for configuration of fpgas).
I am useing ISE 14.4 under Linux and I have some troubles to configure the Virtex 5 FPGA.
(no problems with Spartan).
I am using "Impact" to send the configuration files to FPGAs.
At the beginning Impact scans the board and finds Spartan FPGA without problems
and I can configure it, but when I plug the cable to the other interface and press scan on Impact it says:
"There are many unknown devices being detected. Press Yes to continue or press No to stop."
If I press the NO option, well, obviously nothing happens :-)
And if I click on YES it fails, I can manually add Virtex5 FPGA, but than it fails to upload the config file to it (and even fails when I try to detect the device ID).
I already tried all JTAG interfaces on the board, nothing.
Same operations work on the same board with SPARTAN FPGA, so I'm stuck. Any ideas ?
Well, I am not familiar with that particular board, but there are many things you can look into when it comes to your JTAG problem.
Check the voltage of your VCC, make sure it has a good value for the board
Make sure your ground connection is well connected and you don't have much impedance
between the connector's GND and the boards GND
Try other JTAG connectors and see if you see any difference in the detection of the
devices.
Try to run the IMPACT in debug mode. Capture the data and see if the patterns look OK
Also something that may not be JTAG related, is to make sure your V5 device has all the powers it needs, if there are any power problems, it may cause the JTAG interface to behave like you explained here.
Also, look on the board and see if there are any switches or jumpers to chose different way of configuring the V5 device. This can be a big issues with multi-FPGA board, maybe the V5 is configured to be programmed from a controller or other devices on the board and the JTAG chain is not set up for programming.
These are just different thoughts, they may help you toward the right direction.
Found this on their site:
User guide for the board
To reprogram the flash ROM (ST45DB16D, U11) for the control FPGA (Spartan-3A), attach the configuration
cable to CN7. For configuration, use the provided mcs file sasebo_gii_ctrl.mcs.
Reprogram the flash ROM (ST45DB16D, U4) for the cryptographic FPGA (Virtex-5 LX30) with the provided
mcs file sasebo_aes_comp_lx30.mcs as well. Connect the configuration cable to CN4.
To configure the FPGA immediately after reprog
ramming of the flash ROM, cycle the power.
Blockquote
This means you can't program the FPGA directly, you need to convert your bit file into MCS file and then load it into the FLASH memory on the board.
Related
We have an embedded board that has an iMX8M-Plus Processor and Linux v5.4.161. This board has one PCIe bus and that one is connected to an FPGA. When we power up the board, the FPGA is not yet configured, so it acts as if it was not on the PCIe bus.
Once the Linux is fully booted, we configure the FPGA and only after that it starts acting as a PCIe endpoint (device).
At this point, when I run lspci -> it returns nothing.
When I first execute echo "1" > /sys/bus/pci/rescan as suggested here and here and then lspci, I still get nothing.
But if I reboot the linux without reseting the FPGA, it starts being visible in the lspci list. Rebooting the linux is not an option for us. Somehow I need to tell the linux that whatever it's doing at the boot time, please do it again at runtime. But I couldn't find a solution for this so far.
According to the Texas Instrument support forum, they said if the PCIe link is not trained at the boot time, rescan command never works.
At the boot time, while linux loads a pci driver, it tries to establish a PCIe link, I can see that with an oscilloscope, PERST pin is asserted and PCIE_CLK generated for a while and then stops if it can not detect any device. But the rescan command never does that.
Also in the system there is no pcie device to executeecho 1 > $pcidevice/remove in order to make rescan functional. Or there is no device or bus to set power off and on back like echo 0 > /sys/bus/pci/slots/.../power
I also learned that there was a method in old linux times (v2.6) called adding a Fake PCIe Device which physically doesn't exist to solve this problem. For that I took the fakephp.c driver from an old linux repo and ported it to ours. After solving a couple of deprecated function problems, it is compiled for Linux Kernel v5.4. modprobe fakephp worked and driver loaded but somehow I didn't get this fake device in my device list. Here it is mentioned that the fakephp driver was removed from mainstream linux since PCI core has similar functionality, but he never mentioned how.
Short of the story is that, I am stuck here, I need my FPGA to be visible in the lspci list without restarting the linux.
I recommend configuring the FPGA in u-boot to get away from these kinds of problems. Connect up SPI pins to FPGA's config pins & run it in Slave configuration mode.
Is there an inbuilt or pre-existing feature I can use to accomplish Flashing a Cyclone IV's(EP4CE6E22C8) SROM(W25Q16BV) chip via its JTAG connection? Maybe some setting when compiling in Quartus to tell the FPGA "Hey flash this". Or a specific command for OpenOCD.
I saw that there are IP cores to manually flash the device, but I really do not want to go down that rabbit hole. Programming my own flasher sounds like an unnessisary hell at my experience level.
I hope this is good enough of a question, Ive been suffering with this for months, if you need any more information
INFO:
I have a W25Q16BV SROM chip connected directlyto a EP4CE6E22C8 in AS config mode. (Data input on SROM has single direct connection to FPGA's ASDO)
And to that FPGA I have a JTAG connection that connects to my computer via a J-Link adapter.
Controlling the J-Link adapter is OpenOCD that uploades compiled data(SVF file) provided by Quartus Prime.
The board is from an obscure seller, but it did come pre-flashed with an example program that starts upon every reset, so there must be some way they uploaded this.
I have just finished a project using an Arduino Micro dev board and want to move to a standalone ATmega32.
I need to run this at 3.3V and I dont want to go down the overclocking road so I have an 8MHz crystal to put on it.
I still want to be able to upload sketches via USB and the Arduino compiler so I gather I need to burn a different bootloader.
For this purpose I have purchased a USBASP programmer.
I am slightly unsure of what to do next - everything I can find on the topic either relates to the ATmega328 or to burning bootloaders using another Arduino.
I have worked out that I need to modify boards.txt to point to the correct bootloader....but which is the correct bootloader for ATmega32 at 8Mhz?
Also do I need to change any fuses?
Thanks
I think you're a bit out of luck.
The ATmega doesn't have hardware USB, so I assume the bootloader is using V-USB to implement USB. That stack, being a software implementation of USB's high-speed signalling, requires at least a 12 MHz clock (higher is better).
I don't think you can run V-USB using only the internal 8 MHz oscillator.
According to the OP comments the micro is indeed an Atmega32u4, not an Atmega32 (#OP: please fix the question to match this).
Since it has onboard USB, you can use a pre-existing bootloader like the sparkfun one:
https://www.sparkfun.com/products/12587
Here you have the link to one of their products, the Arduino pro micro 3.3V (which runs at 8MHz). You can add the sparkfun arduino boards repository to your IDE and then just use the board specification for their pro micro 3.3V do upload the correct bootloader and to program it through the USB just like the usual Arduino Micro.
I have a Freescale imx.6q (arm) based board.
Hardware is configured with devicetree.
It had a change major incompatible change to timings and voltage for an onboard fpga, but these changes are invisible to the kernel.
The EE's tell us we shouldn't load the old fpga firmware for fear of damaging it. I would like to support both hardware from the same code (It is already causing confusion)
The solution I have thought of is this:
There are several new spi temperature sensors on the board. If I can read from one of those devices, I can infer that I need the new firmware.
How can I (in one driver) grab an spi device and then release it?
I suspect that I might be able to do something like this with device tree,
But I don't want to make the device unavailable.
Any ideas or examples of something like this being done?
After reading question i think your concern is how to add software support for more than one hardware.
If that is the case i think we can write two drivers supporting both hardware's with different configuration such as irq, voltage, register set etc.
So i will enable both drivers in Makefile and config file.
So at the time of boot when probe of drivers gets called we can check the hardware id by using spi_read command from driver.
If hardware id matches then driver probe gets successful and driver can be used to interact with hardware.
If spi_read fails then driver probe itself will fail.
I think this will do the trick.
EDIT (answer the question)
To detect use an SPI device from another driver use a reference to the device in the devicetree structure.
Short answer: add a reference to the spi device in your devices dts entry.
Slightly longer answer:
When adding spi to another device driver, you are effectively adding a subdevice, which may want its own driver. I have an FPGA which loads its firmware over (something close enough to be considered) SPI. I started with the idea of just treating the spi device as part of the larger driver, but the more work went into it, the more obvious it was that it is its own device, with a purpose and function that is distinct from the rest of the driver. I separated that code into its own driver.
Now instead of a reference to an SPI device, my driver just has a reference to an FPGA Manager device.
See line 98, 370 of https://github.com/d4ddi0/linux/blob/v4.12evi/arch/arm/boot/dts/imx6q-evi.dts
and
make sure the spi driver is loaded before your driver completes loading
My original answer to my question (for historical purposes):
What I ended up doing was using different devicetree files. The difference is know at initial install time (based on the serial number). The bootloader knows which dts filename to load.
There are multiple FPGA firmware versions and the right one is chosen based on the description in the dts.
This way, I can still update the driver and/or dts without breakage.
This works well in practice even though it does not detect anything at runtime.
One problem still exists, if I take an SD card from a new revision, and put it into an old one, the incorrect firmware will be loaded. To really solve this last problem, we've talked about adding an EEPROM to uniquely identify the hardware revision on future boards.
I am trying to export a pin (no. 110) using the following in linux:
echo 110 > /sys/class/gpio/export
When I try to do so, I getthe error message
ash: write error: Device or resource busy
As per my knowledge the pin is not being used by any module, but I may be wrong. I had the hardware line probed and the voltage is changing, the processor seems to be driving something to the line.
The pin according to the user manual is not multiplexed and is "commonly available".
The pin according to the user manual is not multiplexed and is "commonly available".
Apparently you are referring to a SoC manual.
Such a statement will only imply that the pin does not have a dedicated application by an integrated peripheral (as shipped by the SoC manufacturer).
That statement is invalidated when the SoC is designed into a circuit and/or installed on a board.
The document that you really need to consult is the board manual or the board schematics.
That should be the accurate documentation as to how the board designer used the available GPIO pins in that specific application.
When I try to do so, I getthe error message ...
Fortunately for you, the device driver that does use that pin (that you want to use) has properly performed the GPIO reserve/request call to prevent a hijack.
This prevented that other driver from breaking and/or a device/board malfunction.
As per my knowledge the pin is not being used by any module, but I may be wrong
How did you attain this "knowledge"?
Did you scan the .dts and .dtsi files used for your board?
Did you check the source code of every device driver used by your board?