How to modify a $20 Chromebook into a VNC Server for mining

I recently posted about using HiveOS to remotely manage your miner via their built in SSH shell. Thanks to u/SailsAk on Reddit for making a point that you can use a dedicated desktop or laptop to also remotely manage your miners for free with Google’s Remote Desktop.

That got me thinking, can I use a cheap Google Chromebook I have laying around to do this. Turns out, it is a big NO with Google’s own built in Remote Desktop, which I find ironic. So now what, do I buy cheap PC to do this, maybe find an old laptop on Ebay? As Kevin O’Leary  (aka Mr. Wonderful) would say, “Stop the madness, there’s got to be a better way.” OK buddy, I’m going to find it…

Toshiba Chromebook 2

$20 is what it takes, don’t believe me? Check the link out, they’re out there. What most folks don’t realize is that hidden inside those Chromebooks is actually a useful Linux based PC when you know how to unlock them. There are a few steps to follow in order to do it, and some of the newer Chromebooks allow you to go into “Developer Mode” and make life even easier, but I like a challenge.

Ubuntu Operating System

I chose to install Ubuntu on mine, it’s a simple version of Linux, has a good GUI, and supports the bare bones of what I needed; USB to ethernet port, RealVNC, and cheap. There are a few things you have to tweak, which will void any warranty, but if you spent only $20 then I wouldn’t worry about it.

FASCINATINGCAPTAIN.COM

I stumbled onto the FascinatingCaptain.com website and I have to say it was probably one of the single best, and easiest, walkthroughs I’ve ever done. I won’t bother going into all the details, he nailed it and I encourage you to check his site out, but will talk about the steps briefly.

Steps to Install Ubuntu

1. Backup data (I didn’t bother since I had nothing on it.)

2. Enter Developer Mode (by holding down ESC and Refresh while pressing power.)

3. Open the case and remove the metal sticker protecting write mode on the BIOS.

4. Install the modified BIOS (Available here.)

5. Download (on another computer) Ubuntu and burn the .iso to bootable USB drive (using something like BalenaEtcher.)

6. Boot into your live USB Ubuntu drive and do the standard install.

Once you’re done with the install reboot and remove the USB drive. Set your password, make sure your wifi is on, you’re a power user.

Now that you’ve got your Linux Chromebook unleashed, it’s time for the slightly trickier (sometimes) part, install RealVNC server. The reason I chose Ubuntu is that it’s more user friendly when installing certain packages/program. RealVNC is one of those that can either work right away or you’ll spend days running Linux commands to only make things worse before you wipe clean and reinstall and start from scratch. It will probably work right away after that of course…

Installing RealVNC Server

First, go on the RealVNC website and Activate a Home Subscription for your free RealVNC account and to activate Home. Once you enter your email to start, you’ll be sent the download link to get started on the install.

For this I’ll actually defer to the RealVNC help pages. Once again, which is common with Linux, there are great walkthrough instructions out there. I’ll do the same as above, give the basic steps and any comments, but leave the real meat of the steps to the experts.

Steps to Install RealVNC Server

1. Download the x64 .deb file.

2. Install the program by running “sudo apt install ./<downloaded program>”.

3. License and start the server using the vncsetup-helper script.

This should now have the VNC server running on your Chromebook. You may need to reboot however. Once you reboot the server should start automatically on boot and you should see a small icon on the upper right. Click on that to configure your account.

Once your VNC Server is setup and attached to your RealVNC account you should be able to go on to your home computer (or mobile device), launch RealVNC viewer, login and select the remote computer from the team you setup from the RealVNC website.

If you made it this far without any problems, congrats! It took me a day of tinkering around but I finally got it and summed up my steps (that worked) in this post. Hopefully you have the same amount of luck as me or are more of a Linux nerd.

For those that dislike reading, the RealVNC install is all summed up in the video below as well:

Using HiveOS Shell to Fix Problems Remotely

