Larry,
This is completely normal behavior. I will try not to go in depth, but I have do provide some details anyway.
1) The PCI enumeration is done by the BIOS once, indeed.
2) The FPGA has the PCI engine so reprogramming the FPGA terminates the PCIe link, windows/linux loose its link, but it is still known by the operating system, the table handed by the BIOS are still existing and the memory mapped to the device by the operating system can still be used. This is what we call a phantom PCI device, it is still known by the OS, still mapped to the OS, you can write to the memory mapped and if you read from the memory mapped you get 0xFFFFFFFF, because the PCIe have no more configuration, BAR, etc..
3) The 4fm_reset() actually writes on the PCI BAR, this cannot fail.
4) The other utilities will fail because the API only gets timeout values from the PCI (0xFFFFFFFF as value for all the reads)..
So yeah, the behavior you see if common for all operating systems; Windows, Linux and Vxworks and will be same for any programmable hardware having the PCIe link in it. In a way it makes sense, after reprogramming the FPGA you loose all the configuration, typically all the PCI configuration done by the BIOS is gone. BAR registers have 0 so any access to the previous address mapped by the OS will not reach the device, the link from virtual kernel memory down to the PCI BAR is simply broken
There might be low level hacks for that in the software but this should be properly tested. This is something we could investigate for you, please contact
sales@4dsp.com if this is a path you wanna take.
Best Regards
Arnaud