<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>32gb on MOV r0</title><link>https://movr0.com/tags/32gb/</link><description>Recent content in 32gb on MOV r0</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 18 Sep 2017 15:36:15 +0000</lastBuildDate><atom:link href="https://movr0.com/tags/32gb/index.xml" rel="self" type="application/rss+xml"/><item><title>96boards Hikey eMMC hacks!</title><link>https://movr0.com/posts/96boards-hikey-emmc-hacks/</link><pubDate>Mon, 18 Sep 2017 15:36:15 +0000</pubDate><guid>https://movr0.com/posts/96boards-hikey-emmc-hacks/</guid><description>&lt;p>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. &lt;a href="https://movr0.com/images/2017/09/hikey_emmc_schematic.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/hikey_emmc_schematic.png">&lt;/a> We can see that with the default device tree, the card is running in high-speed mode at 52 MHz. You&amp;rsquo;ll also notice that I have a &lt;strong>32GB&lt;/strong> eMMC chip on my Hikey, which I&amp;rsquo;ll touch on later ;) &lt;a href="https://movr0.com/images/2017/09/hs_mode.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/hs_mode.png">&lt;/a> 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: &lt;a href="https://movr0.com/images/2017/09/dt_dwmmc.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/dt_dwmmc.png">&lt;/a> Let&amp;rsquo;s take a quick peek at the device tree documentation for the MMC bindings: &lt;a href="https://movr0.com/images/2017/09/mmc_bindings.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/mmc_bindings.png">&lt;/a> Here we find the missing culprits: mmc-hs200-1_8v and the paramter max-frequency (I&amp;rsquo;m not sure if this is necessary, but the hi6220 datasheet explicitly mentions the maximum frequency is 150 MHz for the controller, so I&amp;rsquo;ll be safe.) Before we add these parameters, let&amp;rsquo;s get a quick and dirty benchmark of the current mode: &lt;a href="https://movr0.com/images/2017/09/hs_info.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/hs_info.png">&lt;/a> &lt;a href="https://movr0.com/images/2017/09/old_benchmark.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/old_benchmark.png">&lt;/a> So we are looking at about 26 MB/s. While this isn&amp;rsquo;t a perfect or ideal benchmark, it&amp;rsquo;s good enough to get an idea of the transfer rate. Let&amp;rsquo;s give it a shot with our new parameters in the device tree, recompile the kernel, and see what happens: &lt;a href="https://movr0.com/images/2017/09/new_hs200_mode.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/new_hs200_mode.png">&lt;/a> We can see the card was successfully detected in HS200 mode instead of the default high-speed mode. &lt;a href="https://movr0.com/images/2017/09/hs200_info.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/hs200_info.png">&lt;/a> &lt;a href="https://movr0.com/images/2017/09/hs200_benchmark.png">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/hs200_benchmark.png">&lt;/a> Wow! So now we&amp;rsquo;re looking at about 36 MB/s! That&amp;rsquo;s a pretty significant improvement. We can see the signal voltage is at 1.8v and the clock running at 150 MHz. I&amp;rsquo;m not sure why this hasn&amp;rsquo;t been enabled by default, but I&amp;rsquo;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&amp;hellip; 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&amp;hellip; &lt;a href="https://movr0.com/images/2017/09/emmc_removal.jpg">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/emmc_removal.jpg">&lt;/a> 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 &amp;ldquo;NC&amp;rdquo; 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&amp;rsquo;d imagine&amp;hellip;) &lt;a href="https://movr0.com/images/2017/09/new_emmc.jpg">&lt;img loading="lazy" src="https://movr0.com/images/2017/09/new_emmc.jpg">&lt;/a> 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 &amp;ldquo;drop&amp;rdquo; 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 &amp;rsquo;l-loader&amp;rsquo; 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 &amp;lsquo;vrl&amp;rsquo;, &amp;lsquo;vrl_backup&amp;rsquo;, and &amp;lsquo;mcuimage&amp;rsquo;, 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&amp;rsquo;m very pleased with this new chip and the speed I&amp;rsquo;ve been able to squeeze out of it with HS200 and hope you find this information useful too!&lt;/p></description></item></channel></rss>