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 10.0.0.30
set netmask 255.255.255.0
set serverip 10.0.0.10
set gatewayip 10.0.0.1
set bootdelay 0
saveenv

This sets the board's address to 10.0.0.30/24. 10.0.0.1 is the router to the other networks. The tftp command will now use tftp from host 10.0.0.10 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
bootdelay=0
baudrate=115200
download_baudrate=115200
ls=fatls ide 0
nuke_env=protect off BFBFE000 BFBFffff; erase BFBFE000 BFBFffff
autoload=n
ipaddr=10.0.0.31
gatewayip=10.0.0.1
netmask=255.255.255.0
serverip=10.0.0.16
fbsd=tftp a800000 kernel.octeon1-32; bootoctlinux a800000 numcores=1
fbsd_cf=fatload ide 0 a800000 kernel.imp; bootoctlinux a800000 numcores=1
coremask_override=0xffff
numcores=16
stdin=serial
stdout=serial
stderr=serial

Environment size: 1274/8188 bytes
Octeon ebt3000# run fbsd
octeth0: Down 10Mbs Half duplex, (port 16)
Using octeth0 device
TFTP from server 10.0.0.16; our IP address is 10.0.0.31
Filename 'kernel.octeon1-32'.
Load address: 0xa800000
Loading: octeth0: Up 100Mbs Half duplex, (port 16)
########################
done
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
Config1=0xbe3303da
Config3=0x80
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)
mem:
nfslock: pseudo-device
null:
nexus0:
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.
SIOCSTIFFLAGS UP/Running
Starting Network: lo0 rgmx0 rgmx1 rgmx2 rgmx3.
lo0: flags=8049 metric 0 mtu 16384
options=3
inet 127.0.0.1 netmask 0xff000000
rgmx0: flags=8843 metric 0 mtu 1500
options=3
ether 00:0f:b7:10:1b:32
inet 10.0.0.31 netmask 0xffffff00 broadcast 10.0.0.255
media: Ethernet autoselect
rgmx1: flags=8802 metric 0 mtu 1500
options=3
ether 00:0f:b7:10:1b:33
media: Ethernet autoselect
rgmx2: flags=8802 metric 0 mtu 1500
options=3
ether 00:0f:b7:10:1b:34
media: Ethernet autoselect
rgmx3: flags=8802 metric 0 mtu 1500
options=3
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)

login:

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.

AsiaBSDCon 2009

I just presented a paper at AsiaBSDCon 2009 on the FreeBSD/mips status. There's a lot going on with the FreeBSD/mips project these days. You can find out most of the details from my paper, which is available in letter or a4 format.

In summary, there's a number of new ports underway. There's Cavium Octeon, Atheros 7xxx/9xxxx, RMI Au1xxxx and a couple others.

AsiaBSDCon is always fun. There's many Japanese developers that don't get a chance to go to other conferences who I only get to see in Japan. This conference allows me to see them, as well as talk to them to see what they are using BSD in general, and FreeBSD specifically. The Japanese have often lead the way in many areas, and seeing their current projects is very interesting.

Also, I could cut and paste large parts of my paper here, but I'm not sure of the value of doing that. Can people that have strong opinions leave feedback on this issue.

Alchemy Au1550 status update

I'm in the very early stages of bringing FreeBSD/mips on the Alchemy Au1550. Plat'Home was kind enough to put an OpenMicroServer into my hands for the port. After months of sitting idle, I've started putting the board to use again. I test booted my first kernel tonight. It is still early days, but I thought I'd mention that I'd committed the very preliminary code to the project/mips tree in svn.

As an aside, the FreeBSD/mips main development has moved from the so-called "mips2" tree in perforce to the projects/mips tree in svn. This move allows us to more easily share the work in progress mips ports that people have been asking for in the past. We'll see how well this works out and see if theory matches reality or not.

DLink DIR-615 Rev C1

Today I saw that Office Depot had a DIR-615 on sale for $40.00. It was a new hardware revision: C1. I took a chance that it was a new non-Ubimax based router. I'm glad I did, at least so far.

