Hi folks, I just committed a change to the bfload program that maybe deserves some explanation. I should have probably put this explanation in the commit message, sorry...
I've been hacking on HostMot2 for the 5i20, using bfload to send the FPGA its firmware before loading the driver. The 5i20 board uses the PLX 9030 PCI chipset, which provides an interface between the PCI bus and a local bus on the card; the FPGA sits on this local bus. The 9030's local bus includes a "Not Ready" line, which local-bus devices can assert to request local-bus wait states. A set of bits called LASxBRD in the 9030 chipset's status/control registers determines whether the chipset honors the Not Ready line. Modern 5i20 boards ship from Mesa with these bits enabled, but older versions of the 5i20 shipped with them disabled (the power-on state of these bits is in an EEPROM). This was not a problem because up until HostMot2, no firmware has needed to request wait states on the local bus. Now it's a bit of a problem, because HM2 needs it. It's an easy condition to detect and change, simply by reading and if needed re-writing a 9030 status/control registers. Note that the tweak should have no effect on most firmwares: if the firmware does not explicitly assert the Not Ready local-bus line, no waitstates are generated. If the firmware tristates the line, pulldown resistors on the board de-assert it. Any comments or concerns are welcome. -- Sebastian Kuzminsky Yes, we have a soul. But it is mechanical. -- Daniel Dennet ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
