 | Level: Intermediate Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net
13 Jun 2006 Having looked at Linux® and eCos support for the TAMS 3011 in the previous installments, Peter Seebach examines NetBSD support for it, which turns out to entail a certain amount of coding.
The TAMS 3011 system this series uses is built around the AMCC
PowerPC® 405GPr, which is a system-on-a-chip (SoC) design. Desktop systems are
typically built around separate, pluggable components which are
intended to allow for upgrades. For the embedded market, single-chip
designs offer substantial savings on materials and wiring, and
upgradability is less of a requirement. The only components you're
likely to need to upgrade are flash and RAM -- which are among the
components typically kept off-chip.
To users coming from a desktop environment, where the system board
contains multiple support chips which provide an environment for a
processor, it's a bit weird thinking of a processor which provides
nearly the entire system. For starters, the 405GPr includes the SDRAM
controller and an ethernet controller (although not the PHY physical
interface that will actually manipulate signals on the wire).
The all-in-one design of the 405GPr makes it comparatively easy to port
software between multiple boards based on this processor. While
different products using this processor might have different peripheral
hardware, such as the DP83816 ethernet controller on the TAMS 3011, the
core hardware stays the same. For instance, a great deal of the source
for ports of eCos, Linux, or even NetBSD to different evaluation boards
is shared. Note that this chip is closely related to the 405GP; the
primary difference is the range of clock speeds (133-266MHz for the
405GP, 266-400MHz for the 405GPr). Despite the higher clock speeds, the
newer GPr actually has lower power consumption.
Having looked at Linux and eCos on the 3011, this series turns now to
the NetBSD port to it. This port differs from the others in that it
doesn't exist yet. However, NetBSD runs on other systems based on the
405GPr chip, and the chip's architecture turns out to make the port a
comparatively simple task. This article reviews some of the ways in
which the 405GPr's architecture contributes to the porting effort and
looks at the preparations needed before getting into the
nitty-gritty of a kernel port. This is a whole new ball game compared to
the curses port described in Part 3.
PowerPC instruction set
Although it might seem fairly trivial, just the fact that this processor
uses a well-known, well-understood instruction set is a pretty big
boost to porting. No special effort is required in getting a working
compiler to target PowerPC, and compiler support for the platform is
generally mature. That means fewer compiler bugs and quirks and better
performance.
And while there isn't much assembly code in a kernel port, it's nice
that, for what little there is, the chip provides a clean and sparse
architecture with a good range of instructions and a lot of generic
registers. Code efficiency is good. The 405GPr has a special feature
for code compression, which I ignored, but which might be useful for
squeezing a few more bytes here and there from a program.
Bus support
In contrast to a system where the CPU talks to a chipset controller,
which handles all the bus architectures, the 405GPr has its bus support
built in. The core bus is the processor local bus, which the processor
core uses to communicate with everything else. This is connected to a
number of secondary buses. The chip includes PCI bus support, used
primarily for expansion devices. Only 32-bit PCI is supported, running
at either 33MHz or 66MHz. (On the TAMS 3011, it's 33MHz.) On-chip
peripherals are supported through the on-chip peripheral bus, which
provides access to the on-board ethernet controller, GPIO interface,
timers, both UARTs, and finally the I2C bus, used in turn for sensors,
EEPROMs, or other I2C devices. (On some systems, though not the 3011, the
I2C bus might be used to detect the amount of installed memory.) There
are also memory controllers: one ROM/RAM controller and one SDRAM
controller.
The use of the on-chip peripheral bus improves the effective bandwidth
available to PCI devices, especially since there's a 10/100 ethernet
controller on it.
From the point of view of a user more familiar with desktop PC
architectures, the 405GPr essentially includes both the "northbridge"
and "southbridge" parts of a motherboard chipset. This dramatically
reduces the wiring needed to build a system around the chip, as well as
reducing points of failure.
For the NetBSD port, this means that the majority of the code necessary
to communicate with devices built in to the 405GPr is already written,
and doesn't need significant modification, or indeed, any modification
at all. (There may be one or two exceptions; all will be revealed in
coming articles.) The on-chip buses and interfaces all work the same on
any board, though, so there's no need for new code for built-in devices,
or for access to external peripherals; that's all been written already.
Memory map
Although kernels tend to have some control over the apparent memory
layout of a system, some portion of the memory map is determined
entirely by hardware. Because the 405GPr includes its own memory
controller and buses, it can provide a consistent memory map for device
control registers, SDRAM, and other things a developer might need to
access. This makes it easier to write documentation, or code, for
systems based on this processor. For instance, if you have access to
code written for the IBM "Walnut" evaluation board, it might come in
very handy when working on a TAMS 3011.
One of the first goals of any kernel is to print messages
on some sort of console. On an evaluation board with built-in hardware,
that means a serial port. Rather than trying to identify a bus and scan
it to find a serial port, though, you can simply attach a driver to the
on-chip UART at a fixed address. The address doesn't change, and no
intermediate bus drivers are needed, because the device's registers are
already mapped into memory. The only part that requires any effort at
all is discerning what clock frequency to tell the serial driver to use.
Similarly, the address space to be used for physical RAM, or for the
PCI bus, is predictable across implementations. The amount of memory
provided varies, but the way in which it's accessed doesn't, so you
don't have to spend time and effort on porting that between boards.
This simplifies the startup code a little, too.
Peripherals
While the 405GPr has most of what you need to build a computer
built-in, there are a few peripheral devices attached. The I2C bus
provides access to a real-time clock (a DS1307) and a small EEPROM which
stores system configuration information. The 3011 has a second ethernet
port, based on a National Semiconductor DP83816. The system also
provides a USB controller and a large chunk of NAND flash memory. The
DP83816 and USB controller are connected over the PCI bus, not using
slots, but merely connected to it electrically. Finally, last but not
least, there's a physical media interface (PHY) attached to the on-chip
ethernet controller, over the Media Independent Interface (MII) bus
built into the controller. The MII bus allows the connection
of alternative PHY hardware. In this case, though, it's just an NS83847
ethernet PHY.
All of these are reasonably standard. The 3011 lives on a PCI passive
backplane, with two additional slots for expansion devices. This is sort
of unusual in evaluation boards, and none of the other 405GPr systems
supported by NetBSD typically have other devices connected to them.
Planning the port
|
Of course it runs NetBSD
Why NetBSD? It's a system with clean, portable code, and it makes a
good environment for exploring the system. The project slogan ("Of
course it runs NetBSD") reflects the project's attitude towards
portability. NetBSD's architecture is designed to encourage and support
easy porting, and there wasn't a port to the 3011 already.
The BSD family has an unusually tangled family tree, even for UNIX®;
suffice it to say that NetBSD is tied with FreeBSD for "oldest surviving
variant." The focus of the projects is different, and NetBSD is the one
with the best support for unusual architectures.
Because NetBSD runs on a very broad range of hardware, some of it
fairly slow, NetBSD also has excellent support for cross-compilation.
While using a faster system to compile for a slower system is appealing,
this is also a very handy thing when targeting a new board. The
well-supported cross-development tools save a lot of time.
|
|
Porting NetBSD to the 3011 is a comparatively simple task. Some ports
take weeks. This one won't. The first thing to do is understand the
NetBSD kernel architecture. The entire kernel is found in
/usr/src/sys/. (Actually, a couple of files are linked in from a common
directory shared by the kernel and the C library.) Within the sys
directory, architecture-specific code lives in the arch subdirectory.
Two architecture directories matter for this port. The
first is the arch/powerpc/ directory, which holds code applicable across
a variety of PowerPC architectures. The second is the arch/evbppc/
directory, which holds a collection of related ports to "evaluation
boards" based on PowerPC chips. Several of the existing evbppc ports
are to systems based on the PowerPC 405GP or 405GPr.
Some code specific to this processor is found in the
arch/powerpc/ibm4xx directory, including device driver support for the
on-board hardware, such as the I2C controller and the emac Ethernet
interface. Conveniently, existing ports already have the layout and
configuration to join these together.
About that config file
Linux and eCos users might be a little horrified to discover that
there's not really a configuration program, similar to "make menuconfig"
or "ecosconfig," in NetBSD. Configuration files are edited by hand, and
then the config utility creates a compilation directory with headers and
a Makefile. BSD kernels are usually monolithic. Although there is
support for loadable drivers, the default arrangement is usually just to
build the GENERIC kernel, which has every likely driver for a given
system.
For embedded systems, there's generally a config file for each target
configuration. Config files refer to other files which provide standard
options and specify which files to load to provide a given feature.
Device probing is partially controlled through the config file. For
instance, the following chunk of configuration file describes the
connection from the "root" device (which is something built-in that the
processor can always find) to the on-board ethernet controller:
Listing 1: The foot bone's connected to the ankle bone
plb0 at root # Processor Local Bus
opb* at plb? # On-chip Peripheral Bus
emac0 at opb? addr ? irq ? # Ethernet Media Access Controller
|
Some devices can be attached to more than one bus. For instance, a SCSI
controller might be found both on a PCI bus and on a CardBus bus; these
would be two separate lines in the configuration file.
Cross-compiling
As you might expect, NetBSD has a mature and flexible set of
cross-development tools. These can be easily created for a given target
using the build.sh program (which lives in /usr/src). The toolchain,
including support programs (such as make and config) and compilers, can
be built with a single invocation of build.sh:
Listing 2: Building a toolchain
$ ./build.sh -T tooldir -m powerpc tools
|
The "tools" represent all the programs needed to build the operating
system. Some tools, such as make, do not depend on the target
architecture. These are built with a prefix (by default, nb) on their
names to distinguish them from host-native tools. This matters in the
case where, for instance, you're trying to build NetBSD tools on a
non-NetBSD system, which might have an incompatible version of make.
So, the newly compiled program will be called nbmake. Other tools, such
as gcc or gas, are specific to the target system. These are created
with a prefix indicating the target architecture. For instance,
powerpc--netbsd-gcc, or i386--netbsdelf-gcc. Both types of tools are
installed in the directory passed to the -T argument.
Once the cross tools are built, you might want to add the tool directory
to your path. "PATH=/usr/src/tooldir:$PATH" is the simple way.
With all of this done, the stage is now set for what we hope will be a
fairly painless process of getting NetBSD running on a new system. In
the next article, I'll show the basic configuration file and setup code
used, and show how the process goes from "why is there no console here?"
to "NFS boot is working great."
Resources Learn
Get products and technologies
Discuss
About the author | 
| | Peter Seebach has used NetBSD on about eight architectures, and wouldn't mind another, if it's not too much work. |
Rate this page
| |
