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!
As we slowly meander our way towards the pointy end of the Fedora 21 release, with Alpha speeding up in the rear view mirror, the Fedora ARM team are starting to discuss the best way to deal with the blossoming amount of ARMv7 devices that can and do run out of the box on Fedora.
With our 3.16 kernel containing device tree blobs for 200+ devices, the Fedora 3.17 rawhide kernel already containing 230+, it’s truly impossible to actively test and support all of those devices. So much like previous releases we’ll be focusing on testing a group of “primary devices” with the remainder being considered as secondary. This doesn’t mean they won’t work, it just means they’re not necessarily a testing focus of the regular contributors or they might not be readily available to purchase.
So what makes a device primary? Well there’s a number of considerations we’ve put into the list. Firstly the device has to be widely available and well supported upstream. Some will notice that some of the devices are no longer widely available (yes Panda, Trimslice and Calxeda I’m looking at you!) and I did consider their removal from the list but given a lot of contributors have them I think it’s worthwhile keeping them around for the moment. The primary devices list won’t be release blocking, we don’t block x86 releases for specific single devices, so I don’t believe we should for ARMv7 either.
Astute readers will notice the proposed primary list of around two dozen devices is much larger than the core devices we supported in Fedora 20! YAY! is all I have to say about that
The list is not final, at the moment it’s a suggested list and one open for discussion to some degree and what we’ll be heading from Alpha to Beta with. I fully expect it to be tweaked as we go along, there might be cool new shiny Chromebooks that arrive on the scene and end up working nicely and are hence worth actively supporting (no EXYNOS Chromebooks I’m not looking at you!) and some devices on the list below that end up not making the grade. One thing is for sure the grade includes that they support Cute Embedded Nonsense Hacks ie DeviceTree… there’s no board support here.
- Wandboard (all models/revisions)
- Utilite (all models)
- Cubox-i (all models)
- Hummingboard (all models)
- BeagleBone Black
- Tegra K1 Jetson
- CubieBoard (all models)
- Banana Pi
- PandaBoard (all models)
- Calxeda Highbank/Midway
- VExpress (qemu)
- BeagleBone White
- Beagle xM
- Qualcomm (IFC6410, DragonBoard)
- Various Marvell devices (Mirabox, AX3, CuBox)
- Various Exynos devices
- Other AllWinner devices (as per available u-boot/DT support)
- Gumstix Overo series of devices
- OMAP5 EVM
- STE SnowBall
- AMD Seattle
- APM Mustang
- VExpress (qemu)
So what can a user expect from the primary devices above? Will all the functionality of a device work? Well it depends on the specific device and the associated SoC. For example the AllWinner SoC GPU support is far from upstream so unfortunately there will be no graphical UX for those devices, the Tegra K1 support for the GPU isn’t quite there yet but we’re hoping by GA it will be. Some will be better than others in terms of certain features but for example the AllWinner devices would make good storage devices with their SoC attached SATA and Network, no ugly usb storage/network here, so they are useful to support as a primary device and can easily have feature enablement in the F-21 cycle with a “yum upgrade” to a newer kernel.
We’ll delve deeper into the specifics of each device and the final list closer to beta.
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.
There’s been quite a bit of water under the bridge since my post on the 3.14 kernel status. With 3.15.x due to land in Fedora 20 shortly I thought I’d give an overview of changes for 3.15 and what’s happened since the last post.
From a shiny new devices and features point of view the 3.15 kernel is relatively boring on the ARM devices front, the advantage of that was that from a development point of view things tended to just work on Fedora. Running a diff between out 3.14 and 3.15 ARM kernel configs and checking our shipped Device Tree Blobs I get the following main changes:
- Enabling of Marvell Dove platform. This primarily will be useful for people with the Original Cubox
- SunXi MMC suuport. The enables initial basic support (Serial/MMC/network) for a number of AllWinner platforms
- Zynq 7xxx platform improvements
- OMAP DRM driver conversion to Device Tree (more on that below)
- Initial Utilite support. It’s pretty basic with support for serial, MMC/SATA, and one of the two NICS. I plan on improving this soon
- Added Device Tree support for a number of OMAP Overo devices
- Added Device Tree support for a number of i.MX6 based devices
So while it was boring form a new device support point of view a kernel cycle for ARM is never really that boring! There was a lot of nice improvements generally under the hood and the march toward Device Tree is basically complete. I’m not aware of any device now that is supported not through DT in Fedora.
I mentioned above OMAP DRM. In the 3.14 post I mentioned I was sure we’d get Panda working soon. And we did! The main issue remaining was actually display support with 3.14 and with 3.15 that problem is now mostly closed because all the connectors and their associated drivers now support DT which meeans all the modules now load in the right order and things mostly just work. There’s some further improvments here in Xorg userspace in rawhide so I’d sugggest trying a nightly or the not far off Fedora 21 Alpha.
I’ve also had a few cycles to test Marvell mvebu support on my Mirabox and fixed a few kernel issues here so it now works. Unfortunately Marvell’s support of uboot, and hence Device Tree, is from the last decade and hence fairly horrible! I’ll save details of that for another post.
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.
Single Sign On (SSO) is one of those nirvana things that rarely happens and a lot of people don’t understand (a central single username/password is not SSO people if you have to keep entering the password!!) but it’s very useful when it does work. With Firefox on Fedora or RHEL it works but it does take a little bit of config to do so efficiently.
- In the Firefox address bar type about:config to display the list of current configuration options.
- Filter the options with ‘negotiate’ to reduce the list of options.
- Double-click the network.negotiate-auth.trusted-uris entry and add the kerberos auth domain, eg: “.example.com” and click OK.
- Repeat the process for the network.negotiate-auth.delegation-uris entry, using the same domain.
Now you need to ensure you have a kerberos ticket. If you’ve configured an “Enterprise Login” using the GNOME Online Accounts check you have a ticket with the ‘klist’ command from a terminal window. If you don’t have a valid ticket run ‘kinit’ and from there you should be able to visit SSO enable sites and be auto logged in. Magic!
With 3.14.1 out Josh and Justin are preparing to land the 3.14 kernel into Fedora 20. So what does it mean in terms of ARM on Fedora. Well it’s an evolution. There’s of course the usual raft of new devices and some new SoCs, and best of all lots of improvements in support for existing devices. Even the return of some old favourites! Generally from the stash of devices Paul, I and others have that get regularly tested things are looking pretty good with 3.14.
New SoCs and device support:
- Tegra 4/K1 support has been enabled. For 3.14 this doesn’t mean much as there’s not a wide level of devices out there that we ship device tree blobs for but it’s a good preparation for 3.15 as we should have pretty reasonable support for the nice new Tegra K1 dev board!
- TI devices: The 3.14 finally brings working support for the OMAP5 EVM board, this will improve further in 3.15 but it boots and generally works. It also adds support for the original BeagleBone and the USB is now finally all back for the Beagle-XM devices so they go back into the fully working list! Also the DT bits for the Overo devices has started to land so if is interested in those I’d love feedback from people with those devices.
- Freescale i.MX: To this lovely growing list we add initial support for the various Cubox-i devices and the hummingboard. Still no HDMI support but here’s hoping for 3.15
- Xilinx Zynq 7000: The SD controller has finally landed for this which means they should be bootable to login but from there I’m not sure the status of the rest of the support. We ship DT for the zynq-zc702, zynq-zc706 and zynq-zed devices so if you’ve got one of those and have time to test feedback would be welcome.
Interesting bugs fixed:
Nothing particularly exciting comes to mind here. The fix for the Beagle-XM usb hub power up is nice, as was the final config option for the BeagleBone White. There’s obviously a deluge of other ARM driver fixes and improvements (PTP high precision time support for modular CPSW ethernet on the BeagleBone’s anyone?).
Outstanding bugs and issues:
So this is really the list of items I have outstanding for 3.14 so that I can spin some new images. Feedback on any of these and anything I might not be aware of would be very useful.
- OMAP DRM display. In 3.11 a new display framework landed for the OMAP DRM driver and in 3.12 the old one was dropped. This broke X on devices like the Pandaboard for 3.12+ kernels. I know roughly the problematic area but I just need to get the cycles to debug this. Any help is welcome.
- Serial over USB. While this isn’t a kernel bug but rather just needs me to hack together some scripts it’s a blocker for easy OOTB support for devices like the BeagleBone Black
- Tegra DRM display. After a re-write it’s back and modular again in 3.14. Just need to ensure it’s working and ready to go
- Testing… testing… testing
That’s mostly all I have on my list. If there’s anything I’m not aware of please do let me know and I’ll endevour to help out where possible. In particular I’m very interested in boot issues for devices that would would be supportable with new ARM images based on 3.14. From the 3.11 kernel that F-20 GA shipped with there’s been a lot of change and improvements, and while non boot enhancements are easy to do with a “yum update” issues with boot aren’t quite so easy to deal with!
I thought I’d start doing semi irregular ARM kernel status reports. I’ll do them as often as I think they might be useful and those who know me know I travel a lot and randomly and that ARM isn’t my $dayjob.
Few are bored or stupid enough to follow the 20 or so ARM kernel trees or have the regular insight as to what’s happening, what’s landed, what new devices might work and what bugs come and go that I do so I thought I’d try and dispense some of the more interesting bits of that information and how it relates to Fedora ARM to a wider audience by both the fedora-arm mailing list and my blog so those people that don’t sit on the IRC channel and those that like to lurk might have a better idea what’s going on.
The general format I plan to use is basically:
- What’s new including SoCs, boards and new devices
- Interesting bugs fixed
- Outstanding bugs and issues
- Random other insights
I don’t intend them to be long but rather short, sweet and to the point. They’ll probably come out when new major releases hit either rawhide or stable or something of particular interest lands. Feedback on both the format most other things is welcome as are questions and status of devices people might have had success or less so with.
I plan to have the first for 3.14 out later today and one for 3.15 RSN.