A number of people complain about our hardware support on ARM. I’m not sure people really understand the issues we have bringing the hardware that we try to support to ARM and the constraints we work in. I’m going to try and outline the process we’ve been through over the last couple of releases and the reasons why we stick to the Fedora processes as much as possible. The other thing that I think people quickly forget is that the hardware support is a very small percentage of the overall work that has gone into bringing ARMv7 up to the excellent state it is in. Unfortunately like so many other projects the last 10% is always the hardest.
Support for hardware primarily revolves around three core components. They are the boot-loader (bios in x86 parlance), the kernel and any user space components needed which generally focuses on X drivers, but is no way the only thing.
Going back to the near memory Fedora 18 shipped with the 3.6.10 kernel. The 3.6 kernel didn’t ship with what’s known as the “Unified Multi Platform ARM kernel” which now allows us to ship a single kernel to boot multiple different SOCs (System on a Chip) by numerous manufacturers. The initial multi platform kernel support landed in 3.7 and initially allowed us to merge the Versatile Express and Calxeda Highbank kernels together. It was only with the 3.10 kernel we actually started to ship a single unified kernel that supported all the SoCs we support. We currently enable around a dozen different SoCs in the mainline kernel and actually support HW running on around half of those.
Supporting the multi platform kernel hasn’t been an easy ride. As you would expect of Fedora we were the first to adopt it and a lot of other distros still haven’t. Debian is in the process of moving over to it for Jessie, I thought Open SuSE was using it but it appears they’re not and Ubuntu certainly isn’t. I’m not sure about Arch or any of the others. It’s been an interesting ride and while a single kernel is something we’ve wanted for some time the lack of testing by a wider audience has certainly made it more painful for us than it could of been, it would be particularly helpful if Linaro, the main developers, actually used multi platform kernels for all their builds.
An example of problems we’ve had with the multi platform kernel is the support for the OMAP4 based PandaBoard, since before Fedora 17 it’s been consistently our best supported device but with the 3.11 kernel and the move of OMAP4 devices to DeviceTree it doesn’t boot and there’s been a number of us try to get to the bottom of the problem to no avail. Similarly going back to 3.6/3.7 the i.MX series of SOCs caused us massive problems to the point we just stopped supporting them but with the i.MX6 it’s very quickly becoming out best supported class of devices with a collection of almost a dozen very nice and relatively cheap devices (starting at USD$45) like the WandBoard dev boards, Compulabs Utilite and Cubox-i. Due to the high level of churn in the upstream kernel it at times makes it really hard and we can, and do, spend a lot of time chasing down issues with a single SoC or even device.
So what hardware actually works in Fedora 20? In theory we support 100s of devices but in practice the testing in limited to a selection of devices that we actually have to be able to easily test. So what actually works:
- Versatile Express via QEMU emulation using libvirt.
- Calxeda Highbank and Midway servers
- Compulabs Trimslice (tegra).
- The three WandBoards (i.MX6) in particular the Quad. 3.12 will improve the support too.
- The BeagleBones (am33xx). In 3.11 there’s issues with usb, 3.12 is looking better.
- BeagleBoard xM (omap3). For network you need to use the usb OTG port.
- Mirabox and other Marvell (mvebu) devices with appended DTB (due to old uboot shipped with device).
Added to the above we ship around 100 device tree files, in 3.13 that rises to over a 120. I’ve had reports of a number of people successfully using some of these devices without issues. So what doesn’t work so well out of the box?:
- PandaBoards (omap4). As mentioned above these broke with 3.11, I’m hoping to get them working again soon but my testing to date hasn’t been fruitful though.
- Compulabs Utilite (i.MX6), well not with the 3.11 shipping kernel, we have initial support in 3.12 but there’s also issues with their initial uboot release.
- AllWinner devices, but there’ll be a high quality remix that supports a lot of these devices, we’re hoping to improve the mainline support a lot in the F-21 development cycle.
- Any device that doesn’t support multi platform kernels
- Any device which isn’t supported in the upstream kernel
I’ve had reports of a number of other devices that “just work” or mostly work and with time this will improve. One thing that we’ve tried very hard not to do is pull 100s of patches in. Fedora likes to be as close to upstream as possible with their kernels and having lots of patches or kernel variants just doesn’t work as we just don’t have the resources to deal with them. We do on occasion pull in patches to fix or improve things but we try to keep as close to mainline as possible so if you want a device supported the first thing you’ll be asked is “What’s it’s supported state on the upstream kernel?”.
So what’s on the ToDo list? In short.. LOTS! With 3.14 we should finally get usable AllWinner devices, 3.13 in theory should have a number of RockChip devices supported and both of those SoCs bring a huge amount of cheap devices along that we have the potential to support. As it makes sense to enable new support we will. I’m also planning on improving and testing the support we currently have. I like the BeagleBone expansion capes so I plan on testing and playing with those and in general improving the support of devices that I have (a post on those coming soon).
All in all while we’ve got a long way to go I believe our hardware support has improved fairly well over the last couple of years where in Fedora 17 we officially supported two devices.