Author Archives: gonzo

Work in Progress: LCD driver for AM335x evaluation module

I’m trying to wrap up some project I started working on quite some time ago and this is first chunk of clean-up.

Patch contains:

  • Kernel config for AM335x EVM
  • dts file for AM335x EVM with TFT panel info
  • LCD controller driver with some functionality missing: only 24/32 bit depth and only TFT mode is supported
  • Really simple PWM driver. LCD backlight is controlled through eCAS submodule of PWMSS0 module.

I tested it only on evaluation module, although I think with proper panel/pinmux configuration it should work with BeagleBone’s LCD caps too.
Parts missing: adjusting clock to proper pixel frequency, proper allocation of framebuffer memory.

FDT driver skeleton generator

Writing new driver for FDT-based device always involves several simple steps:

  • writing generic newbus driver skeleton
  • Checking for compatibility of node in probe routine
  • Allocate memory/IRQ resources in attach routine

I can’t say for other developers but I just copy existing driver, remove all device-specific stuff and rewrite generic stuff. Which is less time-consuming then writing it from scratch but time-consuming it is. Being huge fan of automation of any kind I decided to let computer do all this dumb work and leave creative part (copy-pasting registers definition from spec to code) to myself. the result is this script.

Developer feeds driver description in YAML format to the script and gets driver skeleton that requires minimal amount of editing to get it compiled. Driver description includes author name, prefix for macroses, prefix for newbus method-functions, FDT compatibility string, driver name and number of IRQ/MEMORY resources. A minute saved is a minute earned.

YAML example:

AUTHOR: Oleksandr Tymoshenko <[email protected]>
PREFIX: am335x_pwm
MACRO_PREFIX: PWM
DRIVER: am335x_pwm
FDT_COMPATIBLE: ti,am335x-pwm
IRQ_RESOURCES: 0
MEM_RESOURCES: 4

Netbooting ARM/MIPS devices: ubldr

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

Netbooting ARM/MIPS devices: kinds of kernel and u-boot

U-Boot is a boot loader. Its task is to get kernel into memory and pass control to it. I will cover only parts of it related to netboot.

kernel or kernel.bin

But before we start loading something we need to know what to load. In previous post I mentioned that there are kernel, kernel.bin, and ubldr files. Let’s get into details. First of all: ubldr requires its own post. So there will be one more covering just ubldr. Now kernel and kernel.bin.

kernel is ELF executable. It means that it’s a self-contained file with all the information required to layout its bits in memory. e.g.: this data in file should be copied to address A, and N bytes at address B should be set to zero, code intry point is address X. All this auxiliary information is stored alongside to raw code and data. U-boot (or any other bootloader) reads it, lays out data/code accordingly and passes control to entry point. U-Boot’s command for it is bootelf.

Now, bootelf or ELF support in general is not always available in boot loaders. In this case we load ELF on host machine. Technically it’s called “convert to binary format” but essentially what objcopy utility does is it simulates loading of ELF file into memory and dumps memory region from the lowest address that belongs to loaded executable to the highest one into the kernel.bin file. No auxiliary information is saved – only raw code and data. Without this information it’s users responsibility to point which address this memory dump should be loaded at and where to start execution.

That’s theory in a nutshell. Back to practice.

U-Boot

Network initialization routine depends on the board you’re working with. If the ethernet card connected to board over USB (like on Raspberry Pi or Pandaboard) you might need to initialize USB first:

U-Boot> usb start
(Re)start USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found
       scanning usb for ethernet devices... 1 Ethernet Device(s) found

At this point you can either get network settings via DHCP or set them manually.
Manual control over network is performed by setting U-Boot environment variables:

U-Boot> setenv ipaddr 192.168.10.21
U-Boot> setenv netmask 255.255.255.0
U-Boot> setenv gatewayip 192.168.10.1

DHCP also provides information about TFTP server and boot file, we can set them manually too:

U-Boot> setenv bootfile kernel
U-Boot> setenv serverip 192.168.10.1

And now load it