If you’re like me you’re always wondering how you can tweak or fix every little problem with your miner. I’m very rarely in front of my miners, or even on the same network, but I’m always checking to insure they are running smooth. Most of the time they are, but as the months wear on, seasons change, chips and boards strain, you may find yourself with equipment that doesn’t run like it used to.

If you’re able to get on the same network as your miners, then it’s an easy day. But what if you can’t, what if they’re remote or you’re out of town. We all know the world ends if we have even 1 hour of downtime on one of our miners. Well if that’s how you feel too, then keep reading because I may have an idea that works for you.

A quick caveat, this is specifically geared towards HiveOS firmware. If you’re not running this then you won’t be able to access your miner using this method.

Also a word of warning, be careful what you do here. If you’re not comfortable manually editing the files or using a unix/linux editor then this may not be for you. I use vi, which is a built in editor to the unix/linux OS. It takes a little getting used to if you’ve never played with it, as it’s command line only, but it does the trick once you know your way around.

How to remotely connect to your miner

The first thing you need to do is get in front of a computer and log into your HiveOS farm. I’ve done it from my phone but, at least for me, life is so much easier on a computer. Once logged in you need to click on the specific miner you wish to connect to and pull up their status screen. From there you’ll see a toolbar on the top right, the 4th item in (appears like >_) is the run command shell, click on that and you’ll see a pop-up similar to below.

You will see a pop-up that says, “Worker Commands” and it will list all your recent commands, which may differ from what you see above. From here simply type in, “hssh start” and you’ll start the process of creating an ssh session to your miner. It can take anywhere from a few seconds to a few minutes to create the ssh session so be patient. Once the ssh session is ready you’ll see the status update, “> Hive Shell” with a pop-up link next to it, as seen below.

Once the, “> Hive Shell” pop-up link appears click on the box with the arrow pointing out of it to start the shell. Depending on your network, it will either launch the shell directly or give you another screen with a link as seen below. If you get the screen below, click on the blue highlighted text under, “Web-Link:” to launch the shell.

Your shell should start up and show you the miner you’ve attached to, as well as the time/date and IP and MAC addresses. It should look similar to the screen below.

So now we are connected to our miner, what next? This is where I caution folks, be very careful what you do when you’re in here. I would limit where you go and what you view/edit. I would limit my adventures to just the config directory right off root. To get there simply type, “cd config” hit enter and you’ll be in the directory that contains your base configuration files for the miner settings.

Since we are editing configuration files you’ll actually need to restart your miner after you’re done to have the changes take effect. This is good if you accidentally change something and save it, never fear, you haven’t messed things up yet. Simply go back and undo the changes before restarting, or don’t restart at all.

CONFIG.CONF

In the config.conf file we have the ability to change several items that may help keep the mining running smooth. If you’re going to modify this I strongly suggest making a backup first, copying it to a new name that you can restore if things go south (i.e. config.conf.old.)

If we want to manually change the frequency of a chain (useful if you’re getting a significant number/thousands of HW errors per day) you can edit the bitmain-freq for the specific chain (i.e. bitmain-freq1 for chain 1.) These are whole numbers that correspond with the normal drop down menus. For reference, 384 would be for the stock L3+ and 450 is for the stock L3++.

The next modification you can do is manually set the chain voltage. I’ve found this is extremely useful for chains that get a fair share of HW errors (hundreds per day.) This is set by a number between 1-256 (makes it simple for the DAC), but it’s not as complicated as you think. If I have chain 1 that I’ve initially set to 9.50V, I can bump that up to 9.62V by changing bitmain-voltage1=225 to bitmain-voltage1=205.

Here are some common voltage values found in the file.

145 = 9.98V

175 = 9.80V

205 = 9.62V

225 = 9.50V

If you have several asics that are going bad (i.e. the dreaded “x”) you can also bump up the bitmain-x-restart-threshold to something greater than 3.

