First impression are; Great feeling, snappier than I was thinking, hot device, battery life not great, charging is weird and buggy, KDE plasma while looks alright is an update nightmare. It is not ready for daily driving at this time… as already indicated.
I had exactly the same issues… pacman -Syu didn’t fix it… in fact i think it has made it worse… after a long while i am seeing a better idea of the update size and am currently trying again.
I knocked up an SDCard after the issues originally with the updating saga with manjaro-phosh… I find that to be a much better experience over all so far. I dont like some of the scaling issues with some apps which is kind of annoying. I did fix some of it by putting display zoom back to 150 to get a bit more room back and see more of various menus in non phone optimized apps.
All in all i am actually excited to see a few of the bigger issues sorted and I will daily driving it for sure… the fact that I have a lot of self hosted alternatives to various apps really helps as well as i find that I can use more browser based stuff anyway than relying on mostly non existent apps
The charging when it died completely?
I was talking with @regulareel in the live stream about pulling my hair out trying to find a charger and cord combo that could pull it out of boot looping due to the large power draw when booting up.
The Pine Travel Charger + the cord that came with the PPP did not = charge quicker than power draw while booting.
Pine Travel Charger + C to C cord did = boot up
For those watching on the side lines, the PPP will boot its self up when pluged into power. Nothing you can do about it as far as I can tell, and it’s VERY hard to charge it mid boot.
Quick chargers didn’t work for me. And a 5v 3A charger didn’t either.
I am using a decent quality usb A to C cable with a 3a charger.
I do note that manjaro-plasma is garbage for battery life, even while plugged in it goes down. In manjaro-phosh i was seeing much better charging speeds…
On manjaro-plasma i am getting GPG errors for packages that i cant seem to resolve, which leading to it not updating at all… might have to try and reinstall to the emmc… disappointed about that and a little annoyed.
the maintainer advises that he has the backports of the wireguard stuff for the kernel merged but the app wont allow its use while having a sudo password set… i cant risk losing my phone and have someone free reign access to my home network. Sure i can delete the config key for access on my router but stilll, to run password-less is madness.
I am not sure if i want to run UT permanently based on the poor app support… they need to open it up a bit better for desktop style apps and work on the scaling of same… So many things become more annoying. Atleast with the wider adoption of the PPP the ecosystem is a bit freer.
Yes jumpdrive is massive and seriously provides a very easy way to flash to your device emmc…
That sounds like the app is using sudo internally. That’s bad design on the app part. You could probably fix that though by adding a line to your sudoers, allowing the specific command it runs(you might be able to get the commands it runs from your system log, the sudoers file supports wildcards for commands AFAIK).
I’m currently playing with overclocking the PinePhone(On mobian).
I’ve increased the DRAM frequency from the default 528MHz to 624MHz.
This required compiling u-boot, thankfully that’s easy by a makefile made for the crust-firmware: GitHub - crust-firmware/meta: Build system combining Crust with other firmware components
This also builds the ATF and SCP firmware(“Crust”, the firmware running on the AR100, a tiny OpenRISC 1000 core inside the A64 responsible for managing deep sleep and stuff), but you want that to utilize the power management features.
That alone helped me from a glmark2-es score of ~75 or lower to ~105.
Feels snappier too
Overclocking the GPU 560MHz like described in the wiki resulted in glmark crashes after a few seconds(with strange errors reported in dmesg), so I lowered the GPU clock speed to 540 and that seemed way more stable(finished a glmark run of 141, WOW!), but still crashed once. It’s now running stable at 535(glmark 139, still almost double of where we started at!).
I’m getting almost 25FPS in Minecraft Java edition!
Pro tip for keyboard users: You can set the machine-type via hostnamectl: hostnamectl set-chassis convertible. This permanently unlocks the docked-mode toggle in the notification area for a more desktop-like environment(which also always hides the OSK).
I’ve adapted my touchscreen-as-touchpad script to use the keyboard for mouse buttons, and that works great when combined with docked mode!
Having a full keyboard and mouse really makes Linux on the go way better.
This also works in games
I have the PCB revision 1.2(Not sure if b).
No, I haven’t played around with eMMC bus speed yet.
I lack a precision soldering iron or access to a hackerspace at the moment.
But I definitely want faster eMMC! 125MB/s sounds noice!
But you should have no problem compiling the DTS for another(Mobian in my case) kernel(That’s the same thing needed to do the GPU overclock).
You might not even need to compile the entire kernel, Just editing the DTB should suffice. You can convert the DTB in the /boot directory to a DTS using dtc, edit it, then convert it back to a DTB using dtc again.
Loadable device definitions are awesome!
Today I wrote a script to compile some PinePhone related stuff.
I’ve basically wrapped all the things necessary for compiling a lot of useful stuff in a single script.
It does:
Installs gigabytes of package dependencies for building
Sets up toolchains for aarch64(three toolchains because different build systems) and or1k toolchain(for the SPL)
Compiles u-boot with the crust firmware and arm-trusted-firmware from source
Packages all the build artifacts in a nice .tar for easy installation
It’s intended to be used in a fresh Debian 11 container or VM, and you’ll need a lot of storage(50GB+) and RAM.
Originally written to aid in overclocking, it’s also useful to compile up-to-date versions of what is essentially the Pinephone firmware.
Available here (Probably will change in the future)
In the future, I’d like to use the Mobian version of u-boot+crust+atf so we get a .deb package, and also provide an automated on-device install script.
Maybe someone will find it useful.
The Pinephone keyboard seems to work well in the latest build of Arch on the Pinephone Pro. Touchscreen doesn’t quite work right rotated, (screen rotated, touch didn’t!) will need to fix that.
My Pinephone has been running without a reboot for a couple weeks and still managed to get a text message today. This is the first time I’ve been able to let it sit idle more than a day without having to reboot it to re-gain sms and calling.
I suspect the answer is no, but is there a way (be it a specific project, method) to get something to breathe new life into old/low-end devices (system stability and speed) with high compatibility? The acceptable trade-off would be the phone-specific features likely wouldn’t work. Such as if you could just install desktop Linux and get a newer kernel/system.
The intention would be to save a device from the trash/disuse just to get something to play music and maybe a few time-waster games, anything else would be a bonus.
(if there were some form of widely compatible Android that’d work too)
Yes! There is. You can run a more traditional Linux userland, and often even a mainline kernel on them.
It doesn’t work on every device(in fact device support varies, check the wiki!), but a lot of devices are somewhat supported.
I have a Nexus 7 2012 that happily runs a Mainline-kernel with an accelerated MATE desktop, but a lot of devices still only run some form of “android kernel”(android kernels are heavily patched, and often rely on closed-source binaries, which makes porting them to mainline Linux hard, and explains their often archaic versions).
Speaking of Android:
That exists as well! It’s basically just a stock android, without any bloat, often supports newer android versions on older devices, and gets current security updates.
It supports a lot of devices, but again not everything is covered. But there are a lot of “downstream” projects porting LineageOS to other “unofficial” devices as well.
Some googling with the term " custom rom" might help, but beware of shady sites. I’d stick to XDA and other well-known ones.
Without knowing your exact device, you’ll have to do some googling yourself
Yes I was aware of both of those (also AOSP and a few smaller projects), thus why I was asking. The issue is like usual, the devices available to me seem to be just old/underpowered/unpopular enough that it’s they’re not supported.
The “best” stuff I have:
hTc Droid Incredible (original, not 4G… also I do have backups (it’s rooted) so I’ll try that… and I guess custom ROMs might make even more sense now aside from stability concern)
and Motorola Droid X (also original).
Though I don’t think any of the batteries are still good, so that’s an issue as well…
OK so I just found out about GSI (generic system image) ROMs that do what I was asking IF the phone is new enough (Android 8.1+). I asked someone and they’re going to give me a phone that has a cracked screen (Samsung A51 IIRC).
My question now would be what I should go with (of the options you listed+Ubuntu Touch continued by UBports), particularly with package availability. Aside from music+games (and maybe trying a few desktop apps like Krita just for fun), I’m wondering if GCC/clang/TCC etc would work here (specifically for Nim-lang, assuming a new-enough version is available).
EDIT: Unlocking the bootloader was easy, but everything after that seems like a bit of a mess…
