Why I’m not backing the Purism Librem 5 phone

NOTE: This is a post about my opinion on the device, hence the title of “Why I’m not backing….”, people have been explicitly asking me why I’ve not backed it, this documents it so I don’t need to keep repeating myself!

Numerous people have come up to me and asked “So will you get Fedora to run on your Librem phone?” and when my response is “No, I’ve not backed it” I get weird looks with a question of “Why?” I had thought it was time to do document my concerns with this laudable venture. This was certainly further qualified when I had to inform someone from the EFF that they’re delirious about the “it doesn’t need closed source firmware” on the i.MX chips that are being proposed. While I applaud the general principals and ideas of a fully open rights protecting phone I can’t help but feel that the group doing it either are being false at worst or naive at best with some of their statements.

Firmware

Their site claims “The i.MX 6/8 CPU will be completely free software without any binaries whatsoever!” while this could be sort of true if you want a hobbled device it’s not really the case at all. There’s a number of firmwares that are needed to make a number of pieces of functionality of a mobile device useful. Firstly the SDMA driver needs a firmware to run at any level of reasonable speed. Secondly the accelerated media decode, which will be required if you actually want to consume meda on your phone and have more than moments of battery life, also needs firmware. You’ll note on the media decode I don’t reference the actual firmware! Why? Because it’s not actually distributed in the linux-firmware repository so you have to request it from NXP or somewhere with appropriate signups (while I’m not 100% sure I believe having a driver in the linux kernel without required firmware in linux-firmware is a breach of the requirements of said driver in the upstream kernel).

i.MX6 or i.MX8 SoC

The i.MX 6 or i.MX 8 option concerns me. Basically make a choice! The core issue I have is the i.MX6 SoC is ancient, being announced back in Jan 2011, and based on a Cortex-A9 SoC. It doesn’t support USB-C so to ship as promised they’ll need to add a PCI-e attached USB-3 controller, charging circuitry, and maybe even a LVDS to Display Port option plus a chip to MUX the three through the actual USB-C port if they want to be able to ‘dock’ which will make power consumption on the phone even worse! If I’d spent $600 and received a phone in January 2019 based on an eight year old 32-bit chip design I’d be seriously pissed off. To be quite honest the i.MX8 is no spring chicken either, being announced in September 2013, it’s based on the already quite long in the teeth Cortex-A53 SoC design which was the original aarch64 “little” low end design but it does at least support USB-C on the SoC. The i.MX SoCs are generally quite nice, and the i.MX6 is quite well supported upstream, but the whole line of SoCs are more targeted towards embedded applications like cars, so they do have a long support cycle. They’re not a mobile phone focused SoC though, they also tend to be quite slow to get moving in the market/availability and the i.MX8 has little upstream support in the kernel as yet. Sure the etnaviv driver enables an open 3D accelerated driver, one that isn’t supported by the vendor so doesn’t enable all the features upstream, but you can run this today on Fedora 26/27 on the i.MX6 SoCs now but a free GPU driver is not the only reason to choose a platform.

General concerns

I can’t help but feel that there’s going to be a lot of disappointed people that will end up receiving an expensive sub standard device, probably late, that ends up not taking us much further along the road, to a fully open rights protecting phone, than the days of the Nokia n9xx series phones running Maemo. The HW, if based on an i.MX6, will certainly not be much further along that route and still stuck in the past in terms of HW. I personally believe the project would be better off engaging with the Qualcomm community team to use the Qualcomm 820c/600c SoCs because there’s an open driver that Qualcomm are working to improve, and while there’s a need for firmware for GPU and media offload, in reality it’s no better/worse than the i.MX devices with the bonus that their devices that are more current and aimed at mobile workloads with the vendor actively working to upsteam the enhance the support support of their SoCs.

Ultimately I think a device that closely resembles the specs of a phone of recent history, than that of ancient smart phone history, is likely to get a better following and hence a better software ecosystem than one that’s the same era as the Motorola DROID 4.

Update: So just to clarify a few things that were bought up in a couple of threads:

