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