The router is based around the Atheros AR9130 CPU. This is MIPS based, so there's a good chance that I'll be able to put FreeBSD onto it. We'll see how it goes.

I'll report more when I get a chance to examine the RAM and Flash parts, as well as map out the serial port to see what is reported there. Stay tuned.

More CardBus fixes

After I committed my previous set of CardBus fixes, reports came in about interrupt storms, first with 16-bit cards, and later with 32-bit cards. These have been corrected in my latest fixes. We always act the CSTS interrupt when we see it. In addition, I've changed the acking of the 16-bit ExCA register to only happen when there's a "R2" or 16-bit card in the slot. Otherwise we now skip it. Hopefilly, this will help the shared interrupt case as well by eliminating some PCI bus cycles...

The CSTS bit is interesting. It is the least well documented bit in the CardBus standard. It is unclear when it fires from reading the standard, but seems to be related to the card finishing its reset sequence. How this differs from the power-up interrupt, I'm not sure. I think we could further optimize the bring up of CardBus cards with it.

In addition, I noticed there's a READY bit in the ExCA CSC register. We're currently doing busy waits to bring up the cards, including a couple of millisecond long DELAYs. I'll have to look into the prospect of using that interrupt to get around these issues there.

Finally, I'm looking in earnest at the Alchemy Au1550 CPU for the OpenMicroServer port I'm doing. I've noticed that it uses a 16-bit PC Card interface. Maybe I'll finally need to rewrite the old PCIC driver from OLDCARD to make use of it (snagging the exca routines to make that easier). The OpenMicroServer has a CF card attached to it.

gxemul update

Oleksandr Tymoshenko posted a patch to gxemul that allows FreeBSD/mips to boot on it.

I've committed it to the gxemul port. So now if you have gxemul 0.4.6.5_1 or later, you can run FreeBSD/mips, the MALTA kernel. I'll post a howto and a pointer to a image in a few days.

FreeBSD/mips updated

Here's an update in status to the FreeBSD/mips tree. David O'Brien has been working through issues one at a time to get things building, primarily getting gcc support merged in. After learning from David that more patches were needed than were in my blog, I spent some time collapsing changes from p4 into the main tree. I've updated my patches, and confirmed they work.

First, you can find the patches from my FreeBSD drop box. These patches are 42k right now. This is from my tree that I pulled at revision 183198, taken at 3:30pm MDT September 19th, 2008, for the nit-pickers out there. At this level, I'm able to apply the patch, do a buildworld and all the kernels except SENTRY5 build. To build things:

% svn update
% fetch http://people.freebsd.org/~imp/MipsSvn.diff
% patch -p0 < MipsSvn.diff
% setenv TARGET mips
% setenv MAKEOBJDIRPREFIX /tmp/$LOGNAME/obj
% make buildworld
% make buildkernel KERNCONF={ADM5120,IDT,MALTA,QEMU}

I've just done the build testing at this point. Stay tuned in the coming days for how to setup a qemu or gxemul image and how to run this in emulated. I hope to get instructions for how to deal with real hardware a little bit after that. Right now the ADM5120 kernels are a little too big for the hardware that I have and it will take some time to sort out.

Hopefully we'll have these last 42k of patches into the tree in the coming weeks. I'll keep everybody posted. There are some additional fixes in p4 as well on top of this which I'm still sorting out, but those should be going in as well.

FreeBSD embedded (mips, powerpc, arm) update

The last week or so has show a spike up in FreeBSD embedded platform work. Fixes for mips and powerpc have gone into the tree. Support for a new ARM platform is getting ready to be committed. FreeBSD/mips is almost self-hosting in the svn tree (it has been in the p4 tree for some time). FreeBSD/powerpc and FreeBSD/arm continue to mature.

Thanks to a flurry of activity over the weekend by David O'Brien, the number of patches needed for FreeBSD/mips has been reduced to a set for libpam and for binutils. David cleaned up the diffs for gcc and pushed them into the tree in a manner that allows for easier upstream committing.

