The state of open source GPU drivers on Arm in 2019

I first blogged about the state of open source drivers for Arm GPUs 7 years ago, in January 2012, and then again in September 2017. I’ve had a few requests since then to provide an update but I’ve not bothered because there’s really been no real change in the last few years, that is until now!

The good news

So the big positive change is that there’s two new open drivers om the scene with the panfrost and lima drivers. Panfrost is a reverse engineered driver for the newer Midguard and Bitfrost series of Mali GPUs designed/licensed by Arm, whereas Lima is aimed at the older Utguard series Mali 4xx series of devices. Panfrost, started by Alyssa Rosenzweig, and now has quite a large contributor base, has over the last few months has been coming along leaps and bounds and by the time Mesa 19.2 is out I suspect it should be able to run gnome-shell on an initial set of devices. I’m less certain the state of Lima. The drivers landed in the kernel in the 5.2 development cycle, which Linus just released. On the userspace side they landed in the mesa 19.1 development cycle, but they’ve greatly improving in mesa 19.2 cycle. Of course they’re all enabled in Fedora rawhide, although I don’t expect them to be really testable until later in the 19.2 cycle, but it makes it easy for early adopters who know they’re doing to be able to start to play.

A decent open source driver for the MALI GPUs from Arm had been the last biggest hold out from the Arm ecosystem we’ve been waiting for and it covers a lot of the cheaper end of the SBC market with a lot of AllWinner and some Rockchip SoCs having the MALI 4xx series of hardware, which will use the Lima driver and other lower to midrange hardware shipping with the newer Mali midguard GPUs like in the Rockchip 3399 SoC.

Other general updates

Since I last wrote the freedreno (QCom Ardreno) and etnaviv (Vivante GCxxx series) have continued to improve and add support for newer hardware. The vc4 open drivers for the Raspberry Pi 0-3 generations have seen gradual improvement over time, and there’s a new open v3d driver for the Raspberry Pi 4 which they use from the outset.

The last driver is one that seems to have transitioned to be in limbo is the driver for the Nvidia Tegra Arm platform. While it has an open driver for the display controller, and the GPU mostly works with the nouveau driver, at least on the 32 bit TegraK1 (the upstream state of the Tegra X-series is definitely for another post) they appear to have yet another driver, not their closer x86 driver, but another one (not the latest rev, which is 4.9 based, but the only linkable version I could find) which is needed to do anything fun from an CUDA/AI/ML point of view, I wonder how it will fit with their commitment to support Arm64 for their HPC stack or will that only be interesting to them for PCIe/fabric attached discrete cards for HPC super computer deals?

That brings me to OpenCL and Vulkan for all the drivers above, for the vast majority of the open drivers support for either is basically non existent or in the very early stages of development so for the time being I’m going to leave that for another follow up in this long winded series, probably when there’s something of note to report. The other thing that is looking quite good, but one for another post, is video acceleration offload, there’s been quite a bit of recent movement there too.

Raspberry Pi improvements in Fedora 29

So Fedora 29 is probably going to account for the largest single improvement to support on the Raspberry Pi support in Fedora since we added initial support in Fedora 25. It certainly wasn’t without issue, but after quite a bit of debug we’ve got the post release issues with the WiFi back to being stable!

WiFi improvements
The support for upstream NVRAM files and the ability to add those files to linux-firmware means we get WiFi support for the Raspberry Pi 3 Series of devices out of the box! No need to grab anything, it just works! Well mostly, we had some issues with WiFi being very intermittent, as well as a missed bug around aarch64 but now with the 4.19.10 kernel everything appears to be working and stable. This makes me very happy and it took longer than I had hoped but we’re there. This device specific NVRAM driver support will also help another bunch of cheap Arm and x86 based devices that ship with Broadcom/Cyprus based WiFi support moving forward.

ZRAM enabled by default
By supporting and enabling ZRAM swap by default we get a more responsive device and less wear on the MicroSD storage. Over all we’ve seen reasonable performance improvements and to no date no major issues.