First this reddit thread:

  • I don’t question the value of hardware isolation of the various wireless interfaces that they claim, or the ability of them being able to deliver that bit on what ever SoC they choose, that is why it wasn’t addressed above.
  • I bought up USB-C because it is explicitly claimed as a feature.
  • I bought up display port because given USB-C above and their “It can be a desktop computer and phone all-in-one” claim, including a nice picture, then DP over USB-C is the only real option for that functionality.
  • Qualcomm chips were an example of other SoCs I believe might be a better fit, yes they do provide options in their APQ line without built in radios, they were just an example of another option, there are other possibilities, it wasn’t meant to provide a guarantee, it was an alternative example.
  • Yes, all ARM processors have onboard boot firmware, it’s generically referred to as “PBL” (Primary Boot Loader), so do most other processors.

Second this purism thread:

  • Sure you can disable the media engine with an e-FUSE but media is kind of useful for a lot of use cases like video config, audio calls and music, not just watching videos. If they choose this route, I would hope they leave the fuses unblown and document how a end user can do it else the $600 is a whole lot less useful for a lot of people

Ultimately the main points is I have to make about all of the above is two fold, firstly it’s my opinions and why I didn’t back the device, and secondly there appears to be some large discrepancies in the statements they make about the device and SoCs which I would not have expected and that is the key problem for me because it causes concerns over the ability to deliver a working and useful device to me. $600 is not a small amount of money, for me at least, to hedge on what *might* be a i.MX8 or might be an old 32 bit i.MX6.

A long overdue status update of Fedora on ARM

Well I’ve been meaning on doing a status update on ARM as well as a number of blog posts for quite sometime but I’ve had some personal changes I’ve been settling into (more on that sometime soon).

So first and foremost we’ve announced (a slightly delayed) Fedora 18 ARM alpha. There’s a some of images there for supported devices but if there’s an image you’d like that’s not there feel free to come and help out to make it happen.

We’re looking pretty good for Fedora 18. We’ve got even more packages built than what we had for Fedora 17 and we’ve fixed and improved a lot of issues. I’ve spent a lot of time massaging the kernel into better shape with the help of the Fedora Kernel team and jwb in particular. We have people polishing desktop environments like XFCE and KDE with thanks to some of the XO 1.75s that people received as part of The Fedora Summer of Fun and I look forward to seeing more of the 50 people that received one coming and helping out. Not everything was quite so rosy though as the anaconda newui work has delayed more than just the main Fedora release. We do still have a lot of work to as while the vast majority of packages build and a lot of them even run there’s a lot of testing and optimisation to do.

But it’s not all about Fedora 18 as we’re already working on Fedora 19 (that is after all the reason we branch just prior to Alpha release)! The big thing to note to date is I’ve now landed the first support for a unified kernel. We should be able to boot around 4 different SoC platforms with the 3.7 kernel but expect this to expand rapidly in the 3.8 kernel and by the time Fedora 19 is released with what will probably be the 3.9 kernel I’m hoping we should be able to much easier support a lot more devices with just a couple of kernels.

The last couple of weeks has also been quite mammoth in general ARM news. In the shipping now news the first of the new ARM Cortex-A15 chips has made it to a great and cheap device. We hope to get it running a Fedora Remix soon. It’s the first device and the Samsung SoC based on the A15 and it’s the first of many we’ll see over the next couple of months.

In other not so shipping news it’s been mega ARMv8 / arm64 announcements week. It start with Andrew Haleyannoucing Red Hat is working on openjdk for ARM64. This was followed by Linaro announcing a ARMv8 image based on Open Embedded. Then it was AMD announcing ARMv8 chips and it’s working with Red Hat on them. And then finally today was the announcement of Linaro Enterprise Group. LEG for short (I’m already sick of the puns!). This is great news! And there should be the first starts of the Fedora bring up being available soon and a lot of work to do over the next year too!

Overall it’s been a busy six months in ARM and for me personally. I’ve known about a number of the announcements and it’s finally great to have the cat out of the bag. The soon to be released (hopefully sooner rather than later!) Fedora 18 is another pretty big step forward for ARM on Fedora. The next year is going to be a fun ride!

So one of the things that people often ask me is how do I get involved in ARM stuff. Most of the boring things like builds are mostly automated so I usually recommend to get a device and start using it, hacking on it and testing it. Even the qemu image is a good way to get started. There’s almost 12,000 source packages in Fedora so it’s impossible for us to test all use cases. There’s also a lot of bits of hardware even on the supported devices like the panda boards we don’t have time or the ability to test from GPIO to various sensors etc. So that sort of stuff is a good way to begin!

