Archives For Uncategorized

Just quick (and overdue) update: HDMI for BBB is in HEAD as of r284534.

HDMI support for Beaglebone Black is stable now and supports reading EDID, you can get the path here. Before committing it I’d like to make interoperability between HDMI framer and FB/LCD drivers as generic as possible and for this I need at least one more system with working HDMI to find common patterns. For this purpose I picked up i.MX6-based Hummingboard and now try to get video output working on it. There is some minor progress but it seems before getting to HDMI/IPU I need to do some work on clock management part of the system. So it’s going to be some time before I see first pixels on my monitor.

I also got 4DCAPE-43, neat Beaglebone Black LCD cape by 4D Systems. Patch (download here) for it is pretty minimal: VT support in kernel config, panel info and pins configuration in dts, and one improvement in GPIO driver (setting default values for OUT GPIO pins). None of the other features except reset button work yet but getting GPIO keyboard working would be an interesting project by itself.

Here is the picture of cape in action:


Today for the first time I’ve got stable and correctly positioned output on HDMI monitor connected to BeagleBone Black. It involved fixing bug in AM335x LCDC controller, fixing bug in I2C controller, and a lot of experiments with register-pushing. Code requires major clean-up and is not ready for the tree yet. I’ll post patch when it’s in readable form.


I’ve update ioquake binaries and pushed respective changes to github. New version has support for mouse and keyboard so you can actually play Quake3 on FreeBSD/Pi alas without sound. It should run out of the box on normal console. Make sure you have moused running or specify mouse device by setting Q_MOUSE_DEV environment variable, e.g.:

env Q_MOUSE_DEV=/dev/ums0 ioquake3.arm +set s_initsound 0

A week ago Adrian Chadd asked me to take a loot at FreeBSD/MIPS emulation. So last week I’ve been busy tidying up stuff in that department and looking up bits of information on various emulators. This morning I finally committed last changeset so now is the time to write up summary.


There are two widely used MIPS emulatoes that FreeBSD supports: QEMU and GXemul. Both of them support numerous MIPS devices but we’re interested in only two.

MALTA is more or less standard for MIPS emulation and supported by both emulators. QEMU supports 32 and 64 bit variants with both big and little-endian byte order. So four modes in total. Also for MALTA machine QEMU provides PCNet NIC emulation.

GXemul supports 32 and 64 bit modes of MALTA but only for little-endian byte order. Big-endian byte order is not supported due to incomplete PCI controller implementation. No NIC support for MALTA machine. Also Gxemul provides so-called oldtestmips emulation mode: generic implementation of abstract MIPS machine with very simplified NIC/disk devices. In theory it should be faster then actual hardware emulation but I haven’t got around to benchmarking yet. oldtestmips can be run in 32 and 64 bit mode, but only big-endian byte order is supported.

Disk images

I used raw disk images created by makefs(8) utility. The advantage of raw disk image is that they can be used with both emulators. qemu provides more options in this area but they’re out of scope of this article. I created four images for my tests: disk.img, disk64.img, diskel.img, and disk64el.img. 32-bit big-endian, 64-bit big-endian, 32-bit little-endian, 64-bit big-endian. The process looks somewhat like this script:

set -e

export TARGET=mips
export TARGET_ARCH=mips
export SRCCONF=/dev/null
export SRCROOT=/src/FreeBSD/head
export MAKEOBJDIRPREFIX=/src/FreeBSD/obj/head
export DESTDIR=/src/FreeBSD/tftproot/$TARGET_ARCH
make -C $SRCROOT buildworld

sudo -E mkdir -p /src/FreeBSD/tftproot/$TARGET_ARCH

# modify /etc/fstab and /etc/rc.conf in $DESTDIR

# Create 512Mb disk image with big-endian UFS
# For TARGET_ARCH set to mipsel or mips64el use "-B le" switch 
sudo -E makefs -M 538968064 -B be /src/FreeBSD/disk.img $DESTDIR

Change TARGET_ARCH and disk image name accordingly for mipsel/mip64/mips64el targets.


As of QEMU 1.6.0 there is one known problem with it: NIC emulation does not work in big-endian mode. See this patch for fix and details. Also, amount of memory limited to 128Mb. Use MALTA kernel config for 32-bit mode and MALTA64 for 64-bit mode.

Command lines for various modes/byte orders are:

qemu-system-mips -M malta -kernel /path/to/mips.mips/MALTA/.../kernel -hda /src/FreeBSD/disk.img -nographic
qemu-system-mips64 -M malta -kernel /path/to/mips.mips64/.../MALTA64/kernel -hda /src/FreeBSD/disk64.img -nographic
qemu-system-mipsel -M malta -kernel /path/to/mips.mipsel/.../MALTA/kernel -hda /src/FreeBSD/diskel.img -nographic
qemu-system-mips64el -M malta -kernel /path/to/mips.mips64el/.../MALTA64/kernel -hda /src/FreeBSD/disk64el.img -nographic


