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!
I’ve been a bit lazy on the ARM kernel status updates. There wasn’t one at all for 3.18 but the fact was, that while there was lots of under the hood improvements for ARM/aarch64, the new device support or improvements from a user’s point of view was positively boring so I never bothered!
That said the 3.19 kernel is now on it’s way to the stable Fedora releases and there’s some bit of interest there 🙂
Beginning with aarch64 there’s been a raft of code support landing upstream for the core platforms we support (VExpress, APM Storm, and AMD Seattle) which means the enablement patch set has shrunk massively. The core missing bit from this is primarily the ACPI patches for the server standards. There’s also been a lot of stability improvements for various device drivers particularly on the APM Storm SoC (which massively helps the high network and IO traffic we generate when doing composes in release engineering!). Other improvements include support for seccomp. The upstream support for aarch64 is really starting to settle down nicely which is good because there’s devices finally starting to get to the point where they’ll be more widely available and affordable 🙂
On to ARMv7 changes. In terms of new supported SoCs the support for AllWinner A-23 (aka sun8i) is the most interesting in terms of new devices. There was also a lot of general SoC improvements and cleanups. The largest here is probably Rockchips, QCom and ZYNQ with notable mentions to Tegra, OMAP and i.MX6 too. In terms of new devices we now solely support DeviceTree devices and the built .dtb files we ship that are possible to support with the kernel jumped from 250 to 265 devices. Of course it doesn’t mean we’re testing all of those devices but we’re testing devices across all main SoC groups to ensure at least the core support works. Of course feedback for what works and doesn’t is always welcome. In this cycle there was also significant driver work with special mention to Hans and his significant movement on the Allwinner devices.
I’ll do a longer post for 4.0 and the new u-boot we’ll be supporting in Fedora 22 soon.
A question that I’ve had a few times in the last couple of weeks is whether Fedora supports Cute Embedded Nonsense Hacks, also known as u-boot and device tree, on aarch64 (ARM64) platforms?
The answer is YES!, of course, why wouldn’t we?
I know people are well aware of Red Hat’s involvement in the Server Base System Architecture (SBSA) which mandates the use of UEFI 2.4 and ACPI 5.1 bindings and that the Red Hat Partner Early Access Program uses that standard to enable easy booting and support of server platforms running on aarch64 platforms but the fact is that is not Fedora.
Fedora plans to support the SBSA to enable easy use of Fedora on aarch64 server platforms. But we also plan to support the current standard u-boot with device tree boot options. The fact of the matter is that a lot of non server based aarch64 platforms will continue to use these options and so we’ll continue to actively support them. Just like Fedora support Xen when the Fedora derived enterprise product does not. Basically it’s not hard for us to continue these options and with the improved generic distro support in u-boot, which we’ve actively participated in and driven, testing of Cute Embedded Nonsense Hacks on aarch64 should be easy and straight forward.
Of course the support of both SBSA based uEFI/ACPI or u-boot/DTB isn’t perfect on aarch64 yet so if you’ve got access to aarch64 systems on either platforms I would love testing and bug reports. If you’re a vendor that plans on using u-boot/DTB on aarch64 I would ask to ensure that you support the generic distro options because it’ll enable out of the box booting of at least Fedora, Debian and openSUSE to seamlessly just work on your devices.
With 3.17 due momentarily and Fedora 21 been delayed a little we’ll now be bumping the kernel that ships in F-21 GA. So lets have an overview of what improvements and changes are going to be there for ARM.
Overall 3.17 has been relatively boring in terms of shiny new hardware support for ARMv7. We’ve added support for a bunch of new devices through the addition of appropriate device tree bits. Some of the highlights there include a number of AllWinner devices such as the Banana Pi, a number of new FreeScale i.MX6 devices, some of RockChips devices, and the ZYNQ Parallella.
On the aarch64 side there’s been general improvements all over the place. Over all we don’t have any new platforms but there’s improvements to the three we do support (VExprees, APM X-Gene, AMD Seattle) but the VExpress Juno device should work and initial support for the ACPI 5.1 standard and improved uEFI both of which are part of ARM SBSA Server standard.
Along side 3.17, or at least very shortly there after, u-boot 2014.10 or at least a release candidate should land in F-21 as well. This release adds support for a lot of new devices, primarily AllWinner A-10/13/20 categories, as well as the Tegra Jetson K1, a few i.MX6 devices such as the RIoT Board and the newly upstream distro standards for booting. This makes it much easier for us to “just boot” Fedora ARM with a lot more devices making the experience of getting started a lot easier for most people with supported devices.
The combination of u-boot 2014.10 and the 3.17 kernel will be what we head towards Fedora 21 GA with and things are starting to come together nicely.
So having almost recovered from the lack of sleep that is one of the guarantees of conferences in general, but definitely a Fedora one, I thought I would reflect on a few bits. I’m not going to cover all the talks as a lot of people have done that and all the talks are on the Flock 2014 YouTube channel for your viewing pleasure.
As others have mentioned the venue was great, easy to get to and from for transport and the hotel. Huge kudos to the organisers of the event! An event such as this takes a lot of time and energy, and with the dust barely settled the Flock 2015 Bid process is already under way so if you’re interested in hosting 2015 in North America…
My State of ARM and aarch64 in Fedora went well, I enjoyed it and the room was packed with as many people standing as there were sitting 🙂 There was lots of good questions and interest, both in the talk, and in the hallway in general.
I went to numerous excellent talks, too many to count or remember and I’m looking forward to catching up on a number of talks I missed due to schedule conflicts, via the videos, when I get some spare time. Of course the other major part of the conference is the hall way track. There I had too many conversations to recall and caught up with numerous old friends, met a number of people I’d been dealing with online and had never met in person, and of course met a whole bunch of new friends too! It’s amazing how much can be achieved when talking to someone on the walk between conference rooms!
One of the other major things I enjoyed about Flock this year was the overall positivity of everything about the conference, whether it be people’s general attitude, the presentation titles and the presentations themselves or people in the Litre Pub 😉 . And of course being one of our values I have to mention that catching up with so many good friends is always the sugar on top of the cake!
So I’m at Flock in Prague. So far I’ve been to a bunch of interesting talks about Release Engineering, Secondary Architectures, Fedora Workstation, Docker and Infrastructure.
Of course then there’s the hallway track of which I always actively participate and it’s been always fabulous to meet a bunch of people in real life that I’ve been dealing with online on a regular basis, in some cases for years!
I’ll be around for the entire conference and if you’re interested in chatting about secondary architectures (not just ARM), Sugar, Cloud or just about anything else or just to say hi please come and find me!
With the Fedora 21 Alpha freeze looming in the rear view mirror, although the object wasn’t as close as it would appear, I thought it was high time that I gave a brief overview of the state of ARM aarch64 in Fedora. Some might assume the silence means not a lot has been happening but this is extremely far from the truth!
So lets start with a few statistics:
- Builds the same with mainline: 14973 odd (yes, that’s nearly 15,000 Fedora source packages built on aarch64!)
- Older builds: 217 (we have a built but it’s not the same NVR as mainline)
- Missing builds: 352
So that’s looking pretty damn good! The main components that we’re missing that make up the missing builds comprise of two main groups.
The first is builds that are FTBFS on mainline and that’s basically, if it can’t be build on F-21 on mainline we have no chance of rebuilding the f21 tag.
The second reason is platforms that aren’t yet supported on the aarch64 architecture. The core group of these come down to mono (and anything that depends on mono), golang, v8 (mongodb/nodejs etc), pypy make up the majority of that list. We’re working with upstreams to hopefully fill those gaps before long.
There’s a few other minor stragglers that don’t really fit into either of the above. erlang just needs to be bootstrapped plus a few others like
thunderbird, libreoffice and hadoop that need some attention which we’ll get to soon.
So the aarch64 userspace, while still not 100% there, is looking EXTREMELY good and there’s a number of people that are now putting it through it’s paces on a daily basis which in turn allows us to improve it as we go.
As I indicated in my 3.16 kernel status we now have support for a number of hardware options to run the userspace. Some of them are emulated (qemu, ARM foundation model) and some actual physical (APM Mustang, AMD Seattle) if you’re lucky enough to have access. The support for these devices is improving all the time and support for kernel features are coming along pretty thick and fast.
So in summary the Fedora aarch64 is in very good shape for the Fedora 21 Alpha and will only improve as we apply polish along side x86 and ARMv7 in the lead up to Fedora 21 GA.
So 3.16 is has quite a few new features in terms of newly supported devices, also some what surprisingly this blog post will be out before 3.16! In terms of new device support all the SoCs listed here are exciting for a number of reasons for Fedora ARM. Aarch64 (ARM64) makes it’s first debut with support of real hardware although we’ve actually had kernel support enable for it for some time in Fedora even if only usable on the glacial Foundation emulator.
The 3.16 release is also very likely to be the kernel that ships with Fedora 21 GA and with the Alpha due in about a month we’re starting to polish and test all the platforms and devices we want to support for GA.
Anyway without any further a do let’s get into the gritty details:
- NVIDIA Jetson TK1 support: While we’ve had the basics of this for a while all of the bits are there now.
- EXYNOS support: This SoC is probably the most asked about platform and finally after a long wait the multiplatform support has landed upstream. We currently ship around 20 dtb files for exynos4 and 5 (Chromebook support anyone?). Testing is sought and feedback and greatly appreciated.
- Qualcomm MSM 8×60, 8960 and 8974 support: While the multiplatform support for these devices landed upstream a few releases a go they’re now to the point they should be relatively usable so it’s time to get wider testing. This should be the beginning of supporting the venerable ifc6410 and dragonboard devices.
- APM X-GENE support: One of our first aarch64 supported pieces of hardware. Similar to the QCom SoC the initial support has been upstream for a while but with 3.16 it becomes usable with the vast majority of basic support upstream so minimal patches are needed. More on aarch64 soon.
- AMD Seattle support: The other of our aarch64 supported pieces of hardware if you’re lucky enough to get your mits on a device.
The other feature we’re starting to see mature is GPU and Graphics support. I’m not exactly sure yet as to what the final state of this functionality will be for Fedora 21 GA but we potentially will have suppport for:
- nouveau/mesa support on the NVIDIA Tegra K1
- freedreno/mesa support on the Qualcomm boards
- etnaviv/mesa support on i.MX6 devices
- improved modesetting support for a number of other devices. Some of this has already landed and is usable in rawhide now.
What covered above is just a high level overview of what’s new in the upcoming release. There’s been numerous other improvements in existing supported SoCs and devices all over the place that would take too long to cover off here but in short with all the shiny that’s landed in 3.16 what Fedora ARM will look like as part of the Fedora 21 GA release is quickly starting to take shape.
I realise that there’s not been an update as to the state of ARM aarch64 on Fedora for sometime. We should really shout out our achievements a lot more as over the last few months or so there’s been fairly extreme progress made but we all just tend to apply the nose to the grindstone and get one with it!
So where are we? Well we’ve got the vast majoriity of Fedora built. As we’re only building for rawhide/F-21 there’s a number of missing F-21 builds but with the mass rebuild well and truly underway on mainline we’re all hyped up and building on aarch64 too (appart from a power outage in the Huntsville facility that hosts some of the builders!) and we’re hot on the tail of mainline builds.
So we have HW virtualisation support and a bunch of virt bits on top of that, the vast majority of other services and low level support like storage platforms, all the various desktops and most of the various development stacks (even Ada!). It’s actually looking pretty good. In recent time we’ve added R, ghc and a raft of different language support. The java team have done a really good job getting java-1.8.0-openjdk up to spec too!
So appart for the mainline builds that haven’t yet been built for F-21 what are we missing? Well not much really now. Go and nodejs, the later due to missing v8 js engine support (it’s upstream in a newer v8 release but Fedora is stil trailing), and the things that depend on them are the main ones now missing so no Docker as yet either. There’s no mono, and while the core erlang is built I need to work out the correct order to finishing the bootstrap.
The rest of the job now becomes somewhat boring in that once the mass rebuild is complete we just need to go through packages and fix individual packages that are FTBFS and I strongly suspect most of those will have issues on mainline too.
On the hardware and virtualisation front the current rawhide kernel should boot just fine on the ARM foundation model emulator and the next release of qemu will have full system emulation of aarch64 to enable the running of aarch64 on x86_64 similar to what we can do with ARMv7 now. The 3.16 kernel should allow us to run on the currently and soon to be available HW without too many problems either as the last core bits of support should land upstream in the current merge window.
In short aarch64 on Fedora is looking awesome! By the time Fedora 21 Alpha lands in two months time we’ll basically be feature complete, and even now it’s extremely usable for those lucky enough to have hardware or patient enough to use software emulators.