GNOME performance improvements
In May 2018 the Raspberry Pi Foundation kindly hosted a GNOME Performance Hackfest in the lovely Cambridge. Over a couple of days we managed to fix a number of issues seen, review and document a number of issues and work on a number of ways of reducing the memory usage of GNOME. Of course this improvement is primarily seen constrained devices like the Raspberry Pi but ultimately less memory utilisation by GNOME even helps devices with decent amounts of RAM and CPUs too. The fixes didn’t arrive in time for Fedora 28, but a bunch have landed in Fedora 29 providing noticeable improvements, and the GNOME team is by no means done and there will be more coming in Fedora 30 and beyond! It was an excellent start and I expect there will be ongoing enhancements here into the future especially with devices like the Purism Phone which will have similar constraints.

Initial CPU frequency support
Another of the largest issues around the Raspberry Pi is complaints it was slow, part of the issue here is that there’s no upstream CPU Frequency driver which means all models of the Raspberry Pi run at a glacial, but safe, 600Mhz out of the box compared to the highest speed, which on the 3B+ is 1400Mhz. With Fedora 29 we’ve landed an experimental cpufreq driver which allows us to run the Raspberry Pi 3-Series at much closer to optimal speeds. While this is experimental it might not stay around if we find out it causes issues or ends up being a maintenance burden but to date it hasn’t yet appeared to have caused any issues.

HWmon Voltage Sensor
There’s a new driver that reports when the voltage supplied by the PSU drops below the required voltage. It can be a bit noisy in dmesg but one of the biggest support problems we have with the Raspberry Pis is people using a power supply that’s not powerful enough, this issue is more of a problem with Fedora 29 because with the support for running at faster frequencies due to the cpufreq driver it means we also draw more power and some PSUs that were previously fine now cause issues because they can’t supply enough current.

Enhanced support for config.txt
A lot of the hardware addons are supported in Raspbian are done by enabling things in the config.txt file, this in turn does things like loading DT overlays and merging them with the base DT to enable extra hardware like HAT support. We have enhanced the way Fedora works with this which enables us to be much closer to the way Raspbian handles these things. The advantage this has is that the documentation that’s written for Raspbian is then usable by Fedora in the wider Raspberry Pi ecosystem which in turn makes it easier for end users to get HW up and running due to less differences in process. There’s further enhancements to make here but every step closer is easier for everyone to enable and use their favourite HATs.

Improved bcm283x firmware support
In preparation for grub2 support we enhanced how we deal with the firmware that the Raspberry Pi uses for booting. This deals with the early startup. We never use to upgrade it by default to ensure things didn’t break, but it also meant most users also didn’t by default get the fixes and enhancements. Now we do. The config.txt is also handled directly which means if you never edit the file you now automatically get any changes we make, because rpm handles the file as a config file, if we change it you get a .rpmnew file so you won’t lose your changes.

Camera support
This wasn’t available in the Fedora 29 4.18 kernels, but with the rebase to the 4.19 kernel the support for the camera on the Raspberry Pi CSI Camera interface improved enough we could enable this in Fedora. The early 4.19 kernels don’t automatically detect and load support if the camera module is attached. There’s some patches in 4.20 in rawhide for this, and we’ll bring some of this to 4.19 soon, and we’re working with upstream to further improve the camera support. You’ll also want the latest bcm283x firmware which tweaks some of the config.txt and updates to a firmware with ISP fixes.

Another improvements
There was also a number of general Arm improvements which sped up crypto on the Raspberry Pi, improved the USB, fixed up some issues with the wired ethernet on the 3B+, power and a number of other fixes. As always there’s more coming. The 4.20 kernel rebase should also bring with it analog sound support early in the new year.

Conclusion
Overall I was pleased with the work that landed in Fedora over 2018 for the Raspberry Pi. The WiFi regression was disappointing, but now with that fixed in 4.19.10 we have WiFi support out of the box without users needing to download anything which moving forward will make things a lot more straight forward. The initial support for the camera makes it much more useful in numerous use cases and we’ll really polish up the HAT support in Fedora 30 which for me is the last remaining big ticket item for Raspberry Pi support. There’s still some annoying bits around the EDID detection in the display, but there’s work to improve that upstream, and also there’s work to land the media decode offloading upstream too which will also one of the few remaining bits.