MANUAL_FREQS.TXT

In the manual_freqs.txt file we are able to set the frequency for each asic on each chain. This file is created by the HiveOS firmware when running autotune or setting individual chip frequencies from the advanced menu options on the GUI. I haven’t modified this file in the past as it’s difficult to narrow specific problems down without logging directly in on the same network and running the GUI to see how each asic is performing from the advanced menu.

OTHER .CONF FILES

As you can see there are other files that contain configuration information as well. I’m not touching those specific files in this article as those are easily maintained through the HiveOS farm menus and it’s more likely to cause issues if you attempt to modify them from the ssh shell.

CGMINER.CONF – Stores your mining pool information.

AUTOTUNE.CONF – Stores the most recent autotune configuration.

NETWORK.CONF – Stores network info, such as DCHP or static IP, and hostname.

WATCHDOG.CONF – Stores information on when a restart would be initiated.

EXIT

When you’re done making edits, or just browsing around, make sure to type in, “exit” in the shell and then close the window. This insures the ssh session closes properly.

MINER RESTART

Once you’ve made your changes and exited the ssh session make sure to go back to the “run command” button from your menu (the “>_” button.) This time simply type, “miner restart” into the Worker Commands box and your miner will restart and apply your changes. You can also simply select the power icon and restart from there as well.

I hope you found this useful, please feel free to hit me up with questions or comments.

No chips, no temp, no hash, no problem!

Hey all,

How many times have you seen a post by someone that has a hash board that doesn’t recognize all the ASICs on board, has no temperature reading, and isn’t hashing or the hash rate starts then rolls down to zero?

Well, I’ve seen it a lot, and now just experienced the fun. I had an L3+ hash board I bought on Ebay that was a “FOR PARTS ONLY” so I took that as a challenge. When I first plugged it in it actually worked properly, so much so that I installed it into one of my L3+ units thinking I just hit the gold mine. Well, as soon as I put it in it started having issues; all ASICs found but no hashing, 56 ASICs found the next time, then 0, and so on.

I followed a few simple steps to work through the problem and viola, within 15 minutes I narrowed the problem down to one of the LDO’s that was failing. Using a heat gun I removed the part, replaced it with a similar part (LN1134), a little solder paste and a little heat and that bad boy mounted right down. I find with these smaller parts it’s easier to use solder paste, smear a little on to the pads, the heat gun will reflow it and pull the part on to the pads fairly well.

I put a quick video together to show the process of finding the failure, as always love the feedback and any experiences similar or not.

120V or 240V, what’s right look like?

I’ve seen a lot of posts about crypto miners (all types and brands) where people are having issues such as no hashing, low hash rates, or errors connecting to pools. One thing you should be prepared for, if you ask the Internet what’s wrong, is that you’ll get no shortage of answers. We are in a community that’s more than willing to help, give an idea or two, but sometimes the good ideas and willingness to help aren’t always in line with what the data is telling us.

I’ll stick with some more specific problems I’ve seen over the last few months, and that’s dealing with the power supply for the miners. First and foremost, a 240V supply is superior to a 120V supply (for mining) as it allows us to fit more miners/larger miners per circuit. A standard 120V residential outlet can safely output 1440W, which is enough to carry just a few types of miners. About the largest 120V residential outlet you’ll find is 20A (30A is far less common but exists.) This is by design as wire size increases with amperage. So once you get above 20A you’re having to get much larger wire sizes (10 gauge or larger) which makes for a much harder (and more expensive) run of cable. 

QUICK NEC LESSON

Now let’s take your standard electric over, water heater, or a couple S17 Pro miners. Each of these situations require around ~4500W. If we tried to run this on a 120V system (not saying they would, but stick with me here) we would need at least a 50A breaker and 6 gauge wiring. That’s because 50A gives us 4800W after taking the 80% rule into account.