Fedora Board and run off voting

Well it seems I was re-elected to the board for a second term. I’m looking forward to driving forward some of the issues I was dealing with and continuing with the projects I was working on. Of course the board is just a small proportion of what I do within the Fedora Project. I believe it’s important to represent the areas of the project I work in such as ARM as well as other wide projects such as OLPC and Sugar Labs that use Fedora as a core base to their projects as well as contributing back to some of the non technical parts of the project.

Of the three board seats that were up for election the third seat was a dead heat so don’t forget there is run off election between the two candidates that ends tomorrow.

Don’t forget to VOTE once again. It literally takes less than a minute to follow the link and make your vote heard. I personally think that this is as important as the first vote to ensure we get the best candidate.

I look forward to working with you all over the next 12 months.

My Fedora 2011 in review

Its been a some what mixed year for me personally and I certainly won’t be massively disappointed to see the end of 2011. In Fedora land the year has been completely full on!

The first major event that kicked off 2011 for me in Fedora was FUDCon Tempe which as always was brilliant. Its always awesome to catch up with a lot of Fedora Friends and to drive forward various bits of the project that are sometimes easier done face to face, whether it be in a session or at FUDPub over a beer or two! It was at Tempe that our fearless leader threw down his first challenge of the year to me… to blog about what I’m doing in the land of Fedora on a weekly basis. I didn’t quite meet this goal but have still averaged a post every fortnight.

From April a massive amount of my time was taken up with helping the Fedora ARM in particular getting Fedora 14 built for the XO 1.75 but also massively fixing packages upstream to build on ARM. With the F-14 release for the XO out I’ve been concentrating on F-15+ and later for both hard and soft floating point. The ARM project still continues to consume massive amounts of time and has basically covers a lot of the things I wanted to achieve as part of the Fedora Mobility SIG.

May saw me head off to the excellent Red Hat Summit for the second time. I was there for work and as always its very useful for the type of work I do for my $dayjob. I helped out on the Fedora booth and as always spent quite a bit of time with a number of Fedora contributors. It was there that our fearless leader convinced me that standing for The Fedora Board was also a good idea.

Fedora 15 was next up on the list, of course. A great release with gnome-3 and all sorts of other goodies. Not so good for Sugar on a Stick which had massively broken networking 🙁

October saw me attending FUDCon Milan which was a rather shorter than some FUDCons but great as always.

Fedora 16 was much more successful for Sugar on a Stick and we shipped probably the best release ever. In fact I think Fedora 16 was an awesome release.

I’m looking forward to 2012 greatly, both in the land of Fedora and in my personal life. I’m looking forward to seeing ARM progress onwards and upwards and hopefully make it to a primary architecture in the coming year. I’m not one for resolutions, I think ongoing reviews are much better so I look forward to working with all my Fedora friends throughout the coming year.

Fedora 14 RC1 rootfs for armv5tel

Its been a long while coming, I’ve been meaning on cutting a new F-14 rootfs for a while but I’ve not managed to get around to it.

So what’s new since the last one? Frankly a lot!

  • Kernel’s included for omap, tegra and qemu
  • All packages signed and using the mirrors
  • minimal and XFCE images
  • a lot more!

This release has been proven to be pretty stable and even reasonably fast, in fact its what basically makes up the OLPC XO 1.75 11.3.0 release that I’ve spent the best part of 6 months building 🙂

Downloads:
Fedora 14 RC1 armv5tel minimal rootfs
Fedora 14 RC1 armv5tel XFCE rootfs

Details about what to do with the rootfs can be found on the Fedora ARM wiki pages. Beware its not for the faint of heart.

Enjoy!

New release for OLPC XO laptops

So yesterday the 11.3.0 release of the XO-OS went gold. Its the first release to support the ARM based XO-1.75 and as a result the XO-1.75 is also the first commercial product to be based on Fedora ARM! This is the culmination of over eight months of solid work for me.

There’s a number of interesting points of these releases that the Fedora community might not be aware of. The 11.x releases of the OS have been derived from Fedora 14. Pretty much the entire release is built from mainline Fedora with very few differences, and most of those are patches to the kernel including build related stuff, and a few patches to the Sugar UX to assist with deployments. I strongly suspect that the 11.x releases are the largest deployment of Fedora 14 anywhere 🙂 and probably also of the gnome desktop and its components too.