Using ZRAM as swap on Fedora

One of the changes I did for Fedora 29 adding using ZRAM as swap on ARM. The use of compressed RAM for swap on constrained single board computer devices has performance advantages because the RAM is an order of faster than most of the attached storage and in the case of SD/emmc and related flash storage it also saves on the wear and tear of the flash there extending the life of the storage device.

The use of ZRAM as swap isn’t limited to constrained SBCs though, I also use it on my x86 laptop to great effect. It’s also very simple to setup.

# dnf install zram
# systemctl enable zram-swap.service
# reboot

And that’s it! Simple right? To see how it’s being used there are three commands that are useful:

# systemctl status zram-swap.service
● zram-swap.service - Enable compressed swap in memory using zram
   Loaded: loaded (/usr/lib/systemd/system/zram-swap.service; enabled; vendor preset: disabled)
   Active: active (exited) since Tue 2018-10-09 22:13:24 BST; 3 days ago
 Main PID: 1177 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   Memory: 0B
   CGroup: /system.slice/zram-swap.service

Oct 09 22:13:24 localhost zramstart[1177]: Setting up swapspace version 1, size = 7.4 GiB (7960997888 bytes)
Oct 09 22:13:24 localhost zramstart[1177]: no label, UUID=d79b7cf6-41e7-4065-90a9-000811c654b4
Oct 09 22:13:24 localhost zramstart[1177]: Activated ZRAM swap device of 7961 MB
Oct 09 22:13:24 localhost systemd[1]: Started Enable compressed swap in memory using zram.
# swapon
NAME       TYPE      SIZE   USED PRIO
/dev/zram0 partition 7.4G 851.8M   -2
# zramctl
NAME       ALGORITHM DISKSIZE   DATA  COMPR  TOTAL STREAMS MOUNTPOINT
/dev/zram0 lz4           7.4G 848.3M 378.4M 389.9M       8 [SWAP]
#

When I was researching the use of ZRAM there was a lot of information online. A lot of implementations sliced up the zram into multiple slices to enable the balancing of the slices across CPUs, but this is outdated information as the zram support in recent kernels is now multi threaded so there’s no performance advantage to having multiple smaller swap devices any longer, and having a single larger swap space allows the kernel to be more effective in using it.

In Fedora all the pieces of the Fedora implementation are stored in the package source repo. So those that are interested in using zram for other use cases are free to test it. Bugs and RFEs can be reported as issues in pagure or in RHBZ like any other package.

Fedora on the UDOO Neo

Some time ago I backed the UDOO Neo Kickstarter as it looked like a nifty, well featured, IoT device. I got the full option which came with 1Gb RAM and both wired and wireless Ethernet and some add-on sensors. It was a well run kickstarter campaign and the device was well packaged with a fab box. It has both a Cortex-A9 processor to run Fedora and a Cortex-M4 embedded processor to enable you to do Arduino style functionality which should be interesting to experiment with.

For various reasons it has sat around gathering dust, it’s been a bit of a long drawn out process with me randomly poking it as time allowed.. Primarily this was because there was no decent upstream U-Boot and kernel support, and I’d not had the time to hack that up myself from various downstream git repositories, but even without Fedora support their forked Ubuntu distro in the form of UDOObuntu has an experience that is truly terrible!

Late 2016 the problem of a lack of upstream support for U-Boot and kernel changed with initial basic support landing upstream for all three (Basic, Extended and Full) models so with a few cycles over a weekend it was time to dust it off to see if I could get Fedora 26 (did I mention this has been long running?) running on it and to see what worked.

The first thing for me to do was to setup a serial console for easy debugging. The UDOO Neo documentation is generally outstanding and the pins for the UART1 TTL are documented. Two things to note here is that the headers are female rather than the usual SBC male pins so I had to bodge my usual usb to serial TTL with some male-male jumper wires and you’ll need a ground for the TTL which is undocumented on their page, I used one of the GNDs as documented on connector J7 and all was good.