U-Boot> tftpboot 0x8000

and boot

U-Boot> bootelf 0x8000

By default tftpboot and bootelf would use loadaddr env variable if it’s set so you can combine last two commands to

U-Boot> setenv loadaddr 0x8000
U-Boot> tftpboot
U-Boot> bootelf

With DHCP everything above is combined into three commands:

U-Boot> setenv loadaddr 0x8000
U-Boot> dhcp
U-Boot> bootelf

If you’re booting ELF loadaddr can be any valid address because bootelf will relocate kernel to proper location. Valid range for addresses depends on the board in use.

With kernel.bin though you have to specify specific value as a loadaddr. Usually it’s KERNPHYSADDR option in kernel config file for ARM and KERNLOADADDR value for MIPS. U-Boot commands sequence would look like:

U-Boot> setenv bootfile kernel.bin
...
U-Boot> setenv loadaddr 0x00100000
U-Boot> dhcp
U-Boot> go 0x00100000

uImage, ubldr

This is basic stuff I’ve been using for several years in my development environment. There are more options though: u-boot application images and bootm command and ubldr. Former is well-documented on Internet and about latter I’ll post some information soon.

Netbooting ARM/MIPS devices: server setup

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 192.168.10.0 netmask 255.255.255.0 {
        server-name "cinderella.bluezbox.com";
        server-identifier 192.168.10.1;
        option subnet-mask 255.255.255.0;
        option broadcast-address 192.168.10.255;
        option domain-name-servers 8.8.8.8;
        option domain-name "bluezbox.com";
        next-server 192.168.10.1;
        option routers 192.168.10.1;
}

group {
        host pandaboard {
                hardware ethernet 0E:60:33:B1:46:01;
                fixed-address 192.168.10.90;
                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;
                fixed-address 192.168.10.91;
                filename "ubldr";
                option root-path "/src/FreeBSD/nfs/rpi";
                option root-opts "nolockd";
        }
}

Config is pretty self-explanatory. I use google’s 8.8.8.8 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)

dhcpd_enable="YES"

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)

inetd_enable="YES"

NFS Server

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

rpcbind_enable="YES"
rpc_statd_enable="YES"
rpc_lockd_enable="YES"
nfs_server_enable="YES"
mountd_enable="YES"

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 192.168.10.0/16
/src/FreeBSD/head /src/FreeBSD/nfs/rpi /src/FreeBSD/nfs/armv6 /src/FreeBSD/nfs/am335x -maproot=0 -network 192.168.10.0/16

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

NAT

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:
/etc/pf.conf(5)

ext_if=em0
rede="{192.168.0.0/16}"

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

and rc.conf(5)

gateway_enable="YES"

pf_enable="YES"
pf_rules="/etc/pf.conf"
pf_flags=""

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\"

Installation

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

Netbooting Hackberry A10 (Allwinner A10)

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 miniand.com. 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. mksd.sh does all the job, just make sure you use proper device name for SD card.

Accessing GPIO from Perl, Python, and Ruby

I started this smallish project to overcome coder’s block and original idea was to implement it in only one scripting language. I chose Python as I believed it had most clear API but then I decided to throw in Perl and Ruby as well. It was more exercise in building C extensions then in actual system programming but it was fun nonetheless. All three sub-projects lack proper documentation but there are examples that should be enough to get started.

Sources available on github.

Building image for Raspberry Pi: up to date version

Update 1: Add -DDB_FROM_SRC to install targets
Update 2: Add user “pi” with password “raspberry”

It’s been a while since I posted original build instruction and a lot has change. Here is new version of it with some explanations:

All code has been moved to HEAD. freebsd-pi repository on github serves only historical purpose and I guess will be removed at some point in future. So in order to build image you need sources for -head

svn co svn://svn.freebsd.org/base/head

