Category Archives: embedded

New Device Tree Compiler

This week, I imported a new device tree compiler, dtc(1). This is the tool that is used to translate between different representations of a Flattened Device Tree (FDT), a way of representing boot-time configuration information. The FDT contains more or less the same information as an OpenFirmware device tree, for example the locations of memory-mapped peripherals, reserved sections of RAM, interrupt routing information, and so on.

FreeBSD/ARM makes a lot of use of FDTs, as they’re the standard way of getting information from the bootloader. They are used in two ways. The ideal way is for the bootloader to provide the tree to the kernel at boot time. This allows a single kernel to be used with multiple SoCs. Alternatively, the device tree can be compiled into the kernel.

The device tree in both cases is in the form of a Device Tree Blob (DTB), a binary representation of the tree. The ‘flattened’ in the name comes from the fact that the tree is represented in a linear structured format, like HTML, with explicit delimiters for starts and ends of child nodes, rather than in a format with pointers between elements. The other representation, the Device Tree Source is a human-readable tree using braces to delimit children and is rather similar to the OpenStep property list format or JSON.

The device tree compiler is responsible for converting between these formats. In the FreeBSD tree, we have a number of DTS files that represent supported platforms where the bootloader doesn’t provide the DTB. During the build process, the DTB is generated and linked into the kernel.

Unfortunately, the existing tool was released under the GPL. We try to minimise the amount of GPL’d code installed by default, and intend to remove all of it by 10.0, so dtc was not installed unless your target platform used it (a bit silly, as you want to use it on your host platform when doing embedded device development). The new tool is a (BSD-licensed) from-scratch rewrite that I did over Christmas. It shares no code with the original, but works as a drop-in replacement in our build system.

It is now used by default, although the old GPL’d tool will remain available as an option for a while until I’m confident that we aren’t breaking out-of-tree dtc users. So, if you’re using FDTs and don’t have the DTS in the tree, please test it. Otherwise, this is just another step on the way to a fully GPL-free base system.

Rearranging the deck chairs in the ARM port

Recently, I've been trying to catch up with some of the technical debt that the FreeBSD/arm port has accumulated. Some of that technical debt was my fault, of course, but some of it wasn't. I don't really much care whose fault things were, but I would like to get things cleaned up. Some of these are paths not taken. Some are porting shims that never got properly connected. There's also some features that were poo-poo-ed by some (including me) years ago that seem to make more sense now.

None of this stuff is terribly sexy. Some of it will be addressed by the summer of code project that's working its way through some of the maze of twisty passages in initarm() that are subtly different between the different boards for no good reason.

We have no common place for boot loader code. Some arm ports do use a common routine to fake up just enough metadata that debugging and other symbols work. Some arm ports assume a full /boot/loader is present. However, there's no common facility for getting information from via the Linux boot protocol, nor is there any provisions for having multiple boards supported by a single kernel. There's no uniform interface to get this information that might be passed in by other means. There's no real way for a board to get control early enough to get at meta-data a custom boot loader might pass in.

The first big thing that I'd like to comment on is a small change to the interface between locore.S' _start routine and the first port-specific code in initarm. I've preserved the first 4 registers that were passed in on boot to _start(). Before, there'd be no way to access the Linux ATAGs, for example, by a port since these are passed in as arg 3. To allow for future expansion, I'm just passing in one structure now.

In the coming weeks, I'll be implementing routines to parse these arguments based on standard boot protocols, while allowing customization for special needs.

In the coming months, I plan to expand our support for having multiple boards based on a single Atmel SoC. Once I have the one at a time SoC code working, I hope to get multiple SoCs working in one kernel. While the extra 'bloat' isn't optimal for many users, the convenience of being able to boot one kernel for installation, or trying out the system, is a feature that's been much requested. I've already eliminated the need to have a compiled-in master clock frequency, with improved main clock detection with fallback for people using unconventional frequencies.

I'm also interested in sweeping into the tree many of the Atmel arm changes that have been accumulating in the PR database. Some of these will be easy to integrate, while others may be difficult due to drift from the original submission.

Once we get a good baseline, I hope to merge these changes into 9.x and 8.x. To date, the interfaces that have change have been purely internal ones we do not support. External users may experience some bumpy waves if they haven't been working to get their changes merged upstream. The more that you've submitted, the more I'm likely to go the extra mile to help smooth any transitions. With luck, 8.3 and 9.2 will both benefit from these efforts.