Two problems here, first is if we have a 100A service panel in our home, that’s half your power (roughly speaking.) Second, I can run the same (actually more) power over just a 30A 240V circuit (5760W) and only need 10 gauge wire (commonly available in Romex style.) Now let’s see the cost savings as well, 10 gauge Romex runs about $1.50 a foot whereas the equivalent 6 gauge wiring runs about $3.50 a foot and is a bear to work with. 

Conclusion on this, you can run twice the power over the same size wire by going 240V, essentially doubling the amount of miners you can use on that line.

BACK TO THE PROBLEM

OK, back to the problem at hand. Why is my miner not hashing and why are people telling me it’s my 120V power supply. That’s a great question, and probably not the right answer you’re getting from everyone.

A power supply is generally rated in the power (watts) it outputs. This varies slightly with input voltage in the case of power supplies that allow 100-240V, however the output rating is generally close whether it’s 120V or 240V unless otherwise specified. In the case of the APW3++, it’s significantly different. Its rated for 1600W @ 240V but only 1200W @ 120V, more than enough to run an L3+ @120V but not enough for most S9’s (most common problem I hear about.)

Now the question, will that affect my hash rate. Short answer is yes, but it’s more likely to overload your power supply and cause a thermal shut down, which will shut down the entire supply and your unit won’t work at all.

The long answer is that you probably won’t have a situation where your unit isn’t hashing at all. Start looking at the other posts and suggestions folks are giving. But make sure that whatever you are running is supported properly by the power supply you are using.

In the case of the APW3++, it can pump out 133A @ 12V (1596W) when using a 240V input, however with a 120V input it only pumps out 100A @ 12V (1200W.) If you’re using an S9 (14TH) you need ~1370W to run, therefore if you run the supply at 120V it will “most likely” shutdown due to the lack of available power.

Power supplies are meant to pump out amperage at their voltage rating, up until they can’t pump out anymore. At that tipping point there is (or should be in any UL rated power supply) an overcurrent protection that shuts it down completely, it’s not a taper, it’s a hard shut down.

A Walkthrough of the L3+ Hash Board (1st Edition)

Like many of you I’ve had some frustrations with my L3+ units, mostly surrounding the hash boards and various failures. Bitmain previously released an L3+ Maintenance Guide  in 2018 that did a great job summarizing some basic failures, how to identify, and then the Internet took over with the various fixes. I’ve reviewed Bitmain’s manual many times and have boiled down most of the pertinent info below, as well I’ve added my two cents. Make that more than two cents, I hopefully dive into some of their topics a little deeper and attempt to explain it in more detail and make it easier to understand. Their manual can be cryptic and it’s missing a lot of the middle pieces tying some things together so I attempted to fill in the blanks as well. Some of the graphics and schematics I pulled from their document so I’d like to acknowledge them here.

This is meant to be a living document so I’ll update it as I find new solutions to problems. Furthermore there are several areas where I couldn’t find enough information or wasn’t able to reverse engineer how something functions so I denoted those with an assumption note.

If you need to order any of these parts you can find a link to vendors here.

I’m all about sharing so I’m putting this all out there to help everyone out, but please, if you re-use some of this give me a shout-out. I’ve had things plagiarized in the past and while it’s not anything earth shattering, it’s also a work in progress so I don’t want someone putting info out there that’s not complete nor something they can explain as to how they came to a specific conclusion. It not only makes them look bad, but it can cause distrust in the data being put out there. Long story short, share it and shout outs.

A general note regarding testing voltages at the various test points. You must have the hash board power and I/O cable plugged in and a working L3 control board or test fixture. The PIC (which provides the signal to turn on the 10V) won’t initialize the 10V buck controller until it receives the programming information from the control board, therefore not only the 10V but the 14.2V and the individual power regulators won’t have power to function.

Another quick note, if you don’t have one, getting a hot air rework station will make some of these fixes easier. You can pick up a station complete with a hot air gun and soldering iron for about $50, I use the FEITA 8586 SMD Hot Air Rework Station from Amazon.


PIC (programmable interface controller)

U3 (U74 on V1.6) is a 16LF1704/5 8-bit microcontroller PIC (programmable interface controller.) This is what makes the hash board, well, hash. If this is not programmed properly the hash board may exhibit all sorts of strange errors, anything from missing chips to bad temperature readings, to no or partial hashing, or the board not being recognized at all. 

The PIC takes the frequency and voltage information from the L3 Control Board (what you set them at through the software interface) and adjusts the voltage output and frequency for the BM1485 chain. The PIC communicates with the other ASICs and ICs through I2C (SDA, SCL, and GND) which basically is an IC to IC communication protocol.

It is possible to reprogram this from code from your other hash boards which I will cover in another post at a later date (it’s quite an in-depth process and involves using a Pickit3 programmer and a little luck.)

Common Failures related to U3 (PIC)

No 10V found (measured at both sides of C948 or between either pin of L2 and ground.)

Improper voltage (less than 10V) measured at C948.

  • Your buck converter may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part. Depending on the voltage it puts out you may still be able to run at a lower frequency and have it work. I have one board with a failing buck converter (it only puts out around 8V but it varies) and I’ve tested out various frequencies and actually have it working up to 300MHz. That’s more of an FYI and something my curiosity had me research. You should always conduct the repair before operating them in abnormal conditions, I’m just waiting for a replacement part at the moment.

Temperature Sensor

U87 (U88 on V1.6) is a T451/TMP451 temperature sensor. This is powered by the 1.8V voltage regulator in the first chain. You can get failures if the voltage regulator (U86 on V1.6 hash board) is damaged by a voltage spike/surge.

Common Failures related to U88 (Temperature Sensor)

“Failure to get temp data” error in L3+ Kernel log.

  • Check voltage levels between pin 1 (1.8V) and pin 5 (GND), improper voltage from the first LDO chain can lead to a failure of the temperature sensor working properly.
  • Your temperature sensor may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part.

BM1485 ASIC

There are a total of 72 BM1485 ASIC’s on-board the L3+ hash board. There is no data sheet readily available for this but what I have gleaned from info they’ve put out there aren’t too many failures that are easily tied to these (at least nothing that’s easy for a DIY fix.) These are powered by 12 individual 1.8V power domains.

(*Note: assumption) The clock signal comes from Y1, a 25 MHz crystal, and each board communicates with each other through the CI/CO signals for synchronization.

If one BM1485 in the chain goes bad, it may break the communication to BM1485’s down the line. 

Without a data sheet there is quite a bit of mystery behind how this actually works, but a little reverse engineering and research has led me to assume some of the following (key word is assume):

(*Note: big time assumptions here)

The frequency on each BM1485 (as set in your “Miner Configurations” pages) is set through programming received on CI/CO (command input/output) and RI/RO (respond input/output.) A command string is sent to the BM1485 to set the PLL divide for the various frequency levels on the BM1485. 


1.8V Power Domains for BM1485

The L3+ has a total of 72 ASIC chips spread across 12 voltage domains (with 6 BM1485’s each.) Each voltage domain is controlled by a 1.8V voltage regulator that has changed over various version of the hash board.

* Version 1.5 and earlier hash boards – One SPX5205M5-L-1-8 1.8V voltage regulator (pkg SOT23-5) for each of the 12 voltage domains (6 – BM1485 ASICs per domain.)

* Some versions of the hash board have also used the SGM2202-1.8 (pkg SOT23-5.)

* Version 1.6 hash board – U75, U76, U77, U78, U79, U80, U81, U82, U83, U84, U85, and U86 are LN1134A182MR 1.8V voltage regulators (pkg SOT23-5L) for each of the 12 voltage domains (6 – BM1485 ASICs per domain.)