In addition, David has cleaned up a number of dangling nits in the build. This is the result of a slight mismatch between p4 and the code in FreeBSD's svn tree. Oleksandr Tymoshenko has looped back most of these changes into p4, and is working on resolving the conflicts that were generated. Once this is sorted out, Oleksandr or myself will generate a new set of diffs and go for the final push into the tree.

I'm looking forward to having a good base for FreeBSD/mips in the tree. I've been busy with a number of other projects and haven't given it the time that I really want to give.

On the PowerPC side of the ledger, Marcell Moolenaar and Rafal Jaworowski have been polishing uboot boot loader support in the FreeBSD/powerpc subversion tree. In addition, some bug fixes to and code polishing of the low level Book E PowerPC support have been committed. Many of these improvements were obtained from Semihalf consulting.

On deck to be committed soon is support for Marvell's Orion NAS chips. This code has been in perforce for a while now and is nearly ready for the FreeBSD tree. I'll keep everybody posted when that happens. I hope to have my DLINK DIR-615 Rev A1 working by then with this code, but time has been tight and there's already too many different projects afoot in my life.

Mid august mips status update

Just wanted to jot out a quick status update on FreeBSD/mips.

A few weeks ago, diffs were sent out for review. The 6 patches are now down to three. gcc.diff, binutils.diff and pam.diff remain uncommitted.

pam.diff (now pam3.diff) has been receiving feedback from DES and others and is getting close. The first iteration was really far away from being commit quaility, but the last iteration may be the one that goes in.

gcc.diff has received feedback recently. Gonzo and I are in the process of digesting and understanding the feedback. We hope to produce a revised patch shortly, as there are a number of minor issues.

binutils.diff has had no comments. One person volunteered to look at it and commit it, but so far we're still waiting for feedback to make the patch better, or for it to be committed. If we don't hear anything one way or the other, I'll don my flame resistant suit and push it into the tree. There's really no issues with the patch that I can see. What is going to be a challenge is doing the vendor import of a few upstream files. Hopefully the volunteer will pull through and I won't have to learn how to do this in the new svn world. :-)

All the other diffs have been committed to the tree. It was gratifying to get positive feedback on them all, since I was worried more of them would have maintainer timeouts.

You can see the current set of patches in gonzo's patch directory. Grab only the latest pam patch there. The cddl.diff patch should be removed shortly, as I just committed it.

Had I been paying closer attention, I'd have written all this up for the FreeBSD status report.

MIPS Diffs

Although FreeBSD/mips has been committed to the tree, a few stragglers haven't been pushed into the tree for various reasons. Oleksandr Tymoshenko and I have been honing them down and have just published a set for review.

If you'd like to try FreeBSD/mips out, you can grab these patches from Oleksandr's directory. There's four diffs included. Please send any feedback to arch@freebsd.org.

Minor mips reorg and plans for the future

In trying to bring the MIPS tree more into line with idealized FreeBSD practices, I've moved the SoC directories up one level in the hierarchy. Future changes will make it easier to define different boards, as well as stylizing these sorts of things across different CPU architectures. I need this for the Plat'Home OpenMicroServer work I've started on, so I'll use that to drive these changes.

For the curious, I've moved mips/mips32/adm5120 -> mips/adm5120, likewise with the idt, malta, and sentry5 directories. While all of these were, strictly speaking, mips32 CPUs, having them in their own subdirectory doesn't make a lot of sense. There's never going to be so many of them that having an extra layer of indirection is going to help. Also, mips32 is ambiguous. Does it mean the MIPS ISA known as MIPS32 and MIPS32r2? Does it mean that the ports are running in 32-bit mode? It wasn't clear where a 32-bit kernel for a mips64 processor would live. Also, the idt parts aren't completely mips32 compliant in a couple of minor details. Is that non-compliance enough to move them elsewhere?