FreeBSD/arm -

I've just found out that FreeBSD/armv6 now runs on this:

http://www.embeddedartists.com/products/kits/lpc3250_kit.php

This is excellent news. There's also been some recent work to improve pandaboard support (TI-OMAP) focusing on pmap and SMP fixes.

I'm so very glad that the FreeBSD community is pushing this ARM project along. Yes, the armv6 branch is not very well named (it supports more recent ARM platforms, not just armv6 improvements) and I'm hoping this will all make it into FreeBSD-HEAD soon.

Oh god, so much wireless hardware..

Since I've started doing wireless development, people seem to be sending me more and more hardware. (I've also bought some stuff off of ebay too, so I'm partially to blame for this. :-)So there's this group of developers over in Europe/Russia who have been busy porting FreeBSD to a variety of wireless devices, but their work hasn't made it into the main FreeBSD tree (or been published at all in any public way.) I've been liaising with Aleksandr Rybalko to push their work into -HEAD in time for FreeBSD-9.0.So far this has included:

Support for the Ralink RT305x MIPS SoC, with initial peripheral support;
nvram2env, a way of importing the environment from various bootloaders (eg uboot) into the kernel environment;
geom_map, a GEOM module which describes the flash layout for fixed flash partitioning schemes (again like uboot, but it can be used for anything.)

There's a few other things coming up soon, such as support for one of the Broadcom MIPS SoCs, further peripheral support for the RT305x (including the embedded wireless MAC/radio) and other bits and pieces which will prove to be useful.It's been a pleasure working with them

Oh god, so much wireless hardware..

Since I've started doing wireless development, people seem to be sending me more and more hardware. (I've also bought some stuff off of ebay too, so I'm partially to blame for this. :-)

So there's this group of developers over in Europe/Russia who have been busy porting FreeBSD to a variety of wireless devices, but their work hasn't made it into the main FreeBSD tree (or been published at all in any public way.) I've been liaising with Aleksandr Rybalko to push their work into -HEAD in time for FreeBSD-9.0.

So far this has included:

Support for the Ralink RT305x MIPS SoC, with initial peripheral support;
nvram2env, a way of importing the environment from various bootloaders (eg uboot) into the kernel environment;
geom_map, a GEOM module which describes the flash layout for fixed flash partitioning schemes (again like uboot, but it can be used for anything.)

New FreeNAS beta snapshot released (r5648)

We've released the next beta snapshot of FreeNAS.

You can read the release notes for all the details.

Here's a highlight of the issues that we've fixed since the last beta (r5606):

Upgrades from prior FreeNAS 8 beta releases are now supported.
zfs creation failures have been fixed. The gui would indicate it succeeded, but you couldn't share it.
ufs creation failures have been fixed.
booting off USB or SCSI cdrom is now supported.
Many disk initialization errors that showed up as odd failures have been corrected.
lagg has been introduced.
Errors in the network screen have been corrected.
The storage wizard no longer says 'of X' when creating the storage unit. This eliminates the confusing 1 of 3 -> 2 of 2 dialog heading.
Improved compatibility with IE and Safari.
The installer has been streamlined.

Also, I was pleasantly surprised today when I logged in and found 19 comments from my last blog entry. I'm not used to so many, so hadn't been checking. I'll be checking more here. I'll also write a blog entry to address many of the issues raised in them.

You can download the latest from sourceforge.

New FreeNAS beta snapshot released (r5648)

We've released the next beta snapshot of FreeNAS.

You can read the release notes for all the details.

Here's a highlight of the issues that we've fixed since the last beta (r5606):

Upgrades from prior FreeNAS 8 beta releases are now supported.
zfs creation failures have been fixed. The gui would indicate it succeeded, but you couldn't share it.
ufs creation failures have been fixed.
booting off USB or SCSI cdrom is now supported.
Many disk initialization errors that showed up as odd failures have been corrected.
lagg has been introduced.
Errors in the network screen have been corrected.
The storage wizard no longer says 'of X' when creating the storage unit. This eliminates the confusing 1 of 3 -> 2 of 2 dialog heading.
Improved compatibility with IE and Safari.
The installer has been streamlined.

You can download the latest from sourceforge.

New FreeNAS Beta (r5606)

Just after the release of the first beta, a couple of serious problems came to life. As such, we've respun the release to fix these issues.