So after an initial set of fixes to the U-Boot support it saw my Fedora install and started to boot! Success! Well sort of, as mentioned above the initial support is rudimentary, it started to boot the kernel and very quickly managed to corrupt and destroy the filesystem not making it much beyond switch root. That wasn’t good. In the last week or two I’ve had a little time to look again, similar issues, it was better than it was a year or so ago but it still ended up with corruption. I reached out to one of the maintainers from NXP that deals with a bunch of the i.MX platforms and I got directed to a handful of patches, a test kernel and image later and a test boot… all the way to initial-setup! SUCCESS!

The core support for the i.MX6SX SoC and the UDOO Neo is pretty reasonable, with the MMC fixes it’s been very stable, all the core bits are working as expected, included wired and wireless network, thermal, cpufreq, crypto and it looks like the display should work fine. There’s a few quirks that I need to investigate further which should provide for a fun evening or weekend hacking. There has also been recently merged support for the i.MX6SX Cortex-M4 land upstream in Zephyr upstream for the 1.13 release, so getting that running and communication using Open-AMP between Fedora and Zephyr should also be an interesting addition. I think this will be a welcome addition to Fedora 29, and not a moment too soon!!

Fedora on the UP Squared

With the IoT Working Group and Edition moving forward I’ve been looking for an x86_64 device suitable for testing IoT related use cases. I was originally planning on using the MinnowBoard or Joule but given Intel has killed those product lines off it was back to the drawing board. I eventually settled on the UP², in particular I chose the UP² Pentium-4GB-32GB-PACK as it had everything I wanted in one box.

Hardware

The on paper hardware specs show a recent generation Intel Apollo Lake core, reasonable memory and storage options, an onboard FPGA, USB-3, dual ethernet and various other bits. The kit comes with options for active or passive cooling and the later the heatsink is massive, for the moment I’m running it on the passive cooling. The case is OK, I wouldn’t rave about it though. The power connector on the other hand is terrible, the PSU cable doesn’t seat well into the board and I’ve bumped it already and had it lose power, the power button is also tiny, so small in fact I mistook it for a reset button.

Fedora support

As you would expect the support in Fedora 27 is decent, accelerated 4K graphics, wired RealTek ethernet NICs, Intel m.2 PCI-e WiFI/Bluetooth, although the later is only 4.2 for IoT I would have appreciated Bluetooth 5, all work out of the box as expected. The firmware is uEFI and in theory supports secure-boot but I couldn’t work out how to turn it on in the firmware menus as it was greyed out, it also has a TPM2 module I’ve not had time to investigate. They eagle eyed would also note that I mention Fedora 27 even though Fedora 28 has been out a few days. Well for some reason F-28 doesn’t boot, I tried the network installer and the Workstation live image, they both get to the grub menu, then I get no output and nothing for a moment then it resets and we start again. I need to investigate this further but Fedora 27 Workstation livecd booted and installed fine so that’s what it’s got for the moment. Ultimately this is going to a host to test Fedora IoT so while I tested the general support this is fine.

IoT support

There’s a number of reasons I chose this particular device as an IoT test device:

  • Reasonably priced with a reasonable feature set.
  • Intel hasn’t killed it off yet like they’ve done with the Joule platform and Minnowboard 3 so I could actually buy it 🙂
  • Multiple network interfaces, reasonable WiFi and Bluetooth support.
  • Industrial IO sensors via an onboard Intel Sensor Hub. lsiio is reporting 9 sensors of various types. I’ve not checked this further yet.
  • USB-3, a Raspberry Pi HAT compatible connector and other options to add IoT related functionality or interfaces.

FPGA support

I’ve not looked at the FPGA support at all. The upstream kernel now has a FPGA Manager Framework and there’s a bunch of Altera FPGA support there but I’m not sure how it maps to this device. I also have to investigate open source toolchains for FPGA bitstreams as a lot of them just aren’t, I’ll likely do the HW enablement side of things and leave the toolchain bits to people that understand them. I also have the 96boards Ultra96 board so FPGA investigation was already on my Fedora 29 To Do list, and a lot of other people seem quite interested in them of late, no idea why 😉

