On Mar 31, 2011, at 12:43 PM, Guraaf wrote: > Thanks Jean-Francois, > > Do you remember what was the BIOS POST setting called exactly? I > didn't see anything that resembles leaving a PCIe port ON all the > time, even if there is no device in there. > > Separately, I did see a setting related PCI/PnP options. This one > says whether the OS supports Plug-and-Play or not. Currently, the > setting says "no", i.e., the OS does not > support PnP. Is that correct or should I enable PnP support in OS? > Linux is PnP so I would set that to yes, although I am not sure what effect it would actually have. We probably don't have the same system, so the BIOS menu items will differ. Look for a menu about the north bridge or PCI??, then something about port ... > Finally, I noticed one more thing. > 1. Program the FPGA. > 2. Reboot the PC > 3. lspci lists the device just fine and is usable. Right before the next step, Look back at my previous replies in this thread. There's a file called "remove" in sysfs for the given PCI device you want to reprogram. echo a "1" in that file prior to reprogramming it's FPGA. > 4. try to reprogram the FPGA which causes the PCIe core inside the > FPGA to be reset > 5. lspci now lists the device as "disabled". > 6. A rescan does not enable the PCI device > > This suggests that perhaps the problem is not BIOS?? Because at this > point, the port is powered. It is disabled because I believe the BAR > registers were reset with the second programming. It appears that > rescan isn't working and not programming the BARs again? > > Thanks for your offer for the SPI programmer. It might be useful a > bit later. Right now, our USB cable works fine. Our FPGA board has a > USB transreceiver that is used to program the FPGAs. > > Thanks again, > Guraaf > > On Wed, Mar 30, 2011 at 10:26 PM, Jean-François Dagenais > <jeff.dagenais@xxxxxxxxx> wrote: >> >> On Mar 30, 2011, at 3:59 PM, Guraaf wrote: >> >>> Thanks Jean-Francois (and Greg KH), >>> >>> This was an excellent discussion and resource for a newbie like me. I >>> am trying to something very similar. My current steps are: >>> >>> 1. Boot the Debian Squeeze 2.6.32-5 x86 PC. >>> 2. lspci does not list my FPGA hardware board that is plugged in PCI >>> Express device >>> 3. Power the FPGA board >>> 4. Program the FPGA board using a USB cable >>> 5. Reboot the PC >>> 6. lspci lists the FPGA board. >>> 7. insmod my kernel device driver >>> 8. proceed to use the user-space application >>> >>> I want to avoid the PC reboot and tried the following: >>> 1. Boot the Debian Squeeze 2.6.32-5 x86 PC. >>> 2. lspci does not list my FPGA hardware board that is plugged in PCI >>> Express device >>> 3. Power the FPGA board >>> 4. Program the FPGA board using a USB cable >>> 5. echo 1 > /sys/bus/pci/rescan >>> 6. lspci still does not list my device >> I remember in my first attempts the rescanning failed. My problem was that I plugged my 1x brain dead PCI express device (pre-FPGA programming) in the PEG (16x graphics port). The BIOS POST steps included scanning this port and then powering it down if no device were found. I fixed it by forcing the port ON in the BIOS setup. So generally speaking, BIOS tend to turn off internal slots that don't look like they are populated at power up. >> Hope this helps! ;) >> >> BTW if anyone is interested, I wrote an SPI driver where the SPI slave is xilinx FPGA serial programming interface. It creates write-only "bitfile" attribute in sysfs onto which the bitfile is written. The driver needs the SPI master and at bare minimum 1 GPIO (output) to drive the !PROGRAM signal which initiates the programming in the FPGA, the rest of the signals *can* be ~ignored... (alpha version) It works well except for now I only had a SPI master made from GPIOs so bitbanging using "spi_gpio". So it was slow (7min for 1.5MB). This way in userspace can "dd if=/lib/firmware/abc.bit of=/sys/class/spi/.../bitfile" (or cat > /sys/.../bitfile) to load the FPGA! Then "echo 1 > /sys/bus/pci/rescan" ~hotplugs~ the pci device in the system. >>> >>> Any idea why this wouldn't work? Is this something to do with the way >>> my Linux was compiled? CONFIG_HOTPLUG turned up while doing online >>> searches. Or is my PC hardware not capable of a hotplug rescan? >>> >>> What can I debug or investigate further? Any further pointers will be >>> appreciated. RTFM is fine if I know what "M" to read.. >>> >>> -- Guraaf >>> >>> On Mon, Mar 14, 2011 at 9:29 PM, Jean-François Dagenais >>> <jeff.dagenais@xxxxxxxxx> wrote: >>>> >>>> On Mar 14, 2011, at 9:04 PM, Greg KH wrote: >>>> >>>>> On Mon, Mar 14, 2011 at 07:22:00PM -0500, David Hagood wrote: >>>>>> On Mon, 2011-03-14 at 13:01 -0700, Greg KH wrote: >>>>>>> >>>>>>> Your only hope is to disconnect the device, and add it back with the new >>>>>>> resources changed. >>>>>> >>>>>> OK, fair enough. But how can you cause the kernel to consider the device >>>>>> disconnected? >>>> Look back at my previous reply. There's a file called "remove" in sysfs for the given PCI device you want to ~remove. echo a "1" in that file. >>>> The exact equivalent, within a module's code: call pci_remove_bus_device(struct pci_dev*) like fakephp does. >>>>> >>>>> As noted before, the 'disconnect' file does this. See the functions it >>>>> calls in the pci core to handle the pci device going away. >>>>> >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in >>>> the body of a message to majordomo@xxxxxxxxxxxxxxx >>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>> >> >> -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
