I will repeat what Steve said. Thanks for all the work on this. I will never use that particular interface probably, but I like that there will be a wide and full support for many computer-to-machine interfaces.
On Thu, Apr 3, 2008 at 9:09 PM, Sebastian Kuzminsky <[EMAIL PROTECTED]> wrote: > Stephen Wille Padnos wrote: > > Sebastian Kuzminsky wrote: > > > >> Hi JMKasunich and SWPadnos, would you mind if I added support for the > >> 7i43 (EPP) board to bfload? The structure of bfload makes it look like > >> it could be done pretty cleanly. > >> > >> > > I have no objection to adding that functionality. One question about > > programming via parallel - can you detect the chip type over that > > interface? For PCI boards, we can use the PCI enumeration functions to > > look for known board IDs, and refuse to program if either the correct > > board type isn't found (like 5i20 vs 5i22), or if the correct FPGA isn't > > found, based on the type in the bitfle. Basically bfload is "safe" > > right now - you can't program some other manufacturer's board, and you > > can't load a bitfile into a chip it wasn't meant for. If this is still > > possible with the parallel port programming scheme, then I'm all for > > adding it. If not, then I'm still mostly for it, but would have some > > concerns about how to do it right :) > > I share your concern. I don't think it can be done perfectly, even in > the PCI world, but I have a proposal for making it as safe as I think it > can. > > > First the EPP situation... > > You can not reliably detect the 7i43 over the EPP port, but if there > *is* a 7i43 on the EPP port you're using, you can tell if the > firmware-sending worked. > > My plan was to force the user to provide (on the command-line) the io > address of the EPP port they want to use -- this would be the same as > the io address they give to the HAL driver when they load that, next. > Something like this maybe: > > bfload 7i43:0x378=SV8.BIT > > > Now for some wrinkles in the PCI world... > > Currently bfload is called like this: > > bfload Firmware [BoardNum] > > It inspects the firmware to determine the FPGA it's for, and then looks > for the BoardNum'th PCI board in the system that has that kind of FPGA. > This scheme works well for the set of devices currently supported > (5i20, 5i22-1, and 5i22-1.5), since the three devices all use different > FPGAs. It won't work so well if we want to add support for some of the > other PCI-like Anything I/O boards which use the same FPGAs. The user > would have to know which FPGA is on which board. > > I'm proposing instead to change the command-line syntax to something > like this: > > bfload BoardType[:BoardId]=FirmwareFile > > The BoardType would be one of the supported board names, such as 5i20, > 5i22-1, 4i68, 7i43, etc. For the PCI boards, BoardID would be like the > current BoardNum, but only counting within the specified board type. > For the EPP board, the BoardID would be the io address of the EPP port > (which uniquely identifies the board on the system). So the usage would > look like this: > > # omitted the BoardID, defaults to 0 > bfload 5i20=SV12.BIT > > # one firmware on the first 5i22-1.5, another on the second > bfload 5i22-1.5:0=SV16.BIT 5i22-1.5:1=SVST8_8.BIT > > # different firmwares on different board types > bfload 5i20:0=SV12.BIT 7i34:0x378=SV8.BIT > > This seems a little clearer to use, and a bit more flexible. bfload > will do what verification it can: matching the requested firmware file > to the requested board when possible, and trusting the user when the > situation is ambiguous (4i68, 7i43). > > > > -- > Sebastian Kuzminsky > If you need a machine today and don't buy it, > tomorrow you will have paid for it and not have it. -- Henry Ford > > ------------------------------------------------------------------------- > > > 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 > ------------------------------------------------------------------------- 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
