Mining Bitcoins with OpenWRT and RT-5350

Much respect and admiration goes to P_Shep on bitcointalk for the brilliant idea of compiling the CGMiner tool for the mipsel processor.  Read the original post here!

With this build, and an OpenWRT-capable router (even a $15 one), you can set up your own little desktop-free bitcoin mining rig in an evening.

What we’ll do is walk you through the process of transforming a simple HAME MPR-A1 clone into a lightweight and quasi-portable bitcoin miner.  The ENTIRE process.

It’s a relatively simple task, requiring about an hour or so of time and a bit of hacker hardware. What you’ll need is:


  1. An MPR-A1 or Clone like the MPR-L8
  2. A 3.3V USB to RS-232 Converter (maybe even a hacked one).  MUST be 3.3V!
  3. A powered USB hub able to provide enough current for your mining hardware.
  4. An old or disposable USB flash drive to act as an external HDD for the MPR-A1. We used the Kingston MicroSD reader and a dusty old 1GB TF card.
  5. Some Bitcoin Mining Hardware – we used the ASICMINER Block Erupter USB


  1. A serial console, such as Hyperterminal or Putty
  2. A TFTP server, such as TFTPD32
  3. Compatible OpenWRT firmware, compiled with USB storage, USB Serial, and a couple extras like screen.  Compile it yourself, or download our precompiled Barrier Breaker Build for RT5350 (32M DRAM).
  4. P_Shep’s mipsel build of CGMiner.  Or download from our local copy here

Step I – Flashing OpenWRT to the Device

It all starts with a serial connection to a generic HAME clone.  For reference, here’s the pinout of the serial port test points.  Click for a full size version.


Remember, setup is 57,600-8-n-1  and no hardware control.

  1. Connect the device to your PC through the 3.3V serial port.
  2. Connect the device to your router through a LAN cable
  3. Run TFTPD32 on your host PC, and set the current directory to the place you saved the firmware to.

Boot up, and get ready to quickly press the ’2′ key to tftp a new flash to the device.  Here’s what you’ll see flashing before you after the initial hardware config.

Please choose the operation:
1: Load system code to SDRAM via TFTP.
2: Load system code then write to Flash via TFTP.
3: Boot system code via Flash (default).
4: Entr boot command line interface.
7: Load Boot Loader code then write to Flash via Serial.
9: Load Boot Loader code then write to Flash via TFTP.

You choosed 2

2: System Load Linux Kernel then write to Flash via TFTP.
Warning!! Erase Linux in Flash then burn new one. Are you sure?(Y/N)

In order to have the device fetch and flash the firmware, we must now configure it with a bare minimum of network capability.  Use ipconfig /all or ifconfig on the host PC to determine it’s IP address, as well as the subnet, etc.  Ours was, so all of our meddlings will use 192.168.1.???.  Let’s continue with the flash process.

  1. Agree to an overwrite using the ‘Y’ key
  2. Set the “Device IP” to any unused IP on your network.  We used
  3. Set the server IP to the IP of the computer running the tftp server.
  4. Set the “Linux Kernel Filename” to 32MB_USB_SERIAL_SCREEN.bin or 16MB_USB_SERIAL_SCREEN.bin depending on your memory configuration.

Hit Enter.  The device should display a few T T T’s while connecting, then display a lot of ####’s as it downloads the firmware.  If it gets stuck in a retry/timout (T T T) loop, you made a typo in the IP’s, or your router does not allow TFTP from an IP it didn’t provide.  Throw that router away (it’s probably Belkin) and get one that doesn’t suck.  Several D-Links and a Cisco/Linksys all work fine for us, one single Belkin would not.

After download, the device will flash itself and restart.  Just wait a while.  You’ll see a crapload of dmesg output during the boot sequence, then it will sit quietly after preparing the “jffs2 filesystem”. Once you see this, it’s done