Moving forward from this release we’re investigating moving the OS release process to mirror rawhide. We’re aiming for the XO-OS 12.1.0 release to be based on Fedora 17 and be released around a month after the main Fedora 17 release. Its going to be a massive release as its encompassing a move of the Sugar UX to gtk3 and gobject-introspection and associated underlying changes as well as jumping to other newer technologies like systemd and NetworkManger 0.9. I’ll be doing a release of Fedora 16 on XO for the XO-1 and XO-1.5 with the latest sugar 0.95.x development release for olpc/sugar developers and others that are interested in testing. I’ll also be doing regular snapshots from rawhide throughout the release process.

One of the advantages I see in moving to rawhide is that we’ll be testing the functionality the OLPC uses and depends upon as its being pushed to rawhide which means we can catch all breakages as early as possible and file bugs or generally bother people while its fresh in their minds rather than trying to get fixes for things that broke in the dev cycle two releases ago and that the developer likely doesn’t have any interest in any longer.

So for all Fedora people out there with various releases of OLPC XO hardware gathering dust now is the time to dust it off and play again as there’s new stable releases on F-14 and soon to be various releases on the latest and greatest Fedora releases. I announce all releases to the Fedora OLPC list. The XO-1 is even getting faster with each new Fedora release so there really is no excuse 😀

The Rumor Of My Demise Has Been Greatly Exaggerated!

So it’s been a long time since I’ve blogged! At the beginning of the year I was aiming to post regularly. Jared challenged me to blog about my Fedora happenings weekly at FUDCon Tempe, that seemed to go OK until around June. For a while there I was actually quite a bit ahead, now I’m about 10 posts behind my goal 🙁

So what has this slacker been up to? Well quite a lot actually!

  • I’ve started my tenure on the Fedora Board. I’m some what into the groove now but I need to start blogging more about it too.
  • Fedora 14 on ARM. As part of the OLPC XO 1.75 I’ve been rebuilding the entirety of Fedora 14 on ARM. Its been somewhat daunting and I think to some people it must look like I’m on a quest to get a ChangeLog entry in every package in the distro :-/
  • My $DAYJOB has been manic! Lots of interesting RHEL 6 bit but also massive amounts of VMWare vSphere stuff. I’m off the VMWorld in Vegas this week so if there’s any Fedora people about at VMWorld or Vegas and you want to catch up get in touch with me

I’ve also been going through the final bits of my naturalisation process in the UK and attempting to sail regularly with my crew. Last week we won 2 races and came second in two races in the Sussex Regatta which gave us an overall win 😀

There’s all sorts of other things going on but I think that’s the biggies. Hopefully I’ll be able to start blogging more in the coming weeks!

Fedora 14 on ARM Alpha release

I wanted to do this over a week ago to get this out over a week ago but I broke my Beagle Board XM’s boot and only had time to investigate the issues and fix it on the weekend.

You can get the Fedora 14 ARMv5tel rootfs here. I’m calling it an alpha as none of the packages are signed and just pulled straight from koji. I’ve got a few things on my list that need to be fixed but we’re not looking too bad. One thing to note here is that you’ll need at least a 2.6.32 kernel. All the other details to get it to work are the same as for the F-13 releases.

Note this isn’t the “hardfp” release, that will be coming with F-15 at the same time as the release for this arch and with luck we’ll be in a similar situation with F-15 shortly 🙂

I’ve been crawling through “build previous” slowly… I think we’re around 15% through rebuilding the entirety of the gold release of Fedora 14. While the script has been running I’ve been also pushing targeted groups of packages to minimise the number of runs we have to do and for what I believe to be the most useful stuff. We’re currently concentrating on “dist-f14” (ie the packages tagged for the original release sans any updates), hopefully we can start looking at updates soon.

Now it the time for people that are interested in getting particular group of packages to step up and help out. This includes particular desktops such as gnome/kde/xfce/lxde etc and particular development environments and languages such as eclipse or java/mono/ocaml/haskel etc so if you helped out with the F-13 stuff on ARM we’d like some more assistance.

Fedora ARM hardfp bring up FAD