The next set of changes will try to tease apart the boot loader environment from the SoC that it is running on. While many SoCs have their own bootloader, often times one may also run uboot on the same hardware. In addition, things like uboot are used in many different platforms, so duplicating that code will grow tiresome.

Once the boot loader stuff is better abstracted, the next set of problems will be how to create a system that can run on multiple different boards of the same SoC. At first, this will be statically compiled, but eventually it will be dynamic.

Another key component of this work, whose overall goal is to make it easier to add board support to FreeBSD embedded platforms, will be an overhaul of the hints system. While it can be made to work, there are some practical problems it solves poorly that are desirable to have solved better. For example, it has no good way to tie attributes or parameters to hardware. Today, one can only tie them to a driver instance, which itself can be tied to hardware.

Finally, the last planned component in this work is a simplification of creation of busses with attributes and fixed or semi-fixed children. You can't have variants of hints loaded today that say "If I'm running on a AT91RM9200, use this set, but if I'm runnning on an AT91SAM9620 use this other set of hints" to enumerate the busses. This makes it hard to achieve the dynamic selection of boot code to run needed to allow kernels to boot on a variety of boards.

Most of this is low-level code janitor stuff. However, it is code janitor stuff that's needed and will be important to FreeBSD's success in the future.

Plat'Home provides OpenMicroServer

Plat'Home has generously shipped me an OpenMicroServer. Plat'Home has been doing Emebedded things for years in Japan. They used to have the coolest store to go visit in Akihabara, but that recently closed and now they are expanding their markets internationally through the web. I have fond memories of buying my first HappyHackingKeyboard there almost a decade ago...

So what is an OpenMicroServer? It is a ruggedized router with extra features to allow it to operate in a wider range of environments than just a router. It has DIO pins for control and monitoring. There's a console serial port, as well as an extra serial port. There's three multicolored LEDs as well. It operates over an extended temperature range. Inside there's a CF slot in case the built in flash is insufficient for your needs. Oh, and I almost overlooked the pair of USB 2.0 ports.

Under the hood there's an MIPS cpu inside the box, which is why they send it to me. I've started working on FreeBSD/mips support for it. There's a RMI Alchemy™ au1550 400MHz powering this box with 128MB RAM and 16MB Flash. It supports 3 ethernet ports. 1 10/100 port that also supports POE (to get power over the ethernet) and 2 that are 10/100/1000 gigE ports.

The only bad thing I can say about it is that it ships with Linux preinstalled... :-)

You can find more information about the specs here. Or general information about Plat'Home here.

Stay tuned for updates on how the port is going.

More mips support code committed

This weekend, I've committed more mips support code. Everything except for the tool chain is now in the tree. The tool chain will be pushed in over the next week or so. I have to verify that some changes I remember having to make to the tool chain are compatible with the tool chain that's in the FreeBSD repository. When everything has been pushed into the tree, I'll enable it as part of the make universe target.

FreeBSD/mips is starting to get attention from other FreeBSD developers now that it is in the tree. Alan Cox has started to audit the Mips pmap, for example. This should help FreeBSD/mips transition to the next level of support.

Many changes are still needed for the mips port. We need to audit the basic libc functions to make sure that we haven't stubbed anything out that's going to bite us in the future. We need to look to see if there's anything that can be refactored from the 3 different embedded platforms in the tree today (powerpc, arm and mips). Better documentation and porting to new chips/boards would help us to make things more portable.

FreeBSD/mips entering the tree

I've started committing FreeBSD/mips to the tree. It includes support for the ADM5120 SoC, a generic MIPS 4Kc in a Malta board, the IDT RC32434 (found on RB533) and preliminary support for the Broadcom Sentry 5 series of CPUS. It will likely be a few days before it is all in the tree and buildable. There's a number of issues that are cropping up as I'm pushing the code into the tree that weren't apparent until after the commits and merges back into p4. In addition, support for another platform is delayed pending approval to commit.

Look for more news, how-tos, etc in the days and weeks to come.