[   40.400000] jffs2_scan_eraseblock(): End of filesystem marker found at 0×0
[   40.440000] jffs2_build_filesystem(): unlocking the mtd device… done.
[   40.450000] jffs2_build_filesystem(): erasing all blocks after the end marker
… done.
[   48.520000] jffs2: notice: (1278) jffs2_build_xattr_subsystem: complete build
ing xattr subsystem, 0 of xdatum (0 unchecked, 0 orphan) and 0 of xref (0 dead,
0 orphan) found.

Hit enter to be rewareded with the OpenWRT banner, and a shell prompt.

BusyBox v1.19.4 (2013-04-17 21:38:28 EDT) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.—–.—–.—–.|  |  |  |.—-.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 BARRIER BREAKER (Bleeding Edge, r35917)
  * 1/2 oz Galliano         Pour all ingredients into
  * 4 oz cold Coffee        an irish coffee mug filled
  * 1 1/2 oz Dark Rum       with crushed ice. Stir.
  * 2 tsp. Creme de Cacao

Step II – Initial Configuration of OpenWRT

A) Set your password

Not only is setting a password a vital security measure, it also enables the SSH server for easy connectivity over the LAN interface (no serial port needed anymore!).

Below is an example of what you’ll see.  You type the bold part (duh).

root@OpenWrt:/# passwd

Then just follow the instructions to choose your password.  We suggest you do not use the word password.

B) Set up network

You’ll need to edit /etc/config/network to add your router’s IP address as the gateway, as well as a couple of dns entries to help the device find the outside world.  Use vi, and use a vi cheat sheet if you’re not familiar with this incredibly useful and arcane tool.

root@OpenWrt:/# vi /etc/config/network

Edit the interface ‘lan’  section to fill in the following items.

config interface ‘lan’
        option ifname ‘eth0.1′
        option type ‘bridge’
        option proto ‘static’
        option ipaddr ’′  <– set to any unused address
        option netmask ’′
        option gateway ’′  <– set to your router
        list dns ’′  <– set to your router
        list dns ’′  <– set to a trustworthy (ahem) dns like google

After you’re done, exit vi and restart networking to start using the changes.  You’ll get a handful of messages as your ever-promiscuous network interfaces hit the streetcorner.

root@OpenWrt:/# /etc/init.d/network restart

If it all seemed to work, try pinging our friend google.  If the address resolves and you get a ping back, you’re good to go.

root@OpenWrt:/# ping
PING ( 56 data bytes
64 bytes from seq=0 ttl=54 time=21.258 ms
64 bytes from seq=1 ttl=54 time=22.031 ms
64 bytes from seq=2 ttl=54 time=20.756 ms

C) Set up opkg configuration

In case you want to install more programs later (which you will), you will need to specify the proper hardware in opkg.conf.  Add the following three lines to the end of /etc/opkg.conf so the opkg tool knows where to go to get packages for this device.

root@OpenWrt:/# vi /etc/opkg.conf

And add the bold lines, so your file looks like this.

src/gz barrier_breaker
dest root /
dest ram /tmp
lists_dir ext /var/opkg-lists
option overlay_root /overlay
arch all 1
arch ramips 200
arch ramips_24kec 10

Now test opkg to see if it can see the package server.  If you get the download, you’re ready to install from the wealth of repository packages.  Paste that link below into your browser to see what’s there.

root@OpenWrt:/# opkg update
Updated list of available packages in /var/opkg-lists/barrier_breaker.

D) Test all USB peripherals (Hub, Flash Drive, ASIC Miner)

Really, this just consists of plugging each of the devices in, and watching for the recognition string.  You’ll see the following dmesg output appear in your terminal:

Plugging in the Hub

[ 1150.620000] usb 1-1: new high-speed USB device number 2 using ehci-platform
[ 1150.780000] hub 1-1:1.0: USB hub found
[ 1150.790000] hub 1-1:1.0: 7 ports detected

Plugging in the Flash Drive

