Been keeping a casual eye on Pine64 updates over the past year and this is is the most impressive so far IMO.
The new RK3566 SoC looks really promising - once it eventually makes it into the next generation PinePhone, it's going to make it very attractive as a daily driver.
Their involvement with the larger community is great; collaboration with KDE, donating to pmOS, incentivizing contributors to make truly open wifi and bt a reality.
Pinephone state and ecosystem seems to be continuously improving.
And at long last some news on the SOEdge module.
I kind of wish I could buy shares in this company :P Keep up the great work!
> The new RK3566 SoC looks really promising - once it eventually makes it into the next generation PinePhone, it's going to make it very attractive as a daily driver.
I'm not looking forward to that. For example, mainline lowlevel software stack for RK3399 used in Pinebook Pro still doesn't support suspend to RAM, and RK3399 is quite popular, with many devices based on it. There's barely any recognizable community around RK SoCs.
Just as a mild counterpoint, it's nice to see the Panfrost team getting official support from ARM.
They've been able to make some really rapid progress on bug fixes and efficiency improvements just by re-designing based on the official design docs instead of relying on reverse engineering.
Your argument sounds a lot like "This COVID vaccine has been in development for 9 months and still does not support being stored at room temperature for more than six weeks. I'm not looking forward to it".
So? I'm not looking forward to Rockchip SoC based Pinephone.
Hopefully Allwinner will get its act together and create some higher performing A* series SoC based on some better performing mali GPU. That would be a win for Pinephone.
I agree .. I've been hacking away on the PineWatch as a platform for the last few months, mostly to teach myself baremetal Rust, and it is an extraordinarily satisfying circumstance to be able to tell time on a watch running my own code. The hardware is decent for the price (very cheap), and it is so very, very refreshingly open.
I will pick up a PinePhone as soon as possible, based on this experience, and I'm probably going to be a Pine stalwart for the next few years, at least, as a general platform. These guys are finally delivering devices that we developers can be happy to get involved in.
I say that as a dev with years of iOS experience, where I am currently fatigued with having to keep up with yet more proprietary bollocks from Apple: the future of these devices is open.
The dev kit buy page has a scary warning that the cover doesn't pop on. How much of a problem is that in practice? I really want to get one to play with.
I have two kits - one which I hack on with Rust, and has wires hanging out, and the other which has the pinewatch python project on it, and I have sealed it shut.
When I get my personal little watch application built and ready, I'll get another, install it, and seal it in.
.. there are so many interesting projects to run on the PineWatch, I just bought a couple extra so that I could evaluate them all at once. Its not an expensive investment - I've certainly spent more on the rPi lab-bench over the years:
There was a recent post about that on r/pine64official (or maybe on Mastodon? I've been watching both) that said that the cover is held on with silicone glue. So it sounds to me like there's no mechanical detent, but you can use glue to hold on the cover. The main issues I could see with that would be waterproofness and possible glue mess if it isn't applied just so.
Its easy to seal the watch in a way that produces water-tightness .. but I still wouldn't want bother wearing it in the shower. Maybe okay in rain, though.
Well, I think the project is called "Precursor" for a reason - one can assume it can come closer to a smartphone form factor in a couple more generations - if successful.
I doubt we are going to see the RK3566 in PinePhones in 2021. That sounds more like a 2022 thing to me – unless getting proper mainline Linux support is going to land extraordinarily fast for that new SoC.
Knowing Pine64 I think they might provide upgrade boards unless it turns out that revising other aspects of the PinePhone hardware (e.g. screen, camera, battery) can be revised and improved cheaply so that this would not make sense economically.
I don't want them to focus on RISC-V. Only time will tell how appropriate RISC-V can be technologically in a smartphone application, and why would you want the company that focuses on open source to invest themselves into it? Are you aware that Riscv being an open ISA has absolutely nothing to do with open source (either software or hardware)?
not about the battery life though. My understanding is that applications must be updated to make the life of the battery manager easier. But that's just guessing on past articles read here and there.
Right now, on Mobian, you will get more or less 2-3 hours of screen on time, with everything enabled (modem, wifi, bluetooth, max screen brightness and doing stuff with it
If you just let it sleep (modem on registered to the network, allowing for voice calls, all the rest of the phone suspended), you'll get about 24 hours of runtime.
I think there's still more power management fixes that can be done, mostly in BT/Wifi, but it's not bad at all for a phone that's still tagged as "dev"
They mention suspend from wakeup on incoming calls drastically improved this month, as did call audio quality. The author is now using it as a daily driver for his sim card, but carries an Android alongside it.
They’re optimistic that it will be a recommendable daily driver for some people (probably like you) by early 2021.
- calls -> yes (to include VoLTE on a lot of US carriers)
- SMS -> yes
- battery life -> not very good (3-4 hours screen time?, less than a day standby)
- mobile data -> yes
- wifi ->
- (optional) MMS -> no
It looks like they are asking for testers, but I cannot seem to figure out how to add it. Do you have knowledge on how to do that (or a good place to point to to try it)?
It also looks like it is for downloading MMS only, it doesn't look like it has support (yet) for sending them.
> Wifi works perfectly for me as well, including excellent hotspot (via nmcli)
Sorry, that looks to be a typo by me, I meant to say it works just fine for me.
No MMS last I checked, which is always a bit surprising to me.
Are the developers all outside the US, in countries where MMS isn't used as much so this isn't perceived as a deal breaker? Or is it just a difficult feature to support?
I certainly feel like migrating to a PinePhone in near future but where can I view the list of the apps available anyway?
The most important app I need (I wouldn't even need a smartphone otherwise) is Telegram - it's the major way we communicate in the company and in the family. Is it there?
I seriously consider going away from Android (Google).
Is Linux a viable option as mobile OS? I've got a feeling that it is almost as a 'dumb' phone. You got your calculator and SMS app but that's about it.
Or would going to something like LineageOS be a better option?
> I've got a feeling that it is almost as a 'dumb' phone. You got your calculator and SMS app but that's about it.
GNU/Linux phones are full personal computers in your pocket. They can do everything a computer can do: terminal, desktop Firefox, games, convergence (external screen, keyboard, mouse) etc. See my other links about Librem 5 in this thread.
Android apps on a big screen are not desktop apps [0]. Can you run desktop Firefox with all plugins there? Can you run native GNU/Linux applications in a terminal? Can you use the latest Linux kernel?
I have read it, and again I was already coding in the age of 8 and 16 bit computing, with their OSes built-in into ROM, no issues with them.
I also only cared for Linux because Microsoft wasn't serious about POSIX support back in the day and it was a solution for my problem to avoid commuting for an hour to access a DG/UX system.
If you computer places artificial restrictions on what you can do with it, then it's company participates in the war against the general-purpose computing.
If it's a technical limitation, it's a totally different thing.
I'm sorry that you do not care about the freedom of users. Users who do not know about all these things suffer from unlimited power of developers [0] and cannot do anything to escape various walled gardens and traps of proprietary systems [1].
Staying away from the proprietary software is already hard in practice (I'm trying hard, works in 95% cases). Not sure if staying away from those licenses will help more.
As someone in the US, I would have to say no, for one reason:
None of the mobile Linux distros yet support group texts (reliably, anyway). If someone sends you a group text, you won't see it. (The only distro that seems to have partial support for it is Ubuntu Touch, and there it seems incomplete; sometimes I would receive group messages and sometimes not. I missed a few important ones this way.)
This is probably only relevant to those in the US as I understand MMS is not as prevalent elsewhere.
> This is probably only relevant to those in the US as I understand MMS is not as prevalent elsewhere.
I've heard this a few times in connection with the Pinephone, but we certainly do use MMS in Europe.
I seem to recall, assuming my memory is at all reliable, that when the iPhone first launched, Europeans were complaining about the lack of MMS and Americans were saying it wasn't a problem because everyone should just use e-mail.
2007 was a different time. (A time when almost nobody had smartphones - how foreign is that from today's perspective?) Have a look at the plan available in the US for the iPhone at the time: https://www.apple.com/newsroom/2007/06/26AT-T-and-Apple-Anno...
Even the cheapest plan has unlimited SMS and effectively unlimited MMS as a result. Whether it's used more because it's included or whether it's included because it's used more (probably a bit of both)... I don't think 2007 is a useful reference point for what people expect from their phones today.
The cheapest plan on that page is $30. I get unlimited MMS on my $17 plan in Europe, so I don't see how the pricing would make MMS more prevalent in the US than in Europe.
Do you have a reference supporting the idea that MMS is mostly relevant to the US and not the rest of the world? It doesn't match up with my experience, but maybe my family and friends are atypical.
> You got your calculator and SMS app but that's about it.
Well, thankfully it's not the case. The heart is a ARM processor with plenty of code already ported to run on it, and the surrounding hardware isn't that different from many single board computers that already run complete Linux distributions. As an example, Firefox, GIMP and Libreoffice -the real ones, not dumbed down versions- already do run on the Pinephone.
Keep in mind that the video is one year old, meaning old phone model with less RAM, very young OS and likely no code optimization for apps to run on a phone rather on a desktop PC.
Actually I wouldn't be surprised at all if one year from now we would have more software available for the Pinephone compared to Android. Sometimes it's just a matter of recompiling (huge argument in favor of Open Source).
As another example, if Lazarus (lazarus-ide.org) would run on it (it already does on the Raspberry PI and many other ARM boards), one could develop native GUI apps directly on the phone. Probably not comfortable, still possible.
The only problem in my opinion would arise from the unavailability of phone specific apps, particularly closed ones or those depending on proprietary servers whose owners wouldn't give a damn about recompiling their client and are particularly anal retentive wrt allowing 3rd party apps accessing the services, for example Whatsapp. In that case one would have to attempt to emulate a different platform in which run the original proprietary app, which very likely would make things too slow to be useable.
With regard to Whatsapp, it should run on Anbox (Android emulation for PinePhone), because Whatsapp does not require Google Play Services and runs on vanilla Android.
Do you have any data on performance? Having Whatsapp run at acceptable speed on Linux phones would represent a great bump for their acceptance among normal users.
No, there’s a lot more. Also, some Android apps work via Anbox. I have been blogging (https://linmob.net) about this since June and created a bunch of videos. If you have more specific questions, feel free to email me.
Yes, I do. However I have to switch off my phone when not using it to get through a day, or use a second battery (which is fine for me). A night takes about 50% battery when it's on. Improvements are very much expected.
That would be a problem for those of us who would rather have a thick phone (I'm perfectly fine with 2 centimeters, no kidding) with great battery life (== early morning to late night at high load), rather than a credit card thin one that needs to be recharged too often. Might be a further development in which users can purchase a thicker rear cover with bigger or additional batter(y|ies) and snap them in place of the original one.
Telegram Desktop works fine when tweaked as described on the Mobian wiki.
For other apps may be https://LINMOBapps.frama.io can help you to get an idea.
Check for AArch64 binaries if you want to run something closed.
Personally I would avoid that, so in that case it's mostly whatever is in the distro you're using plus maybe whatever the developers responsible for the port added. (ex: postmarketOS is based on alpine, but includes some extra stuff like gnome maps and phosh.)
I love the concept and would buy it in a heartbeat, even at Apple level premiums, but that spec sheet.... 2/3 GB RAM is not enough in the Android world of 2020/2021. And eMMC storage instead of UFS? Oooof.
Shame, I really want to support the own your phone initiative(user replaceable battery, no more walled gardens, no more telemetry out the wazoo) and willing to pay the premium but I also want my device not to be a huge downgrade on my daily driver and go back to 2012 Andorid hardware.
The kind of ecosystem that Pine are trying to foster tends to produce much, much leaner software though. Of course, at the moment there are simply some apps (like Telegram IIRC) that are thin wrappers around a web app. But taking f-droid as a reference, compared to the play store, I have great hopes to end up with a less bloated stack.
Cynics would call the apps on f-droid feature poor. But for me, the FOSS apps that I use day to day tend to just do the thing you need them for, no more.
There's no telemetry overhead, they tend to use fewer dependencies, are less likely to be built on heavy frameworks like electron. Of course there's heavy sampling bias involved in this since I specifically select apps that feel snappy and light.
But this has always been true for linux desktop apps, too.
My favourite comparison is the size of pdf viewers. I have never lacked a feature from the Adobe pdf reader. The 400KB binary of evince totally sufficed, and it used much fewer resources at runtime, too.
I really hope that this ecosystem can push the boundaries of what's possible with lower-spec hardware, even if just to hold the mirror to the big platforms.
> Cynics would call the apps on f-droid feature poor.
Maybe for some apps. NewPipe absolutely destroys the official YouTube app in terms of features. Plus, I'd consider "don't spy on you or shove ads down your throat" to be a couple of very compelling features.
Yes, and from how I understand it, it is also a native app in android/ios.
But I just checked on my Mobian install on the pinephone and that app looks a lot like the telegram web app. Which, by the way, is one of the best executions of webapps I've seen to date.
Edit:
I should clarify, I mean the telegram app that came preinstalled on mobian. There may be others that I'm not aware of. On ubports there were at least two IIRC
Edit 2:
And going by this GH issue [1] there is in principle no reason to not run the native QT app on the pinephone. Of course, I'm not sure how it would handle the sreen size etc. And it is only for the snaps apparently.
Edit 3: disregard edit 2, I'm stupid. Thanks to @linmob for the correction. :)
It has to start somewhere, with hardware where it IS possible to run open-source software without too much reverse-engineering and fighting NDAs and so on.
Supporting them NOW means that later, what you want, will be possible. It's an investment into a better future..
The Pinephone thus far is mostly for tinkerers. The super low price point is what will enable the community to form. It's not really a mainstream daily phone yet.
Maybe the Fairphone is something for you? It's 3x the price but still far from premium pricing gives you a decent 4G/64G Android phone without fuss. I had their first phone which was good enough for an everyday phone and support in Lineage was great. Removable battery, 3.5mm jack, and they try to keep spare parts around for at least a new years.
Yeah, from my experience the speed of RAM makes the biggest difference in regular usage. It's especially visible in GTK apps which perform noticeably better on the Librem 5. Compilation times on L5 are also much shorter. GPU is another factor, but obviously that matters only in GPU-heavy workflows, like games (or at least should, there are still some optimizations in phoc to be done ;)).
From obvious things that matter a lot in regular usage I'd also mention that L5 supports 5GHz WiFi that PP doesn't (and I've already seen some places with 5GHz-only WiFi), and its screen is much prettier (colors and blacks - I don't have many objective measures, but the difference is obvious in person).
Anyway, that table seems a bit inaccurate in a few places. Video out on USB-C is not limited to 1080p, cameras are not using MIPI CSI but parallel interface, not sure how to interpret meaning of 4 channels in the codec (it's a stereo codec, so mostof the paths have 2 channels, L/R and number of inputs/outputs is way larger - in the range of 20 or so), also it's not limited to 48kHz, but to to 192kHz.
I see that I was mixing up inputs/outputs and channels. The A64 supports 4 inputs and 4 outputs, but only two channels in the DAC and ADC. I see that the DAC supports 8 - 192 kHz, but the ADC only supports 8 - 48 kHZ. OK, I'll clarify that in the table.
-----
2.8.Audio Subsystem
Audio Codec
•Two audio digital-to-analog(DAC) channels
•Stereo capless headphone drivers:
-100dB SNR@A-weight
-Support DAC Sample Rates from 8KHz to 192KHz
•Support analog/ digital volume control
•Differential earpiece driver
•Analog low-power loop from line-in/microphone to headphone/earpiece outputs
•Support Dynamic Range Controller(DRC) adjusting the DAC playback output
•Accessory button press detection
•Four audio inputs:
-Twodifferential microphone inputs
-One differential Phone input
-Stereo Line-in L/R input
•Four audio outputs:
-Earpiece amplifier differential output
-Phone amplifier differential output
-Headphone amplifier L/R channel output
-Line-out L/R output
•Two audio analog-to-digital(ADC) channels
-96dB SNR@A-weight
-Supports ADC Sample Rates from 8KHz to 48KHz
•Support Automatic Gain Control(AGC) and Dynamic Range Control(DRC) adjusting the ADC recording output
•Two PCM interface connected with BB and BT
•One 128x24-bits FIFO for data transmit, one 64x24-bits FIFO for data receive
Terminology around camera sensor interface module is confusing. MIPI CSI is supposed to be a camera serial interface. Cameras on Pinephone are connected via a 8-bit parallel interface.
I'm also not sure how they came up with 5Mpix in the datasheet, CSI can do up to 4800x4800 which is 23Mpix.
OTOH, 1080p@30fps is not attainable on the parallel interface, at least not with the cameras that are in the phone. It would require ~120MHz clock, and communication starts to break down at around 60-70MHz.
Looking at the pin description on page 24 of the A64 Datasheet, it looks like the 8 data pins (CSI_D0 … CSI_D7) are for a MIPI Camera Parallel Interface (CPI), but Allwinner is calling it "CSI" (MIPI Camera Serial Interface).
This is really confusing, but I am simply repeating what the A64 docs say.
Out of curiosity, what is the highest-resolution still photo anyone has taken so far on the PinePhone? Maybe I should list that in the table.
Is 1080p@15fps the best video anyone has managed so far with the PinePhone?
OS seems to have gotten much slicker-looking in addition to a host of exciting updates. Been following these guys for a while and it's really great to see them releasing a cheaper phone. Excited to see what's next!
Why they cannot use something like Snapdragon? I am contemplating buying a new phone, but it seems like most of the new ones have call recording disabled, so a phone with an open API and privacy conscious is something I could pay for, but it seems like this one is lacking in the hardware department. If I bought it that would certainly be a downgrade from my current old Samsung phone (which is running old OS and call recording works fine).
I've seen this explanation coming up quite often in discussions around Qualcomm or other similarly sized players: you have to be ordering (very) large numbers to be able to get their attention.
Documentation is provided under NDAs I hear, and if you'd let's say, decide to buy a small(er) number of boards off the grey market (from one of their direct customers), you'd still have the problem of lack of support (firmware/code, docs, etc).
That makes sense. I hope the development of Risc V will be akin to what Arm is to Intel now in near future.
I am thinking I am probably still going to buy Pine phone just to support the developers even if I won't be using it.
Isn't it more important for the community to fight against closed drivers at the level of legislation than engage in these endless reverse engineering battles?
Why don't all these Pinephone fans put more of their time and their money into funding an international effort to reverse closed blobs instead of repeated crowing over the success of their reverse engineering efforts and how willing they are to fork out good money on outdated hardware?
Personally, while that sounds appealing, I think we also still need the RE efforts. Hardware that's built to run free software out of the box is important, and it would be ideal if all those blobs were gone and we didn't have to worry about them. I'd absolutely be on board with an effort to enforce free drivers for the hardware we buy.
But... in the short term, given that's not currently the case, we still need a way to move forward, right? And it's much easier to demonstrate why free drivers are important if you have working software to show for it. ("Hey, there's this whole phone OS and app ecosystem that we could run on this hardware if it had free drivers!")
That said, yes, the endless reverse engineering required to keep the devices you've bought secure beyond the 2 or 3 years that the manufacturer supports it is ridiculous. I wish it weren't so. But given that that's unfortunately the situation we're in, I applaud anyone contributing to the RE efforts. (But I sure am keeping an eye on hardware that doesn't require it!)
We should definitely do that, but given that e.g. EU politicians still don’t understand why crypto-backdoors are a terrible idea, I have very little hope for succeeding on that level.
1.) You can't just open up every driver. I say this as somebody who works on proprietary firmware and software that is basically the future of our company. We operate in a market with thin margins, our control strategies are our advantage, and divulging any info past the bare minimum concerning them would result in mass counterfeiting and ultimately the death of our company. A lot of hardware development is like this. I wish it were some other way, because I know some people would be over the moon with what it would enable, but most of the time it's just not possible.
2.) I think you misunderstand what the Pinephone is -- if my memory serves me correctly, minus the modem blob, there is no need for reverse engineering, as the documentation for the hardware is available. You're talking about sending good money after bad ideas while advocating stopping the thing that has a clear path to victory (starting from a clean slate with something that has real documentation) in favor of something else that has a negligible chance of ever happening (having source be released for drivers but not getting any documentation for it).
What legislation? Mandating that all OS level software/firmware has to be under FOSS license?
Mandating a release of detailed HW documentation (datasheets for all the parts + device schematics) prior to being able to sell devices would also be an interesting experiment.
I think dino has patches for it to run better on small devices. the default texting app runs on libpurple so it has support for jabber, i dont know if it constitutes decent though, I have nobody to talk to on jabber :(
Wonder when the 8GB one will release. Main concern for me is the sms/call being reliable and if it will "just work" on carriers like Boost mobile.
Also when using as a "desktop" be nice to have some simple toggle to reduce GUI load by going into something like i3-wm
Does anybody know if the PinePhone has NFC? I looked at all the specs and didn't see it at all. That would tell me that (1) the phone does not have NFC, or (2) NFC is such a given so why would they list it, because "duh"?
In Duck Duck Go, it’s not the first result, but it is on the first page (once you click through the spell checker warning about rewriting “bogo” to “pogo”):
Well, this would be sort of integration of hub in a phone (aside from that that the new chip already has built in 3 usb ports) thus a big advantage for daily driver phone that you would use as portable PC. USB3 is already supported AFAIK.
I think usability of a single port is better. With multiple ports you'd have to teach users which ports support what, like charging, display port, gadget mode, USB 3, etc, despite all ports looking the same.
At most you'd get 2 ports anyway, if you want to use USB internally for other purposes (connecting to the modem, etc.)
Power Delivery negotiations should technically allow charging from any port, but still you can go simple and use appropriate USB logo (as USB certification requires).
> At most you'd get 2 ports anyway
Two is still better than one ;-) Three is better than two ;-)
The new RK3566 SoC looks really promising - once it eventually makes it into the next generation PinePhone, it's going to make it very attractive as a daily driver.
Their involvement with the larger community is great; collaboration with KDE, donating to pmOS, incentivizing contributors to make truly open wifi and bt a reality.
Pinephone state and ecosystem seems to be continuously improving.
And at long last some news on the SOEdge module.
I kind of wish I could buy shares in this company :P Keep up the great work!