TARGET_CPUTYPE is dropped to in favor of TARGET_ARCH=armv6. U-Boot, firmware files and boot process were upgraded too. Current boot chain is as follows:

  • Pi is powered up and loads firmware files
  • Firmware loads FDT blob defined in config.txt as device_tree variable at address defined as device_tree_address and fixes up fields like memory size, clock frequency and MAC address
  • Firmware loads u-boot and passes control to it
  • U-boot loads boot.scr and executes it
  • Default boot.scr loads ubldr(loader(8)-compatible implementation built over U-Boot API) and passes control
  • ubldr checks FreeBSD partition for /boot/loader.rc, loads it, the loads /boot/kernel/kernel and passes control to it
  • loader.rc should contain “fdt addr 0×100″ command. It will pass FDT blob filled in step #2 to kernel

So updated build script will look something like this:

#!/bin/sh
set -e

# Change this
export GPU_MEM=128
export PI_USER=pi
export PI_USER_PASSWORD=raspberry
export SRCROOT=/src/FreeBSD/head
export MNTDIR=/mnt
export MAKEOBJDIRPREFIX=/src/FreeBSD/obj
export IMG=/src/FreeBSD/obj/bsd-pi.img

export TARGET_ARCH=armv6
export MAKESYSPATH=$SRCROOT/share/mk
export KERNCONF=RPI-B

if [ -z "$MNTDIR" ]; then
        echo "MNTDIR is not set properly"
        exit 1
fi

KERNEL=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/$KERNCONF/kernel
UBLDR=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/boot/arm/uboot/ubldr
DTB=`realpath $MAKEOBJDIRPREFIX`/arm.armv6/`realpath $SRCROOT`/sys/$KERNCONF/bcm2835-rpi-b.dtb

make -C $SRCROOT kernel-toolchain
make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel
make -C $SRCROOT MALLOC_PRODUCTION=yes 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

rm -f $IMG
dd if=/dev/zero of=$IMG bs=128M count=8
MDFILE=`mdconfig -a -f $IMG`
gpart create -s MBR ${MDFILE}

# Boot partition
gpart add -s 32m -t '!12' ${MDFILE}
gpart set -a active -i 1 ${MDFILE}
newfs_msdos -L boot -F 16 /dev/${MDFILE}s1
mount_msdosfs /dev/${MDFILE}s1 $MNTDIR
fetch -q -o - http://people.freebsd.org/~gonzo/arm/rpi/freebsd-uboot-20130201.tar.gz | tar -x -v -z -C $MNTDIR -f -

cat >> $MNTDIR/config.txt <<__EOC__
gpu_mem=$GPU_MEM
device_tree=devtree.dat
device_tree_address=0x100
disable_commandline_tags=1
__EOC__
cp $UBLDR $MNTDIR
cp $DTB $MNTDIR/devtree.dat
umount $MNTDIR

# FreeBSD partition
gpart add -t freebsd ${MDFILE}
gpart create -s BSD ${MDFILE}s2
gpart add -t freebsd-ufs ${MDFILE}s2
newfs /dev/${MDFILE}s2a

# Turn on Softupdates
tunefs -n enable /dev/${MDFILE}s2a
# Turn on SUJ with a minimally-sized journal.
# This makes reboots tolerable if you just pull power on the BB
# Note:  A slow SDHC reads about 1MB/s, so a 30MB
# journal can delay boot by 30s.
tunefs -j enable -S 4194304 /dev/${MDFILE}s2a
# Turn on NFSv4 ACLs
tunefs -N enable /dev/${MDFILE}s2a

mount /dev/${MDFILE}s2a $MNTDIR

make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC installkernel
make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC installworld
make -C $SRCROOT DESTDIR=$MNTDIR -DDB_FROM_SRC distribution

echo 'fdt addr 0x100' > $MNTDIR/boot/loader.rc

echo '/dev/mmcsd0s2a / ufs rw,noatime 1 1' > $MNTDIR/etc/fstab

cat > $MNTDIR/etc/rc.conf <<__EORC__
hostname="raspberry-pi"
ifconfig_ue0="DHCP"
sshd_enable="YES"

devd_enable="YES"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
__EORC__

