/ FPGA-README
FPGA-README
1 2 This README contains extended details about FPGA mining with cgminer 3 4 5 For ModMinerQuad (MMQ) BitForce (BFL) and Icarus (ICA, BLT, LLT, AMU, CMR) 6 -------------------------------------------------------------------------- 7 8 When mining on windows, the driver being used will determine if mining will work. 9 10 If the driver doesn't allow mining, you will get a "USB init," error message 11 i.e. one of: 12 open device failed, err %d, you need to install a WinUSB driver for the device 13 or 14 claim interface %d failed, err %d 15 16 The best solution for this is to use a tool called Zadig to set the driver: 17 http://sourceforge.net/projects/libwdi/files/zadig/ 18 19 This allows you set the driver for the device to be WinUSB which is usually 20 required to make it work if you're having problems 21 22 With Zadig, you may need to run it as administrator and if your device is 23 plugged in but you cannot see it, use the Menu: Options -> List All Devices 24 25 You must also make sure you are using the latest libusb-1.0.dll supplied 26 with cgminer (not the libusbx version) 27 28 When you first switch a device over to WinUSB with Zadig and it shows that 29 correctly on the left of the Zadig window, but it still gives permission 30 errors, you may need to unplug the USB miner and then plug it back in 31 32 - 33 34 When mining on linux, but not using 'sudo' and not logged into 'root' you 35 may get a USB priviledge error (-3), so you may also need to do the following: 36 37 sudo cp 01-cgminer.rules /etc/udev/rules.d/ 38 39 And also: 40 sudo usermod -G plugdev -a `whoami` 41 42 If your linux distro doesn't have the 'plugdev' group, you can create it like: 43 sudo groupadd plugdev 44 45 Then reboot ... 46 47 - 48 49 There is a hidden option in cgminer to dump out a lot of information 50 about USB that will help the developers to assist you if you are having 51 problems: 52 53 --usb-dump 0 54 55 It will only help if you have a working FPGA device listed above 56 57 58 ModMinerQuad (MMQ) 59 ------------------ 60 61 The mining bitstream does not survive a power cycle, so cgminer will upload 62 it, if it needs to, before it starts mining (approx 7min 40sec) 63 64 The red LED also flashes while it is uploading the bitstream 65 66 - 67 68 If the MMQ doesn't respond to cgminer at all, or the red LED isn't flashing 69 then you will need to reset the MMQ 70 71 The red LED should always be flashing when it is mining or ready to mine 72 73 To reset the MMQ, you are best to press the left "RESET" button on the 74 backplane, then unplug and replug the USB cable 75 76 If your MMQ doesn't have a button on the "RESET" pad, you need to join 77 the two left pads of the "RESET" pad with conductive wire to reset it. 78 Cutting a small (metal) paper-clip in half works well for this 79 80 Then unplug the USB cable, wait for 5 seconds, then plug it back in 81 82 After you press reset, the red LED near the USB port should blink continuously 83 84 If it still wont work, power off, wait for 5 seconds, then power on the MMQ 85 This of course means it will upload the bitstream again when you start cgminer 86 87 - 88 89 Device 0 is on the power end of the board 90 91 - 92 93 You must make sure you have an approriate firmware in your MMQ 94 Read here for official details of changing the firmware: 95 http://wiki.btcfpga.com/index.php?title=Firmware 96 97 The basics of changing the firmware are: 98 You need two short pieces of conductive wire if your MMQ doesn't have 99 buttons on the "RESET" and "ISP" pads on the backplane board 100 Cutting a small (metal) paper-clip in half works well for this 101 102 Join the 2 left pads of the "RESET" pad with wire and the led will dim 103 Without disconnecting the "RESET", join the 2 left pads of the "ISP" pad 104 with a wire and it will stay dim 105 Release "RESET" then release "ISP" and is should still be dim 106 Unplug the USB and when you plug it back in it will show up as a mass 107 storage device 108 Linux: (as one single line): 109 mcopy -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0 110 modminer091012.bin ::/firmware.bin 111 Windows: delete the MSD device file firmware.bin and copy in the new one 112 rename the new file and put it under the same name 'firmware.bin' 113 Disconnect the USB correctly (so writes are flushed first) 114 Join and then disconnect "RESET" and then plug the USB back in and it's done 115 116 Best to update to one of the latest 2 listed below if you don't already 117 have one of them in your MMQ 118 119 The current latest different firmware are: 120 121 Latest for support of normal or TLM bitstream: 122 http://btcfpga.com/files/firmware/modminer092612-TLM.bin 123 124 Latest with only normal bitstream support (Temps/HW Fix): 125 http://btcfpga.com/files/firmware/modminer091012.bin 126 127 The code is currently tested on the modminer091012.bin firmware. 128 This comment will be updated when others have been tested 129 130 - 131 132 On many linux distributions there is an app called modem-manager that 133 may cause problems when it is enabled, due to opening the MMQ device 134 and writing to it 135 136 The problem will typically present itself by the flashing led on the 137 backplane going out (no longer flashing) and it takes a power cycle to 138 re-enable the MMQ firmware - which then can lead to the problem happening 139 again 140 141 You can either disable/uninstall modem-manager if you don't need it or: 142 a (hack) solution to this is to blacklist the MMQ USB device in 143 /lib/udev/rules.d/77-mm-usb-device-blacklist.rules 144 145 Adding 2 lines like this (just above APC) should help 146 # MMQ 147 ATTRS{idVendor}=="1fc9", ATTRS{idProduct}=="0003", ENV{ID_MM_DEVICE_IGNORE}="1" 148 149 The change will be lost and need to be re-done, next time you update the 150 modem-manager software 151 152 TODO: check that all MMQ's have the same product ID 153 154 155 BitForce (BFL) 156 -------------- 157 158 --bfl-range Use nonce range on bitforce devices if supported 159 160 This option is only for bitforce devices. Earlier devices such as the single 161 did not have any way of doing small amounts of work which meant that a lot of 162 work could be lost across block changes. Some of the "minirigs" have support 163 for doing this, so less work is lost across a longpoll. However, it comes at 164 a cost of 1% in overall hashrate so this feature is disabled by default. It 165 is only recommended you enable this if you are mining with a minirig on 166 p2pool. 167 168 C source is included for a bitforce firmware flash utility on Linux only: 169 bitforce-firmware-flash.c 170 Using this, you can change the bitstream firmware on bitforce singles. 171 It is untested with other devices. Use at your own risk! 172 173 To compile: 174 make bitforce-firmware-flash 175 To flash your BFL, specify the BFL port and the flash file e.g.: 176 sudo ./bitforce-firmware-flash /dev/ttyUSB0 alphaminer_832.bfl 177 It takes a bit under 3 minutes to flash a BFL and shows a progress % counter 178 Once it completes, you may also need to wait about 15 seconds, 179 then power the BFL off and on again 180 181 If you get an error at the end of the BFL flash process stating: 182 "Error reading response from ZBX" 183 it may have worked successfully anyway. 184 Test mining on it to be sure if it worked or not. 185 186 You need to give cgminer about 10 minutes mining with the BFL to be sure of 187 the MH/s value reported with the changed firmware - and the MH/s reported 188 will be less than the firmware speed since you lose work on every block change. 189 190 191 Icarus (ICA, BLT, LLT, AMU, CMR) 192 -------------------------------- 193 194 There are two hidden options in cgminer when Icarus support is compiled in: 195 196 --icarus-options <arg> Set specific FPGA board configurations - one set of values for all or comma separated 197 baud:work_division:fpga_count 198 199 baud The Serial/USB baud rate - 115200 or 57600 only - default 115200 200 work_division The fraction of work divided up for each FPGA chip - 1, 2, 4 or 8 201 e.g. 2 means each FPGA does half the nonce range - default 2 202 fpga_count The actual number of FPGA working - this would normally be the same 203 as work_division - range is from 1 up to 'work_division' 204 It defaults to the value of work_division - or 2 if you don't specify 205 work_division 206 207 If you define fewer comma seperated values than Icarus devices, the last values will be used 208 for all extra devices 209 210 An example would be: --icarus-options 57600:2:1 211 This would mean: use 57600 baud, the FPGA board divides the work in half however 212 only 1 FPGA actually runs on the board (e.g. like an early CM1 Icarus copy bitstream) 213 214 --icarus-timing <arg> Set how the Icarus timing is calculated - one setting/value for all or comma separated 215 default[=N] Use the default Icarus hash time (2.6316ns) 216 short=[N] Calculate the hash time and stop adjusting it at ~315 difficulty 1 shares (~1hr) 217 long=[N] Re-calculate the hash time continuously 218 value[=N] Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80) 219 220 If you define fewer comma seperated values than Icarus devices, the last values will be used 221 for all extra devices 222 223 Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in 224 processing speed 225 If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the 226 default values will maximise the MH/s and display it correctly 227 228 Icarus timing is used to determine the number of hashes that have been checked when it aborts 229 a nonce range (including on a LongPoll) 230 It is also used to determine the elapsed time when it should abort a nonce range to avoid 231 letting the Icarus go idle, but also to safely maximise that time 232 233 'short' or 'long' mode should only be used on a computer that has enough CPU available to run 234 cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough) 235 Any CPU delays while calculating the hash time will affect the result 236 'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares 237 'long' mode requires it to always be stable to ensure accuracy, however, over time it continually 238 corrects itself 239 The optional additional =N for 'short' or 'long' specifies the limit to set the timeout to in N * 100ms 240 thus if the timing code calculation is higher while running, it will instead use N * 100ms 241 This can be set to the appropriate value to ensure the device never goes idle even if the 242 calculation is negatively affected by system performance 243 244 When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated 245 In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns 246 scan hash time, for the first 5 nonce's or one minute (whichever is longer) 247 248 In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default 249 value or the value specified 250 The optional additional =N specifies to set the default abort at N * 100ms, not the calculated 251 value, which is ~112 for 2.6316ns 252 253 To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different 254 bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use 255 'short' mode and take note of the final hash time value (Hs) calculated 256 You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time 257 258 The Icarus code currently only works with an FPGA device that supports the same commands as 259 Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s 260 If an FPGA device does hash faster than ~840MH/s it should work correctly if you supply the 261 correct hash time nanoseconds value 262 263 The Icarus code will automatically detect Icarus, Lancelot, AsicminerUSB and Cairnsmore1 264 FPGA devices and set default settings to match those devices if you don't specify them 265 266 The timing code itself will affect the Icarus performance since it increases the delay after 267 work is completed or aborted until it starts again 268 The increase is, however, extremely small and the actual increase is reported with the 269 RPC API 'stats' command (a very slow CPU will make it more noticeable) 270 Using the 'short' mode will remove this delay after 'short' mode completes 271 The delay doesn't affect the calculation of the correct hash time