Tag: ARM

ARM hardware support on Fedora 20

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.

Nose back to the grindstone

Some may have noticed that I’ve not been around as much as usual in the last month, I’ve been on 4 weeks (originally meant to be 3) of holidays visiting my family back in Australia. It’d been 2.5 years since I’d last been home and well over a year since I’d had any form of break at all so I decided to disconnect myself as much as possible. I vaguely kept up to date on email replying to the urgent stuff and just deleting most stuff leaving the bits in between to deal with when I got back. So I’m now going through the large stack of outstanding stuff but if you’ve been expecting a response from me now you know why you’ve not had one and if you don’t get a response by the end of the week I suggest you poke me via IRC/Email again to follow me up. I have Fedora 20, Fedora ARM, Fedora in general and $dayjob on my list…. not necessarily in that order! I’m endeavouring to prioritise… we’ll see how that goes!

For those that don’t believe I can disconnect here’s a couple of photos for your viewing pleasure (click for full size) up on the family farm.

The farm at sunrise
The farm at sunrise
Me on a horse! Off to do sheep work
Me on a horse! Off to do sheep work

Fedora Flock Presentations

For Flock I did three presentations. Two of them didn’t have slides and I’m not sure if they were recorded but the “Fedora ARM – State of the Union” was pretty well covered. My slides are here and you can watch the whole talk on YouTube here and a transcript here.

I’ll do further write ups of my various Flock activities over the coming days.

the newish Fedora ARM koji build platform

I’ve been meaning to do a post on the Fedora ARM koji build platform. I’ve been sort of busy with my day job including a load of travel as well as concentrating on Fedora ARM builds and kernel issues.

Up until the end of January for well over two years the arm.koji.fedoraproject.org platform that we all love had been hosted at The Seneca Centre for Development of Open Technology. In that time the platform was tirelessly run by Chris Tyler and his team. Over the years it has had a number of upgrades. It originally started off as a bunch of Guru plugs with a few higher end boards, over time we added in Panda Boards and then remote access to more enterprise level devices. With the increasing number of releases across two architectures it’s been clear for some time that the platform was reaching end of its usable state and building for three releases (F-17 to F-19) it was clear it was no longer up to the job.

So at the end of January the migration over to a new platform went live. The new platform builders are based on the latest revision of the Calxeda Energy Cards in the form of Boston Viridis server chassis. We have 96 of the Calxeda EnergyCore nodes spread across 4 chassis that are plugged into the usual enterprise class storage and networking. The ECX-1000 units are quad core 1.4ghz with 4Gb of RAM, local SATA storage and Gig ethernet networking which is a slight improvement over the old devices 🙂

The improvement in stability and builds has been fabulous and it’s not until you get a shiny new platform with all sorts of enterprisey features that you realise things like loopback filesystems over NFS over 100Mb ethernet over USB on pandaboards with dual core 1Ghz processors and 1Gb of RAM aren’t the best platform in the world! Nicely a number of random build issues unsurprisingly just disappeared and it’s allowed me to focus on fixing packages and other more useful things rather than a group of us coaxing builds along and generally spending too much time dealing with issues we shouldn’t have. The mass rebuild ran nicely on the new HW and it banged it’s way through it quite happily with me battling to keep it full of builds and having trouble keeping up with any issues.

Fedora 18 on ARM retrospective

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.

GNOME 3 fall back mode

I’ve been aware of the possibility of gnome fallback mode being dropped for quite some time. I wasn’t aware a decision had been made to definitely do so.

This is somewhat disappointing to me as I know of a lot of users of it. For starters there’s the 2.5 million OLPC XOs that were in the field as of January 2012 (I’m led to believe there’s around 1.5 million more to add from this year) and there’s a lot of ARM devices that have no 3D support because it’s pretty much impossible to use ESGL with gnome-shell at the moment (yes I know there’s plans to refactor mesa and friends to cope with this but that’s not now).

This isn’t designed to be a Federico style rant and if it was it would be aimed as much at the MATE Desktop as the GNOME team. I personally believe MATE would have been better off targeting their resources at properly fixing the GNOME 3 fall back mode to do the things they miss from GNOME 2 as attempting to glue together the GNOME 2 desktop as at least all the core apps are not duplicated and they get to keep the newer code which ultimately will be a lot more maintainable moving forward through the shared development of code. I’m not sure why they went the other route.

