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
