Archives For December 2012

It’s been a while since last update on the project status so it might seem as there was no progress in this area. The reality is: there is a bunch of activities happening with various levels of success. So I decided to give kind of end-of-the-year round-up of ongoing projects, plans and obstacles ARM hackers face.

First of all we tried switching default cache type from write-through to write-back type. It should have increased performance but instead opened a can of worms. Memory corruption debugging led to L2 cache driver on Pandaboard, EHCI driver code and subsequently to busdma code. Whole process took quite a few days full of hair-pulling and nagging various people and ended up in committing USB fixes and Ian Lepore’s busdma patches. PL310 (L2 cache controller) driver is being tested at this very moment. Original issue (WB caches) still stands and postponed till next year.

Then there are two projects by Andrew Turner aimed at modernizing FreeBSD/armv6 subsystem: switching to EABI and clang support for ARM. Daisuke Aoyama took both of them and produced working image for Raspberry Pi. He also fixed two issues with event timers on Raspberry Pi so now the platform is much more stable. I ran buildkernel in a loop overnight and by the morning Pi had survived 7 cycles and still was alive and kicking. I also managed to get python built and working on it. Didn’t have 100% success with perl 5.14/5.16, ports were built but failed at install stage segfaulting in do_clean_objs function.

My Pandaboard survived overnight buildkernel loop with L2 cache disabled, but acting up if I enable it. Investigating.

Then there are also several platform bring-ups in progress. Alexander Rybalko works on getting FreeBSD running on Efika MX Smartbook. Ganbold Tsagaankhuu hacks on Allwinner 10. Alexander Dutkowski’s hardware of choice is BeagleBoard-xM.
Ruslan Bukin experiments with Exynos4412 and Thomas Skibo reported about FreeBSD running on Zedboard (Xilinx Zynq-7000).

But what about devices/platform we have in tree? I have limited knowledge about some platforms so here is summary of the ones I’m aware of. If you have more information on any of these targets (or any other ARM-related projects) – let me know, I’ll update post.

  • BCM2835 Raspberry Pi the most accessible and therefore the one that gets the most exposure and testing. Pretty stable, considering. Supported devices: USB, network, MMC, GPIO, framebuffer, GPU. The rest is on ToDo list. VCHIQ driver is BSD-licensed now and I’m planning on getting it to sys/contrib. Userland bits of OpenGL ES should be added as a port though.
  • (update) LPC32x0 No first hand experience but judging by the code it supports MMC, FB, GPIO and USB
  • Marvel Armada XP I don’t have information about this one, sorry
  • Nvidia Tegra2 Just barebone boot stuff.
  • TI AM335x Examples: BeagleBone, TI Sitara EVM. Network was reported working but unstable on BeagleBone. USB is not supported. Haven’t tested GPIO yet.
  • TI OMAP3 Example: BeagleBoard-xM. See Alexander Dutkowski’s project
  • TI OMAP4 The hw I have – Pandaboard ES. Supported devices: USB, network, MMC, GPIO. Some issues with L2 cache
  • Versatile Platform Board Exists only as emulation target for QEMU. Supported hardware: PCI, network, framebuffer. Seems to be fairly stable, no extensive testing performed.

BeagleBone, PandaBoard ad Raspberry Pi images can be built using Tim Kientzle’s scripts.

Not really stellar list of supported peripherals I’d say. I tend to blame several things.

First – experimental and unstable state of FreeBSD/armv6 in general. It’s no fun adding new hardware support when you’re not confident in underlying subsystems stability. “I flush cache for this TX descriptor but is it really gets flushed?”. Been there, no fun at all. That’s why I believe task #1 for nearest future is maximum performance and rock-solid stability of what we have.

