Hello,
I performed keyboard firmware update for my Pinebook Pro ANSI as described on Pine64 wiki (just performed on Manjaro) and noticed few things.
- during update there were few messages "device not found" but firmware update seems to completed successfully
- after update some keys are behaving differently from their labels
  - Fn + F9 - labeled as Print Screen, behaves as NumLK
  - Fn + F10 - labeled as NumLK, behaves as ScrLK
  - Fn + F11 - labeled as ScrLK, behaves as Pause
  - Fn + F12 - labeled as Pause, behaves as NumLK

The rest of the keyboard is working propperly as it should. Before the update everything worked propperly so I assume this is caused by firmware update itself. Is there any way to narrow these things? I am affraid of messing things up and ending with non-working keyboard.
Thanks in advance!

Hi,

I've Pinebook Pro for sale - I got it in January 2020 - since then it was used for approximately 20-30 hours of work (mostly testing different OS) - it was meant as a secondary gear - so it's almost brand new. I can send pictures if you're interested. I'd like to sell it in Poland, while shipping abroad can cause additional costs. Price - 700 PLN. Please DM me if you're interested.

regards 

I've been using my Pinephone for my daily driver. As long as I get my calls and texts pretty reliably, I'm ok with various bugs. I understand this is beta software. But I would like to read about releases before I install them. I've got manjaro phosh. The update that was released last week is much buggier than the previous release. My phone is freezing too much for reliable usage. Where can I get information about releases before I install them?

jmms is a memory-safe script to receive and view MMS messages (all types: group threads and multimedia) and unclog your message queue for SMS.

I've been developing and using it for a year now and it's been great at doing one thing well.

I've gotten feedback from a few people that install was a barrier to them being able to use it, so I've put some effort into hopefully making installation drastically simpler - at least on Mobian. It should be pretty simple to reuse the code to support other distros - merge requests very welcome!


The new instructions are here: https://git.sr.ht/~amindfv/jmms#installation


Enjoy, and feel free to let me know if you encounter issues - either here or on the bug tracker!

I recently replaced Manjaro Plamo with pmOS SXMO, which was way more stable and way quicker, and doesn't suffer from the touch to unlock problem Plamo still has as well as the heating and battery sucking problem Phosh has (crust is the workaround, but it's not optimal when it comes to usability).

However, I don't like the lack of available apps in the repos, so I gave Arch ARM SXMO a try.
The performance is slightly worse, but so far I like it much more than the pmOS one.

However, I'm still trying to figure how to enable Fcitx and how to get Gajim to work. but at least I got them installed, which is already way further than what I got with pmOS in which both of the apps are uninstallable.
Not only because they don't exist in the repos, on top of that you can't build those from source too.
But this is my homework, and perhaps provide a way to get it to work if people are interested in it.

One problem that maybe the community would know: I can't change the brightness.
Brightness is too low, and when trying to make it brighter, brightness doesn't change and the value always seems to start from 0 for some reason.
In pmOS setting brightness works like a charm.

Maybe related, but in both pmOS and Arch as soon as you "rotate" the screen from portrait to landscape, the screen turns pitch black.
In Arch, the only way to fix it is to reboot the phone via SSH so it boots up in portrait again.
In pmOS, the only way to fix it is to re-flash and re-install the entire OS altogether.
But considering that pmOS seems to remember this setting while Arch doesn't, I do suspect that the problems with brightness is perhaps related?

Hi All,

I downloaded Manjaro Phosh's nightly build and updated my preferences for SMS/MMS in Chatty for Mint Mobile.

MMSC: http://wholesale.mmsmvno.com/wapenc
APN: Wholesale

I confirmed that these changes carried through in

I once bricked the phone and had to reinstall using iso and jumpdrive. During that time I fairly certain it asked for me to setup luks encryption passphrase. With this new .iso, mobian-pinephone-phosh-20210517.img, it didn't seem to give me this option.

I probably just missed something, but could an expert comment on this? It's company policy not allowed to have a phone without encryption. Can I set this up after the fact? I'd hate to reflash and reupdate again. But if I must, I'll do it over again 

thank you!

There are a lot of videos popping up lately telling you how crappy the PinePhone software is and that it's "for developers only". 

However, here is what I currently have:

I use a ZTE Open phone from 2014, running Firefox OS. I use it for phone calls, text messages, taking photos, and occasional web browsing (much of the newer stuff won't load in the outdated browser app). 

The hardware is old, and Firefox OS has long been discontinued. I would like to have better hardware, a long-term maintained operating system, and a reliable map service for locating stuff. I won't use GPS even on a PinePhone, but if it can be reliably switched off, that's fine with me.

I dislike Android and I am not going to switch back.

I have a degree in CS, use Linux (currently Artix) on my laptop, and have some experience running Linux servers, but I wouldn't call myself an advanced user. If I ditch my current device and get a PinePhone, will I be able to continue doing what I do without being annoyed all the time?

The OEM 64GB Sandisk eMMC in my first Pinebook Pro just failed from one moment to the next. I'd been using that machine heavily, for everything, including daily web browsing with the cache on the emmc, for about two years.

I'd never used anything with an emmc, sd card or ssd before, so my expectations for reliability were set by traditional spinning platter disks, where you could leave a good one running for a decade with no problems. Looking up emmcs & sd cards now, I had no idea they were so incredibly unreliable and prone to catastrophic failure with no warning at all.

The immediate takeaway is to back up your user data daily. The OS can be reinstalled, and adds a lot of bulk; if it's slow, you're less likely to do it regularly. Ideally don't just trust sd cards for the backups; you should have network-attached storage with real disks. And turn off web browser disk cache, or put it on a ram disk. I also did a fair amount of compiling, which generates a massive amount of disk writes on large projects, and I didn't switch to zram instead of disk swap until recently.

I was running Manjaro Xfce from the sd card, with the emmc mounted for storage. I tried to save a file in Mousepad, and it said the file was read-only. Checked perms; it should be writable by me. I tried to create a new file in Thunar, knowing I shouldn't have to do that, and it said the file system was read-only. That was the "oh shit" moment because I know linux remounts file systems read-only when an I/O error occurs.

I checked the dmesg, and it was full of CQE recovery failed messages for the mmc. The filesystem was still navigable due to caching, but trying to read a file, even with less, would result in the command locking up. On the web, it looked like rebooting solved similar errors temporarily, so I rebooted. After reboot, lsblk showed ~30MB capacity for the emmc instead of the expected 58.9G, and the sd card was flagged read-only in short order; the system would not allow remounting the sd card rw.

I attempted to reboot again, and the system wouldn't boot. I now know that the boot priority on the PBP always starts with the emmc, and the bootloader on the emmc is supposed to check for bootable media on the sd card, so if the emmc bootloader is out of sorts, you have to flip the emmc disable switch or pull the emmc in order to boot.

I put the pulled emmc on the pine store-supplied emmc-to-usb adapter, and tried it in a second PBP. The USB mass storage device lists as 0b capacity, and reports "Medium not present". testdisk isn't able to read it.

Looking at recovery options, there are at least four levels you can access these devices on. The highest level is a usb adapter, where the simple circuitry on the adapter presents it to the system as a generic block device. Next is putting it into an emmc socket, where it reports as /dev/mmcblkX, and you can manipulate it as an mmc. I'm going to see what I can do with that next. The ideal testbed for that is a single-board computer in an open enclosure, so you don't have to open your running PBP and flip the switch back on.

Then there's JTAG ? I still need to read about that.

And finally, there's reading the NAND directly. This is the best single thread I've found about it so far, including the linked pages and PDFs:
Which NAND flash reader ?
https://web.archive.org/web/202110171442...10&t=33785

It looks like tons of people lose their data on these every year, and data recovery is a solved problem. But, it's all proprietary. Third-party companies have developed the tools & software to read the raw NAND, and sell them at high prices. Sending your chip to commercial data recovery would be privacy suicide; there's no way to guarantee the company doesn't keep a copy, and some just make nand dumps and ftp them to other countries for outsourced processing without telling the customer. The data is usually all there, including deleted files, but most people don't get it recovered.

There should be an open source solution for emmcs widely used by the open source community, like these sandisk emmcs are now.

Steps,
- Acquire a bunch of emmcs for practice, document the process of exposing & connecting to the nand interface, develop a training curriculum like the commerical vendors have that affected users can follow at home to develop the hardware skills.
- Start with a commercial nand dumper. Eventually can be replaced with an open source device at lower cost.
- Develop the software & procedure for the specific combination of the Sandisk hardware & likely linux filesystems. Less work than having to support all mmcs from all manufacturers, and all operating systems.

Next to do for me: Try the mmcblk interface, then start looking at how much of step (3) has already been done.

All Pine devices should have socketed emmcs, not hard-soldered. A common failure mode is that a phone dies for some other reason, and the emmc is still good, but the user never gets it desoldered, so the data is lost anyway. Socketed emmcs are a major step forward compared to the usual way of doing it.

Most of the time, my system wasn't hitting the swap, but I was experimenting with different thread counts during builds to balance compile speed against the system running out of memory in bottlenecks. Just two threads could result in the system swapping massively when the make process was attempting to build two large source files concurrently. That may account for a lot of the reduced life expectancy. Nonetheless, properly designed solid state storage should remain readable in a read-only mode when it runs out of writes, and it appears that common emmcs do not.

I pop my SIM  into my pinephone every once in a while to see how things are coming along and on my most recent test on PostmarketOS phosh I noticed I can't use pithos anymore, its worked previously on mobian/postmarketOS phosh. And I really like to have my music on my phone. Apparently it stems from the dev having some issue with the gnome keyring, there's a back forth about it on the project page. In any case are there any good alternatives or fork that allows use of the gnome keyring?