[ 1197.260000] usb 1-1.1: new high-speed USB device number 3 using ehci-platform
[ 1197.420000] scsi1 : usb-storage 1-1.1:1.0
[ 1198.420000] scsi 1:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0272 PQ
: 0 ANSI: 0
[ 1198.760000] sd 1:0:0:0: [sda] 1995776 512-byte logical blocks: (1.02 GB/974 M
<a bunch of other stuff>
[ 1198.900000] sd 1:0:0:0: [sda] Attached SCSI removable disk

Plugging in the Block Erupter

[ 1275.350000] usb 1-1.4: new full-speed USB device number4 using ehci-platform

E) Optional – Turn off wifi.

In our build, wifi is enabled by default.  To turn it off, change “option_disabled” to 1 in /etc/config/wireless.  It may be nice to connect to the box wirelessly (it wants to act as an access point, naturally) but for security reasons, you may want to turn this off.

root@OpenWrt:/# vi /etc/config/wireless

option disabled 0  <– default, means this device will act as a hotspot


option disabled 1  <– change to this to disable wireless

Step III – Copying the OS to External Flash, and Setting Up EXTROOT

We’ll quickly run out of space in the onboard flash if we try to do anything interesting now, so the next thing we need to do is set up EXTROOT.  This is where we copy the entire OS from internal flash to our external USB flash drive, then tell the device to boot from the USB drive from now on.  Booting from USB will take slightly longer, but you’ll have tons of free space to work in.

NOTE: We did not put a swap partition on our flash drive due to wearout concerns.  Other people swear by it.  It’s probably not needed for mining, but may be useful if you’re running a web server off the device or otherwise hogging memory.  You can learn about how you may set up external swap here on the OpenWRT wiki.

But for now, we’ll just move the filesystem from internal to external.  We will first copy all files to USB, then set up the extroot configutation in the normal flash storage.

This way, if you want to fool around with the original settings you can simply boot up with the USB drive detached.  You’ll boot from internal flash and can muck with the configuration to your heart’s content.  This is better than doing the config first, THEN copying to external flash because this way it’s very apparent what configuration you’ve booted in to (so you know which files are actually valid).  This prevents the common error of booting to USB, then changing the fstab files (now on USB) and expecting these changes to occur on next boot.  They won’t.  Fstab is read from the original copy on internal flash, THEN the boot process is forked to external USB.  It can be forking confusing.  So first we copy, then we mod.

A) Copy the entire filesystem to the USB drive

This consists of mounting the USB stick we plugged earlier, and copying the whole filesystem to it using the tar command.  Here, our usb stick is the device “sda1″.  To find out what your usb stick was plugged, just ls the device directory /dev.  The device sda always exists, you want to find the first device after sda – here, sda1.

root@OpenWrt:/# ls /dev
bus                 mtd2                mtdblock1           random
console             mtd2ro              mtdblock2           sda
cpu_dma_latency     mtd3                mtdblock3           sda1  <-- lookie!
full                mtd3ro              mtdblock4           shm
kmsg                mtd4                mtdblock5           tty
log                 mtd4ro              mtdblock6           ttyS0
mem                 mtd5                network_latency     ttyS1
mtd0                mtd5ro              network_throughput  urandom
mtd0ro              mtd6                null                watchdog
mtd1                mtd6ro              ptmx                zero
mtd1ro              mtdblock0           pts

To actually copy the filesystem, we first make a temp directory.  Then we mount that directory as well as the usb stick, and use tar to copy all the files over.  In the 5th command (tar), YES, there are spaces between the dash, dot, and | there in the middle.  it will take a few minutes to copy.

root@OpenWrt:/# mkdir -p /mnt/sda1 /tmp/cproot
root@OpenWrt:/# mount –bind / /tmp/cproot
root@OpenWrt:/# mount /dev/sda1 /mnt/sda1
root@OpenWrt:/# tar -C /tmp/cproot -cvf – . | tar -C /mnt/sda1 -xf -
root@OpenWrt:/# sync
root@OpenWrt:/# umount /mnt/sda1
root@OpenWrt:/# umount /tmp/cproot

There you go, your whole filesystem is now copied to the flash drive, ready to act as the new “hdd” next time you boot.  All we have to do now is tell the device to boot from said drive.  That’s next!

B) Set up the “mount” section of fstab as follows

root@OpenWrt:/# vi /etc/config/fstab

