after libztex_selectFpga() failed we can not be sure which fpga is now
selected. can be the old one or maybe even the new one. so set the
selected fpga variable to unknown so that the next call must set it
again.
The high speed and low speed configureFpga functions should not return
an error when no bitstream needs to be downloaded. These codepaths are
not executed for now, because all calls to configureFpga set the force
parameter to true. Future commits may change that, allowing cgminer to
start mining immediately if each hardware has already been correctly
configured with firmware and bitstream(s).
The first 8 bytes are matched, which ensures that the mining firmware
actually fits the hardware, assuming that the correct dummy firmware
is present in the device.
The download sequence starts with a reset command, which tells the board
that a new firmware is about to be downloaded. The board gets unhappy if
no new firmware is actually sent, so only send the reset command AFTER
the new firmware has actually been successfully read.
When one or more ZTEX devices with dummy firmware are found on startup,
the correct firmware is downloaded to each device, and then USB devices
are rescanned until all devices have reattached with the mining firmware.
This allows to discover and configure all ZTEX devices and start mining
directly, without first running the ZTEX Java software to download a
firmware to the device.
The ZTEX USB firmware doesn't correctly support GET_DESCRIPTOR requests
for string descriptors, specifically the device always returns the full
string descriptor, even if the request wLength is shorter. The FreeBSD
implementation of libusb_get_string_descriptor_ascii() first requests 4
(four) bytes to validate the start of the string descriptor, and since
the device sends back too many bytes the USB host controller signals an
error to FreeBSD which returns the error to us.
In order to avoid this mess the libusb_get_string_descriptor_ascii()
call is replaced with the way libusb-1.0 works; which makes only a
single request to read the entire string descriptor.
- Adding fpga number to the ztex string representation
- Removing usb details from the ztex string representation
- First frequency set no longer reports a bogus old freq
Not yet using suspend and while we have fpga counting implemented it isn't being used yet, thus only the groundwork for quad board support is done, not actually working yet.
It seems that thread heap space is neither large nor consistent across OSs. Specifically on windows I couldn't get a large enough buffer for the whole bitstream in one go, so I'm reading incrementally now