Any experiences with hardware mod to improve eMMC speeds?
#1
I recently came across this very interesting article on how to modify the PinePhone's hardware to allow a different timing mode for the eMMC in order to improve read speeds (theoratically up to 200 MB/s vs. currently 104 MB/s). I'm wondering if anybody has performed this hardware mod and can comment on how noticeable the speed improvements are for everyday use? Does it even make a real difference at all (e.g. for application loading times)?
  Reply
#2
I too would be interested in actual experiences. And also if the device tree has now been resolved (for say Mobian & Arch) or if it still requires a hack?

I suspect the difference may be hard to notice in day-to-day use: I run Mobian from my eMMC (hdparm 60 MB/sec) and Arch from a Samsung Evo+ (hdparm 22 MB/sec) and do not notice radical differences between them (say Firefox load times). Although Arch boot time does seem quicker (which is unsurprising, but clearly despite its disk speed!)
  • ROCKPro64 v2.1 2GB, 16Gb eMMC for rootfs, SX8200Pro 512GB NVMe for /home, HDMI video & sound, Bluetooth keyboard & mouse. Arch (6.2 kernel, Openbox desktop) for general purpose daily PC.
  • PinePhone Pro Explorer Edition, daily driver, rk2aw & U-boot on SPI, Arch/SXMO & Arch/phosh on eMMC
  • PinePhone BraveHeart now v1.2b 3/32Gb, Tow-boot with Arch/SXMO on eMMC
  Reply
#3
Any real world benchmarks?
  Reply
#4
(01-14-2022, 04:45 AM)vusra Wrote: Any real world benchmarks?

Speed measurements can be found at the bottom of the linked article. That doesn't say much about it being a noticeable difference for regular use, but what @dukla2000  wrote makes sense, SD card speeds in the PinePhone are much slower anyway and it doesn't feel that different.
  Reply
#5
hdparm benchmarks don't help. real world would be showing how much faster firefox opens. The pinephone does not open applications fast. Fast opening applications is more important than fast boot times.
  Reply
#6
I'm considering trying out the hardware mod, but the 1.2a mainboard schematic is giving me pause. Under R614 there's a note: "If eMMC IO-Voltage is 1.8V. Mount R401, NC R423."

