to detect a totally non working fpga we only do that if the last
round had some valid nonces.
if we would count the errors the automatic megahertz adaption
would drop and never recover.
the ztex bitstreams gives back the latest checked nonce and
its hash7 value and two possible solutions.
every 250ms the latest nonce is checked and compared with hash7
to count hw errors and adapt the MHz value. one change is to
use the solutions even if the latest nonce is not correct. the
original java ztex code also does it this way.
since the second solution is often not correct we have alot
of hw errors. now we always check the second solution before
we submit it to the cgminer main code.
the java code also ignores all hw errors 500ms after a sendHash.
we now do the same. this can possibly yield in a higher MHz rate.
but the chance is so low nobody will ever notice in practice.
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.
