PINE64 has [nearly] finalized the PinePhone design

PinePhone design as of February 21, 2019

It has a headphone jack, USB-C with video output, data transfer, and 5V fast charge, and PINE64 is about 90% sure they’ve got the final design, with a few possible modifications still to come.

At Category5 TV, we’re really excited about the privacy features of the PinePhone, as discussed with Lukasz Erecinski during our recent interview. The ability to turn off the cameras, cellular data, WiFi, Bluetooth and speaker using hardware switches is definitely a sought after feature for the privacy-minded user. It comes as a bit of a surprise at first that these hardware privacy toggles will be hidden beneath the “easily removable” back cover. However, with a little more thought I begin to realize that this could be a really, really good thing. Albeit inconvenient for the impromptu Skype call with mom.

From a privacy perspective, it makes a lot of sense that the switch that re-enables your camera is hidden from accidental switching, or even from another person enabling it: Hand your child your phone to play a game and don’t worry about them accidentally triggering the camera. Similarly, it gives me great peace of mind knowing for sure that my LTE data plan isn’t being used in the background. My data minutes are a rare resource that we must conserve.

A headphone jack is very much a necessity. Personally, I listen to audio books and podcasts at night. I am not going to use Bluetooth headphones for that. I use a pillow speaker, which is ideal for nighttime listening. It also stands to be noted that the PinePhone, at a target price of just $150, is a budget phone: it is possible it will be used in markets where Bluetooth headphones (which cost significantly more than wired headphones) are not practical. At least having the headphone jack gives the budget, hard-wired option. It also means the PinePhone can be used to play music at events via loudspeaker. I know, it sounds silly, but I know businesses and restaurants who simply plug their phone into an amp to play music for the customers.

For the current mockup, PINE64 intends to put the headphone jack at the top of the phone. That’s exactly where I want it. However, some people argue it should be on the bottom. I suppose this is a personal preference thing. Back to my pillow speaker, for me, having it on the bottom would be inconvenient (my wall charger is on the far side where my pillow speaker plugs in on the opposite side). So, PINE64, being the community-centred company that they are, put it to a vote:

The speaker, at least for now, is on the back of the phone. I’m not particularly keen on that design features since it means the audio for the video I’m watching will be better heard by the person sitting across from me. But PINE64 says this may change in the final, final design.

The PinePhone will feature the typical volume rocker on the side of the phone, along with a lock button.

Here’s what we know so far about the upcoming PinePhone specs:

  • USB-C for data and charging, with HDMI Video Output (requires an adapter or special cable)
  • Bluetooth + WiFi
  • 4G LTE
  • Privacy (hardware) switches for BT/WiFi, LTE, cameras, speaker
  • eMMC module socket
  • mSD Slot
  • Gyro magnetic sensor
  • Light sensor
  • Volume, power, reset, home buttons
  • Audio aux
  • MiPi and TP interfaces
  • 2mpx and 5mpx front / back cameras
  • Small and compact size of (approx. 165x77mm)
  • 1440×720 IPS panel
  • SOPine module: Allwinner A64 with 2GB of LPDDR3 RAM
  • Price Target: $150

I’m really eager to start hearing of some manufacturers working on cases for the PinePhone. As of yet, I have not seen anything coming down the wire. But I’m really hoping we’ll see some attractive protective cases and screen protectors that will be suited to this new device.

I’ll continue to keep you updated as I learn more.

Here’s what PINE64 has to say on Twitter:

NTP on Debian reporting 95 years in the future – Part 5: Patching the Kernel

If you haven’t read part 1 yet, make sure you start there.

Okay — I can’t wait 24 hours — I’m an eager beaver. But 14 hours later, the system is still showing the correct time. Let’s play.

Okay – so I’m on the absolute most amazingly modern kernel ever. Great! So let’s fix that kernel.

We’ll check again to see if the timer workaround is implemented in our kernel:

So what does this tell us?

CONFIG_FSL_ERRATUM_A008585 shows whether the workaround for Freescale/NXP Erratum A-008585 is active. The workaround’s description is “This option enables a workaround for Freescale/NXP Erratum A-008585 (“ARM generic timer may contain an erroneous value”). The workaround will only be active if the fsl,erratum-a008585 property is found in the timer node.”

For those who are even nerdier than me, check out’s log of the patch here:

You’re such a nerd!

Now I’m getting into the experimental. I’ve never changed a kernel config before. Funny, that. I guess if you’ve never needed to do something, you never learn to do it.

I have yet to find online instructions for doing this, and here’s what I’ll try.

Note for tl;dr – this didn’t work.

Alright, let’s change my default config as we prepare to re-compile the kernel. I’m unsure if changing this config will make the newly compiled kernel receive the change or not, but it’s worth trying.

Great, my config is now set to include this patch.

Okay, I’m obviously gonna need the kernel headers here…

Looks good, and the default setting is the same as my running kernel config:

Great! I think I’ve made a connection… this file has the same setting as my default kernel config.

