Tag: BeagleBone

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.

Serial console options on the Beagle Bone Black

So unlike the original Beagle Bone, which had a built in USB serial adapter, the Beagle Bone Black only has a serial header and you have to buy a USB to serial adapter to get a real serial console.

There’s one other option for a pseudo serial console over the USB On the Go port but the problem with this is that it doesn’t work with u-boot so only works once the kernel has booted as we can setup the port. The enabling and use of the USB OtG in Fedora is still on my ToDo list to investigate for ARM but we can possibly enable it as both serial and usb network at some point in the future.

So for now we need to use the 6 pin header to connect a USB to serial adapter. The most important thing to note here is that it requires 3.3 volts for the data signals so don’t use some of the older 5 volt units. The best USB to Serial to use is the FTDI FT232RL but at $20 it’s almost half the price of the device. The advantage is that it just works and the 6 pin connect just plugs straight onto the board (black goes to PIN 1). I’ve also tried the Adafruit 4 Pin Cable (PL2303), which at $9.95, is less than half the price and as the 4 pins are on 4 separate 1 pin headers it can be used on a number of different devices as it doesn’t matter how the serial headers are pinned out. To connect to The BBBlack the black wire goes to PIN 1 (Ground), the green wire to PIN 4 (Receive) and the white wire goes to PIN 5 (Transmit). The red wire is power and isn’t needed. CircuitCo has a number of other Serial Cable Options listed and the appropriate configurations for them too.

Now for a serial console app on Fedora I usually use screen. So simply once you have your serial console connected to the BeagleBoneBlack just plug the usb port into you computer and run sudo screen /dev/ttyUSB0 115200 and then power up the Beagle Bone and you should soon see the output from u-boot and you’re on your way.