So the hardfp on Fedora bring up is happening today. Newer ARMv7 chipsets can basically run in two modes that aren’t compatible. The current and most widely used variant is softfp which uses a software based FPU. The newer and cooler (read faster) variant ARMv7 chips contain a hardware FPU but the GNU open tool chain has only recently got to the stage where its all supported. All the needed components should be in Fedora 15 with one of the key pieces being gcc 4.6.

What does it mean for ARM on Fedora…. in the short term likely not much. The older ARMv5tel platform support isn’t going anywhere. Its a little like mainline x86_64 vs i386 platforms, except you can’t run 5tel binaries on 7hl distributions (although you can run an entire 5tel distro on ARMv7 hardware. Also with the hardfp stack support being very new there will likely be a number of weird and interesting bugs that will make it not for the faint of heart.

With luck this should change in the Fedora 16 time frame and with luck we should be in sync on both armv7l (hardfp) and armv5tel (softfp) in the Fedora 16 timeframe for a near in-sync release.

Mobility Devices

I’ve been meaning to do a post with details of all the small devices I have. Not all the devices pictured below currently run Fedora although nine out of the twelve shown either currently run Fedora or I’ve had them boot Fedora. The three devices that don’t, as yet, boot Fedora are devices 8, 9 and 11. There’s no reason why they can’t as they all run some form of Linux, in the case of 8 and 11 its Android and 9 is a Logitech SqueezeBox Touch.

One of the things that I’ve been trying to achieve in Fedora for many years is slimming of the required dependencies of certain combinations of installs. Not everyone needs everything, and not everyone has Terabytes of storage that can be thrown about.

So what are all the devices above. I’ll go through each one and give some details of each:

  1. OLPC XO 1.75: 1Ghz ARMv7 Processor, 512Mb RAM, 4Gb eMMC storage, GPU Unknown
  2. OLPC XO 1.5: 1Ghz VIA C7 Processor, 1Gb RAM, 4Gb microSD storage, VIA VX855 GPU
  3. OLPC XO 1.0: 433Mhz AMD Geode Processor, 256Mb RAM, 1Gb Flash storage, Geode GPU
  4. Nokia n900: 800Mhz OMAP3 A8 ARMv7 Processor, 256Mb RAM, 32Gb eMMC storage, PowerVR SGX530 GPU
  5. BeagleBoard XM: 1Ghz OMAP3 A8 ARMv7 Processor, 512Mb RAM, 8Gb microSD storage, PowerVR SGX530 GPU
  6. Fit-PC 1.0: 500Mhz AMD Geode Processor, 256Mb RAM, 40Gb HDD, Geode GPU
  7. O2 Joggler: 1Ghz Z520 Atom Processor, 512Mb RAM, 2Gb Flash storage, GMA-500 Poulsbo GPU
  8. Orange SanFrancisco AKA ZTE Blade: 600Mhz Qualcomm MSM7227 ARMv6 processor, 512Mb RAM, 150Mb Flash, Adreno 200 GPU
  9. Logitech SqueezeBox Touch: 600Mhz ARMv6 Processor, 128Mb RAM, 128Mb Flash, GPU Unknown
  10. Toshia AC100: Dual Core 1Ghz Tegra 250 A9 ARMv7 Processor, 512Mb RAM, 8Gb SSD, GeForce ULP GPU
  11. Samsung Galaxy Tab:1Ghz Samsung A8 ARMv7 Processor, 512Mb RAM, 16Gb SSD, PowerVR SGX540 GPU
  12. Asus EeePC 901: 1.6 Ghz Atom Processor, 1Gb RAM, 4Gb Primary SSD, 16 Gb Secondary SSD, Intel G450 GPU

All the devices have WiFi, some have wired Ethernet, some 3G, GPS etc.

There’s two main issues with smaller “mobility” devices. Firstly is the GPU support is obviously a mixed bag, there’s obviously AdamW’s favourite GPU… the Poulsbo on the Intel Z5xx series atoms. The Poulsbo is basically a variant of the PowerVR GPU’s that Intel licenese. Unfortunately this is still basically the case for the new Z6xx series which contain a GMA-600 Poulsbo device. Buyer beware! Its been leaked this week that Intel for later generations isn’t going to improve the situation as they just going to use the PowerVR GPU directly.

The other issue is storage. Most of the devices just don’t have that much of it. This is why I spend so much time filing bugs to split out dependencies. While you can install the standard desktop into 4Gb it doesn’t leave that much for things like yum updates or fun things like music 🙂