So since I’ve already updated my own config, let’s compile withΒ oldconfig – I’m assuming that means “grab the old config”… hmmm…. makes sense to me.

Alright, is it set now?

Weird… the setting is gone! Well, let’s see what happens? Maybe the kernel will default to “yes” if the setting … let’s try.

Oh – If it’s going to ask me to say yes to a crapload of defaults, I’ma abort that!

I’ll trust the kernel devs and my config πŸ˜›

Wow, that’s a lot of output.

Now, a quick reboot and re-connect, and then check the running kernel…


Strangely, the default config (my config) shows that my setting remains there…

So maybe I just didn’t compile it correctly.

I wish someone in the threads would have posted how to actually add this. I mean, as a teacher, I try not to make assumptions. Saying to someone “set CONFIG_FSL_ERRATUM_A008585=y in your kernel” is a big assumption. Even I, the Bald Nerd, am not quite sure how to do that, yet I’m sure the people who make the statements are. Let’s instead post the actual commands or at least point the person in the right direction.

I’ll try to figure it out in the next couple days, and will post my step-by-step. I’ve posted a cry for help in the forum thread related to the Debian image I’m using. Hopefully they can point me in the right direction.

UPDATE: Ohmigosh, it just hit me… this is using make, yet I didn’t install!

Let’s try it, just for good measure:


Yeah, there’s no there.

I’m sure it’s something simple I’m missing since I’m not experienced at this kind of thing.

More to come!

NTP on Debian reporting 95 years in the future – Part 4: Back To The Past

If you haven’t read part 1 yet, make sure you start there.

I had a great idea after posting part 3 last night… why not try to set the interface as static so DHCP isn’t impacted? That way, I won’t have to re-flash to an earlier image. So I stuck the SD card into my SD reader and low and behold, /etc/network/interfaces is accessible! So I commented out the DHCP line and set it instead to the static IP I have reserved for it, and low and behold, I’m up and running.

And to boot, get this:

That’s right… the date is correct after booting this way.

Strangely though, there are no updates in /var/log/dpkg.log – the last entry was in 2113.

Another interesting anomaly when checking the ntp service:

Hmm, yeah… it has been running for over 95 years. Yet the date is correct on my system now.


So, let’s just try…

And… wait for it….


Okay, so let’s leave the server running for 24 hours and see if this is a DHCP-related issue.

To be sure, I have indeed checked my router to make sure it’s not serving up bogus NTP timestamps, and it’s all good.

What’s Next? Read Part 5:

NTP on Debian reporting 95 years in the future – Part 5: Patching the Kernel

NTP on Debian reporting 95 years in the future – Part 3: Community

If you haven’t read part 1 yet, make sure you start there.

Hooray! I am not alone, and it does indeed appear to be a Pine64-specific issue. That means I’m not crazy. Or at least, this issue doesn’t prove my craziness.


Looking at martinayotte‘s suggestions, since he seems to have been through what I’m going through right now…

Okay, so just in case they fixed it already, let’s just try…

Hmm, it seems apt doesn’t like time travelers like me. So … [le gasp]…

Wait for it….

Like trying to play my 8-track cassettes in a Blu-Ray player, apparently some services don’t play nicely 95 years in the future. DHCP is showing locally on the TTY splash screen as, and the only way to recover will be to re-flash to a point before the NTP issue struck.

What’s next? Read Part 4:

NTP on Debian reporting 95 years in the future – Part 4: Back To The Past

NTP on Debian reporting 95 years in the future – Part 2: The Time Traveler

If you haven’t read part 1 yet, make sure you start there.

This issue has really intrigued me.

Setting the date manually fails:

Invalid argument? Maybe it wants me to set the time too?

Nope, that made no difference.

Well, what does my hardware clock say (since the Pine A64+ has one)?

Oh yay, that looks better! Let’s use that! Obviously the system knows the date and time…


Maybe I’ll try the long-form command…

Nope. Same result. Ach!

This is looking a lot like an old kernel bug I recall from the late 2000’s. Better check what kernel I’m running…

If I had hair…

Just to be sure, let’s reconfigure my timezone config:

Okay, so let me get this straight… it’s August 28, 2113. But it’s July 5, 2018 according to the RTC.

Think, Robbie, think.

I did a quick grep through the /var/log folder for anything talking about ntp, and interestingly, I find this at the top of dpkg.log:

So on first boot, the system had the date correct: July 4, 2018. The time is off by a couple hours however (it was perhaps 6am when I flashed and fired up the system and then left for work).

What’s interesting here is that the typical ntp startup tasks unpack, install and run, but then after the package is installed (a presumably automated process since I didn’t do it!) the date suddenly changes to August 27, 2113.

Being a Raspberry Pi user all my SBC life, I’m honestly impressed that the Pine A64+ has a built-in RTC… but nowhere in the specs do I see that it also includes a corresponding flux capacitor, so I must presume the jump through time is more likely a glitch in the matrix.

I’m afraid to reboot.

What’s Next? Read Part 3:

NTP on Debian reporting 95 years in the future – Part 3: Community