thodg/cgminer

diff --git a/FPGA-README b/FPGA-README
index 7972514..7b9f004 100644
--- a/FPGA-README
+++ b/FPGA-README
@@ -1,6 +1,18 @@
 
 This README contains extended details about FPGA mining with cgminer
 
+Bitforce
+
+--bfl-range         Use nonce range on bitforce devices if supported
+
+This option is only for bitforce devices. Earlier devices such as the single
+did not have any way of doing small amounts of work which meant that a lot of
+work could be lost across block changes. Some of the "minirigs" have support
+for doing this, so less work is lost across a longpoll. However, it comes at
+a cost of 1% in overall hashrate so this feature is disabled by default. It
+is only recommended you enable this if you are mining with a minirig on
+p2pool.
+
 
 Icarus
 
@@ -12,45 +24,45 @@ There is a hidden option in cgminer when Icarus support is compiled in:
            long          Re-calculate the hash time continuously
            value[=N]     Specify the hash time in nanoseconds (e.g. 2.6316) and abort time (e.g. 2.6316=80)
 
-     Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
-     processing speed
-     If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
-     default values will maximise the MH/s and display it correctly
-
-     Icarus timing is used to determine the number of hashes that have been checked when it aborts
-     a nonce range (including on a LongPoll)
-     It is also used to determine the elapsed time when it should abort a nonce range to avoid
-     letting the Icarus go idle, but also to safely maximise that time
-
-     'short' or 'long' mode should only be used on a computer that has enough CPU available to run
-     cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
-     Any CPU delays while calculating the hash time will affect the result
-     'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
-     'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
-     corrects itself
-
-     When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
-     In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
-     scan hash time, for the first 5 nonce's or one minute (whichever is longer)
-
-     In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
-     value or the value specified
-     The optional additional =N specifies to set the default abort at N 1/10ths of a second, not the
-     calculated value, which is 112 for 2.6316ns
-
-     To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
-     bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
-     'short' mode and take note of the final hash time value (Hs) calculated
-     You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time
-
-     The Icarus code currently only works with a dual FPGA device that supports the same commands as
-     Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
-     If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
-     correct hash time nanoseconds value
-
-     The timing code itself will affect the Icarus performance since it increases the delay after
-     work is completed or aborted until it starts again
-     The increase is, however, extremely small and the actual increase is reported with the
-     RPC API 'stats' command (a very slow CPU will make it more noticeable)
-     Using the 'short' mode will remove this delay after 'short' mode completes
-     The delay doesn't affect the calculation of the correct hash time
+Icarus timing is required for devices that do not exactly match a default Icarus Rev3 in
+processing speed
+If you have an Icarus Rev3 you should not normally need to use --icarus-timing since the
+default values will maximise the MH/s and display it correctly
+
+Icarus timing is used to determine the number of hashes that have been checked when it aborts
+a nonce range (including on a LongPoll)
+It is also used to determine the elapsed time when it should abort a nonce range to avoid
+letting the Icarus go idle, but also to safely maximise that time
+
+'short' or 'long' mode should only be used on a computer that has enough CPU available to run
+cgminer without any CPU delays (an active desktop or swapping computer would not be stable enough)
+Any CPU delays while calculating the hash time will affect the result
+'short' mode only requires the computer to be stable until it has completed ~315 difficulty 1 shares
+'long' mode requires it to always be stable to ensure accuracy, however, over time it continually
+corrects itself
+
+When in 'short' or 'long' mode, it will report the hash time value each time it is re-calculated
+In 'short' or 'long' mode, the scan abort time starts at 5 seconds and uses the default 2.6316ns
+scan hash time, for the first 5 nonce's or one minute (whichever is longer)
+
+In 'default' or 'value' mode the 'constants' are calculated once at the start, based on the default
+value or the value specified
+The optional additional =N specifies to set the default abort at N 1/10ths of a second, not the
+calculated value, which is 112 for 2.6316ns
+
+To determine the hash time value for a non Icarus Rev3 device or an Icarus Rev3 with a different
+bitstream to the default one, use 'long' mode and give it at least a few hundred shares, or use
+'short' mode and take note of the final hash time value (Hs) calculated
+You can also use the RPC API 'stats' command to see the current hash time (Hs) at any time
+
+The Icarus code currently only works with a dual FPGA device that supports the same commands as
+Icarus Rev3 requires and also is less than ~840MH/s and greater than 2MH/s
+If a dual FPGA device does hash faster than ~840MH/s it should work correctly if you supply the
+correct hash time nanoseconds value
+
+The timing code itself will affect the Icarus performance since it increases the delay after
+work is completed or aborted until it starts again
+The increase is, however, extremely small and the actual increase is reported with the
+RPC API 'stats' command (a very slow CPU will make it more noticeable)
+Using the 'short' mode will remove this delay after 'short' mode completes
+The delay doesn't affect the calculation of the correct hash time
diff --git a/README b/README
index 58e89b9..bc1c59d 100644
--- a/README
+++ b/README
@@ -201,23 +201,23 @@ FPGA mining boards(BitForce, Icarus, ModMiner, Ztex) only options:
 
 --scan-serial|-S <arg> Serial port to probe for FPGA mining device
 