Make the mount section look like this:

config mount
        option target   /home
        option device   /dev/sda1
        option fstype   ext4
        option options  rw,sync
        option enabled  1
        option enabled_fsck 0
        option is_rootfs 1

C) Make banner note

It’s useful to add a little note on the original banner, to warn us if the external boot didn’t work.  We use the echo command to quickly slap a single line to the end of the banner file residing in internal flash.  Remember to use >> and not >, or you’ll overwrite the whole banner file.  Which still works.

root@OpenWrt:/# echo “BOOTED FROM INTERNAL ROM!” >> /etc/banner

D) Reboot with USB drive attached.

root@OpenWrt:/# reboot

Now wait a while as the device shuts down and boots back up.   Other than seeing the unmodified banner, an easy way to tell if you’re running from external flash is to check how much disk space is free.  After the device has booted all the way to “br-lan entered forwarding state”, press enter to get console and execute a “df”.

root@OpenWrt:/# df -h

You’ll want to see a bunch of free space in “rootfs”, such as you see here.

Filesystem                Size      Used Available Use% Mounted on
rootfs                  955.2M     34.5M    872.2M   4% /
/dev/root                 2.0M      2.0M         0 100% /rom
tmpfs                    14.6M     80.0K     14.5M   1% /tmp
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/sda1               955.2M     34.5M    872.2M   4% /overlay

Once again, we must reiterate that if you happen to boot up sometime without the USB drive attached, the device will default to booting from internal flash.  This means you get your old configuration back, just like in step II.

This can be useful for debugging or other hacking, but be careful about changing things! OpenWRT requires a matching md5sum between internal and external flash before booting from an external device.  If you change anything when running from internal flash, you will need to copy /etc/extroot.md5sum (from internal flash) to /etc/extroot.md5sum (on the flash drive, of course) before trying to boot externally again.  Otherwise your “untrusted” usb drive will be mounted as overlay, and you’ll continue to boot from internal flash.

Step IV – Copy CGMiner and Associated Files

Your device has an ftp server (vsftpd) built in.  Open an FTP connection to your device, using the LAN address you put in to /etc/config/network.  Username: root, Pass: <whatever you chose>

Extract the cgminer zip file anywhere on your host PC, we will only FTP a few of the files to the device.  Basically the executable and the config file.  The serial driver is already included in our build.

Send the 1.12MB executable cgminer to /bin/

Send the 222 byte cgminer.conf to /etc/