Oh well ultimately I believe it will be yet another net loss for GNOME as possibly eventually losing 4+ million odd young users from OLPC deployments (and all the other people such as families that use the devices) when they leave school I think would be a loss for the community moving forward and then add to that the users of it on ARM devices and other old computers in the developing world I think they’re not even aware of the users they have.

N.B. As always the words and thoughts are those of my own and don’t represent anyone else’s opinions.

Using Fedora on your shiny new OLPC XO

So you’ve just received your shiny new OLPC XO 1.75 as part of the awesome Fedora Open Hardware Summer of fun! or you have an existing OLPC XO that you haven’t used for a while and it’s gathering dust. While it’s running Fedora it doesn’t seem to act completely like Fedora and what’s more it’s likely running an ancient Fedora 14 based release and that’s not really cool is it?

Well the first thing to do is to update it to a newer release. There’s XO releases based on both Fedora 17 (stable 12.1.0 release) and devel releases based on Fedora 18 (development 13.1.0 releases). For a XO-1.5 or XO-1.75 the update process is identical. The process I mention here re-images the machine so if there’s anything you need to save back it up first!

It’s relatively straight forward. You basically get the appropriate .zd file, put it on a USB key and away we go. The Fedora 18 based 13.1 images can be found here. You just need the latest .zd (and it’s good practice to grab the .zd.md5 file too) so for 13.1.0 os3 we’d download this file or for F-17 we’d use this one and pop it on a usb key. From there we make sure our XO has battery juice and is plugged into the power. We power it on and instantly hit ESC to get the OFW OK prompt. Plug in the usb key and run the command “fs-update u:\31003o2.zd“. The screen should change to a grid and slowly go all green. Once we’re back at the OK prompt we can type “reboot”. It will take a while to boot the first time as it will update the Open Firmware and do a few other bits but you should eventually be greeted with a Sugar prompt to enter your name. More detailed instructions including for the XO-1 can be found on the OLPC WIKI.

If you wish to move from the Sugar UX to the more familiar GNOME UX you can right click on the little man in the middle, select “My Settings” to get the Control Panel and there’s a icon “Switch to GNOME”. It will ask you to restart X. There’s a matching App in the GNOME menus to switch back.

Next up we want to unblock all updates from the Fedora repositories. The OLPC releases have a specific package NVR set for stability and release just selected updates rather than the usual firehose from Fedora. We generally want all updates available. The one exception to that at the moment is the kernel. So we do the following which removes the OLPC excludes and excludes just the kernel:
vi /etc/yum.repos.d/fedora*
delete this line
include=file:///etc/yum/olpc-exclude
add this line
exclude=kernel

Of course the first thing you want to do now is “yum update” to get the latest and greatest :-D!

Next up is enabling the standard GDM login. This is as simple as yum install gdm and then updating which display manager starts with the following:
rm /etc/systemd/system/display-manager.service
ln -s /usr/lib/systemd/system/gdm.service /etc/systemd/system/display-manager.service
reboot

Finally I suggest joining the Fedora OLPC mailing list. It’s a pretty quiet list but it’s where we copy any release announcements and also a spot to ask XO specific Fedora questions.

So that should get you to something a little more standard and allow you to install some of your favourite bits. Next up of course is getting more involved in both OLPC and ARM things happening in the Fedora community. I look forward to hearing about what works and what doesn’t on the Fedora planet and mailing lists 🙂

Also note that the above isn’t just restricted to the ARM based XO 1.75, even the original XO-1 runs Fedora 17 and 18 well so if you have an old XO lying around now is a good time to dust it off.

Fedora Board and run off voting

Well it seems I was re-elected to the board for a second term. I’m looking forward to driving forward some of the issues I was dealing with and continuing with the projects I was working on. Of course the board is just a small proportion of what I do within the Fedora Project. I believe it’s important to represent the areas of the project I work in such as ARM as well as other wide projects such as OLPC and Sugar Labs that use Fedora as a core base to their projects as well as contributing back to some of the non technical parts of the project.