These are extremely susceptible to damage from a voltage spike out of the boost circuit. To measure the output of each one you need to measure between pin 2 and pin 5. You can measure the input voltage between pins 1 or 3 and pin 5.

Common Failures related to 1.8V Voltage Domains

ASICs showing as “x” or no ASICs found.

  • Check voltage levels at the following test points on each voltage domain (set your ground lead on the negative size of the capacitor closest to each set of the test points.) Make sure you have the boards plugged into power and I/O cables to the control board. Without this the hash board won’t initialize the voltage domains.
  • RST – 1.8V
  • BO – 0V
  • RI – 1.6V – 1.8V
  • CO – 1.6V – 1.8V
  • CLKO – 0.9V

If you encounter a voltage domain that does not output 1.8V on pin 5 of the voltage regulator then it most likely should be replaced. It’s common for these to go out, especially during voltage spikes. The boost circuit has been known to knock the later domains (ASICs 49-54, 55-60, 61-66, and 67-72) when they fail.


10V Circuit

U1 is a LM27402 synchronous buck controller. On the V1.5 it is called U74, and on the V1.6 it is called U200. On versions 1.5 and later it is a uP9305W synchronous buck controller and has other components not originally on the earlier versions.

This output value is set by the PIC and is derived from the value that the user selects in the firmware (i.e. if you change the chain voltage from the “Miner Configuration -> Advanced Settings” page this is where that voltage changes.)

Q1, Q3 (not installed), Q4, and Q5 are THPR9003NL MOSFET N-Channel Switching Regulators. These rarely fail and they are fairly difficult to isolate.

On version 1.6 there are additional components for the 10V circuit, Q30 and Q32 are 8040 NPN Silicon Epitaxial Planar Transistors, Q31 and Q33 are a 6040 PNP Silicon Epitaxial Planar Transistors.

Common Failures related to the 10V circuit

Improper voltage (less than 10V) measured at C948.

  • Your buck converter may have failed or may have cold solder joints. First try reflowing the joints and if that doesn’t work, replace the part. Depending on the voltage it puts out you may still be able to run at a lower frequency and have it work. I have one board with a failing buck converter (it only puts out around 8V but it varies) and I’ve tested out various frequencies and actually have it working up to 300MHz. That’s more of an FYI and something my curiosity had me research. You should always conduct the repair before operating them in abnormal conditions, I’m just waiting for a replacement part at the moment.

14.2V Boost Circuit

U111 is an RT8537 switching power supply. This is used to boost the 10V supply (coming through the inductor L2) to 14.2V. It’s generally considered the most finicky part of the hash board itself and seems to fail quite often. Early on Bitmain discovered that components were oxidizing and therefore leading to failure so they started covering the circuit in epoxy. Why you may ask? I have no idea why this oxidizes any more or less than other parts of the circuit, but they seemed convinced this would fix the problem. In the end of the day, nope, they still fail and we still add in external booster circuits

Basically this circuit boosts 10V from the buck controller to 14.2V. L1 is used to store the energy for the boost and D1 isolates the 14.2V BOOST_OUT through reverse protection. When you install an external boost circuit you have to remove D1 to eliminate the possibility of interference from the old boost circuit.

Failure of the boost circuit can also cause damage to the 1.8V voltage domains.

Common Failures related to the 14.2V boost circuit

Improper voltage at D1 (less than 14V, generally much less.)

  • Your on-board boost circuit may have failed. Install an external boost circuit  and remove D1 to isolate the on-board boost from the external boost.
  • Your 10V may also be off from the buck controller, this should be researched and solved before assuming the boost circuit is bad.

Q10 is a 1AMP SOT-23 package which I believe is a MMBT3904 NPN general purpose amplifier. More on this later once I figure out what’s going on here.


Y1 is a 25.000 MHz crystal that’s used as the clock signal for all ASICs. If this goes out, nothing works, you’ll need an oscilloscope to verify this.