Fedora 21 and ARM device support

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.

Primary:

  • Wandboard (all models/revisions)
  • Utilite (all models)
  • Cubox-i (all models)
  • Hummingboard (all models)
  • RIoTBoard
  • BeagleBone Black
  • Tegra K1 Jetson
  • CubieBoard (all models)
  • Banana Pi
  • Trimslice
  • PandaBoard (all models)
  • Calxeda Highbank/Midway
  • VExpress (qemu)

Secondary:

  • BeagleBone White
  • Beagle xM
  • Novena
  • UDOO
  • AC100
  • 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

ARM64:

  • 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.

3.15 Fedora ARM kernel status

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.

Semi irregular Fedora ARM kernel status reports

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.

Booting PandaBoard with Fedora 20 GA

So I’ve always thought the fix for Fedora 20 booting on the PandaBoard devices would be a simple fix. I’ve always assumed it would be a minor kernel config change. I was wrong, it was even more simple once we worked it out with some help of our friends!

So to make it work you can do the following. First get a Fedora ARM Image, I used the Minimal Image, you’ll need the VFAT variant for which ever one you choose.

As root (or use sudo) run the following commands but remember to change the device path:

xzcat Fedora-Minimal-VFAT-armhfp-20-1-sda.raw.xz > /dev/mmcblk0; sync

Eject the card and put back it back in so it gets the new partition table etc and then copy the uboot over to the uboot partition. In my case I did (but change the path to your mount points):

cd /run/media/USERNAME/__/usr/share/uboot-panda/
cp MLO u-boot.img /run/media/USERNAME/uboot/
cp uEnv.txt.panda_es /run/media/USERNAME/uboot/uEnv.txt
umount /run/media/USERNAME/__/ /run/media/USERNAME/uboot/
sync

At this point you’ll likely want to use gparted or similar tools to expand the root filesystem. Once complete run screen or your favourite serial console application:

screen /dev/ttyUSB0 115200

Put the SD card into the panda, apply power, and boot through to u-boot but interrupt the boot process and get the Panda# u-boot prompt and enter the following set of commands:

setenv bootm_size 0x20000000
setenv bootargs console=${console} vram=${vram} root=LABEL=_/ ro rootwait
ext4load mmc 0:3 0x82000000 /boot/vmlinuz-3.11.10-301.fc20.armv7hl
ext4load mmc 0:3 0x88080000 /boot/uInitrd-3.11.10-301.fc20.armv7hl
ext4load mmc 0:3 0x88000000 /boot/dtb-3.11.10-301.fc20.armv7hl/omap4-panda-es.dtb
bootz 0x82000000 0x88080000 0x88000000

From there it should boot all the way through to the first boot configuration tool on the serial console, once you set a root password, create new user and set the timezone it will boot you thought to the login prompt.

That will get you to the point of being able to play. Networking works fine as does USB and a bunch of other core functionality, X doesn’t appear to with the first look and if you update the kernel (I’ve tested the shipping 3.11.10-301.fc20 and latest 3.113.13.6-200) you’ll just need to follow the process above with updated kernel details to reboot.

We’re working to get updated arm-boot-config to ensure the expected automated boot process plus some updates for X etc but I wanted to get this process out for those chomping at the bit to play while we review the changes! As always please report any issues (or success) to the Fedora ARM mailing list or IRC channel.

In terms of working devices I’ve personally tested my Panda-ES prototype (which never successfully booted anything later than 3.6.x) and Panda-ES B2, I’ve had reports of a number of variants of the vanilla Panda and ES working. I’m not sure about the B3 revisions with the Elpida DDR2 RAM but you might want to try the above with the Fedora 2014.01 uboot as it has the uboot components needed.

Lastly I’d like to explicitly call out Paul Whalen for his persistence on this one and Tom Rini who ultimately provided the tiny bit of glue we needed to solve this so simply!

I’m glad to be able to add this mainstay of the Fedora ARM project back into the supported list with fan fair, I just wish we’d found this prior to F-20 GA!

Update: It appears that X with at least the XFCE image works with the GA image.