Of the three board seats that were up for election the third seat was a dead heat so don’t forget there is run off election between the two candidates that ends tomorrow.

Don’t forget to VOTE once again. It literally takes less than a minute to follow the link and make your vote heard. I personally think that this is as important as the first vote to ensure we get the best candidate.

I look forward to working with you all over the next 12 months.

Failure to build

Having done two complete OS builds of Fedora on ARM. First with Fedora 14 and now with Fedora 17 on both hardfp and softfp flavours of ARM is never ceases to amaze me how many packages won’t build on mainline Fedora. Now days if I get a build failure on ARM the very first thing I do is a scratch build on mainline so I can be sure whether the problem is ARM specific or a general failure, in a lot of cases sadly it’s the later.

What’s more it’s surprising to see how many packages are FTBFS post mass rebuilds even though it’s advertised that packagers need to fix their build failures post mass rebuild. In fact post F-17 mass rebuild there’s still nearly 300 packages that are FTBFS in F-17 and that’s just doing a basic grep against the latest f-17 tagged packages so it doesn’t take into account packages that were built in the f17-build prior to gcc 4.7 landing but are FBTFS with gcc 4.7.0, ruby or some of the other F-17 features.

I know of the last 3-4 months I’ve personally fixed into the 100s of broken packages, and I know spot fixes a lot too but it still amazes me that maintainers don’t fix the build failures for their packages. A lot of fixes, especially for the older build packages, are basic things like patch fuzz so shouldn’t be hard to fix!

