You could say that it is the essence of a site like this one, that the kind of people who form our readership are also the kind of people who examine the specs of the devices in front of them to reveal hidden features. Such was the case with [Ryan], who noticed that the eMMC controller on his 96Boards HiKey development board supports both HS200 data transfer speeds and 1.8v signaling, both of which it wasn’t using.
In unlocking the extra performance, he takes readers through a primer on the device tree, and is happy to report that his transfer rate has increased from 26 to 36 MB/s, a tidy return on his work.
However, the story doesn’t end there. The 8GB Samsung eMMC chip wasn’t quite as roomy as he’d have liked, so it was time to replace it with a 32GB version. Even with careful desoldering, he managed to lift a few pads, though very fortunately they were ones that were either NC or power rails that were duplicated elsewhere. Some tricky reflowing of what is quite a formidable BGA package to do by hand, and he was rewarded with a working board featuring higher flash capacity. We salute him for taking it on, we probably wouldn’t have had the courage.
We’ve brought you a similar upgrade before, this time an eMMC on a Nexus 5 phone.
Thanks [darkspr1te] for the tip.
I’m not sure turning on a documented feature and replacing a part with a larger capacity really qualifies as a hack… but /shrug.. kudos I guess.
Yes, because everything here has to be a hack. /s
The name suggests that there’s just one hack per day, not one per post. Why do y’all need to bitch so much? I’d be pretty proud of myself if I pulled off that BGA rework, so I’m certainly not upset to see it.
really? Why not? What would he have had to do to make it qualify as a hack?
I disagree. There are a huge number of readers for whom digging into the device tree and reworking a BGA would be anything but straightforward. If you can do both those things without raising a sweat then well done, but it doesn’t make it any less worthy of sharing with the world.
So you’d happily take a hot air gun to your shiny piece of kit for the sake of storage capacity then?
It’s not the technical aspect… it’s the very high risk of it all going awfully wrong. In this case, Ryan was lucky in that the pads he managed to rip off were not critical, but had it been a data line, he’d be up for one hell of a repair job.
Out of curiosity, I got a quote for ~$150-500 depending on how many of the integral vias I wanted repaired (at least 2x the cost of the board itself, with minimum repair). Luckily the Vcc is tied to three others, and is redundant, and there’s several grounds for both the NAND and the controller. The only reason I lifted the pads was because I was using an iron during cleaning that was hotter than it probably should have been. It was all I had around, and I wasn’t patient enough to wait to get another. Had I been a little more careful, I probably would have been able to do it without lifting pads also. Lesson learned, lucky roll of the dice.
This is quite the definition of a hacks to me. It’s under the hood, it uses heat, and it improves the specs of an existing system thru hardware and software modifications. Compared to stacking shields on an Arduino and run a GitHub software…. Nice job Ryan !
It is also possible the OEM did not enable HS200 due to signal integrity being on the edge. I’ve built products where we had to disable HS200 on controllers and emmc parts until we could respin the PCB to tune trace lengths and shorten the overall runs (73 mm max) to get margin. It is possible the new speed may work on that unit instance of that product or may be intermittent. Careful.
For sure, classic case of YMMV. Unless more people attempt the mod, this could well be a “fluke”.
There’s really no objective benefit to enabling HS200 on an 8GB eMMC with JEDEC 4.5 spec. The max throughput on a chip that small is pretty much hit in MMC high-speed mode. You’d really only see a benefit with a 16GB+ chip, hence the upgrade. That’s my guess as to why they hadn’t done it themselves, on top of the fact the SoC is still in the process of being mainlined by Linaro, and has taken a backseat to the Hikey960. The last official kernel release was 3.18 for this board.
The SoC lies on the opposite side of the board of the eMMC and signal lines are (rough guess) all under 50mm. Samsung eMMC/SD generally have a pretty good tolerance for poor signal integrity on top of that. It’s a cheap board and I figured why not. Worst case scenario I’d drop it back to SDR50. I’ve had zero issues, and I suppose could verify signals with a scope, but I’m not really concerned.
Nah
Hack this 8=>