GXemul requires two patches for proper FreeBSD/MIPS emulation. First one implements rdhwr op for reg 29 required by TLS support. The second one fixes UDP packet checksum calculation and required for proper functioning of emulated DHCP server. Both of these patches have been committed upstream but there were no GXemul release after that so they’re not available as part of emulators/gxemul port.

As with QEMU kernel configs for MALTA are MALTA and MALTA64. And since only little-endian byte order is supported command lines for this emulation mode are:

gxemul -e malta -C 4Kc -d /home/gonzo/FreeBSD/diskel.img /path/to/mips.mipsel/.../MALTA/kernel
gxemul -e malta -d /home/gonzo/FreeBSD/disk64el.img /path/to/mips.mips64el/.../MALTA64/kernel

For oldtestmips emulation mode is other way around, only big-endian. And to make things more complicated it’s GXEMUL kernel config for 64-bit and GXEMUL32 for 32-bit. So here you are:

gxemul -M 256 -E oldtestmips -d /home/gonzo/FreeBSD/disk64.img /path/to/mips.mips64/.../GXEMUL/kernel
gxemul -M 256 -C 4Kc -E oldtestmips -d /home/gonzo/FreeBSD/disk.img /path/to/mips.mips/.../GXEMUL32/kernel

Maximum amount of memory set could be set by -M command-line switch for oldtestmips emulation is 256M. Otherwise physical memory would overlap with memory-mapped regions reserved by devices. There are some preliminary work to work around this limitation but no results yet.

It took me two months but I finally got back to hacking on musb driver for FreeBSD (the one that is used in TI AM335x-based devices like Beaglebone or Beaglebone Black). Previous revision turned out not to be ready for production. Here is the new one: beaglebone-usb-20130626.diff. I adopted it to latest HEAD, fixed numerous bugs, added support for SPLIT transactions and USB suspend/resume signalling. There is some cleaning-up to do but unless something major comes up the plan is to commit it over next few days.

I finally got around to finishing the PWM and LCDC driver for AM335x. Everything was committed today. Here is demo on AM335x EVM (I apologize for quality):


As it was mentioned in previous post U-Boot can boot FreeBSD kernel directly but this approach doesn’t allow a great deal of control over boot process: there is no way to set tunables’ values or pre-load module. Controlling this stuff requires more knowledge of FreeBSD internal data structures and its boot process then U-Boot holds.

On i386 and other Tier1 architectures this task is handled by the loader(8) program. It’s last stage boot loader (e.g. it’s supposed to pass control to FreeBSD kernel only), highly customizable and scriptable. loader(8) relies on one of the previous stages boot loader to access resources like disks, console, network. For i386 it’s BTX and BIOS.

ubldr is implementation of loader(8) for ARM on top of U-Boot. Original code was developed by Semihalf back in 2008 and has been being improved by them and FreeBSD Community since then. Despite it has been around for almost 5 years amount of documentation is shockingly low. I found only these slides from BSDCan 2008.

One of the nice feature U-Boot provides is API for stand-alone process. If you don’t need full-blown operating system running on your hardware but still want access to SD card/network/console you can request them from U-Boot via syscall-like API that turns boot loader into quasi-OS. Some bits of information on this topic can be found in api/README file in U-Boot sources: here.

ubldr uses U-Boot API to enumerate devices that might be used as a boot source: block (e.g. SD card) or network. For network device it will use BOOTP to try to obtain network/boot data and then mount directory over NFS. For block device it will inspect partition table and try to find suitable partition to use as a root device. Once root is mounted ubldr will perform standard loader(8) magic: get loader-related config from /boot/ directory and act on it.

There is no dedicated top-level build target for ubldr so getting it compiled is a little bit tricky. You need to perform whole buildworld cycle before compiling ubldr. Build script would look something like this:

export SRCROOT=/src/FreeBSD/head
export MAKESYSPATH=$SRCROOT/share/mk
export TARGET=arm
export TARGET_ARCH=armv6
export MAKEOBJDIRPREFIX=/src/FreeBSD/obj

make -C $SRCROOT buildworld

buildenv=`make -C $SRCROOT buildenvvars`

eval $buildenv make -C $SRCROOT/sys/boot clean
eval $buildenv make -C $SRCROOT/sys/boot obj
eval $buildenv make -C $SRCROOT/sys/boot UBLDR_LOADADDR=0x2000000 all

Meaning of UBLDR_LOADADDR is the same as KERNPHYSADDR in previous post.

ubldr is ELF executable and can be used with bootelf command. Typical boot log is something like this:

## Starting application at 0x02000054 ...
Consoles: U-Boot console  
Compatible API signature found @7b662a8
Number of U-Boot devices: 2

FreeBSD/armv6 U-Boot loader, Revision 1.2
(gonzo@bsdbox, Fri Apr 19 18:52:33 PDT 2013)
DRAM:    128MB

Device: disk

Device: net

/boot/kernel/kernel data=0x3ae624+0x2128c syms=[0x4+0x71ca0+0x4+0x44075]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
Waiting for Ethernet connection... done.
Using DTB provided by U-Boot.
Kernel entry at 0x100100...
Kernel args: (null)
KDB: debugger backends: ddb
KDB: current backend: ddb
Copyright (c) 1992-2013 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.