Getting started with Fedora on the 96boards Dragonboard

Support for this board has been a long time coming, it was originally announced in March 2015 and shipped later that summer. Two years on we can finally add support for it to Fedora. The enablement here will also assist us with supporting the newly announced 600c and 820c boards more quickly. We’re not all the way there yet, there’s still some firmwares that needs to go upstream into linux-firmware, but the improvement is fantastic and it’s been a pleasure working with the 96boards and Qualcomm teams getting to where we are today.

At the moment we support running Fedora off either an micro SD card or a USB stick. We don’t currently support running off the eMMC and currently basically treat that as the location of the firmware. Anyway lets get started!

Updating the firmware

You’ll want to update to the latest firmwares, my board originally had an old firmware without support for PSCI and so it didn’t bring up all four cores or support reboot. OOPS! You’ll need the latest linux rescue images from the 96boards download site. As I write this the latest is the 17.09 release (version 88). Create a directory for this file before you unzip it because it’ll expand all into the current directory. While there we also need a u-boot build that’s prepared for flashing, the upstream support isn’t quite complete, we add a few patches to the Fedora build to get everything working nicely. You can grab a pre-built version here and also get LK firmware build which enables display output.

You’ll need a host with the fastboot utility, in Fedora this is found in the android-tools package, and a micro USB cable. This process is very similar to flashing a phone with a new image, not surprising given the chipset really. If you have a serial console on the board you can follow along on the console but it’s not required for this board.

To put the board into fastboot mode we hold down the volume down button, labeled as ‘(-)’ near the middle USB port and then power it on. Wait around 30 seconds to ensure it’s booted to fastboot. You can test this with the fastboot devices command. You’ll likely want to run the next commands as root, or use sudo, and be in the directory you created with the extracted firmware and u-boot build:

sudo ./flashall
sudo fastboot flash aboot emmc_appsboot.mbn
sudo fastboot flash boot u-boot.img
sudo fastboot oem select-display-panel adv7533_1080p

The flashall command runs a series of fastboot command to write out various early boot firmware to the eMMC, then we write u-boot out to the boot partition, and finally ensure that output is configured to appear on the HDMI port. Assuming you don’t get any errors from fastboot that should be all the firmware done and in place.

Fedora image and further setup

Next up is the Fedora image. I chose the Workstation image, but we also have a Minimal Image and a traditional Server image. GNOME not the fastest in the world as 1Gb of RAM isn’t really enough for GNOME-3 anymore, but it works well enough. On a USB stick or Micro-SD card (I’ve tried both). We need to write out the image, then expand the rootfs (Note: update XXX for the device you’re writing to):

xzcat Fedora-Workstation-27-1.6.aarch64.raw.xz | sudo dd status=progress bs=4M of=/dev/XXX
sudo gparted /dev/XXX (expand the last partition)
partprobe

Next up we need to adjust the kernel command line slightly, mount up the first partition and edit /EFI/fedora/grub.cfg and search for the string cma=256MB and delete it, then add in it’s place the following console=tty1 console=ttyMSM0,115200n8. Next mount the boot partition (partition 2) and create a sym link

ln -s dtb-4.13.9-300.fc27.aarch64 dtb

. Unmount the partitions and we should be good to go on the Dragonboard.

Plug in a keyboard, mouse (and/or a usb cable for the serial console if you’re going that route) and a HDMI cable, plug in the USB stick or SD card and power it up. If you’re following along on the serial console you should see output straight away, screen might take a little longer.

Once you’ve booted you should be able to complete initial-setup (text or the one from Workstation) and login. To get the WiFI and Bluetooth working you need to install a Radio (WiFi and friends) firmware package which I’ve made into a rpm you can grab from here until it lands into linux-firmware.

What next?

The DragonBoard 410c is pretty functional. I’ve not widely tested sound, the Venus media offload components (we have all the firmware and kernel bits for this), the GPS or some of the other more advanced components but I’ll have more details about those soon. I’ll be documenting the above plus other bits on the Fedora ARM wiki so keep an eye on that or get involved and help out 😛