gmirror error displayed bogusly
the extremely long write times for disks
The lack of feedback during the installation (although with the significantly faster imaging, this is much less of an issue).
Default ownership and permission for Windows shares has been fixed
Shares are browseable by default now
The extra and redundant steps in the installer have been eliminated
The inconsistent menus in the installer have been made regular
A ZFS issue on reboot has been corrected
Multi-line config fields have been fixed
Problems with snmp have been resolve
proftpd's config file is now generated properly the second time
minor nits fixed in many places

You can find the release notes or the release. Stay tuned for more updates.

New FreeNAS Beta (r5606)

Just after the release of the first beta, a couple of serious problems came to life. As such, we've respun the release to fix these issues.

gmirror error displayed bogusly
the extremely long write times for disks
The lack of feedback during the installation (although with the significantly faster imaging, this is much less of an issue).
Default ownership and permission for Windows shares has been fixed
Shares are browseable by default now
The extra and redundant steps in the installer have been eliminated
The inconsistent menus in the installer have been made regular
A ZFS issue on reboot has been corrected
Multi-line config fields have been fixed
Problems with snmp have been resolve
proftpd's config file is now generated properly the second time
minor nits fixed in many places

You can find the release notes or the release. Stay tuned for more updates.

FreeNAS 8 Beta released

iXsystems is pleased to announced FreeNAS 8.0 Beta. FreeNAS 8.0 has undergone a complete rewrite. We've redesigned the GUI to be easier to use and extend. We've upgraded many technologies in the system for improved hardware support, faster I/O, better modularity, and easier upgrades. We trust that you'll find the system easier to use and, in time, much more feature rich than the current FreeNAS offering.The base system has migrated from FreeBSD 7.x and the m0m0wall build system to FreeBSD 8.1-RELEASE and NanoBSD. The system startup has migrated from the older php scripts to the standard FreeBSD rc.d boot system. We've pushed many of the bug fixes and system improvements back into FreeBSD.We've rewritten the GUI using Python and Django. We've completely removed the old php system. In addition to Django, we're using Dojango and Dojo to implement AJAX features. The new system is much more modular than the old system. We will use this modularity in a future version for easy integration of custom features into your FreeNAS box.The installer has been rewritten using pc-sysinstall, the future FreeBSD installation technology. The scripts have a similar feel to the old PHP scripts for users of the current system. The ISO now is only an installer. You can no longer run in live mode from a CDROM.The installation types have changed; there's no longer an embedded or full install, nor can the image be installed on a data disk. You must now install FreeNAS onto a dedicated device. FreeNAS supports USB flash, CompactFlash, hard drives, ssd or any other mass storage device supported by FreeBSD.FreeNAS 8.0 features ZFS version 14.FreeNAS 8.0 beta has retained the core functionality of a storage appliance. The media center features of the box have not been reimplemented in the core FreeNAS package. A media center add-on package will provide this functionality in the future. We've focused on creating a robust, easy-to-use, and extensible system. We're creating the base to allow other types of packages to be added, such as printer support, scanner support, or home automation. To help prioritize what current features are turned into packages in future FreeNAS releases, please visit http://support.freenas.org/ to provide feedback. Please add feature requests tickets. If a feature you would like to see in FreeNAS already has a ticket please just subscribe to it add a small comment, even if it's a "++." It will help us better judge and meet community needs.You can download FreeNAS from Source Forge and read all the release notes on our wiki.

FreeNAS 8 Beta released

iXsystems is pleased to announced FreeNAS 8.0 Beta. FreeNAS 8.0 has undergone a complete rewrite. We've redesigned the GUI to be easier to use and extend. We've upgraded many technologies in the system for improved hardware support, faster I/O, better modularity, and easier upgrades. We trust that you'll find the system easier to use and, in time, much more feature rich than the current FreeNAS offering.

The base system has migrated from FreeBSD 7.x and the m0m0wall build system to FreeBSD 8.1-RELEASE and NanoBSD. The system startup has migrated from the older php scripts to the standard FreeBSD rc.d boot system. We've pushed many of the bug fixes and system improvements back into FreeBSD.

We've rewritten the GUI using Python and Django. We've completely removed the old php system. In addition to Django, we're using Dojango and Dojo to implement AJAX features. The new system is much more modular than the old system. We will use this modularity in a future version for easy integration of custom features into your FreeNAS box.

The installer has been rewritten using pc-sysinstall, the future FreeBSD installation technology. The scripts have a similar feel to the old PHP scripts for users of the current system. The ISO now is only an installer. You can no longer run in live mode from a CDROM.

