It’s been a while since I’ve done a general update on Fedora 18 on ARM. Post release always tends to be a good have a look at what’s been achieved, where we are and what we have planned for the next release. At the beginning of last year I was trying to blog weekly on my Fedora involvement, or at least tech involvement that’s related to Linux, I need to get back into that habit, if for no other reason than to stop people bothering me ;-). As a result this is a bit of a mammoth post at around 1500 words!
Overall Fedora 18 was a reasonably standard release process for ARM. We had the usual package build issues with lots people scrambling to help us get things fixed even if some took longer than hoped, kernel issues also featured but that’s not unusual as there’s been a lot of upstream ARM churn! The extended release process wasn’t as bad for ARM as it was for some of the other teams as it allowed us to fix up some more bits and get them landed in the release. So what were the major achievements of this cycle?
- Supported Devices: The number of devices we support has actually gone down due to the Efika devices not being updated to run on the newer kernels and then being completely dropped for the 3.7 cycle due to lack of DeviceTree support. That being said the number of devices that work with only little intervention is on the way up and this should increase dramatically over the Fedora 18 life cycle due to the unified kernel. People are also starting to play with remixes for devices and I have some ideas to support this better (see kernel section).
- Packaging: The number of packages that didn’t build out of the total of 12,614 packages in the final F-18 GOLD release was a rather small 280 at mainline release. This has actually gone down since as we’ve had a couple of packages that were blocking a lot more land in the post F-18 updates flurry and more are on the cusp of landing too. I’m working through the remaining packages to document the remaining hold outs and classify them as 1) non ARM arch 2) simple fixes required 3) complex fixes required 4) language bootstrap required 5) unknown or 6) dependent on another package from 1-5.
We’re also working on improving and optimising packages for ARM. Over this release cycle I’ve pushed a number of fixes to improve performance and operation of packages. I expect this to continue for a number of cycles to come as well as enabling more HW device support like UCM support for sound devices in F-19.
- Kernels: I’ve spent an inordinate amount of time this release doing kernel work. I would never consider myself a kernel hacker but clearly I’m able to fool people as I was asked by a kernel developer if my employment by Red Hat was to become the ARM kernel maintainer, while chuffed at the complement I’m really not a kernel hacker!
So what have we achieved in the kernel this cycle? Well we’ve landed the first iteration of the 3.7 “unified” ARM kernel which allows us to boot a single kernel on multiple devices. We have two devices currently supported in 3.7 with the qemu based Versatile Express emulation and Calxeda Highbank being the first candidates that have been tested to work, we have the Marvell mvebu support enabled in 3.7 too but there’s not enough driver support for it to work on real devices. The 3.8 kernel expands this out by adding IMX (yet to be enabled), SunXI (also known as AllWinner A1x) and some other devices. The A1x support is similar to the mvebu in 3.7 in that it’s just core SoC support so not really useful as yet. The unified kernel has allowed us to collapse a number of our kernels into one which has reduced our build times dramatically (one of the bullet points needed for primary arch) but it’s not all completely rosy. The unified kernel is still problematic and I don’t believe this is helped by its current lack of use. This is especially disappointing when Linaro don’t even build unified kernels for testing. It appears Fedora is leading here and I get to feel the pain 🙁
Moving forward I’m starting to hack about on a new kernel idea to enable easier support and “Remixes” for non mainline ARM devices. Basically I want to do a remote clone of the Fedora kernel tree and setup a branch for each device we wish to support. From there I plan on pulling in the patches/trees needed to support the device. It’s not going to be pretty as some still use the 3.4 kernel etc but the planned outcome is an automated yum repo with a series of kernels enabling people to build their own install images for a much larger range of devices, a long with a central repo so that when/if the support goes mainline it’s easier for us to merge the changes in. Once this is working I hope for people to be able to submit new platforms via git pull requests. I’ll blog about this more as I get more bits working. I need to upshift my git skills and I suspect this will be an interesting challenge!
- FUDCon and FOSDEM: Unfortunately due to personal commitments I was unable to attend FUDCon NA this year. I was some what amazed at the number of people that contacted me to ask why I wasn’t there and if everything was OK or just to express their disappointment at not catching up with me. Believe me it was unavoidable and I wasn’t just trying to avoid you all! From everything I’ve heard it was a great event with lots achieved both around the ARM and non ARM stuff but others have reported on this so I won’t bore you!
On the plus side I did make it to FOSDEM this year! And what an excellent event it was! It’s an event I’ve been wanting to attend for 5 years or so. I was even recorded in a podcast by the excellent EMEA Cloud Guy talking about ARM, OLPC, all sorts of cloud computing tech as well as other things that I do in my day job. So if you really did miss my voice at FUDCon or are just having problems sleeping you can have a 30 minute odd fix there 😉
There was a lot of things covered on the ARM side from ARM64 (or aarch64) through to the varying state of GPU support. I plan to write up more about this in other posts but it’s certainly going to be an exciting year for ARM development! You can mark my words 😀
- Awareness: I’m constantly surprised about the people that get in contact with me about Fedora ARM support. It’s amazing and exciting the places people are looking to use and actually are starting to use it, it’s nice to know that the thousands of hours I and others are putting into Fedora on ARM aren’t going to waste. The awareness of the project both inside the Fedora community and in the wider Fedora ecosystem is expanding rapidly and that can only be a good thing! For example OLPC announced the XO-4 Touch at CES and it’s running Fedora 18 on ARM to boot.
- Build platform: We’ve finally got enterprise hardware on it’s way. I was kind of hoping we would have made the switch a month a go but any moment now we’ll be moving the koji instance used for ARM builds over to a unified set of enterprise builders based on the Calxeda EnergyCore platform. This is in preparation for a push to promote ARMv7 to primary architecture. I must say, primary or otherwise, I’m really looking forward to having a unified set of builders running on enterprise storage and networking. While the existing platform has served us well it’s really starting to bulge around the edges while building for the three Fedora releases on two architectures. Look for the announcement Real Soon Now or just listen out to me celebrating!
- Dropping armv5tel: We’ve decided to drop ARMv5tel support as of Fedora 19. Both Fedora 17 and 18 will continue to be supported for the entire mainline life cycle. The fact is that ARM themselves, with the introduction of the Cortex-A5, have stated that all cost points and use cases are now covered by the ARMv7 Cortex-A* series of designs and as the memory supported by the v5 series of chips is only DDR1 the devices were getting expensive to make. While there are a number of plug devices out there still the fact is there’s probably less devices there as there were PPC devices when it was decided to drop PPC so I don’t see it as a major issue. The Raspberry Pi is going to be supported by Seneca in a separate ARMv6 secondary arch effort so isn’t going to be left out.
- Anniversary and statistics: Stats are always fun and I noticed the other day that it was in fact my two year anniversary of working on Fedora ARM builds, although like a typical male in a relationship I did forget it! In my defence I have also forgotten my own birthday in the past too 😐
I pushed my first build on January 9th, 2011 and since then I’ve done a mere 82,876 builds via a lot of tasks (koji times out on that query!). I’ve also submitted well over 300 updates for F-17 and at a little over 125 not quite as many for F-18 putting me on the top of the updates list (sorry!) for both releases. They weren’t all for ARM though but I’m very glad F-18 is, currently, a lot less than F-17 which means that we’ve made progress on fixing ARM issues 🙂
Look for some more specific, less wordy, ARM related posts soon.