They say the first step of coming to terms with addiction is admitting you have a problem… I have a problem with collecting ARM devices… there I said it! How big is this problem you ask? How about I list them out and let you decide!
I’ll break the list down into categories as I believe it’s big enough to do so :-/
The aarch64 set of devices currently stands at:
- 2x Applied Mustang (different x-gene SoC revs)
- AMD Seattle
- 96boards HiKey (hi6220)
The ARMv7 boards list is currently:
- Compulabs Trimslice (tegra-2)
- Toshiba AC100 (tegra-2)
- nVidia Jetson TK1 (tegra-124)
- Acer Chromebook (tegra-124)
- BeagleBoard xM (omap3)
- Nokia n900 (omap3)
- Nokia n950 prototype (omap3)
- BeagleBone (am33xx)
- BeagleBone Black (am33xx) x3
- BeagleBone Green (am33xx)
- PandaBoard ES Prototype (omap4)
- PandaBoard ES B2 (omap4)
- CubieBoard (allwinner-a10)
- CubieTruck (allwinner-a20)
- Banana Pi (allwinner-a20)
- C.H.I.P. Alpha x2 (allwinner-r8)
- Snowball (u8500)
- Compulabs Utilite (imx6q)
- WandBoard Quad revb (imx6q)
- novena board (imx6q)
- RIoTboard (imx6s)
- UDOO Neo (imx6sx)
- Origen (exynos-4)
- OLPC XO 1.75 – a number of variants (mmp2) xNumerous
- OLPC XO-4 including XO-Touch (mmp3) xNumerous
- Linksys WRT1900AC (armada-xp)
- Mirabox (armada-370)
- ifc6410 (qcom)
- Parallella Board (zynq7000)
- Raspberry Pi 2 x3
The Cortex-M series for IoT sensors is currently:
- TI SensorTag 2015
- ARM mBed IoT starter kit
- BeeWi SmartClim
Other random related bits:
- BeagleBone Breadboard Prototyping Cape x2
- BeagleBone CryptoCape
- Original 256Mb Raspberry Pi model B
- Grove starter kit for BeagleBone Green
- Explorer HAT
- PiGlo HAT
- TI CC2531 802.15.4 USB dongle x3
- numerous random sensors
So the list above is the devices that I use for hacking on. I count 41 without listing out the dozen or so ARM based XOs I have (various prototypes and models). I also don’t have in that list phones, tablets and two drones as I don’t really hack on those as it’s not like with the list above I don’t already have enough toys! So do I have a problem?
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.
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.
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!