cat > $MNTDIR/etc/ttys <<__EOTTYS__
ttyv0 "/usr/libexec/getty Pc" xterm on secure
ttyv1 "/usr/libexec/getty Pc" xterm on secure
ttyv2 "/usr/libexec/getty Pc" xterm on secure
ttyv3 "/usr/libexec/getty Pc" xterm on secure
ttyv4 "/usr/libexec/getty Pc" xterm on secure
ttyv5 "/usr/libexec/getty Pc" xterm on secure
ttyv6 "/usr/libexec/getty Pc" xterm on secure
ttyu0 "/usr/libexec/getty 3wire.115200" dialup on secure
__EOTTYS__

echo $PI_USER_PASSWORD | pw -V $MNTDIR/etc useradd -h 0 -n $PI_USER -c "Raspberry Pi User" -s /bin/csh -m
pw -V $MNTDIR/etc groupmod wheel -m $PI_USER
PI_USER_UID=`pw -V $MNTDIR/etc usershow $PI_USER | cut -f 3 -d :`
PI_USER_GID=`pw -V $MNTDIR/etc usershow $PI_USER | cut -f 4 -d :`
mkdir -p $MNTDIR/home/$PI_USER
chown $PI_USER_UID:$PI_USER_GID $MNTDIR/home/$PI_USER

umount $MNTDIR
mdconfig -d -u $MDFILE


VCHIQ drivers work again

I synced both vchiq-freebsd and userland to latest and greatest.

As I mentioned earlier – OS compatibility shim was removed from upstream sources so I had to create Linux KPI implementation layer which turned out not that awful task because I managed to reuse a lot of code from Max Khon’s DAHDI port. I had to implement (in somewhat hackish fashion) kthread API, re-implement semaphores support using condvar and mutex in order to get _interruptible part of API working properly and create dumb implementation of rather small subset of Linux list.h API.

With latest code I got pretty much all demos in hello_pi working except hello_jpeg(crashes system) and hello_encode(didn’t test). The most exciting bit for me was watching H.264 video playing on Raspberry Pi in hello_video demo. Network throughput still sucks so I had to copy file to tmpfs partition in order to get smooth playback though.

If you want to test VCHIQ – in addition to sources you’ll need latest firmware files. For demos you’ll also have to install freetype2 and manually hack Makefile.include in hello_pi. I’m planning to create ports/packages for both drivers and userland some time next week.

On the related note: Aleksandr Rybalko got XOrg working on Efika MX Smartbook so FreeBSD/Pi will get graphic interface soon :)

Packages(*) for Rasberry Pi(**)

I finally got around to setting up experimental pkgng repo for ARM in order to share packages with other ARM developers and users who feel adventurous. And man, was it simple. I have pandaboard that is super-fast comparing to Raspberri Pi so I use it for building ports. There were several installed so I just had to generate packages for them using

pkg create -a

command. Then I uploaded all newly generated files to the server, grabbed packages built and shared by Stephen Hurd, removed duplicates with older versions and generated repo.txz by issuing

pkg repo

command.

Then on a raspberry pi I created pkg.conf in which I pointed to my newly created “repo”, updated metada and installed git:

# echo 'PACKAGESITE: http://people.freebsd.org/~gonzo/arm/pkg/' > /usr/local/etc/pkg.conf
# pkg update
# pkg install git

Pi took some time to push files back and forth over NFS (I use NFS root on my devices) but eventually I got git with all dependencies up and running.

!!! Please note that packages are not officially provided by FreeBSD Project. They’re only for experimental purpose so install them at your own discretion !!!

Thanks to bapt@ for working on this great tool.

* – some
** – And for other ARM devices

VCHI driver, part 2

Some time ago I announced port of VCHI driver to FreeBSD. Since then it was re-licensed as BSD/GPL and I had high hopes for bringing it into the tree as a part of sys/contrib. This weekend I finally got around to it but turned out things had changed for worse. VCHI driver used to have this neat OS-abstraction wrapper, so overall porting process was quite simple: implement synch primitives, physical pages management, driver-specific initialization and you’re done. But… The layer was lost with driver update in October. The reason for it – OS compatibility shims are banned from Linux mainline kernel.

So now I face two options: create complete port of VCHI driver by replacing linux-specific parts with freebsd-specific code. Or create Linux compatibility shims and try to keep sources as close as possible to upstream. I’m going to try latter approach in order to minimize maintenance work. If it doesn’t work out – I’ll fall back to the former. But with any of these approaches code difference with upstream will be too significant to go to contrib tree and most likely driver will be distributed as a port.

FreeBSD/armv6: what’s new and exciting?

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!

FreeBSD/armv6 in QEMU

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:

Build

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)

Run QEMU

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 

Caveats

  • 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

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.

FreeBSD on Pi: more stuff

Long overdue update on how the things are going with FreeBSD on Raspberry Pi. We've made some good progress so far:

  • Hans Petter Selasky fixed low-speed interrupt endpoints problem which means we have working USB keyboard now
  • GPIO driver by Luiz Otavio O Souza. So now you can blink OK LED (gpioctl -f /dev/gpioc0 -t 16). Not the most productive activity though.
  • Kernel now obtains information about display resolution, memory layout, MAC address from firmware
  • Framebuffer/syscons support added
  • Some stability fixes for SDHCI/li>
  • Initial port of VCHIQ interface (vchiq-freebsd)
  • Port of userland libraries (userland)

Overall stability and performance is still a problem, but it's what we're going to work on next.

And if you missed previous post: freebsd-pi is no more, use HEAD from FreeBSD subversion repository.

Boot process has been changed and now it looks like: firmware → uboot → ubldr → kernel. So old script for building image is no longer relevant. Here is new one. Tim Kientzle's scripts collection for building images for BeagleBone, Pandaboard and RPi uses more systematic approach but RPi part hasn't caught up to latest boot chain changes yet. Once it is up to date I suggest using Tim's scripts.

Building FreeBSD does not require any additional tools but if you want VideoCore bits you'll need following packages installed:

  • devel/cmake
  • devel/git
  • devel/gmake

If you don't need VideoCore binaries, just comment build_videocore and install_videocore calls. This script will also install OpenGL ES hello_triangle demo to /root folder. To run it run perform following steps:

# cd /root
# kldload vchiq
# ./hello_triangle.bin

I tried to build Qt5 with OpenGL ES support, but build choked on compile-time assert triggered by FreeBSD using OABI. Good news though: EABI work is almost done, so there is a fat chance we'll see Qt5 with eglfs backend running on FreeBSD in near future.

You can try pre-built image (124Mb, MD5 sums). Login is "root", no password. Use dd to write it to SD card. U-Boot seems to be somewhat finicky about SD cards, so if you get "** Unrecognized filesystem type **" message try another card. First boot might take some time because sshd will generate keys. U-Boot output goes to serial port and monitor, FreeBSD console messages go only to monitor, but by the end of boot sequence you should get login prompt on serial.

This image is a snapshot of work in progress and by no means a production system.

UPDATE

** Unrecognized filesystem type ** U-Boot issue seems to be more widespread then I thought. I'm working on it.

U-Boot env variables iterator

Ran into it recently and decided to post here just in case someone will have this problem too. Do not define both CONFIG_LOADADDR and loadaddr in CONFIG_EXTRA_ENV_SETTINGS. Otherwise environment variables enumeration API(API_ENV_ENUM) will loop forever.

FreeBSD/Pi update

So, here is status update on the progress:

- freebsd-pi github repo has been merged to HEAD and should be considered only as a reference from now on.
- I repackaged freebsd-pi-uboot-20120806-sd.tar.gz so tar should not complain about uid/guid stuff
- Hans Peter Selasky and Alexander Rybalko added host mode support for DWC OTG driver
- Problem with tty on serial port has been fixed. Use 3wire.115200 type for ttyu0 in /etc/ttys

Still a lot of stuff to do though.
P.S.
I'll post updated build script later.