-     This option is only for BitForce, Icarus, and/or ModMiner FPGAs
+This option is only for BitForce, Icarus, and/or ModMiner FPGAs
 
-     By default, cgminer will scan for autodetected FPGAs unless at least one
-     -S is specified for that driver. If you specify -S and still want cgminer
-     to scan, you must also use "-S auto". If you want to prevent cgminer from
-     scanning without specifying a device, you can use "-S noauto". Note that
-     presently, autodetection only works on Linux, and might only detect one
-     device depending on the version of udev being used.
+By default, cgminer will scan for autodetected FPGAs unless at least one
+-S is specified for that driver. If you specify -S and still want cgminer
+to scan, you must also use "-S auto". If you want to prevent cgminer from
+scanning without specifying a device, you can use "-S noauto". Note that
+presently, autodetection only works on Linux, and might only detect one
+device depending on the version of udev being used.
 
-     On linux <arg> is usually of the format /dev/ttyUSBn
-     On windows <arg> is usually of the format \\.\COMn
-       (where n = the correct device number for the FPGA device)
+On linux <arg> is usually of the format /dev/ttyUSBn
+On windows <arg> is usually of the format \\.\COMn
+(where n = the correct device number for the FPGA device)
 
-     The official supplied binaries are compiled with support for all FPGAs.
-     To force the code to only attempt detection with a specific driver,
-     prepend the argument with the driver name followed by a colon.
-     For example, "icarus:/dev/ttyUSB0" or "bitforce:\\.\COM5"
+The official supplied binaries are compiled with support for all FPGAs.
+To force the code to only attempt detection with a specific driver,
+prepend the argument with the driver name followed by a colon.
+For example, "icarus:/dev/ttyUSB0" or "bitforce:\\.\COM5"
 
 For other FPGA details see the FPGA-README
 
@@ -795,7 +795,9 @@ A; Try the --net-delay option.
 Q: How do I tune for p2pool?
 A: p2pool has very rapid expiration of work and new blocks, it is suggested you
 decrease intensity by 1 from your optimal value, and decrease GPU threads to 1
-with -g 1.
+with -g 1. It is also recommended to use --failover-only since the work is
+effectively like a different block chain. If mining with a minirig, it is worth
+adding the --bfl-range option.
 
 Q: Are kernels from other mining software useable in cgminer?
 A: No, the APIs are slightly different between the different software and they
@@ -812,6 +814,13 @@ They are Field-Programmable Gate Arrays that have been programmed to do Bitcoin
 mining. Since the acronym needs to be only 3 characters, the "Field-" part has
 been skipped.
 
+Q: How do I get my BFL device to auto-recognise?
+A: They are only automatically recognised on linux, and no option needs to be
+passed to them. The only thing that needs to be done is to load the driver for
+them, which on linux would require:
+sudo modprobe ftdi_sio vendor=0x0403 product=0x6014
+
+
 ---
 
 This code is provided entirely free of charge by the programmer in his spare