Topic: Block Erupter USB *branding* (Read 4311 times)
Nice find, thanks for the custom hex file. Shell script works great!
Here's an (untested) (edit: now tested and confirmed to work well) BASH script to program multiple devices with unique serial numbers:
Code:
#!/bin/bash
EEPROMHex='eeprom-content.hex' # File used for manufacturer brand
Product='Block Erupter Sapphire'
SerialPrefix='Foo-' # Prepended before 8-digit serial number
SerialNoFile='last-serialno' # File holds the last allocated serial number
if ! [ -e "${SerialNoFile}" ]; then
echo "WARNING: Initializing ${SerialNoFile} file (this should only happen ONCE EVER)" >&2
echo '10000000' > "${SerialNoFile}"
fi
i="$(<"${SerialNoFile}")"
for dev in $(lsusb | perl -nle 'm/(\d{3}).*?(\d{3}).*CP210x/ && print "$1/$2"'); do
let ++i
echo "$i" >"${SerialNoFile}"
./cp210x-program -m $dev -w -F "$EEPROMHex" \
--set-product-string="$Product" \
--set-serial-number "${SerialPrefix}$i"
done
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected?
IMO, people should have the right to do what they want with their own property: I would opt not to buy from a vendor who put any locks in place, just on principle, if there was an alternative.Maybe I don't want my Ford to advertise the manufacturer, so I want to sand it off.
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected?
IMO, people should have the right to do what they want with their own property: I would opt not to buy from a vendor who put any locks in place, just on principle, if there was an alternative.I can see both sides of this. Yes, it is yours to do with as you please. But branding implies more, an identification of source of origin. With out a lock, it is like buying a gun with the serial number ground off. I'd want my Ford to say "Ford" on it, Not Tata because the previous owner thought the company's name was cute. Without a lock, this is just a novelty.
I think their code does that, but I am not sure. If it does, one can only hope nothing bad comes of it (ie, don't put an explosive controller on a CP210x chip connected to a mining rig 
)
)Damn, there goes that idea for world domination! I was thinking about something that blows up a bank every time you find a share!
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected?
IMO, people should have the right to do what they want with their own property: I would opt not to buy from a vendor who put any locks in place, just on principle, if there was an alternative.
I kind of like this idea. It would be cool if each erupter had a unique serial number. but to be meaningful, the serial number should be set by the manufacturer, not the wholesaler or retailer. I could see the argument for the Product ID being set by the manufacturer as well so they would all be the same product. But there is precedent for retailers rebranding things as their own. I know there was a time when Radioshack stereos were Panasonic with a different face plate.
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected?
I do have a question though, couldn't i use the same software to go in and change what someone else put in? can it be write protected?
Yes if you can find some other device on the planet that accepts my specific Icarus work item and responds with the expected nonce, then cgminer will think it is indeed an AMU
Likelihood approximately zero.
I was thinking more of some device that behaves poorly when it receives the specific Icarus work item used to probe it Likelihood approximately zero.
Still pretty unlikely, but IMO very much non-zero.
Does CGMiner using the WinUSB driver have this same problem? Just curious, here.
Current cgminer simply looks at the chip.idVendor = 0x10c4,
.idProduct = 0xea60,
Yes if you can find some other device on the planet that accepts my specific Icarus work item and responds with the expected nonce, then cgminer will think it is indeed an AMU
Likelihood approximately zero.
... I will however add, that adding a unique serial number would be advantageous once I complete the zombie code in cgminer that I started back in January
At the moment the hotplug devices are 'plugged' in as a new cgminer device.
If you pull out and plug in a device (or it disconnects and reconnects) the old device will go ZOMBIE and the new device will get a new number.
(it's been like that since January)
I've just never got around to 'plugging' them back into the old device if there was a match.
The iSerial will be one of the items that will be used to select the old device and ensure a match
(but of course there will be a bunch of rules of how it decides)
Does CGMiner using the WinUSB driver have this same problem? Just curious, here.
In theory, yes: there is (without this) no way to identify an Erupter distinct from another CP210x-based device.In practice, it's possible the cgminer developers have chosen to just probe anything CP210x-based regardless of whatever devices might be using it.
I think their code does that, but I am not sure. If it does, one can only hope nothing bad comes of it (ie, don't put an explosive controller on a CP210x chip connected to a mining rig
)BFGMiner can also do that, but I think it's safest not to make any assumptions, so it requires the -S all option.
Does CGMiner using the WinUSB driver have this same problem? Just curious, here.
Block Erupters currently come from Bitfountain with the default USB strings of the CP210x UART chip they used:
Since this can (and probably is) used by other, non-mining devices, BFGMiner cannot safely probe it for a miner.
Future versions will look for the iProduct string "Block Erupter" to autodetect, and track statistics better with unique serials.
(If you don't brand your device, it will still work just like it does now!)
Even if you don't use BFGMiner, you might be interested in branding it just for fun, or to distribute to customers if you are a vendor.
With a handy program for programming this chip, these can be branded.
Since this program does not support changing the iManufacturer, I had to go to some extra effort for that.
Here are two EEPROM "hex" files: Bitfountain and BTCGuild
You can use them like so:Then you get:
Editing the hex files for other vendors shouldn't be very hard, but if any vendors would like me to assist in that, send me a PM.
Note: I had to apply a small patch to get cp210x-program to work for me:
Code:
iManufacturer 1 Silicon Labs
iProduct 2 CP2102 USB to UART Bridge Controller
iSerial 3 0001
Since this can (and probably is) used by other, non-mining devices, BFGMiner cannot safely probe it for a miner.
Future versions will look for the iProduct string "Block Erupter" to autodetect, and track statistics better with unique serials.
(If you don't brand your device, it will still work just like it does now!)
Even if you don't use BFGMiner, you might be interested in branding it just for fun, or to distribute to customers if you are a vendor.
With a handy program for programming this chip, these can be branded.
Since this program does not support changing the iManufacturer, I had to go to some extra effort for that.
Here are two EEPROM "hex" files: Bitfountain and BTCGuild
You can use them like so:
Code:
./cp210x-program -w -F eeprom-content.Bitfountain.hex --set-product-string='Block Erupter Sapphire (Red)' --set-serial-number=ljr0001
Code:
iManufacturer 1 Bitfountain
iProduct 2 Block Erupter Sapphire (Red)
iSerial 3 ljr0001
Editing the hex files for other vendors shouldn't be very hard, but if any vendors would like me to assist in that, send me a PM.
Note: I had to apply a small patch to get cp210x-program to work for me:
Code:
diff -r d852ade43170 cp210x/usb.py
--- a/cp210x/usb.py Fri Sep 10 17:14:59 2010 +0200
+++ b/cp210x/usb.py Fri Jul 05 03:45:45 2013 +0000
@@ -17,7 +17,7 @@
dll=cdll.LoadLibrary("libusb.dylib")
elif sys.platform == 'linux2':
PATH_MAX = 4096
- dll=cdll.LoadLibrary("libusb.so")
+ dll=cdll.LoadLibrary("libusb-0.1.so.4")
else:
raise NotImplementedError("Platform %s not supported by usb.py" % sys.platform)
except OSError:
Jump to: