Booting instructions for FreeBSD on Cavium Octeon

Here's a quick note on how to net boot the Cavium EBT3000 board running uboot. The Cavium kernel is still a work in progress as I restore all the fixes I made to an earlier version of this code that I was unable to release.

You'll need to break into the boot sequence for this board. Usually that's just hitting ^C before uboot starts to load the kernel.

Once you have a uboot prompt, similar to below, you'll be ready to start to fix the environment for netbooting.
U-Boot 1.1.1 (Development build) (Build time: Jan 26 2007 - 14:06:35)

EBT3000 board revision major:4, minor:0, serial #: xxxxxxxxx
OCTEON CN38XX-NSP revision: 1, Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)
DRAM: 2048 MB
Flash: 8 MB
IPD backpressure workaround verified, took 14 loops
Clearing DRAM........ done
BIST check passed.
Net: octeth0, octeth1, octeth2, octeth3
Bus 0 (CF Card): OK

ide 0: Model: SanDisk SDCFB-1024 Firm: Rev 0.00 Ser#: X0308 20050726142909
Type: Removable Hard Disk
Capacity: 977.4 MB = 0.9 GB (2001888 x 512)

Octeon ebt3800#

It couldn't be easier to setup for netbooting. You'll need to setup an tftp server. I had to install the FreeBSD port from net/freebsd-tftpd to get a working tftpd, since there appears to be some issues with the stock FreeBSD tftpd. Once I had that, I set different addresses like so:
set ipaddr
set netmask
set serverip
set gatewayip
set bootdelay 0

This sets the board's address to is the router to the other networks. The tftp command will now use tftp from host to get the named file. saveenv makes these setting permanent. I usually reboot at this point to make sure that the settings took.

Next, you'll need to know how to load a FreeBSD kernel. This is also fairly straight-forward, although finding the right addresses took a bit of guesswork. You are tftping the ELF kernel to a chunk of memory. The bootoctlinux command then takes that image and copies it to the right place and starts executing it. So you have to be sure whereever you load it doesn't clash with uboot's memory use or with where the kernel will ultimately reside.
tftp a800000 kernel.octean1-32
bootoctlinux a800000 numcores=1

As with any u-boot platform, it can often be useful to define macro commands. I did the following:
set fbsd 'tftp a800000 kernel.octeon1-32; bootoctlinux a800000 numcores=1'
so that I don't have to keep typing it over and over. I can just type
run fbsd
to run my next test.

The Cavium port is in a state of flux right now. The latest status as I am preparing this to be published is that there's an interrupt problem that's causing the serial port to be non-responsive after going to multi-user (eg, the login: prompt) and also the network stops responding. Also, I have to comment out the enableintr() call in mips_vector_init around line 365 of sys/mips/mips/machdep.c. I'm trying to hammer these issues out, and I think they are related. Earlier versions of the code worked with earlier versions of FreeBSD, so I'm sure this is just a shift in interfaces that needs to be accounted for.

Here's the latest slightly trimmed log from a boot:

U-Boot 1.1.1 (Development build) (Build time: Jan 26 2007 - 14:06:35)

EBT3000 board revision major:4, minor:0, serial #: xxxxxxxxx
OCTEON CN38XX-NSP revision: 1, Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)
DRAM: 2048 MB
Flash: 8 MB
IPD backpressure workaround verified, took 32 loops
Clearing DRAM........ done
BIST check passed.
Net: octeth0, octeth1, octeth2, octeth3
Bus 0 (CF Card): OK

ide 0: Model: 512MB CKS Firm: 2N3-0925 Ser#: 2435E7C34A52930007
Type: Removable Hard Disk
Capacity: 491.6 MB = 0.4 GB (1006992 x 512)
Octeon ebt3000# print
ls=fatls ide 0
nuke_env=protect off BFBFE000 BFBFffff; erase BFBFE000 BFBFffff
fbsd=tftp a800000 kernel.octeon1-32; bootoctlinux a800000 numcores=1
fbsd_cf=fatload ide 0 a800000 kernel.imp; bootoctlinux a800000 numcores=1

Environment size: 1274/8188 bytes
Octeon ebt3000# run fbsd
octeth0: Down 10Mbs Half duplex, (port 16)
Using octeth0 device
TFTP from server; our IP address is
Filename 'kernel.octeon1-32'.
Load address: 0xa800000
Loading: octeth0: Up 100Mbs Half duplex, (port 16)
Bytes transferred = 3370489 (336df9 hex)
argv[2]: numcores=1
ELF file is 32 bit
Skipping non LOAD program header (type 0x6)
Skipping non LOAD program header (type 0x3)
Skipping non LOAD program header (type 0x70000000)
Allocated memory for ELF segment: addr: 0x1000000, size 0x295a60
Loading .text @ 0x81000000 (2064384 bytes)
Loading .MIPS.stubs @ 0x811f8000 (16 bytes)
Loading .rodata @ 0x811fa000 (33248 bytes)
Loading .reginfo @ 0x812021e0 (24 bytes)
Loading .rodata.str1.4 @ 0x812021f8 (189300 bytes)
Loading set_sysctl_set @ 0x8123056c (3496 bytes)
Loading set_sysinit_set @ 0x81231314 (1684 bytes)
Loading set_sysuninit_set @ 0x812319a8 (952 bytes)
Loading .interp @ 0x81231d60 (13 bytes)
Loading .dynsym @ 0x81231d70 (78320 bytes)
Loading .dynstr @ 0x81244f60 (72163 bytes)
Loading .hash @ 0x81256944 (35984 bytes)
Loading set_kdb_dbbe_set @ 0x8125f5d4 (8 bytes)
Loading set_modmetadata_set @ 0x8125f5dc (288 bytes)
Loading set_cons_set @ 0x8125f6fc (8 bytes)
Loading .data @ 0x8125f704 (116476 bytes)
Loading set_pcpu @ 0x8127be00 (3136 bytes)
Loading .got @ 0x8127ca40 (5296 bytes)
Loading .rld_map @ 0x8127def0 (4 bytes)
Loading .sdata @ 0x8127def4 (12 bytes)
Clearing .bss @ 0x8127df00 (97120 bytes)
## Loading Linux kernel with entry point: 0x81000000 ...
Bootloader: Done loading app on coremask: 0x1
Boot Descriptor Ver: 6 -> 1/2 CPU clock: 500MHz
Dram: 2048 MB Board Type: 2 Revision: 4/0
Octeon Chip: 0 Rev 0/0 Mac Address 00.0F.B7.10.1B.32 (14)
octeon_dram == 80000000
reduced to ram: 2048 MBReal memory bytes is 7ffff000
phys_avail[0] = 1296000 phys_avail[1] = fffffff
realmem_bytes is now at 5ffff000
Next block of memory goes from 20000000 to 7ffff000

Total DRAM Size 0x80000000
Bank 0 = 0x 1296000 -> 0x FFFFFFF
Bank 1 = 0x20000000 -> 0x7FFFF000

physmem: 0x6ed69Cache info:
picache_stride = 4096
picache_loopcount = 8
pdcache_stride = 128
pdcache_loopcount = 64
cpu0: Cavium processor v1.0
MMU: Standard TLB, 32 entries
L1 i-cache: 4 ways of 64 sets, 128 bytes per line
L1 d-cache: 64 ways of 1 sets, 128 bytes per line
Physical memory chunk(s):
0x1296000 - 0xfffefff, 248942592 bytes (60777 pages)
0x20000000 - 0x7fffefff, 1610608640 bytes (393215 pages)
Maxmem is 0x7ffff000
KDB: debugger backends: ddb
KDB: current backend: ddb
hz=100 cyl_per_hz:250000 cyl_per_usec:250 freq:250000000 cyl_per_hz:2500000 cyl_per_sec:250000000
Copyright (c) 1992-2010 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.
FreeBSD 9.0-CURRENT #141 r202986:202997M: Mon Jan 25 20:07:07 MST 2010
imp@paco-paco.bsdimp.com:/tmp/imp/be-obj/mips/pe/imp/svn/head/sys/OCTEON1-32 mips
real memory = 1859555328 (1815972K bytes)
Physical memory chunk(s):
0x013ab000 - 0x0fffefff, 247808000 bytes (60500 pages)
0x20000000 - 0x7d830fff, 1568870400 bytes (383025 pages)
avail memory = 1813180416 (1729MB)
nfslock: pseudo-device
Compact flash found in bootbus region 3 (8 bit).
rgmii0: on nexus0
rgmx0: Ethernet address: 00:0f:b7:10:1b:32
rgmx0: type (null), full duplex
rgmx1: Ethernet address: 00:0f:b7:10:1b:33
rgmx1: type (null), full duplex
rgmx2: Ethernet address: 00:0f:b7:10:1b:34
rgmx2: type (null), full duplex
rgmx3: Ethernet address: 00:0f:b7:10:1b:35
rgmx3: type (null), full duplex
rgmii0: [FILTER]
cf0: on nexus0
clock0: on nexus0
clock0: [FILTER]
obio0 at mem 0x1 flags 0x1 on nexus0
uart1: on obio0
uart1: [FILTER]
uart1: fast interrupt
uart1: console (115200,n,8,1)
uart0: on obio0
uart0: [FILTER]
uart0: fast interrupt
uart0: console (115200,n,8,1)
Device configuration finished.
Reducing kern.maxvnodes 117045 -> 100000
Timecounter "MIPS32" frequency 250000000 Hz quality 800
Timecounters tick every 10.000 msec
GEOM: cf0: partition 2 does not start on a track boundary.
GEOM: cf0: partition 2 does not end on a track boundary.
GEOM: cf0: partition 1 does not start on a track boundary.
GEOM: cf0: partition 1 does not end on a track boundary.
GEOM: cf0s2: geometry does not match label (64h,32s != 16h,63s).
Trying to mount root from ufs:cf0s2a
WARNING: / was not properly dismounted
warning: no time-of-day clock registered, system time will not be set accurately
start_init: trying /sbin/init
Setting hostuuid: 1c99760e-1dd2-11b2-bd6a-00156dc12838.
Setting hostid: 0xb0f278c1.
No suitable dump device was found.
Entropy harvesting:.
Starting file system checks:
t_delta 16.010fac783006c1a6 too long
/dev/cf0s2a: 11100 files, 256973 used, 150946 free (426 frags, 18815 blocks, 0.1% fragmentation)
Mounting local file systems:.
t_delta 15.fece5003dd62224a too short
Setting hostname: ebt3000.
Starting Network: lo0 rgmx0 rgmx1 rgmx2 rgmx3.
lo0: flags=8049 metric 0 mtu 16384
inet netmask 0xff000000
rgmx0: flags=8843 metric 0 mtu 1500
ether 00:0f:b7:10:1b:32
inet netmask 0xffffff00 broadcast
media: Ethernet autoselect
rgmx1: flags=8802 metric 0 mtu 1500
ether 00:0f:b7:10:1b:33
media: Ethernet autoselect
rgmx2: flags=8802 metric 0 mtu 1500
ether 00:0f:b7:10:1b:34
media: Ethernet autoselect
rgmx3: flags=8802 metric 0 mtu 1500
ether 00:0f:b7:10:1b:35
media: Ethernet autoselect
Starting devd.
Creating and/or trimming log files.
Starting syslogd.
/etc/rc: WARNING: Dump device does not exist. Savecore not run.
ELF ldconfig path: /lib /usr/lib /usr/lib/compat
Clearing /tmp (X related).
Updating motd:.
Starting cron.
Starting inetd.
Starting background file system checks in 60 seconds.

Tue Jan 26 02:07:16 UTC 2010

FreeBSD/mips (ebt3000) (ttyu0)



DLINK DIR-615 REV C1 Redux

After hitting a dry hole with my DIR-615 REV A1, I thought I'd try the DIR-615 REV C1 that I have. It has an Atherose AR9130 in it. This is very similar to the AR7130 that the RouterStation I have running, and I thought it would be a simple matter to use uboot to netboot this code.

Again, I was mistaken. There's no way to break into the boot sequence for this device. The best I can hope for is to create a compressed image that's < 1MB and blow it into the FLASH partition for the kernel under linux. That would work out OK, if I had known good image to start from. Alas, I don't. And there doesn't appear to be an accessible JTAG header that I can use to write a new u-boot. Linux seems to protect u-boot from being overwritten as well.

But the biggest issue of all is that the FLASH is only 4MB in size. It would take some doing to get everything shrunk down that small. The DIR-615 REV A1 at least had 8MB of FLASH, which is doable. Maybe I'll perfect the kernel for the DIR-615 REV A1 on the Marvell eval board I have. Looking at the Linux sources, the deltas between these kernels are small and inconsequential for bootstrapping purposes. Hmmm, the Linux kernel just has support for the DNS-323, now that I look closely, but the required bits of hacking after I have a known good kernel doesn't seem huge. Plus, if I could get one good kernel on the box, then I could put a better uboot on there which would support the network for netbooting...

If I ever make good images for these boards, I'll be sure to post pointers to them here.

DLINK DIR-615 REV A redux

Yesterday I burned a couple of hours playing with the DIR-615 REV A1 that I have had for ages. FreeBSD runs on the Marvell Orion SoC that's inside it now and I thought I'd netboot the box and try to put together an image that can replace my firewall since this little box uses less power and my firewall doesn't need to do *THAT* much.

Unfortunately, it appears as if the network was purposely crippled on this box. Not disabled entirely, but crippled to not work. Sometimes you can get packets out, but generally there's a huge packet loss rate that makes pinging impossible, let alone netbooting.

Talking to other folks that have worked in this area, it appears that this was a deliberate attempt to discourage others from running alternative operating systems on the box.

Since the box will still boot to Linux, there's hope that one can bootstrap the FreeBSD installation from there. When I get some time again, I'll be pursuing that avenue. Maybe I can find the JTAG header for this board and reflash uboot that way, since debugging a new kernel can be difficult to get right in one shot on hardware the kernel has never run on before...

I had planned on publishing instructions for netbooting the thing, but alas, it appears that isn't possible.


Post-mortum on projects/mips branch

Greetings to one and all. As you have read elsewhere, I recently merged all the changes from the projects/mips branch onto head. In other reports, I've made cryptic reference to the branch being damaged. I thought I'd go through all the problems we encountered running this development effort on the projects/mips branch.

First, we created the branch in the normal way:
svn cp svn+ssh://svn.freebsd.org/base/head svn+ssh://svn.freebsd.org/base/projects/mips

and then started committing to it. So far so good.

Then it came time to merge in changes from head. Here is where we made our first mistake. We merged just the kernel changes, and not the entire tree. The next time we merged the entire tree. The effect of this sequence meant that the changes between the creation and the first merge in the rest of the tree (outside of src/sys) were lost. I don't know if this is the result of a buggy svn client, or if they are a fundamental flaw in svn. So when it came time to collapse the results back into head, we couldn't just do a reverse integration, or even a more conventional merge.

Next, we pulled in pieces of the projects/mips tree into head, either by hand or with the svn merge command. Doing both was a mistake, I think. Although svn coped with later merged from head into projects/mips fairly well, occasionally we'd have issues to sort out.

So, when it came time to merge everything back into head, we were left with a number of difficult choices. We opted to copy the new files/directories in the repo (to preserve the history) and merge patches by hand with svn log entries. The latter went really well. There were no problems with it apart from the odd fuzz and .rej file to sort out (no different than a normal merge). The former, however, causes a lot of problems.

First, it created svn:mergeinfo entries on the files I copied over. This conflicts with the project's "merge everything from sys" edict. This happened because I did the copy in the server rather than the client (which was an attempt to preserve history). It was a simple matter to delete these entries when it was brought to my attention.

Next, somehow we created the files on the branch without the required svn:keywords, svn:eol-style and svn:mime-type properties. This caused problems when we went to commit changes to these files. The precommit complained, at this point, that the files lacked svn:keywords, and we had to add $FreeBSD$ by hand (since the copy didn't complaint that they were lacking). Also, I didn't discover these problems on my own. Other sharp-eyed individuals saw the problems and reported them to me.

Finally, since I did the copies on the server, there was no way to batch them. When I copied a directory, I got the whole directory. When I copied a file, I got the file. Each one generated a commit message.

I'm unsure what other damage was lurking in the projects/mips tree, but the lack of properties, the inability to easily use merge info and the missing commits lead me to the conclusion that it was easier to abandon the branch and create a new branch if needed in the future.

The mips team plans to create more branches, that are more for special purposes, that will be shorter lived in the future. We have no further plans to have one monolithic mips branch that acts as a staging ground for commits into head.


Hack to allow automatic wired/wireless failover with lagg on FreeBSD

For years I've had a love/hate relationship with my wireless card. On the one hand, it allows me to roam. On the other I like being able to plug into the wired Ethernet when I'm sitting at my desk since I get better throughput and lower latency. So for years, I just loaded and unloaded kernel modules to make dhclient (and/or wpa_supplicant) do its thing. This changed the IP address of my box, which messed up NFS mounts until I went back to the old way.

Recently, Josh Paetzel came up with a way to use lagg to do automatic failover. Inspired by the lagg man page, he created a number of rc.conf lines that would do this automatically. Xin Li and I refined the trick a bit. To completely integrate this into FreeBSD, I suppose that the rc.d scripts would need to be enhanced to automatically generate these lines when appropriate. However, the hack is so easy to do now, I'm going to share it with you here. Xin Li is writing up a longer description of how to set this up for the handbook. Let's say you have a ath0 wireless interface, and a re0 wired interface, just add the following to your /etc/rc.conf file:

  • ifconfig_re0="up"

  • ifconfig_ath0=`ifconfig re0 ether`

  • ifconfig_ath0="ether ${ifconfig_ath0##*ether }"

  • wlans_ath0="wlan0"

  • ifconfig_wlan0="WPA"

  • cloned_interfaces="lagg0"

  • ifconfig_lagg0="laggproto failover laggport re0 laggport wlan0 DHCP"

This bit of code brings up re0, programs ath0 with the ethernet MAC address of re0 (so your MAC doesn't change when you switch over), creates a wlan0 interface from ath0, causes lagg0 to be created and configured to do the fail over.

Hope this tip is useful...

Revision at Wed Jan 13 16:00:00 UTC 2010:

Note: "ifconfig re0 ether" doesn't work in versions prior to 8.0. The following should fix it, but I don't have a system to test it on:
  • ifconfig_ath0=`ifconfig re0 ether`

  • ifconfig_ath0="${ifconfig_ath0##*ether}"

  • ifconfig_ath0="ether ${ifconfig_ath0%%inet*}"

  • This sequence avoids using grep, awk and/or sed to accomplish this (and thus touch /usr too early for systems where / and /usr are on different partitions).

    Also corrected the bwi0 reference in the feedback...

    Revision at Mon Jan 18 23:00:00 UTC 2010:
    Corrected () vs {} confusion in the above...

    FreeBSD/mips updated

    The base/projects/mips branch has been merged into base/head. The merge is complete and the sanity tests have passed. The code has booted on both a Ubiquiti RouterStation (big endian) as well as in gxemul (little endian).

    The branch lived for one year, minus a day, and accumulated much work:
    • A new port to the Atheros AR71xx series of processors. This port supports the RouterStation and RouterStation PRO boards from Ubiquiti. Other boards should work with minimal tweaking. This port should be considered as nearing production quality, and has been used extensively by the developers. The primary author of this port is Oleksandr Tymoshenko (gonzo@freebsd.org).

    • A new port to the sibyte BCM1250 SoC on the BCM91250 evaluation board (aka SWARM). This port is reported to be stable, but this hardware is a little old and not widely available. The primary author of this port is Neel Natu (neel@freebsd.org). Only one core is presently supported.

    • A port, donated by Cavium, to their Octeon and Octeon plus series of SoC (CN3xxx and CN5xxx). This code is preliminary, supporting only a single core right now. It has been lightly tested on the CN3860 evaluation board only in 32-bit mode. Warner Losh (imp@freebsd.org) has been driving the efforts to get this code into the tree.

    • A port, donated by RMI, to their XLR series of SoCs. This port is single core only as well. The code reaches multi-user but should be considered beta quality for the moment. Randal Stewart (rrs@freebsd.org) has been driving the efforts to integrate this into the tree.

    • Preliminary support for building a mips64 kernel from this source base. More work is needed here, but at least two kernels successfully build in 64-bit mode (OCTEON1 and MALTA64).

    • Very early support for N32 and N64 ABIs

    • Support for booting compressed kernels has been added (gonzo@).

    • Improved support for debugging

    • Improved busdma and bus_space support

    • Many bug fixes

    • More types of MIPS cores are recognized

    • Expanded cache handling for newer processors

    • Beginning of a port to the alchemy au1XXX cpus is present but experimental.

    • Work on SMP is underway to support multicore processors like the sibyte, Octeon and XLR processors.

    I'm sure there are minor items I've forgotten. If so, please forgive any omission on my part...

    The branch had been updated incorrectly several times over the past year, and the damage was too much to repair. We've retired the branch and will do further mips development in "head" for the time being. If you have a checked out tree, the suggested way to update the projects/mips tree you have is to do a "svn switch svn://svn.freebsd.org/base/head" in that tree.

    I'd like to thank everybody that has contributed time, code or hardware to make FreeBSD/mips better.

    We are still investigating how feasible merging all this work into stable/8 will be, as it represents a huge leap forward in code stability and quality.

    As development proceeds, I'll keep posting updates. In addition, I hope to have some mini "how-to" wiki pages done for people that want to try it out.