Frequently Asked Questions for the Librem 5

By every way that I can think to define “mass production”, I think that the PinePhone got there before the Librem 5, which isn’t surprising considering the design choices that PINE64 made compared to Purism’s design decisions.

If we define “mass production” as when a product has its full functionality available with only minor bugs, then neither the PinePhone nor the Librem 5 are at mass production, but the PinePhone is definitely closer to that state than the Librem 5.

If we are going to call the PinePhone “beta”, then we also have to call Evergreen “beta” or maybe “alpha”, considering the lack of FCC/CE certification and all the software dev work that is still required for things like the cameras, GNSS, OpenPGP, suspend-to-RAM, system wakeup by the cellular modem and WiFi, etc.

If we define mass production as when shipping a large number of the devices, then the PinePhone started mass production in June 2020. Maybe you can argue that Librem 5 started mass production in November 2020, but I don’t think 250 devices per month is a large enough number for that definition. At this point the PinePhone has shipped 20k - 30k units, whereas the Librem 5 is around 1200.

Another definition could be when the hardware stops changing. By that definition, I would say that the PinePhone reached mass production with v1.2b in October 2020. At this point we don’t know for sure if the Librem 5 will have any further hardware changes, but it appears likely that there won’t be any changes to v.1.0.2 of the schematics, which were released in November 2020.

1 Like

No debating this, but do you have a source for that? I would be interested. And I agree with your post :).
Just asking, because I know the size of the Mobian CE batch (sorry, non-public) and if the other editions are similarly sized, I would not arrive at that number…


I disagree. Pinephone still have a backlight hardware bug making display blink from time to time:, It means that you cannot buy the final hardware now, whereas for Librem 5 you can. You just buy Librem 5, wait until software is ready and get perfect final device.

Those are just software problems. There are a ton of them for Pinephone as well. The point is they are temporal for both phones, while hardware problems are permanent. Except maybe certification, but did Pinephone CE Ubports have it? It also should not change anything. I would not say that the innovation does not exist without this certification…

This is not true, see above.

Here you suggest that thousands of devices is large, whereas hundreds is not large. I don’t think it makes much sense. Also remember that we are talking not about all produced phones, but only about who was the first, i.e. Birch vs CE Ubports (or Evergreen vs ??).

Just because a device has a hardware design flaw that does not mean it is not mass-manufactured. Just ask Toyota, Tesla or Volkswagen where 100,000s of cars are regularly pulled back for HW fixes.

The pinephone SoC is from 2016 and besides small fixes I would guess no major changes are to be expected until a Gen2 brings a new architecture.

UBports said that it shipped between 3.5k and 4k units for the first Community Edition in one of the monthly updates. There have been 5 Community Editions and I assumed that PINE64 would ship more with each successive edition.


After 3 Community Editions and now Beta with the same v1.2b board, it looks like PINE64 won’t ever fix that bug with the flickering backlight.

When asked about this issue, PINE64 Community Manager Lukasz Erecinski said in the comments to the March Update:

I’ve never seen any flicker on 1.2b boards

I suspect that PINE64 considers the PinePhone to be good enough as it is, which I guess is the difference between the two companies and their phones. PINE64 aims for good enough and shipping quickly, so the community projects have hardware to work on, whereas Purism aims for higher quality, but it takes a lot longer and the device costs a lot more.

I also think that the different business models of the two companies make them use different terminology. PINE64 wants to emphasize that it is producing hardware for software development and it is selling it with only a 30 day warranty and promises virtually no support, because that allows it to sell the phone for a very low price to people working on community projects. In contrast, Purism is using crowdfunding to finance its development, and trying to generate more orders by promising that Evergreen is the final product and it just needs software updates.

However, Purism says that it is using JIT manufacturing of the Evergreen, because the hardware may change in the future. With both phones, we have a situation where the hardware may change, but we probably already have the final hardware.

However, a realistic assessment of the two phones places the Librem 5’s software significantly behind the PinePhone’s software. The PinePhone is very close to solving the problem with the modem being able to wake up the system from suspend fast enough to not miss phone calls, whereas the Librem 5 doesn’t have suspend-to-RAM working and there is a bug report about the BM818 not being able to wake up the system from suspend when it gets a phone call. These features are necessary to give the Librem 5 a long enough battery life to be a viable phone for most people.

Another factor is that if you order the PinePhone today, you will get it by the end of April, whereas if you order the Librem 5 today, you will get it in 6+ months. To me, it looks like the PinePhone has reached “mass production” before the Librem 5.

PS: I have been holding off on buying the PinePhone for the last 6 months, because I wanted the final hardware, but I finally decided that PinePhone isn’t going to fix the backlight flicker bug. I tried to order the PinePhone Beta yesterday, and then I discovered that PINE64 doesn’t have a shipper for South America. That is another difference between the two phones, because Purism does ship to South America.