The installation types have changed; there's no longer an embedded or full install, nor can the image be installed on a data disk. You must now install FreeNAS onto a dedicated device. FreeNAS supports USB flash, CompactFlash, hard drives, ssd or any other mass storage device supported by FreeBSD.

FreeNAS 8.0 features ZFS version 14.

FreeNAS 8.0 beta has retained the core functionality of a storage appliance. The media center features of the box have not been reimplemented in the core FreeNAS package. A media center add-on package will provide this functionality in the future. We've focused on creating a robust, easy-to-use, and extensible system. We're creating the base to allow other types of packages to be added, such as printer support, scanner support, or home automation.

To help prioritize what current features are turned into packages in future FreeNAS releases, please visit http://support.freenas.org/ to provide feedback. Please add feature requests tickets. If a feature you would like to see in FreeNAS already has a ticket please just subscribe to it add a small comment, even if it's a "++." It will help us better judge and meet community needs.

You can download FreeNAS from Source Forge and read all the release notes on our wiki.

FreeNAS 8 — First alpha snapshots

My blog has been somewhat quiet lately. I've been busy with other things lately.The biggest of the other things is FreeNAS. iXsystems stepped up to the plate late last year when FreeNAS was going to become a Linux based platform.The iXsystems engineering team has moderized FreeNAS in a number of ways. We wanted a platform that was more extensible than the current m0m0wall-based framework allowed. We wanted to create a platform that could be expandable by modules (possibly not even written by us). We wanted to make it easier to upgrade the base FreeBSD release, as well as leverage more base FreeBSD technology that has been integrated into the system since FreeNAS was originally developed.We've migrated the build to be NanoBSD based. This allows us to leverage the embedded work that has gone into NanoBSD. It also allows us to push some of the features that are important to FreeNAS back into the base FreeBSD distribution. NanoBSD gives us the flexibility that we need. Since we're using the FreeBSD package system to add ports and packages, users will be able to add their own packages (we'll likely expand the basics to use the PBI's that PC-BSD produces for ease of installation). We're using the normal rc.d system, so upgrading is easier as well.On the GUI side we've moved to using django. This is a python-based front-end to sqlite3 which is extensible and easy to use. While we've kept things rather plain so far, we plan on jazzing things up a bit now that we have the basics working fairly well. Since the GUI is based on django, we'll be able to allow packages to hook into the GUI to present a united interface to the user.The GUI calls into a middleware layer that manages the services on the box. This middleware is responsible for generating updated config files, as well as starting, stopping and restarting daemons on the system. The same code generates the files at boot as well. Having all the configuration data in one database makes it easier to upgrade from release to release, since you don't have to merge your changes into the config files: the system takes care of that details.If you'd like to read about the nuts and bolts about trying out the latest snapshot, you can check out my forum post on the topic over at the FreeNAS forums.

FreeNAS 8 — First alpha snapshots

My blog has been somewhat quiet lately. I've been busy with other things lately.

The biggest of the other things is FreeNAS. iXsystems stepped up to the plate late last year when FreeNAS was going to become a Linux based platform.

The iXsystems engineering team has moderized FreeNAS in a number of ways. We wanted a platform that was more extensible than the current m0m0wall-based framework allowed. We wanted to create a platform that could be expandable by modules (possibly not even written by us). We wanted to make it easier to upgrade the base FreeBSD release, as well as leverage more base FreeBSD technology that has been integrated into the system since FreeNAS was originally developed.

We've migrated the build to be NanoBSD based. This allows us to leverage the embedded work that has gone into NanoBSD. It also allows us to push some of the features that are important to FreeNAS back into the base FreeBSD distribution. NanoBSD gives us the flexibility that we need. Since we're using the FreeBSD package system to add ports and packages, users will be able to add their own packages (we'll likely expand the basics to use the PBI's that PC-BSD produces for ease of installation). We're using the normal rc.d system, so upgrading is easier as well.

On the GUI side we've moved to using django. This is a python-based front-end to sqlite3 which is extensible and easy to use. While we've kept things rather plain so far, we plan on jazzing things up a bit now that we have the basics working fairly well. Since the GUI is based on django, we'll be able to allow packages to hook into the GUI to present a united interface to the user.

