96boards Hikey eMMC hacks!

I currently own two Hikey development boards from 96boards.org. A 1GB and 2GB board, respectively. Recently I got to thinking as I was scanning through the schematics and hi6220 datasheet about the capabilities of the MMC controller. I discovered the Hikey has an DWC (Designware) MMC controller, which is very common on single-board computers, and found that the device supports eMMC up to version 4.5.

The board itself supports up to HS200 mode and 150 MHz clock. As I sifted through the device tree for the board (based on my own mainline kernel, but is reflective of their current releases), the device tree was only setup for high-speed mode, and seemed to have 3.3v signaling enabled, whereas the board is capable of HS200 and 1.8v signaling, especially considering the signal lines are connected to LDO5_1V8.

We can see that with the default device tree, the card is running in high-speed mode at 52 MHz. You’ll also notice that I have a 32GB eMMC chip on my Hikey, which I’ll touch on later 😉

If we take a look at the device tree, we can see we are missing some important properties to reach the full potential of the eMMC and the board:

Let’s take a quick peek at the device tree documentation for the MMC bindings:

Here we find the missing culprits: mmc-hs200-1_8v and the paramter max-frequency (I’m not sure if this is necessary, but the hi6220 datasheet explicitly mentions the maximum frequency is 150 MHz for the controller, so I’ll be safe.) Before we add these parameters, let’s get a quick and dirty benchmark of the current mode:

So we are looking at about 26 MB/s. While this isn’t a perfect or ideal benchmark, it’s good enough to get an idea of the transfer rate. Let’s give it a shot with our new parameters in the device tree, recompile the kernel, and see what happens:

We can see the card was successfully detected in HS200 mode instead of the default high-speed mode.

Wow! So now we’re looking at about 36 MB/s! That’s a pretty significant improvement. We can see the signal voltage is at 1.8v and the clock running at 150 MHz. I’m not sure why this hasn’t been enabled by default, but I’ve seen no issues or stability problems as a result.

This is one of my favorite development boards, but I felt a little restricted by the 8GB eMMC… I had an SMD rework station sitting around and a couple spare eMMC chips I had from old devices and eBay. This board came with the KLMBG1GEAC chip (8GB Samsung eMMC), and I just so happened to have a KLMBG4GEAC (32GB) sitting around, so I figured why not give it a shot…

As you can see, my impatience and inexperience led to damaging some of the pads. I was incredibly, lucky, as all of these pads were “NC” or not connected and not used, with the exception of two. They are in the inner square of pads in the bottom left corner. I had damaged a Vcc and Vss pad.

Another stroke of luck, there are quite a few redundant grounds, and three other Vcc, which are tied together internally, which meant I could get by just fine without the damaged Vcc and Vss. Lesson learned, use tighter temperature profile, and have a little more patience in removal. After flattening the pads out with some flux and desoldering braid, then a touch up of isopropyl, I spent about 20 minutes trying to line the new eMMC chip up just perfectly (much more frustrating than you’d imagine…)

After a few minutes of heat (slowly working my way up from ~180c, always preheat the board, it helps) I cooked the eMMC chip at around ~260-280c. I carefully watched for the chip to “drop” into place, when the solder balls melt and attach to the pads. I kept some heat on it for about 20-30 seconds after that occurred to ensure even and thorough heating. Afterwards, I allowed the chip to cool down and gave it some time to relax. My next concern (in hindsight) was that I needed to enable HWRESET in the ExtCSD of the chip, so the Hikey could properly initialize the chip, in addition to enabling the BOOT1 partition for booting in 8-bit mode.

After some careful research, I discovered that the ‘l-loader’ used to burn the chip did this for me, which was a big relief. I made sure to backup a few of the partitions from the old chip like ‘vrl’, ‘vrl_backup’, and ‘mcuimage’, and was able to flash those through the l-loader fastboot. Thereafter, I flashed the UEFI/boot partition and system partition with the 16.06 Debian release, and sure enough, it booted right up. I believe that makes this the first 32GB Hikey board! I’m very pleased with this new chip and the speed I’ve been able to squeeze out of it with HS200 and hope you find this information useful too!