A list of the current < f17 packages currently tagged into F-17 stable (sorry if there's already a fix in the works via updates-testing): Mayavi-3.4.0-2.fc15 Panini-0.71.103-5.fc15 PyKDE-3.16.6-7.fc15 Temperature.app-1.5-8.fc16 UnihanDb-5.1.0-7.fc15.3 alacarte-0.13.2-3.fc16 alevt-1.6.2-16.fc15 amanda-3.3.0-2.fc16 apache-commons-fileupload-1.2.2-2.fc15 apache-commons-jxpath-1.3-6.fc15 apache-commons-launcher-1.1-7.20100521svn936225.fc15 ape-1.1.0-3.fc15 aplus-fsf-4.22.4-21.fc16 async-http-client-1.6.1-1.fc16 audtty-0.1.12-3.fc15 autoarchive-0.2.0-3.fc15 ax25-apps-0.0.6-8.fc16 barcode-0.98-17.fc15 base64coder-20101219-2.fc16 blahtexml-0.8-3.fc16 boolstuff-0.1.13-2.fc15 bwa-0.5.9-1.fc16 cargo-parent-4.7-1.fc15 chronojump-0.8.14-1.fc12 cmucl-20b-1.fc15 cobertura-1.9.3-3.fc15 compat-flex-2.5.4a-6.fc12 coredumper-1.2.1-10.fc12 crossvc-1.5.2-7.fc12 ctemplate-0.97-1.fc14 dhcp-forwarder-0.9-1501.fc15 diveintopython-5.4-19.fc16 driftnet-0.1.6-21.20040426cvs.fc15 dvipdfm-0.13.2d-42.fc15 eboard-1.1.1-7.fc15 eclipse-anyedit-2.3.3-2.fc15 eclipse-collabnet-merge-2.2.1-2.fc15 eclipse-emf-query-1.4.0-2.fc15 eclipse-emf-transaction-1.4.0-2.fc15 eclipse-emf-validation-1.4.0-2.fc15 eclipse-m2m-qvtoml-3.0.0-2.fc15 eclipse-mdt-ocl-3.0.0-2.fc15 eclipse-mdt-uml2-3.1.0-2.fc15 eclipse-mercurial-1.8.2-1.fc16 emacs-common-proofgeneral-3.7.1-5.fc15 email2trac-0.13-6.fc12 erlang-ebloom-1.0.2-5.fc15 erlang-js-0.5.0-3.fc16 esc-1.1.0-14.fc15 ext3grep-0.10.2-2.fc15 ezmorph-1.0.6-3.fc15 fbdesk-1.4.1-7.fc15 fbida-2.07-8.fc15 fedora-idm-console-1.1.3-3.fc15 felix-parent-1.2.1-6.fc16 felix-shell-1.4.2-3.fc15 fillmore-lombard-0.1.0-5.fc15 flickcurl-1.18-2.fc15 freenx-client-0.9-11.fc15 fuse-emulator-1.0.0.1-1.fc16 fvwm-2.5.30-4.fc16 fwbuilder-4.1.2-1.fc15 g-wrap-1.9.11-4.fc12 gant-1.8.1-5.fc15 gconf-cleaner-0.0.3-2.fc15 gdmap-0.8.1-8.fc15 gengetopt-2.22.3-1.fc13 gforth-0.7.0-5.fc16 gimmix-0.5.7.1-2.fc15 gmpc-0.20.0-4.fc15 gnaughty-1.2.4-2.fc15 gnofract4d-3.13-2.fc15 gnome-do-docklets-0.8.2-4.fc15 gnome-speech-0.4.25-5.fc15 gok-2.30.1-1.fc15 goldendict-1.0.1-4.fc16 gooddata-cl-1.1.9-2.fc15 google-gson-1.7.1-3.fc16 grace-5.1.22-9.fc16 gshutdown-0.2-8.fc16 gtkglextmm-1.2.0-10.fc12 gtkmm-utils-0.4.1-3.fc15 gtksourceview-1.8.5-8.fc15 gtksourceview-sharp-2.0.12-14.fc16 gtksourceview2-sharp-1.0-10.svn89788.fc16 gtksourceviewmm-2.10.2-2.fc16 gwget-1.0.4-5.fc15 hardinfo-0.5.1-3.fc15 healpix-2.13a-2.fc14 ibus-table-cangjie-1.2.0.20100210-18.fc15 ibus-table-cantonese-1.2.0.20100305-3.fc15 ibus-table-code-1.2.0.20100305-8.fc15 ibus-table-others-1.3.0.20100907-6.fc15 ibus-table-xingma-1.2.0.20100305-3.fc15 ibus-table-yinma-1.2.0.20100305-7.fc15 icewm-1.3.7-1.fc16 ini4j-0.5.1-1.fc16 ipe-6.0-0.32.pre32patch1.fc12 jaffl-0.5.9-1.fc16 jgraph-5.13.0.0-2.fc13 jmol-12.0.41-1.fc16 jpoker-1.0.16-2.fc15 json-lib-2.3-5.fc15 kadu-0.6.5.4-5.fc15 kaffeine-1.2.2-1.fc16 kismet-0.0.2011.03.R2-1600.fc16 komparator-0.9-5.fc15 krecipes-1.0-0.2.beta2.fc15 ksplice-0.9.9-2.fc15 latexila-2.3.0-1.fc16 lekhonee-gnome-0.11-4.fc15 libAfterImage-1.20-2.fc15 libbsr-0.2-4.fc12 libcrystalhd-3.5.1-1.fc14 libfc14audiodecoder-1.0.2-3.fc17 libfwbuilder-4.1.2-1.fc15 libgdbus-0.2-6.fc15 libgdiplus-2.10-2.fc16 libgtkhotkey-0.2.1-4.fc15 libgtksourceviewmm-0.3.1-7.fc15 libharu-2.1.0-3.fc15 libhid-0.2.17-6.fc15 libinfinity-0.5.0-2.fc15 libkml-0.6.1-8.fc15 libmnetutil-0.8.0-0.3.20100629svn3775.fc15 libofx-0.9.4-1.fc16 libopensync-plugin-opie-0.22-5.fc15 libpano12-2.8.6-5.fc15 libqttracker-6.11.0-2.fc15 libsoup22-2.2.105-9.fc15 libvpd-2.1.1-2.fc15 licq-1.3.5-10.fc15 links-2.2-13.fc15 lsvpd-1.6.8-3.fc15 maven-changelog-plugin-2.2-7.fc16 maven-changes-plugin-2.6-2.fc16 maven-invoker-plugin-1.5-5.fc16 maven-license-plugin-1.8.0-5.fc16 maven-plugin-cobertura-2.5.1-1.fc16 maven-stage-plugin-1.0-0.3.alpha2.fc16 mercury-1.0-0.4.alpha6.fc16 metapixel-1.0.2-7.fc15 mimetic-0.9.6-2.fc15 mod_scgi-1.13-5.fc15 mod_security-2.5.12-4.fc15 moksha-0.5.0-5.fc15 munipack-1.2.10-2.fc15 nagios-plugins-rhev-1.0.0-2.fc16 natus-0.1.5-2.fc15 ndesk-dbus-0.6.1b-1.fc13 node-0.3.2-8.fc15 notify-sharp-0.4.0-0.14.20100411svn.fc15 ntfs-config-1.0.1-13.fc15 numptyphysics-0.3-0.6.20080925svn.fc15 ocaml-augeas-0.4-9.fc15 ooo2gd-3.0.0-1.fc16 openoffice.org-diafilter-1.7.0-6.fc15 openvrml-0.18.8-2.fc16 ovaldi-5.9.1-1.fc16 parole-0.2.0.2-6.fc15 perl-Config-Augeas-0.701-5.fc16 perl-Crypt-CBC-2.29-8.fc16 perl-Log-Any-0.11-6.fc16 perl-MD5-2.03-10.fc16 perl-Module-Starter-Plugin-CGIApp-0.30-6.fc16 perl-Test-Refcount-0.07-1.fc16 perl-XML-Filter-XInclude-1.0-9.fc16 pgp-tools-1.1.3-4.fc16 php-ezc-Authentication-1.3.1-2.fc15 php-pear-File-Find-1.3.1-1.fc15 php-pear-Payment-Process-0.6.6-7.fc16 pianobooster-0.6.4b-3.fc15 piccolo2d-1.3-9.fc16 pino-0.3-0.3.20101112hg.fc15 pioneers-0.12.3-3.fc15 pki-java-tools-1.3.1-1.fc14 plexus-sec-dispatcher-1.4-4.fc16 pmd-4.2.5-11.fc16 pngcrush-1.6.10-7.fc15 pngnq-1.1-1.fc16 pnmixer-0.3-1.fc16 polyxmass-bin-0.9.8-2.fc12 postgresql-odbcng-0.99.101-0.5.test1.fc15 postgresql-pgpoolAdmin-2.2-2.fc12 postgresql_autodoc-1.40-2.fc14 printoxx-2.8.1-2.fc15 professor-is-missing-0.1-6.fc15 putty-0.60-7.20100910svn.fc15 pxe-kexec-0.2.3-3.fc15 pysvn-1.7.5-1.fc16 python-GeoIP-1.2.5-0.4.20090931cvs.fc15 python-HTMLgen-2.2.2-14.fc14 python-bitarray-0.3.5-4.fc15 python-blinker-1.1-1.fc16 python-blist-1.3.4-1.fc16 python-catwalk-2.0.2-4.fc15 python-cclib-1.0.1-1.fc16 python-cement-0.8.18-2.fc16 python-cerealizer-0.7-3.fc15 python-cherrypy2-2.3.0-15.fc15 python-cherrytemplate-1.0.0-12.fc15 python-chm-0.8.4-10.fc15 python-clientform-0.2.10-2.fc15 python-cloudservers-1.2-3.fc16 python-coffin-0.3.5-2.fc16 python-compositor-0.2b-4.fc15 python-configobj-4.7.2-3.fc15 python-couchdb-0.6.1-4.fc15 python-cpio-0.1-12.fc15 python-cssutils-0.9.7-2.fc15 python-ctags-1.0.5-4.fc15 python-daap-0.7.1-7.fc15 python-daemon-1.6-1.fc16 python-dialog-2.7-14.fc15 python-dictclient-1.0.1-6.fc14 python-dmidecode-3.10.13-3.fc15 python-dns-1.9.4-1.fc16 python-dotconf-0.2.1-12.fc15 python-dpkt-1.7-2.fc15 python-drizzle-0.08.2-7.fc15 python-dtopt-0.1-8.fc15 python-durus-3.9-2.fc14 python-empy-3.3-7.fc15 python-enum-0.4.4-3.fc15 python-epdb-0.11-6.fc15 python-exif-1.0.8-6.fc15 python-formencode-1.2.2-4.fc15 python-modjkapi-0.1.2.28-7.fc15 python-mpmath-0.17-2.fc15 python-pywt-0.2.0-3.fc15 python-unidecode-0.04.7-4.fc16 qalculate-kde-0.9.7-3.fc15 qbrew-0.4.1-7.fc15 qtparted-0.4.5-26.fc15 quesoglc-0.7.2-2.fc15 qwtplot3d-0.2.7-10.fc15 ragel-6.6-3.fc15 raul-0.8.0-2.fc15 rinputd-1.0.4-1.fc16 rmic-maven-plugin-1.1-7.fc16 rpmdepsize-1.0-7.fc15 scite-2.22-2.fc15 selenium-core-1.0.2-0.5.20100324svn.fc15 selenium-remote-control-1.0.3-8.20100318svn.fc15 sinjdoc-0.5-10.fc15 snoopy-1.8.0-1.fc16 sofsip-cli-0.16-3.fc15 specto-0.3.1-3.fc15 sphinx-0.9.9-6.fc16 spor-1.0-4.fc15 sshfp-1.2.0-1.fc16 stardict-3.0.2-2.fc16 stratagus-2.2.4-9.fc15 subcommander-2.0-0.7.fc15.7 surf-0.4.1-3.fc15 svnkit-1.3.4-2.fc15 symkey-1.3.0-4.fc13 synapse-0.2.6-1.fc16 synfigstudio-0.62.02-1.fc15 tesseract-3.00-2.fc15 testng-6.0.1-1.fc16 tilda-0.9.6-6.fc16 tomoe-0.6.0-19.fc15 tucnak2-2.31-1.fc13 txmpp-0.0.2-3.fc14 txt2man-1.5.6-1.fc15 tyrion-0.1.0-1.fc15 ucblogo-6.0-8.fc15 umlgraph-5.4-2.fc15 uncrustify-0.58-1.fc16 vifm-0.5-5.fc15 vorbisspi-1.0.3-3.fc15 winwrangler-0.2.4-2.fc15 wmdrawer-0.10.5-11.fc16 wmfire-1.2.3-4.fc15 wmweather+-2.11-3.fc15 wormux-0.9.2.1-5.fc16 writer2latex-1.0.2-6.fc16 xaos-3.5-2.fc15 xdrawchem-1.9.9-15.fc15 xesam-glib-0.5.0-5.fc15 xmlbeans-2.4.0-7.fc15 xulrunner-python-2.0-1.20110406hg.fc16 xxdiff-3.2-14.fc15 yaws-1.89-4.fc15 zhu3d-4.2.2-3.fc15

ARM hardware now and the not so distant future

So one of the things that I noticed during the heated discussion on the devel mailing list is the impression is why would we want to promote ARM to a Primary Architecture when there wouldn’t even be hardware available to run it in the next year or so. Well the lack of hardware is completely untrue and that will only increase in the coming months and years. So I thought I would try and cover off some of the hardware that is either available now or will be in the next year or so that you might want to run Fedora on. All of the devices covered are available now or should be available by the time Fedora 18 makes it’s Halloween début, of course I have no crystal ball as to HW time lines so things might well change.

Development Boards: all these devices are currently available, there will no doubt be new releases or refreshes in the coming months, likely as Cortex-A15 chips become more widely available.

  • BeagleBoards: There’s three main varieties of these single core Cortex-A8 devices consisting of the original BeagleBoard, the BeagleBoard xM and the new tiny BeagleBone. They range from 800Mhz – 1Ghz and 256-5126Mb RAM with a few other options.
  • PandaBoards: There’s the PandaBoard and the PandaBoard ES. Bother at dual core Cortex-A9 processors the former at 1Ghz, the later at 1.2. From there the specs are similar with 1Gb RAM, WiFi, BT, 100Mb ethernet and various other features.
  • Raspberry Pi: The little baby that took the world by storm taking pre orders in the order of 200K boards and taking a couple of sites offline. There’s a model A and B based on a Broadcom ARMv6 chip the later has ethernet, both have 256Mb of RAM. Fedora is the recommended OS by the Foundation
  • Snowball: A ST-Ericsson based dual core Cortex-A9 with 1Gb RAM, wifi, BT, GPS, ethernet, 4/8Gb emmc and a raft of other fun stuff. It also has a MALI GPU which has development on the open “LIMA” driver
  • Origen: based on a Samsung dual core 1Ghz Cortex-A9 processor which can be replaced, it has 1Gb of RAM, wifi and number of other bits including the same MALI GPU of the igloo
  • Freescale i.MX53: A single core 1Ghz Cortex-A8 Freescale board 1Gb RAM, SATA, ethernet, with options of LCDs etc

SmartBooks, SmartTops, Terminals: These devices are the equivalent of the x86 netbooks and nettops, all are mostly available now.

  • OLPC XO 1.75: Initially shipping with Fedora 14 but we’ve already got dev images running F-17 and it will be the basis of the June stable release. The first production shipment of this device will be 60,000 units. There’s various SKUs but it’s a 1ghz Marvell processor with either 512Mb/1Gb RAM, 4/8Gb emmc, wifi, and the usual XO features, it should have in excess of 9 hours of battery life.
  • Efika SmartBook: a 800Mhz Cortex-A8 Freescale processor, 512Mb RAM and with all the usual 10 inch Netbook style of features
  • Efika SmartTop: the same specs as the smartbook
  • Toshiba AC100: A dual core Cortex-A9 1ghz processor with 1gb of RAM, and all the usual 10 inch netbook options, very thin and light with great battery life but the device wasn’t widely available but is sought after
  • ASUS eeePad Transformers: These devices are a combination tablet and netbook. Depending on the model they either come with a dual core 1ghz Tegra2 or a quad core Tegra 3 CPU with various specs. They are a tablet with the option of a keyboard dock which makes them into a netbook. With touchscreens, quad core processors, an interesting form factor and an unlocked bootloader they’re an interesting format.
  • HP t5325 thin client: A Marvell 1.2ghz Cortex-A8 512Mb RAM thin client
  • Trimslice: A Tegra 2 based smarttop desktop device with a couple of different modes all with a dual core 1ghz Cortex-A9 processor with 1Gb of RAM, 1Gb ethernet plus a couple of options including dual HDMI, 11n wifi.

Tablets: these aren’t readily available at the moment but should be available this year.

  • OLPC XO 3: Similar specs to the XO-1.75 but in tablet form factor, it will ship the Fedora derived OS all touch based UX it will likely be one of the first production devices using the new gtk3 and XInput 2.2 touch support in Fedora 17
  • Vivaldi: A 7inch tablet running KDE Plasma tablet UX on Mer the HW is a 1ghz single core Cortex-A9 processor with 512Mb of RAM and a MALI GPU it’s not the highest spec device but it should be easy to run Fedora on it

Servers:

  • HP Moonshot: In conjunction with Calxeda this is a quad core processor server with 4GB of RAM with up to 288 servers in a 4U chassis. Includes all the expected server features with things like a fully reconfigurable switch backplane with each device using a mere 5 watts of power.
  • Dell: has announced it’s intention to enter the ARM server market, there’s not much detail as yet
  • Seco Carrier Boards: these are various boards using Tegra processors used in things like the Barcelona Super Computer

Plug Computers: There’s a number of plug computers out there based on the Marvell Sheeva Plug generally a 1ghz ARMv5tel processor with 512Mb RAM. These devices are low power, generally quite cheap and come in a number of different devices.

So I think that gives a reasonable overview of ARM based devices that will be available in the coming months, if not already, that should be easily able to run Fedora on ARM without too many problems. This covers but a few of the available ARM based devices but they are a subset that should be relatively easy to run Fedora on them in the coming releases. ARM processors have a number of interesting advantages hardware wise. Firstly they are generally very low power with a lot of quad core devices needing only 5 watts to run, but some of the other advantages is HW encode/decode support for things like MPEG2/4 out of the box which would enable HD decode without having to ship encumbered codecs in Fedora as well as HW crypto as well.

I’m also sure this isn’t a definitive and there’s a lot of other devices that should be able to run Fedora on ARM without too many problems if someone is prepared to roll up their sleeves and get stuck in.