Overview of aarch64 SBC support in Fedora 27

Support for ARM 64 bit (aarch64) Single Board Computers (SBCs) has been one of the most highly requested features along side the Raspberry Pi. It’s something I’ve been working towards almost as long too. Finally with Fedora 27 I felt we would have enough of the bits in place for a Minimum Viable Product (MVP).

You’ll note from the Fedora change linked above I was very cautious with what we planned to achieve. The change has a very focused list of images: Server, Workstation and Minimal and a limited list of devices: basically the Raspberry Pi 3, the 96boards Dragonboard 410c and HiKey, and a handful of AllWinner devices with a focus on the Pine64 series of boards. The reason for this was I knew there was going to be a lot of low level boot and kernel bits that needed focus and polish and the Fedora 27 cycle was severely limited time and resource wise so the plan was to focus on getting all the core bits into place for Fedora 27 and have a couple of well polished devices and then expand that rapidly for Fedora 28.

The key functionality we were aiming for was a well polished uEFI implementation in u-boot to enable a single install/boot path in Fedora on aarch64 using uEFI/shim/grub2 to boot Fedora on both SBCs and SBSA compliant aarch64 platforms. We now have that platform in place, primarily due to Herculean efforts of Rob Clark and Peter Jones, as well as many others who have provided insight into the deep dark details of the uEFI specification. Fedora 27 will ship with a quite heavily patched, well by Fedora’s standards anyway, u-boot 2017.09 which provides us the core of this functionality enabling us to use a vanilla upstream shim and grub2 to boot a standard Fedora. All this work is already upstream, or making it’s way there in 2017.11. In Fedora 28 there will be even more improvements that will enable us to do a bunch of other cool stuff (that’ll be a post for later!) and also enable much quicker upstream board enablement now all the core bits are in place.

So what do we actually support? Well all the usual bits that you would expect on a standard Fedora install, whether it be x86_64, ARMv7 or aarch64, like SELinux, containers, desktops and all the other bits. There’s a few bits and pieces that are a little rough around the edges but overall the feature is pretty robust. On a board by board feature set lets break the this down across the boards:

Raspberry Pi 3

The support for the Raspberry Pi3 is the equivalent to the ARMv7 support but with boot via uEFI/grub2. The memory isn’t quite as good as on 32-bit but that’s to be expected, overall it’s pretty reasonable for a device of the specs and cost. Like on 32 bit support we’re seeing regular improvements each release and throughout the releases. The aarch64 support for the RPi3 is just an evolution to this.

DragonBoard 410c

The support for the DragonBoard 410c is looking pretty decent. Qualcomm has been doing a pretty decent effort to get stuff upstream, we have firmwares for the GPU and for video decode/encode upstream as well, along with kernel drivers and the open freedreno 3D drivers, HDMI audio should work as well. The WiFi firmware isn’t yet upstream but I’ll document how/where to get that and hopefully that should be in linux-firmware soon as well. Overall I’m quite happy with the status of this device, although like all devices with 1Gb RAM it’s a little constrained, but that should make the newly announced 820c with 3Gb of RAM a decent device ;-). All the details for getting it running will soon be in the Fedora 96boards wiki page.

HiKey

Most features and functionality of the HiKey are supported, note this isn’t the HiKey960 (look to F-28 for support for that), except accelerated graphics due to the use of a MALI GPU. Other than that the functionality is pretty decent. You’ll likely want the latest tianocore firmware and the details for that can be found on the Fedora 96boards wiki page.

Pine64 (AllWinner A64 SoC)