The GUI calls into a middleware layer that manages the services on the box. This middleware is responsible for generating updated config files, as well as starting, stopping and restarting daemons on the system. The same code generates the files at boot as well. Having all the configuration data in one database makes it easier to upgrade from release to release, since you don't have to merge your changes into the config files: the system takes care of that details.

If you'd like to read about the nuts and bolts about trying out the latest snapshot, you can check out my forum post on the topic over at the FreeNAS forums.

What is all the TBEMD stuff

I've been getting questions about what TBEMD means in my commits to FreeBSD head.First, I'll tell you the name. TBE stands for TARGET_BIG_ENDIAN. For the MIPS and ARM ports, it is an environment variable that you have to set to build these targets for big endian (otherwise they default to little endian). MD is Must Die. A few years ago, there was an action movie whose title was more memorable than the file "Romeo Must Die." So I just stole the name for this branch.So why must TARGET_BIG_ENDIAN die? It breaks things. For all the other platforms that FreeBSD supports, you just set TARGET and/or TARGET_ARCH to do cross builds. You know everything you need to know from the MACHINE and MACHINE_ARCH in the resulting image. In addition, the build system segregates things so you can build all the targets in one tree..But for mips and arm, you don't know what endian a binary is, the obj tree will collide if you try to build both little endian and big endian binaries at the same time. There's also other, more subtle issues. For example, TARGET_BIG_ENDIAN isn't set on big endian mips, so a native biuldworld tries to build little endian binaries (oops).So, mips will be moving to mipsel (for little endian) and mipseb (for big endian). Arm will move to arm (for little endian) and armeb (for big endian). You could fill an entire email archive with all the possible other names and why they are better or worse than these names. History, however, trumps all those arguments: these are the names used elsewhere and we're just following convention.Once tbemd is completely merged, you'll be able to build both endians of MIPS in the same object tree, for example, and all the other issues I've discovered. It also helps with new architectures as we move into powerpc64 (already merged) and mips64 (to be done after tbemd is collapsed). It will also mean we can have different packages for the different endians now.

What is all the TBEMD stuff

I've been getting questions about what TBEMD means in my commits to FreeBSD head.

First, I'll tell you the name. TBE stands for TARGET_BIG_ENDIAN. For the MIPS and ARM ports, it is an environment variable that you have to set to build these targets for big endian (otherwise they default to little endian). MD is Must Die. A few years ago, there was an action movie whose title was more memorable than the file "Romeo Must Die." So I just stole the name for this branch.

So why must TARGET_BIG_ENDIAN die? It breaks things. For all the other platforms that FreeBSD supports, you just set TARGET and/or TARGET_ARCH to do cross builds. You know everything you need to know from the MACHINE and MACHINE_ARCH in the resulting image. In addition, the build system segregates things so you can build all the targets in one tree..But for mips and arm, you don't know what endian a binary is, the obj tree will collide if you try to build both little endian and big endian binaries at the same time. There's also other, more subtle issues. For example, TARGET_BIG_ENDIAN isn't set on big endian mips, so a native biuldworld tries to build little endian binaries (oops).

So, mips will be moving to mipsel (for little endian) and mipseb (for big endian). Arm will move to arm (for little endian) and armeb (for big endian). You could fill an entire email archive with all the possible other names and why they are better or worse than these names. History, however, trumps all those arguments: these are the names used elsewhere and we're just following convention.

Once tbemd is completely merged, you'll be able to build both endians of MIPS in the same object tree, for example, and all the other issues I've discovered. It also helps with new architectures as we move into powerpc64 (already merged) and mips64 (to be done after tbemd is collapsed). It will also mean we can have different packages for the different endians now.

Embedded BSD