Then there is the case of syscons. It’s old, it’s inflexible and it’s mostly i386-centric. Just until recently most of our so-called embedded targets were headless so there were no pressure from this side to reorganize things. My experience with coding two framebuffer drivers or trying to add PS/2 keyboard support on non-i386 platform was not very pleasant. It’s messy and there is a lot of code duplication. newsyscons project may be the way to go, I haven’t looked at it yet. We just need someone(tm) to finish it and get into the tree.

Fix these two issues should make bring-up process easier. It leaves us with question of GPU support. But it’s different story for different post…

Happy New Year, everybody!

vchiq, kernel driver for interfacing ARM with VideoCore is now dual-licensed (BSD/GPL).


FreeBSD/armv6 in QEMU

December 5, 2012 — 7 Comments

[QEMU 1.5 users see this update]

First take at getting FreeBSD/armv6 running in simulators. Simulators are great for tracking down nasty bugs and building packages.

So here is support for Versatile Platform Board machine supported by QEMU. Most likely this code will not run on real VersatilePB because I do not have this hardware and timing code (or lack of it) on CLCD driver and Keyboard/Mouse interface (PL050) is pure guesswork.

Back to gory details:


You’ll need this patch and this script. Apply patch, use script to get freebsd-versatilepb.flash.

As for userland – it’s fully compatible with Raspberry Pi’s userland, or Pandaboard’s one. So you can use latest RPi SD card image. As for now it’s freebsd-pi-r243778.img.gz (124Mb)


I believe that at least QEMU 1.2.0 is required. It’s still 1.1.1 in ports due to some blockers that prevent upgrade to 1.3.0. This patch updates port to 1.3.0 and it worked for me. Also I tested images with QEMU on windows and OS X – works fine.

qemu-system-arm -M versatilepb -m 128M -kernel freebsd-versatilepb.flash  -cpu arm1176 -hda freebsd-pi-r243778.img 


  • Serial console is off by default, use graphics console. If you need headless mode, rebuild image with “device sc” and related options disabled or use prebuilt flash image for headless mode
  • root device name is hardcoded so if you’re using some other image or building your own – be sure that’s ROOTDEV actually match real root
  • Memory size is hardcoded – 128M. For getting this information run-time we’ll need uboot and ubldr added to boot chain

Prebuilt kernels

freebsd-versatilepb.flash (4Mb)
freebsd-versatilepb-headless.flash (4Mb)
MD5 (freebsd-versatilepb-headless.flash) = 24a41807bf94c5fec0565adcfef48678
MD5 (freebsd-versatilepb.flash) = 085dedae67895ac1d1a7c04c7cda8468

Cross-compilation hiccups

December 1, 2012 — 21 Comments

Good news and bad news. Let’s start with good ones.

Daisuke Aoyama tracked down what causes “Unrecognized filesystem type” error with some SD cards. It is U-Boot using High Speed mode. Root cause is still unknown but as a workaround I just disabled HS mode for SD card in u-boot and updated freebsd-uboot-20121129.tar.gz. Or alternatively you can get uboot-nohs.img and use it to replace uboot.img on your SD card.

Bad news are: installworld for cross-compiled FreeBSD is broken unless you’re doing it on the latest HEAD. The reason is utility called mtree(8). It is used to ensure that target filesystem permissions and owners/groups are correct. Owners and groups are described as usernames and group names, not as numeric UIDs/GUIDs and mtree uses getpwXXX family of routines to convert names to numeric values. See the problem already? If new system user is added to latest HEAD and you use old trusty FreeBSD 9.0, there is no way mtree would know about this user. NetBSD solved this problem by introducing -N command-line option that lets you point mtree to the target system’s master.passwd and groups. So we need to port this feature to FreeBSD in order to get proper cross-compilation environment. And that’s my plan for next few days.

So if you see something like this:

mtree -eU  -f /src/FreeBSD/head/etc/mtree/BSD.var.dist -p /mnt/var
mtree: line 22: unknown user auditdistd
*** [distrib-dirs] Error code 1

Either update to latest HEAD, use mergemaster -p or wait couple of days.