Only problem is, there is no R423 in the schematic, and it looks like R401 should be mounted anyway (it's present in the schematic and not marked NC). I haven't had time to open up the phone and take a look, but has anyone else looked at this?
  Reply
#7
(01-28-2022, 03:02 PM)kk22 Wrote: I'm considering trying out the hardware mod, but the 1.2a mainboard schematic is giving me pause. Under R614 there's a note: "If eMMC IO-Voltage is 1.8V. Mount R401, NC R423."

Only problem is, there is no R423 in the schematic, and it looks like R401 should be mounted anyway (it's present in the schematic and not marked NC). I haven't had time to open up the phone and take a look, but has anyone else looked at this?

I'm not an electrical engineer and just making uneducated guesses, but looking at the schematics and trying to make sense of that note, I think R423 is a typo and is meant to be R403. R401 (and R402) are used for ZQ calibration of the DRAM (on the chip itself) as is R403 (on the A64). Setting the eMMC to 1.8 V is done by connecting VCC-PC to CPVDD (which also powers the DRAM) while setting it to 3.3 V means connecting VCC-PC to DCDC1. My guess is that ZQ calibration somehow depends on that and shouldn't be done via the A64 if VCC-PC is connected to CPVDD, maybe to reduce noise? I really have no understanding of this though, maybe someone else can make more of this information.
  Reply
#8
Working on this some more, I've noticed one other potential required change: on page 7 of the schematic, there's a note: "If use eMMC 5.0, mount D. else, NC D. Or if use Flash NC D." Here "D" refers to a group of 3 resistors. This message is a little confusing to me - I guess NAND and eMMC are considered different things, even though according to EETimes eMMC "consists of a number of NAND flash memory devices and a controller in a single ball grid array (BGA) package." All this can probably be ignored until HS400 is supported anyway, since that's the only mode that requires eMMC 5.0.

It leads me to my next question though - how do you figure out which components on the board correspond to components in the schematics? My electronics experience is limited to through-hole hobbyist electronics and minor repairs on surface mount components on PCBs, not reverse engineering inputs and outputs to a BGA chip on a multi-layer PCB where most of the traces are invisible. A few searches for this process just turned up X-ray imaging or destructive delayering.
  Reply
#9
I believe there was a bit of discussion in this forum on this back in 2020, on this subject, a bit over my head, but I did read it.
But I think they were referring to changing the main board firmware to accomplish faster read & write speeds.

I do not know how accurate the App 'Disks' is for bench-marking the emmc, -- but it should be good enough to compare
the original Pine phone with the new Explorer phone.

Using Disks, My Explorer shows : 177.6 MB/s read and 157.2 MB/s write
My PMOS convergent phone shows : 74.8 MB/s read and 69.2 MB/s write

While both show about ~ 23 MB/s read speed on the sd cards. ( a bottle neck reading the sd cards ? )

Both phones running Mobian/Bookworm from the sd card.
      LINUX = CHOICES
         **BCnAZ**
               Idea
   Donate to $upport
your favorite OS Team
  Reply
#10
I reached out to Federico over email and he was happy to answer the questions I've posed in this thread. With his permission, here are the answers he sent me in response:

Quote:
  • Did you run into any problems?
No, I’ve done the mod on two PinePhones (Braveheart and pmOS CE) and they both run fine. A minor inconvenient is that Jumpdrive does not work anymore (because the Vccq mod would require a separate target with the adjusted device tree)
But if you install Tow-boot you can use the built-in USB storage mode instead of Jumpdrive.
  • How to figure out where components are placed on the board
Look for a “component placement drawing” in this wiki page. You will find the physical location of the schematics components
https://wiki.pine64.org/wiki/PinePhone#P...ifications
  • Mount R401, NC R423 if eMMC I/O voltage is 1.8V
R401 is marked as populated in the schematic. R423 does not exist.
This note might be a leftover from a previous project (like the Pinebook)
  • If use eMMC 5.0, mount D. If use NAND Flash NC D
An eMMC storage includes a NAND flash and a microcontroller which takes care of NAND management (wear leveling, address translation…). When you see NAND Flash is a document, they mean a “raw NAND”, which is a chip containing one or more NAND dices without a controller, with raw NANDs the O.S. has to take care of NAND management and they are only used in very low cost devices.
The PinePhone has a eMMC, not a raw NAND.
Also with the Vccq mod we are not changing the eMMC standard version (5.0), so there is no need to change D.

I had missed the Braveheart component placement drawing earlier, but this was enough for me to go ahead and perform the mod. In preparation for the mod, I timed several apps opening with the "time" command, with benchmark results presented below. I also installed tow-boot and a new image of postmarketOS before running the tests. Tow-boot is really nice because it gives easy access to the eMMC by booting with the volume up button pressed, so no more need for Jumpdrive.

The solder on the PCB is very difficult to melt, so I used a soldering iron with the tiniest tip I had for it and melted some leaded solder into the existing solder on each end of the resistor. That allowed me to use my hot air gun (temperature set to 400 ℃) and remove the resistor from R615. A little leaded solder on each pad for R614, and some careful tweezer maneuvering along with some hot air, and I was able to place the resistor on R614.

After that, it was time to get the phone to boot. I tried booting the existing postmarketOS image - no dice. You still need to include the "device-pine64-pinephone-vccq-mod" package (or maybe manually apply changes to the device tree overlay and boot script Federico mentioned in the original article, but I haven't tested this) and the only documented way to add that package is to use pmbootstrap, a tool I'd never used before, but it seemed preferable to trying to set up a cross-platform chroot. It was fairly easy to use pmbootstrap, although it did crash a few times trying to unmount one of the chroot filesystems it creates with a "target is busy" error. Just waiting for a few minutes and then retrying the command allowed it to complete successfully.

I installed the image directly to the phone by booting into tow-boot's jumpdrive mode and running "pmbootstrap install --sdcard=/dev/sdm" where /dev/sdm was the block device for the phone as it appeared on the desktop. After that, I was able to boot up like normal. I re-ran all the benchmarks: the average of five startups of each app, all radios off (to minimize variables like network delay). I wasn't able to find a way to cut the timer immediately once the app displayed, so for Firefox I allowed it to load the cached homepage before quitting, for Giara I quit as soon as it displayed, and for the web app I also quit as soon as it displayed. Here are the results:

Code:
+=====================================+==============+===============+
|                                     |    No Mod    |   With Mod    |
+=====================================+==============+===============+
| Firefox ESR 91.8.0-r0               | 16.574 sec   | 11.426 sec    |
+-------------------------------------+--------------+---------------+
| Giara 1.0.1 (Flatpak)               | 8.302 sec    | 8.312 sec     |
+-------------------------------------+--------------+---------------+
| Epiphany web app (forum.pine64.org) | 6.372 sec    | 5.128 sec     |
+-------------------------------------+--------------+---------------+
| hdparm                              | 44.06 MB/sec | 119.97 MB/sec |
+-------------------------------------+--------------+---------------+


Subjectively, the phone definitely feels faster. Firefox still feels like it takes ages to load, but it's not absurdly slow like it is without the mod (the worst time I got for opening Firefox without the mod was 24.79 seconds!). Smaller apps like calls and Chatty load in under a second, which feels about as fast as similar apps would open on an Android or iPhone (although I didn't record benchmarks for them). If anyone with an unmodded phone wants to compare loading times, I'd be happy to test other apps as well.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Microphone on Hardware Model 1.2 is Unusably Noisy In Some Circomstances ASmartSuitedSimpleton 4 3,625 03-23-2024, 10:55 AM
Last Post: Ferriah
  eMMC upgrade EuvzO8 5 1,418 11-08-2023, 11:58 PM
Last Post: brken
  Is the hardware still being developed and refined? orbital 10 4,687 09-01-2022, 08:05 PM
Last Post: orbital
  RAM corruption, possible eMMC corruption alnyan 3 1,620 08-24-2022, 03:07 AM
Last Post: JeremyWadsworth
  How to check hardware revision? jojuma 1 1,502 07-16-2022, 12:28 AM
Last Post: bokomaru
  Emmc yvan 1 1,314 07-07-2022, 08:16 AM
Last Post: Chief
  Modem Hardware bad? Not ready for 5g?? linux76 8 4,491 05-31-2022, 06:41 PM
Last Post: SwordfishII
  Hardware switch for mic is not working properly submariner 10 7,355 01-25-2022, 07:01 AM
Last Post: wibble
  Case hardware request/idea HobanWashburn 5 4,356 09-15-2021, 04:02 AM
Last Post: biketool
  PinePhone Hardware Critique KABA 2 2,825 08-13-2021, 06:47 PM
Last Post: Zebulon Walton

Forum Jump:


Users browsing this thread: 1 Guest(s)