The latest issue of BSDMag is ready for download. The editorial theme this month is Embedded BSD and the authors include:

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 #: xxxxxxxxxOCTEON CN38XX-NSP revision: 1, Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)DRAM: 2048 MBFlash: 8 MBIPD backpressure workaround verified, took 14 loopsClearing DRAM........ doneBIST 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.30set netmask 255.255.255.0set serverip 10.0.0.10set gatewayip 10.0.0.1set bootdelay 0saveenv

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-32bootoctlinux 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 #: xxxxxxxxxOCTEON CN38XX-NSP revision: 1, Core clock: 500 MHz, DDR clock: 266 MHz (532 Mhz data rate)DRAM: 2048 MBFlash: 8 MBIPD backpressure workaround verified, took 32 loopsClearing DRAM........ doneBIST 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# printbootdelay=0baudrate=115200download_baudrate=115200ls=fatls ide 0nuke_env=protect off BFBFE000 BFBFffff; erase BFBFE000 BFBFffffautoload=nipaddr=10.0.0.31gatewayip=10.0.0.1netmask=255.255.255.0serverip=10.0.0.16fbsd=tftp a800000 kernel.octeon1-32; bootoctlinux a800000 numcores=1fbsd_cf=fatload ide 0 a800000 kernel.imp; bootoctlinux a800000 numcores=1coremask_override=0xffffnumcores=16stdin=serialstdout=serialstderr=serialEnvironment size: 1274/8188 bytesOcteon ebt3000# run fbsdocteth0: Down 10Mbs Half duplex, (port 16)Using octeth0 deviceTFTP from server 10.0.0.16; our IP address is 10.0.0.31Filename 'kernel.octeon1-32'.Load address: 0xa800000Loading: octeth0: Up 100Mbs Half duplex, (port 16)########################doneBytes transferred = 3370489 (336df9 hex)argv[2]: numcores=1ELF file is 32 bitSkipping 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 0x295a60Loading .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: 0x1Boot 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 == 80000000reduced to ram: 2048 MBReal memory bytes is 7ffff000phys_avail[0] = 1296000 phys_avail[1] = fffffffrealmem_bytes is now at 5ffff000Next block of memory goes from 20000000 to 7ffff000Total DRAM Size 0x80000000Bank 0 = 0x 1296000 -> 0x FFFFFFFBank 1 = 0x20000000 -> 0x7FFFF000physmem: 0x6ed69Cache info: picache_stride = 4096 picache_loopcount = 8 pdcache_stride = 128 pdcache_loopcount = 64cpu0: 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=0x80Physical memory chunk(s):0x1296000 - 0xfffefff, 248942592 bytes (60777 pages)0x20000000 - 0x7fffefff, 1610608640 bytes (393215 pages)Maxmem is 0x7ffff000KDB: debugger backends: ddbKDB: current backend: ddbhz=100 cyl_per_hz:250000 cyl_per_usec:250 freq:250000000 cyl_per_hz:2500000 cyl_per_sec:250000000Copyright (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 [email protected]:/tmp/imp/be-obj/mips/pe/imp/svn/head/sys/OCTEON1-32 mipsreal 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-devicenull: nexus0: Compact flash found in bootbus region 3 (8 bit).rgmii0: on nexus0rgmx0: Ethernet address: 00:0f:b7:10:1b:32rgmx0: type (null), full duplexrgmx1: Ethernet address: 00:0f:b7:10:1b:33rgmx1: type (null), full duplexrgmx2: Ethernet address: 00:0f:b7:10:1b:34rgmx2: type (null), full duplexrgmx3: Ethernet address: 00:0f:b7:10:1b:35rgmx3: type (null), full duplexrgmii0: [FILTER]cf0: on nexus0clock0: on nexus0clock0: [FILTER]obio0 at mem 0x1 flags 0x1 on nexus0uart1: on obio0uart1: [FILTER]uart1: fast interruptuart1: console (115200,n,8,1)uart0: on obio0uart0: [FILTER]uart0: fast interruptuart0: console (115200,n,8,1)Device configuration finished.Reducing kern.maxvnodes 117045 -> 100000Timecounter "MIPS32" frequency 250000000 Hz quality 800Timecounters tick every 10.000 msecGEOM: 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:cf0s2aWARNING: / was not properly dismountedwarning: no time-of-day clock registered, system time will not be set accuratelystart_init: trying /sbin/initSetting 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 shortSetting hostname: ebt3000. SIOCSTIFFLAGS UP/RunningStarting 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 autoselectrgmx1: flags=8802 metric 0 mtu 1500 options=3 ether 00:0f:b7:10:1b:33 media: Ethernet autoselectrgmx2: flags=8802 metric 0 mtu 1500 options=3 ether 00:0f:b7:10:1b:34 media: Ethernet autoselectrgmx3: flags=8802 metric 0 mtu 1500 options=3 ether 00:0f:b7:10:1b:35 media: Ethernet autoselectStarting 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/compatClearing /tmp (X related).Updating motd:.Starting cron.Starting inetd.Starting background file system checks in 60 seconds.Tue Jan 26 02:07:16 UTC 2010FreeBSD/mips (ebt3000) (ttyu0)login:

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#

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
[email protected]:/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.

Post-mortum on projects/mips branch

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.