projects/armv6 branch is no more

ARMv6/AMRv7 support is now in main FreeBSD codebase.

New goodies:

  • General ARMv6/ARMv7 kernel bits (pmap, cache,
    assembler routines, etc...)
  • ARM SMP support
  • VFP/Neon support
  • ARM Generic Interrupt Controller driver
  • Improved thread-local storage for cpus >=ARMv6
  • Two new values for TARGET_ARCH: armv6 and armv6eb
  • Driver for SMSC LAN95XX and LAN8710A ethernet controllers
  • Marvell MV78x60 support (multiuser, ARMADA XP kernel config)
  • TI OMAP4 and AM335x support (multiuser, no GPU or graphics
    support, kernel configs for Pandaboard and Beaglebone)
  • LPC32x0 support (multiuser, frame buffer works with SSD1289
    LCD controller.Embedded Artists EA3250 kernel config)
  • Barebone Nvidia Tegra2 support (timers, interrupts and UART.
    No kernel config)

I'm going to re-create Raspberry Pi port off HEAD and start merging least intrusive bits back to the tree.

FreeBSD/Pi setup HowTo

Took some time but it seems we're there too :)

Alexander Rybalko, who works on USB drivers for the platform got remote telnet shell to the device: http://pastebin.com/6NqQLWD2

Having fixed serial console for userland applications (two lines change) and after some tweaking of SDHCI driver I got access to multiuser shell too: multiuser.txt
Still not usable for putting together distros but stable enough for those who are willing to get their hands dirty with kernel side.

Here is short how to on getting FreeBSD boot on Raspberry Pi:

Get sources:

git clone git://github.com/gonzoua/freebsd-pi.git
cd freebsd-pi
git checkout rpi

Fetch u-boot files from here: freebsd-pi-uboot-20120806-sd.tar.gz.

Build sources and create SD card image with script like this:
#!/bin/sh
set -e

export TARGET_ARCH=arm
export SRCROOT=/usr/home/gonzo/Sources/freebsd-pi
export MAKEOBJDIRPREFIX=/usr/home/gonzo/Sources/obj
export KERNCONF=RPI-B
KERNEL_BIN=`realpath $MAKEOBJDIRPREFIX`/arm.arm/`realpath $SRCROOT`/sys/$KERNCONF/kernel.bin

make -C $SRCROOT kernel-toolchain
make -C $SRCROOT KERNCONF=$KERNCONF WITH_FDT=yes buildkernel
make -C $SRCROOT TARGET_CPUTYPE=armv6 MALLOC_PRODUCTION=yes buildworld

IMG=bsd-pi.img
rm -f $IMG
dd if=/dev/zero of=$IMG bs=128M count=8
MDFILE=`mdconfig -a -f bsd-pi.img`
gpart create -s MBR ${MDFILE}
gpart add -s 32m -t '!12' ${MDFILE}
gpart add -s 896m -t '!12' ${MDFILE}
gpart set -a active -i 1 ${MDFILE}
newfs_msdos -L boot -F 16 /dev/${MDFILE}s1
newfs /dev/${MDFILE}s2
mount_msdosfs /dev/${MDFILE}s1 /mnt
tar -x -v -z -C /mnt -f freebsd-uboot-sd.tar.gz
cp $KERNEL_BIN /mnt
umount /mnt
mount /dev/${MDFILE}s2 /mnt
make -C $SRCROOT DESTDIR=/mnt installworld
make -C $SRCROOT DESTDIR=/mnt distribution

# Minimal config
echo 'hostname="freebsd-pi"' > /mnt/etc/rc.conf
echo '/dev/mmcsd0s2 / ufs rw 1 1' > /mnt/etc/fstab

umount /mnt
mdconfig -d -u $MDFILE

dd image to SD card, insert it to Raspberry Pi and check serial port for some output

There is also U-Boot configuration that uses dhcp/tftp method by default freebsd-pi-uboot-20120806-netboot.tar.gz. It's more suitable for kernel hacking but requires environment setup.