Everything else (including the is not needed or included in the build.

Last, we must set permissions.  Back at the command prompt.

root@OpenWrt:/# chmod +x /bin/cgminer

You will now want to open the /etc/cgminer.conf file and add your pool information and login.  Or you can run cgminer with command line switches and ignore the conf file entirely.

Step V – Get Headless

If you haven’t switched to SSH at this point, it’s time to disconnect the serial port umbilical and get Putty-ing.  Log in with root and <your password>, and you’ll get the same command shell that you had been using over serial.  But now you’re using the tubes!

Step VI – Screen Command, and Mining!

Before we actually run cgminer, we must first suggest you get familiar with screen.  Screen is a way to run multiple sessions over the command line.  Yes, it’s already included in the build.

Aside from the obvious multitasking advantage, the real benefit for us from using screen is that if we disconnect or our SSH session dies,  our mining session continues to run.  You can connect again later and check in by attaching to the running screen session.  This feature is pretty much vital for running standalone.

The main command sequence in screen is Ctrl-a.  You type a C-a, then type the number of the session you want to hop to, or ” to list all sessions and pick one, or so on and so forth.  There’s too much to describe here, so always remember you can type C-a then ? to get the help screen.  Priceless.

Go ahead and start a session by running screen.

root@OpenWrt:/# screen

This session will become session 0.  You can run as many as you like, but for now just stick with session 0 to make it simple.

Finally, run cgminer now that you’re in screen session 0.  If you’ve filled out the config file, use the -c switch to point to the config file. Otherwise use the good old -o -u -p switches for server, worker, worker password.

You’ll be greeted with a slightly abbreviated version of the console output you know and love.  Accepts will scroll along vertically, and every 5 seconds the overall progress will be shown at the very bottom.

root@OpenWrt:/# cgminer -c /etc/cgminer.conf
 [2013-08-22 03:19:30] Started cgminer 3.3.1
 [2013-08-22 03:19:30] Loaded configuration file /etc/cgminer.conf
 [2013-08-22 03:19:30] Probing for an alive pool
 [2013-08-22 03:19:32] Network diff set to 50.8M
 [2013-08-22 03:20:01] Accepted 1e94aa19 Diff 8/1 AMU 0
 [2013-08-22 03:20:01] Stratum from pool 0 requested work restart
 [2013-08-22 03:20:02] Accepted 2ac1fced Diff 5/1 AMU 0
 [2013-08-22 03:20:29] Accepted 868dbf32 Diff 1/1 AMU 0
 [2013-08-22 03:20:30] Accepted c86017e9 Diff 1/1 AMU 0
 [2013-08-22 03:20:45] Accepted c0c54786 Diff 1/1 AMU 0
(5s):360.9M (avg):334.5Mh/s | A:19  R:0  HW:0  U:6.0/m  WU:6.0/m

There you go, you’re mining!  If you get disconnected, you can always reconnect and check all the running screen sessions with:

root@OpenWrt:/# screen -ls

And reattach to a running session with

root@OpenWrt:/# screen -r <sessionname>

Although there’s plenty more, that’s all you need to know to get up and mining quickly.  And more cheaply (and less power usage) than even a raspberry pi.  And it serves wifi as well – ain’t technology grand?

Good luck!  And if you strike it rich, throw a couple our way at 1GieyeEW5ZVcgzRvd5W4wsWFTU4C2WfYbh.

Until next time, happy hacking!


Posted in Hacks, Projects | Tagged , , , , | 4 Comments

Original Protek D620 Software Archive!

You may have seen some very old articles here about a datalogging multimeter called the Protek D620.  The support for this device (and maybe the manufacturer) are completely defunct.  So after recently digging out this old meter and using it to datalog some temperature data, we couldn’t find the *@#&@ CD with the datalog reading tool!

It doesn’t seem to appear anywhere on the web, either – drat!  After a long search, it was deemed necessary to revive a dusty old winbox to search further for an original copy.  Score!  An original archive of the tool was found, and will be posted here.  Doesn’t work on x64 machines, so you may need to revive your own dusty old winbox in order to get it working.  Head to page 2 for the download

Posted in Miscellaneous | Tagged , , , | Leave a comment

Openschemes FT232 JTAG SVF Player V1.0

NOTE: For anyone who downloaded the zip file on 6/21/13 or 6/22/13, please redownload – that version was missing an item.

A few years back, we coded up a bit-banged JTAG programmer for Xilinx CPLDs using the FT232.  It worked suitably well for flashing the Digilent CMOD to such purposes as a …Reset Glitcher, as well as some other projects.  We followed up with a few small bugfixes in the v0.11 release of the same tool.

Because it worked for the XC2C64 in the CMOD board, we mistakenly assumed it would work with any Xilinx CPLD, until a savvy user named Peter found that it was impossible to program the XC9572 using our tool.

We went back and forth on email over these issues, and it seemed that the ’72 would program fine for many data bits, and then just crap out.  Very puzzling…  Until we found Xilinx Application Note XAPP067, which explained that their chip just doesn’t program properly all the time.  Doh!  So rather than fix their device, Xilinx explained how users could implement a “failure recovery loop” to reset and retry the program or erase function.  Hmm?

They also explained that only if a device fails 32 times in a row should it be considered bad.  Huh?

And last, that about 1% of the bits in the 9500 series will fail.  What???  let’s take a step back – at about 52,000 bits in the device, that means that ON AVERAGE 520 bits will fail programming.  That seems really, really awful – doesn’t it?

Continue on to page 2 to hear the dramatic conclusion..

Posted in Hacks, Projects | Tagged , , , , , , , | 5 Comments