i wouldn’t bet on 4k @ 60Hz but it’s still going to be pretty nice ALL things considered.
The H.265 and VP9 decoders are separate circuits so they don’t tell you much about the GPU, but Antutu’s GPU and UX benchmarks for the i.MX 8M Quad aren’t that bad and you need a decent GPU to be able to output 4K@60 and a 1.6 gigapixel/s fill rate.
Yes, the phrase “the spec sheet says” has a special meaning in the Linux/BSD world. We are used to not getting want the spec sheet says. 
It looks like the Etnaviv driver supports 4K (at least I found commits for it), but this chat from November 2017 says that Etnaviv devs weren’t able to get it work, but this was a long time ago:
17:24 cphealy_: wumpus: you mentioned 4K@60Hz was not working with the i.MX8M. Did you try display port instead of HDMI?
17:25 cphealy_: I ask as with HDMI, you need your display to support HDMI 2.0 for this to work.
17:28 wumpus: cphealy_: the display supports it, I tried with a chromecast ultra (which has HDMI out 4k)
17:28 cphealy_: Same cable?
17:29 cphealy_: The i.MX8M looks to support HDMI 2.0 (HW wise.)
17:29 cphealy_: Good datapoint though.
17:29 wumpus: the chromecast comes with a cable attached, so no I couldn’t try that
17:29 cphealy_: Do you know if the HDMI cable supports the higher frequency of 4k@60Hz?
17:29 wumpus: but I did try with two different cables, also the one that came with the monitor
17:29 cphealy_: OK, probably not that then.
17:30 wumpus: wouldn’t it completely block the signal in that case though? it seems work sort-of, just synchornization fails sometimesw
17:30 wumpus: does the board have displayport output? I haven’t noticed
17:30 cphealy_: I’m not sure if it has DP output.
17:31 cphealy_: If it does, that would be a good thing to try.
17:31 wumpus: I have displayport output attached to my desktop at the moment (its gfx card doesn’t support HDMI 2.0)
17:31 dv_: are there any figures about how many MPixel/s the mx8m can handle?
17:32 wumpus: but I’ll check
17:34 cphealy_: From what I’ve read, 4Kx2K @ 60Hz is supported by the HDMI transmitter.
17:37 wumpus: no displayports on the board
17:37 cphealy_: OK
17:37 wumpus: yes, it definitely should support it
17:37 wumpus: that’s why I thought it’s a kernel problem
17:39 cphealy_: I’ll see what I can learn.
17:44 wumpus: ok
17:54 wumpus: also it’s a very recent monitor model (from this year), so I’d be really surprised if it’s a monitor issue, though ofc there’s the possibility it’s an interaction problem between the specific HDMI transciever and monitor.
17:56 cphealy_: Yea, that stuff can be touchy. I’ve been battling some display port transmitter issues recently and it’s a pain getting it to work reliably.
18:17 wumpus: for some reason it seems a recurring problem with ARM boards for me
18:19 wumpus: I just remember I had another problem with this board: back when I started testing, another monitor would not work with it. Even though it supports 1920x1080x60 fine (“timing out of range” or such). I had to swap it with another monitior I had, which worked.
18:19 wumpus: so another indication the timing might not be exactly up to spec
3 Likes
also even if 4k@60 will be doable from a gnome/wayland/driver perspective it still leaves the issue of heat dissipation if it’s going to be pushed to the max.
i’m not confident at all with such prognosis.
1 Like
Put your phone in LN2 and you’re good to go 
I’m curious about how the Librem 5 will handle 4k@60
1 Like
@reC don’t overthink this. We’re talking about showing a 4k desktop, not rendering a x264 video of that resolution or a 3D game.
I had a 0.040Ghz PC doing 800x600@60 and a 0.133GHz PC with 2MB video RAM doing 1600x1200 (256 colors), didn’t even have a fan on the vga.
Then 0.300Ghz PC with 16MB video RAM so it could do the same resolution in true color.
There were also adapters without cooler that could have two such screens attached.
20 years later, why would you have a heat problem by merely emitting twice the amount of pixels from a chip that is likely ten times as energy efficient than what we had back then?
How do you know, that the Pinephone uses proprietary blobs?
I don’t know much about the pinephone, so about the proprietary blobs it’s something that I heard/read somewhere on the Internet and assumed it was true since the goal is not the same as the L5 so I’m sorry but I can’t give you any sources.
if just showing a 4k desktop is all a user wants then it’s fine i guess. in practice when a user ventures into desktop teritory limitations can quickly become apparent. but then again this isn’t a real desktop grade cpu so you might have a point. we’ll see.
2 Likes
According to the Pine64 Mastodon account:
To my knowledge, there are no blobs required running on the A64 SoC to make the device fully function. You can use a blob for the Mali GPU, but the open-source (Lima) driver works as well.
The only parts of the complete software that are not completely free are low level bootloader (irrelevant and not running after it starts uBoot), and the cellular modem (has a few blobs, but runs independent from the A64 and doesn’t have access to your data).
3 Likes
Sunxi has been working to get the driver for the Allwinner A64 SoC into the Linux kernel. See:
http://linux-sunxi.org/Linux_mainlining_effort
It looks like the open source driver now supports everything except audio over HDMI, frequency reporting and spinlocks, which pretty awesome.
One problem is video decoding and encoding with the Mali 400 MP2 GPU. The open source Cedrus driver is able to decode MPEG1, MPEG2, H264, VP8, H265 (8 bits only) and partly supports MPEG4, DIVX, XDIV, but has no support for WMV1, WMV2, H263, VP6, WMV9 and AVS. I assume that Pine64 will use the Sunxi-CedarX driver, which is partially proprietary and partially open source.
The open source Lima driver for the Mali 400 MP2 GPU is progressing, but it is still not ready for general use according to Sunxi, because it lacks some features to support Mesa. See:
http://linux-sunxi.org/Mali
In terms of 3D, the Etnaviv and Lima drivers both support OpenGL ES 1.0 and 2.0, but don’t support OpenGL ES 3.0 and 3.1 and Vulkan.
Given Purism’s goal of 100% free software, the NXP i.MX 8M Quad was the better choice and its Vivante GPU has better specs than the Mali 450 MP2 GPU in the Allwinner A64. Allwinner and Arm Holdings are not companies which are very friendly to the free software community, compared to NXP and Vivante.
However, Librem 5 probably won’t be very power efficient compared to the PinePhone. We will have to wait for the i.MX 8M mini to get a power-efficient SoC for the Librem 5.
it is truly amazing that we might have 2 Linux phones on the market by the end of the year, made by community-friendly companies. The fact that both Purism and Pine64 are sending their dev kits to other mobile OSes and encouraging them to work on ports is incredible. We really can’t ask for more.
7 Likes
dat’ quake 2 running on the dev-kit though > https://puri.sm/posts/librem-5-june-software-update/
2 Likes
Hi Amosbatto. Looking through these posts I found this from you. It seems I’m missing something: besides Ubports who else did Purism send dev kits to?
As far as I know, only KDE Plasma Mobile and UBports got Librem 5 Dev Kits. UBports won’t get the Librem 5 until 2020 and it is probably the same for the KDE Plasma Mobile team, so Purism hasn’t collaborated nearly as well with the other mobile projects as well as PINE64.
Of course, PINE64 is relying on the mobile OS projects to supply the software, whereas Purism is developing its own mobile OS – creating its own mobile shell in Wayland+GTK, writing new mobile apps (Calls, Chats, squeekboard, Kings Cross, etc), and adapting GNOME apps with libhandy.
1 Like
Never heard about the Librem 5 running coreboot? All info I read from purism was that it will be runnung uboot (just like many SBCs and the Pinephone).
Also, there are already phones that run a Linux userland. Have you tried one of the phones supported by UBports such as the Nexus 5? You can run a Desktop in convergence mode since quite a while as you can see in this video from around two years ago:
My bad. Coreboot is only for x86 processors (Intel or AMD). The Librem 5 will use U-Boot.
Not really - coreboot also works on non-x86 hardware. Several ARM-based Chromebooks use it and even facebook runs it on some ARM servers. On the Chromebooks it is also used it to verify the boot chain (secure boot). Sadly, for the L5, I did not find any information whether and how secure boot is going to be implemented.
1 Like
Thank you, I must have missed that. So they are thinking about porting coreboot to the device later, but I guess it will ship without any evil maid protection and an “open” uboot. Imho this is weaker than what Google devices offer when it comes to protection from “regular” evil maids and - coming back to the OP - nothing that really distinguishes the L5.
Regarding the secure boot: What you mean is UEFI secure boot. The term “secure boot” itself is quite ambigious but I suppose we all know what we want here.
Slightly different direction: Some people out there do already have a phone. Would be nice if someone could run some benchmarks on it. There are not so many i.MX8 benchmarks on the internet and especially not from a phone
2 Likes
Looking at the benchmarks of the OnePlus One (the phone I am currently using), the Librem 5 has an only ever-so-slightly slower processor, a 720p instead of 1080p screen, about half the storage, but more modularity/repairability with a removable battery (of slightly larger size), SD card slot (so it can have the same amount of storage or more), and modular modems, as well as the exact same back camera and amount of RAM, so I would say the OnePlus One is at least fairly similar, especially since both phones have unlocked bootloaders.