We actually should have a number of devices based on the AllWinner A64 SoC working here but we’ve only tested the 3, 2Gb/1Gb/512Mb, Pine64 device sizes. The support for these devices is headless and you will need a serial console else you’re on your own as none of the display bits in the kernel have made it upstream, and of course the GPU is a MALI 400 series so when it does it won’t be fast. The support for the rest of the device is basic, it’s usable for a headless server style device, we support network, USB, KVM, RTC and a few other bits. Other than display we don’t yet support the SDIO attached wireless, sound, crypto offload or any of the other media interfaces. A lot of this is under review upstream so I think Fedora 28 should look much better for this series of devices and 4.15 might even bring very basic console output. Speaking of series of devices which ones should actually work other than the three Pine64 devices? Well the following A64 SoC devices have a Fedora built u-boot and kernel DT support so should work as well as the Pine64: BananaPi-m64, OrangePi Win, SoPine baseboard (PineBook boots if you’re happy with serial console), NanoPi-A64 and the A64-OLinuXino. We had some troubles with the AllWinner H5 SoC devices earlier in the cycle but I’ve had a couple of reports that it seems to be resolved so they should work too and that adds the Orange Pi PC2, Prime and Zero+ 2 as well as the NanoPi NEO2. So that’s around a dozen or so devices! 🙂

Other ARM64 SBCs

I’ve had reports that other aarch64 SBCs boot on Fedora just fine. I’ve not listed those where I can’t verify whether they boot with our uEFI enabled u-boot. Looking around on my desk I do have a number of devices that I expect us to be supporting in Fedora 28, or maybe even just enabling u-boot bits in a F-27 update.

Overall I’m pretty happy with the state of Aarch64 SBCs for Fedora 27 and what we’ve managed to achieve is such a short cycle!

Flock Rochester

I’m not going to do a day by day outline of what I did at flock, if I did it would basically be “blah blah blah I talked a lot to a lot of people about a lot of tech topics” and anyone that’s ever met me would have guessed that! It was, as in the past, a great conference. A big shout out to the organisers for an excellent event with two excellent evening events! So I’m going to give a brief summary to my talks and link to slides and video recordings.

My first talk was an overview of the state of aarch64 and POWER as secondary architectures. The slides aren’t particularly interesting as they’re just words for discussion points. The video has all the interesting bits. A related talk was Dennis’s Standardising ARMv7 booting with a memorial quote by Jon Masters 😉

My second talk was about using Fedora as a base for IoT. Slides are here but the talk was quite a bit different to the slides and is more interesting so I suggest watching the video.

I also actively participated in Dennis’s Fedora Release Engineering going forward because well obviously I’m part of it 😉 and it was interesting for where we’re going, and even where we’ve come from in the last year or so 🙂

Finally I loved the Keynote Be an inspiration, not an impostor by Major Hayden. He’s published a follow up blog post with a FAQ too.

The least memorable bit was the terrible Amtrak ride back to New York City. On the plus side it makes the worst of the British National Rail service seem amazingly on time! NEVER AGAIN!

Fedora 23 on the Thinkpad X1 Carbon gen 3

So my corporate laptop for the last three years has been a Thinkpad x220, it’s getting a bit long in the teeth, when I got it the x230 was already out but the corporate standard hadn’t rebased. This time I happened to get a new device just after the new corporate refresh so I have the shiny X1 Carbon gen 3 with real track pad buttons.

Of course I grabbed the latest rawhide nightly boot.iso to install the latest shiny! How did I get on? Initially it was disaster, the kernel crashed before I even got to anaconda (will spend some time to recreate and log that soon). Oops! So I grabbed a couple of the earlier installers and with a bit of trial and error before long I was at the initial anaconda screen. From there the process was relatively boring! Up and running with Fedora Workstation installed, disk encrypted I started to play with it to see which bits were good, bad or ugly.

So first up with the good. Over all the vast majority of the hardware just worked out of the box. The GPU, USB3, wired ethernet, wireless ethernet (iwl 7265 AC), trackpad/thumb pointer, bluetooth mouse, camera, onboard speakers all work just fine, I even managed to enrol my finger in the finger print reader without issue. I must say I’m loving the 1920*1080 screen over the old 1366*768 of the x220 and I’m getting use to the chiclet keyboard layout. Overall F-23/rawhide is solid right out of the gate with pretty much everything working as you’d expect on a stable release. 🙂

