04-19-2022, 02:36 PM
(This post was last modified: 04-20-2022, 08:49 AM by kk22.
Edit Reason: hopefully fixed table formatting to make it render correctly on mobile
)
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:
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:
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.
Quote: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)
- Did you run into any problems?
But if you install Tow-boot you can use the built-in USB storage mode instead of Jumpdrive.Look for a “component placement drawing” in this wiki page. You will find the physical location of the schematics components
- How to figure out where components are placed on the board
https://wiki.pine64.org/wiki/PinePhone#P...ificationsR401 is marked as populated in the schematic. R423 does not exist.
- Mount R401, NC R423 if eMMC I/O voltage is 1.8V
This note might be a leftover from a previous project (like the Pinebook)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.
- If use eMMC 5.0, mount D. If use NAND Flash NC D
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.