While this is true, in my experience the pinephone can’t actually operate nearly as long as what people are saying the L5 can. If you streamed a YouTube video on both phones, the pinephone would die long before the L5 did (as I understand it, I don’t have both phones). But perhaps that’s not correct. Would anyone care to test my hypothesis?

1 Like

From comments on the PINE64 forum, it does appear that the PinePhone doesn’t last as long as the Librem 5 with its screen on, but it would be nice if someone would do an apples to apples comparison (like PinePhone Mobian Bullseye vs Librem 5 PureOS Byzantium).

I would guess that the Librem 5 should last longer on a single charge than the PinePhone when the screen is on, because:

  • The A64 in the PP is a larger 40nm node size vs the Samsung 28nm in the i.MX 8M Quad in the L5,
  • The LPDDR3 in the PP uses 1.2V vs LPDDR4 in L5 that uses 1.1V,
  • The RS9116 WiFi/BT in the L5 is a power efficient chip and is probably a smaller node size than the Realtek RTL8723CS in the PP,
  • The 4500mAh battery in the L5 is bigger than the 3000mAh battery in the PP.
  • The GC7000Lite GPU in the L5 probably consumes less energy compared to the Mali-400 MP2 in the PP to output the same screen resolution.

The counter argument is that L5 has roughly twice as many components as the PP and has 2.6 times more chips than the PP, so in theory it should take more energy to run the L5.


I also am of the belief that pinephone doesn’t use hardware acceleration, at least not as much as the L5 does. I can’t say I’ve looked into it very much though.

The i.MX 8M Quad processor in the Librem 5 offers 35% better integer performance, 50% better floating point performance and 140% better GPU performance than the Allwinner A64 in the PinePhone, plus the Librem 5 uses a 160% faster RAM standard (LPDDR4-3200 vs LPDDR3-1104), should have 4 times the USB speed (150-170MB/s vs 40MB/s), and has 3 times the number of camera pixels (13/8 MP vs 5/2 MP).

At the same time here:

I guess one of those statements needs to be updated.


The Librem 5 stores these binary blobs on a separate Winbond W25Q16JVUXIM TR SPI NOR Flash chip and it is executed by U-Boot on the separate Cortex-M4F core.

Some people say that is incorrect:

The actual blob then runs on the PMU (“PHY Micro-Controller Unit”) inside the DDR controller.

Could you comment on that?

I replied here:

Give the guy credit for digging up some interesting info about the ARC core in the DDR PHY, but the way he spins it is pretty annoying in my opinion.


Commenting on your comment … if a customer were really concerned that early boot RAM training code can initialise and use either of the M.2 cards then boot with those cards killed and only unkill after the boot is done (in order to make it more challenging for the hypothetically compromised RAM training code).

However that is arguing about slivers of a percent of likelihood of some hypothetical attack vector v. hundreds of megabytes of known hostile code that runs in mainstream phones - which was probably your point too.

1 Like

Interesting to read that guy’s response:

He argues that Apple’s M1 booting procedure is more secure than the Libre 5’s, because it has secure boot and because Apple deliberately limits what hardware the boot procedure can reach in stages, so early boot can’t reach the WiFi or cellular modem for example.

I responded to some of his points in follow up comments. I agree with him about problems with the RYF, but don’t agree with him on most other points.


As always secure from end user I presume? :slight_smile: I’ve tried to find information in “series of tubes” to disprove my sarcasm but I couldn’t.
Jokes aside I think lack of secure boot is a big problem. Normal secure boot, as the one into which microsoft proposed crap has evolved - ability for end user to define own trust root and ringfence boot process to that trust root. Without it even smartcard is not much helpful (can we trust kernel? Not the file at /boot partition, but the EL1 executable at memory?)

1 Like

It depends what your threat model is.

For most people in this forum, this guy is completely missing the point. Secure boot merely serves to ensure that you, the customer, you, the ostensible owner of the phone, can’t disable any of the hundreds of megabytes of known hostile code. Secure boot only serves to ensure that Apple owns your phone and you don’t - and that also serves to ensure that various governments, by proxy, pwn your phone if they want to.

Within the limitations of the previous, he is right. Until Purism implements support for the Librem Key, or functional equivalent, a Librem 5 can be tampered with if someone has physical custody of your phone and the boot process won’t detect the tampering and the tampering could 100% compromise the software aspects of the phone (although the hardware kill switches would then come into their own).

In my opinion, boot sequence tampering shouldn’t be the priority for Purism right now.


8.8. How do the PinePhone and the Librem 5 help each other? (i.e. why it’s stupid to fight)

One should add this link here:

1 Like

If you mean that it should be added to the FAQ in the Librem 5 Community Wiki then presumably you could add the link yourself but otherwise: @amosbatto.

Yes. I don’t have an account (or time) and hoped someone else could do it. @amosbatto created this topic, so I presume he receives notifications without being called.

1 Like

It would be good if this answer was updated
3.14. How are Android apps installed in the Librem 5?
with this link