It’s not all rosy though and some of the bad is that I’ve not managed to get the firmware upgraded to support 4K displays @ 60hz, thanks to Major and Sandro for the heads up on this, but it never seems to find the usb stick as a bootable image. Not a major issue in the short term as the OneLink Pro Dock I ordered is AWOL but I’ll want it soon as I’ve got a standing desk with a Dell 24 inch 4K monitor. The x220 and 4K monitor had never really worked overly well, the big issue was it only ran at 30hz refresh but I knew that when I got the monitor because I knew I was due for a refresh soon, it also had random glitches. I also need to workout how to adjust the acceleration of the thumb pointer thingy with libinput. Adjusting either the trackpad or mouse options in control panel doesn’t seem to have any effect, I never really used the trackpad on the x220 but I admit I’m getting use to the two finger scrolling for reading long pages. This should all be relatively easy to solve with a bit of poking!

The ugly seems to be the stability of the iwl 7265 wireless driver/firmware. It generally works but regularly shits itself. Some times minor by dropping SSH connections, sometimes majorly resulting in a need to unload/reload the modules or even to reboot! URGH! I’ve heard people complain about recent Intel Wireless stability but the “Advanced-N 6205 [Taylor Peak] (rev 34)” that was in the x220 was always solid. The solid lockups seems to be when pushing a reasonable amount of data via rsync/ssh. I do have a WRT1900AC router and I’ve connected to the 5 ghz 11ac so I’m wondering whether this combo is part of the issues. There is a newer firmware that hasn’t made it upstream yet. I need to do some more playing here testing the 11n 2.4ghz network as well as testing the newer firmware and possibly some patches that are on the wireless mailing list which I’m hoping will actually just land in 4.2 before long 🙂

There’s a few other things I need to play with some more. I’ve not tried external HDMI video/audio, the external display port, the DP to VGA converter (nice one was included in the box though) or the headphone/mic socket. None of the functionality of the dock has been tested yet simply because it’s yet to show up! It reports around 7.5 hours of battery life but I want to look at what the state of power consumption on these devices after mjg59’s post about it to see if I can’t get that well into the double digit hours.

Overall I’m pretty impressed with out of box experience of F-23/rawhide on the Thinkpad X1 Carbon gen 3 🙂

Fedora 22 on ARM and aarch64

So with Fedora 22 well and truly out for both ARMv7 and aarch64 lets have a look at the release in general and also at the 4.0 kernel it ships.

Firstly I’d like to shout out to the AMAZING job done by the web team on the new sites for Spins, ARM and Labs. They really do look awesome!

It’s all to easy to get bogged down in the actual technical components that make up the actual release and not forget that there’s work that goes on all over the place that contributes to making the release easy to use even before you begin the download.

Anyway! On to ARMv7. We shipped GA with the 4.0.4 kernel and u-boot 2015.01. This combination gives us improved support for numerous devices primarily through new DT support and improvements to drivers. The 4.0 kernel from an ARM HW support PoV really was a minor revision. With the fully packaged and updated fedora-arm-installer it’s even easier to get a device up and running.

We were hoping to get enough time to rebase this to 2015.04 but we just plain ran out of time, although we do have a plan to be able to update the u-boot when writing an image to card/stick without the need to regenerate the images. More details on the improvements we’re planning for fedora-arm-installer for another post!

From an aarch64 point of view the big change, although one an average user won’t notice, was we went from carrying a rather large (around 65K lines) enablement patch for the kernel to a small collection of 4 bug/problem specific patches! This is a massive change where in the F-21 cycle we had a gigantic architecture enablement patch! This makes it much more straight forward and less stressful for both myself as the architecture maintainer and the core Fedora kernel developers. In terms of the rest of aarch64 we still support VExpress, APM Storm platform primarily with the Mustang boards, and the AMD Seattle platform.

Overall the Fedora 22 release on the ARM platforms is a really nice release, there’s been some good changes there to enable easier and quicker updates in the future and easier means of adding decent support to new devices mid cycle. AArch64 is maturing and hopefully we’ll start to see some more platforms land and the architecture start to depart the niche status!