I was asked to share details about my root-over-NFS setup so here they are. I decided to split how-to in two posts: server/kernel part and u-boot part.

Usual components in the setup are:

  • DHCP server
  • TFTP server
  • NFS server
  • NAT (optional)

DHCP server

I use net/isc-dhcp42-server as a server. Sample dhcpd.conf:

option root-opts code 130 = string; # NFS / mount options
log-facility local7;

subnet netmask {
        server-name "";
        option subnet-mask;
        option broadcast-address;
        option domain-name-servers;
        option domain-name "";
        option routers;

group {
        host pandaboard {
                hardware ethernet 0E:60:33:B1:46:01;
                filename "kernel.PANDA.bin";
                option root-path "/src/FreeBSD/nfs/armv6";
                option root-opts "nolockd";

        host rpi {
                hardware ethernet b8:27:eb:f6:08:83;
                filename "ubldr";
                option root-path "/src/FreeBSD/nfs/rpi";
                option root-opts "nolockd";

Config is pretty self-explanatory. I use google’s nameserver but you can change it to your very own DNS server. Difference between various filename “…” will be explained later.

dhcpd should be enabled in rc.conf(5)


TFTP server

TFTP server provides access to all files described in filename “…” options so it’s better to keep them together. By default it’s /tftpboot directory but I have whole drive dedicated to FreeBSD development environment and mounted under /src/FreeBSD mountpoint. So I keep everything there and my TFTP server root is /src/FreeBSD/tftpboot. TFTP server is standard FreeBSD’s one and config line in inetd.conf(8) looks like:

tftp    dgram   udp     wait    root    /usr/libexec/tftpd      tftpd -l -s /src/FreeBSD/tftpboot

inted should be enabled in rc.conf(5)


NFS Server

NFS server is not just one daemon but several services combined. So rc.conf(5) part of config looks like this:


Filesystems that are exported via NFS listed in exports(5). Mine contains following:

# Mind mount points obj and nfs are different
/usr/ports -maproot=0 -network
/src/FreeBSD/head /src/FreeBSD/nfs/rpi /src/FreeBSD/nfs/armv6 /src/FreeBSD/nfs/am335x -maproot=0 -network

Note that you can join several directories into one line only if they belong to the same mount point.


If you’re planning on building ports on the device – you’ll need internet access on it. All my devices are restricted to one LAN with laptop acting as a gateway. I use pf(4) for NATing. Config:


nat on $ext_if from $rede to any -> ($ext_if)

and rc.conf(5)



Kernel config

FreeBSD kernel should be properly configured in order to be suitable for mounting root over NFS:

options         NFSCL
options         NFSCLIENT # NFS v3
options         NFS_ROOT
options         BOOTP_NFSROOT
options         BOOTP_COMPAT
options         BOOTP
options         BOOTP_NFSV3
options         BOOTP_WIRED_TO=ue0

BOOTP_WIRED_TO value is SoC-specific. If you do not have full control over your DHCP server (e.g. it’s cable modem) and can’t specify root-path/root-opts you still can hardcode root location by removing BOOTP_NFSROOT and adding

options         ROOTDEVNAME=\"nfs:192.168.10:/src/FreeBSD/nfs/rpi\"


Depending on your boot sequence installation consists of one or two steps.

Normal system installation, e.g.:

sudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC installworld
sudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC distribution

And installing kernel copying kernel to tftpboot directory:

sudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC installkernel
cp /src/FreeBSD/nfs/rpi/boot/kernel/kernel /src/FreeBSD/tftpboot/kernel.RPI 

In some cases you’d want to use kernel.bin instead of kernel (more on it in next post) so second step would look like

sudo -E make TARGET_ARCH=armv6 DESTDIR=/src/FreeBSD/nfs/rpi -DDB_FROM_SRC KERNEL_EXTRA_INSTALL=kernel.bin installkernel
cp /src/FreeBSD/nfs/rpi/boot/kernel/kernel.bin /src/FreeBSD/tftpboot/kernel.RPI.bin

And if you’re going to use ubldr, there is no need to copy installed kernel anywhere.

More details on different types of binaries and boot process in the next post

Last few weeks I’ve been acting as a reviewer for Ganbold Tsagaankhuu’s port of FreeBSD for Cubieboard so in order to provide more valuable input and less naysaying I decided to get A10-based device to test his changes. So I ordered Hackberry from I’m not great fan of pushing SD cards back and forth so first thing I do with my SoCs is get them netbooting. That’s where fun begins.

Long story short – I had to get latest official u-boot, merge network driver (sunxi_wemac) from hno’s u-boot and add some GPIO magic to emac initialization. Namely – configure pin H19 (emac_power) as function 1 and set its value to 1. Only then I got net-related commands working properly.

If you’re interested in building your own bootable SD card: fetch these files. uEnv.txt and boot.scr are tailored to my needs so you might want to change them. does all the job, just make sure you use proper device name for SD card.