From the Archives: This article was resurrected from our white paper archives from back in December of 2004. Principles presented should be long-enduring, but there may have been some changes in the NetBSD/Linux/Unix marketplace since.
NetBSD is very similar to Linux (and actually can run Linux binaries), so you may be asking yourself why one would choose to run NetBSD instead of Linux? I will list the most common general reasons cited that apply to specifically to embedded systems designers. Wasabi Systems also has a very well written write-up describing Linux vs. NetBSD and even a guide for OEMs migrating from Linux to NetBSD.
- NetBSD is not encumbered by the GPL: you are free to do what you will with its source code; including making money off it. Apple is an example of a company that has done this as the core Mac OS X kernel is based on an early fork of BSD. With the GPL if you modify the Linux kernel, you must release your code for free unless you can do your change as a binary-only kernel module. A kernel module can be limiting especially in embedded applications since some types of kernel modifications do not lend themselves well to modules. NetBSD is more a culture of pure engineers and developers rather than of evangelists pushing an ideology of how the software industry should be run. As such, you or your company will never get flamed for not releasing source code modifications open-source.
- NetBSD is built from one large source tree and maintains a single, unified distribution. One can build everything (including toolchain) all the way to releasable installation media from a single command using nothing but a POSIX compatible shell. A unified distribution and comprehensive build system also saves developers from having to keep up with multiple separate open source projects each with different ways of doing things spread across the internet. A single talented developer is typically more effectively utilized in this arrangement, and is part of the reason NetBSD can do with a few hundred developers what Linux does with tens of thousands. The differences in each OS’ development criteria is apparent even at startup in the kernel dmesg. Compare Linux’s ad-hoc dmesg with NetBSD’s more structured dmesg booting from the same hardware.
- NetBSD follows a very conservative engineering approach Compared to the Linux kernel, released versions change less and get tested longer. Source code is maintained with higher standards of quality and cleanliness of design. As an embedded systems designer, this means there is less chance that a new API will come along that breaks existing code. This can be a nuisance because it can force developers to drop everything they’ve learned so far, preempt current work, and learn/implement the new fangled way of doing things. Longer living subsystems allow for documentation and developer skill to accumulate. A good portion of Linux kernel documentation is largely out of date or soon will be. NetBSD recognizes that developer time and talent is finite and does not waste energy with superfluous redesign.
- NetBSD is portable. Linux is also portable, but more by brute force than by design. Linux gets its portability from hordes of programmers willing to write patches on top of patches to make hardware look like a i386 to the rest of the kernel. NetBSD has honed abstractions that enables all architectures to be built simultaneously with a single kernel tree. All notable internal abstractions including most drivers are also documented in system man pages.
- Practical development features such as an integrated in-kernel debugger (DDB) and kernel-level core dumps. In Linux, the mantra is that developer time is 0-cost and available in infinite quantities, which is not a method of thinking that lends itself well to commercial ventures with deadlines and schedules, or with people with other things to develop. Linus has traditionally been against including any mechanism in the kernel that makes the developer’s life easier (Reference). With NetBSD, one rarely has to concern themselves with things like toolchain procurement, libc versions, or build system machinery since these details have already been taken care of and are included in the source tree. Cross-toolchain management is typically one of the most complicated issues for starting work using non-x86 Linux, but practically a non-issue on NetBSD since its been taken care of in the higher-level parts of the build system.
- NetBSD has good corporate support and easy-to-find developer talent for hire. An ever evolving list of consultants is maintained at NetBSD.org. It is usually much more straightforward for a company to work with NetBSD due to its structured management, appointed committers, and technical committees. Working with mainstream Linux often requires the involvement of so-called gatekeeper positions that may or may not have the political clout within a given open-source community to successfully lobby changes. Staffing such a position is very hit-or-miss, especially if having to deal with the prospect of using multiple distinct unfamiliar (to the appointed company gatekeeper) projects and communities.
NetBSD Support for the TS-7200
Initial NetBSD support for the TS-7200 was committed to the NetBSD -current CVS repository on December 24, 2004 as a sub-configuration of the NetBSD/evbarm port Current supported peripherals are described on the NetBSD/evbarm webpage As a kernel, the most notable hardware support difference between the current NetBSD kernel and the Linux 2.4.26 kernel currently shipping by default with the TS-7200 is that NetBSD has an isabus driver that allows PC/104 cards to be more fully utilized on the TS-7200. Getting generic ISA bus drivers to work with Linux can be very difficult due to the x86 style ISA assumptions throughout the kernel. Linux right now does have something NetBSD does not and that is support for using the onboard flash as a filesystem (NetBSD requires the CF to boot). NetBSD has support for the watchdog timer on the TS-7200 and can also boot very easily to a USB thumb drive or mass storage device. Linux currently has no watchdog driver and has to use a very technical incantation involving an initrd and a pivot_root to boot USB drives. Kernel bootup time is slightly longer on NetBSD than Linux, but can be improved by disabling certain drivers and certain (overly conservative) delays.
Since this is a new port, support for the TS-7200 is only available in the -current (i.e. development) version of NetBSD and not in the 2.0 release that was just released late 2004. It could also be back-ported to the 2.0 release, but you won’t find that make it to the official NetBSD tree. Technologic Systems could be commissioned to provide you with a patch to 2.0 should you desire, otherwise you’re going to have to wait until sometime around May-June 2005 for this port to make it to the 3.0 official release. In NetBSD, even if the code is solid, it must “age” a bit before making it into an official release. Since the code has been committed to -current, it will inevitably be included in the next major release, so if you are starting a venture with a product based on the TS-7200 using NetBSD, I’d suggest you track -current until February 2005 when the 3.0 release will be branched and then follow that branch until its release. Right now 3.0 is scheduled for release sometime around June 2005. Technologic Systems will do some minimal QA and build informal releases from NetBSD -current and make them available for download from time to time until the NetBSD project autobuild servers are back online.
Installing NetBSD/evbarm on Your TS-7200 Using Nothing but RedBoot and the Internet
All TS-7200’s come pre-installed with Linux since Linux is Technologic System’s most marketable platform. Installing NetBSD is not difficult and can be done from the RedBoot ROM monitor completely from the internet. Before you start, you’ll want to make sure you have at least version 1.04 of the TS-BOOTROM firmware installed. Also, there is currently no gzimg for the 16MB onboard flash versions of the TS-7200. Send a message to joff-AT-embeddedARM.com if you have a 16MB flash unit you would like to try NetBSD on. The first thing you’ll want to do is use the RedBoot command fconfig to set your IP address and default gateway so that you can access the internet. After that, you need to load the 5MB install kernel from the internet using the command:
load -v -r -b 0x00200000 -h 18.104.22.168 -m http /ftp/ts-arm-sbc/ts-7200-netbsd/netbsd-TS7200_INSTALL.bin
Note that this may take some time as eCos/RedBoot is not particularly speedy at downloading via HTTP. You may alternatively download the file to a TFTP or HTTP server on your local network which may speed things up. After successfully downloading the install image to RAM, type go to start the kernel and menu driven installation program. The NetBSD installation program will take you through installing NetBSD to your CompactFlash card or USB thumb drive. Just installing the minimal number of sets will require a 128MB CF, and although you can run the full OS with compilers in a 256MB CF, you need 512MB to install it because of required temporary storage of the downloaded set tarballs. When the time comes to ask for the installation medium, choose “FTP” and accept the default parameters since the installation kernel you downloaded from Technologic Systems will default to the correct FTP location (also at Technologic Systems)
After the OS has been installed to the CF, you need to write a kernel to the onboard flash and tell RedBoot to boot it. A kernel that boots to CF is downloadable via HTTP and can be written using the following sequence of commands:
- load -v -r -b 0x00200000 -h 22.214.171.124 -m http /ftp/ts-arm-sbc/ts-7200-netbsd/gzimg_TS7200_wd0_flash_0x60660000 (Load NetBSD gzimg from HTTP into RAM)
- fis delete vmlinux (To delete flashed Linux kernel)
- fis create -b 0x00200000 -l 0x160000 -f 0x60660000 netbsd.gz (puts the gzimg into the RedBoot FIS)
Once the gzimg image has been written to flash, you can modify your RedBoot bootscript to issue the command go 0x60660000 which will then start NetBSD on your TS-7200
NetBSD has a separate sub-project dubbed pkgsrc that handles package management and building of the several thousand other open-source projects. This is somewhat akin to RedHat’s RPM or Debian’s dpkg/apt-get facilities. Currently, ftp.netbsd.org only has pre-built binary packages for evbarm from the NetBSD-1.6 release of pkgsrc. You can use these by setting the PKG_PATH environment variable to ftp://ftp.netbsd.org/pub/NetBSD/packages/1.6/evbarm/All then running pkg_add, e.g. pkg_add -v perl. Package dependencies are downloaded and installed automatically providing functionality similar to Debian’s apt-get. Note, however, the typical usage of the NetBSD pkgsrc framework is downloading/extracting the pkgsrc framework tarball into /usr/pkgsrc and building each package right on the hardware that will run it. This is a little bit more involved on the TS-7200 since one rarely has the patience to compile completely on a 200Mhz ARM. Instead, the recommended way would be to use the distcc compiler to distribute the compiling to a higher power workstation running the distccd daemon with the ARM netbsd cross toolchain across the network. This way, the TS-7200 is still running the build, but the bulk of the CPU-intensive parts are offloaded to another machine.
Besides pkgsrc, another notable difference is in the NetBSD startup configuration. Linux distributions vary, but they typically use the SysV initialization scheme with numbered runlevels 1-6, startup scripts in /etc/init.d/* and specially named symlinks in /etc/init.d/rc##.d directories corresponding to each runlevel. NetBSD uses a simplified startup configuration where single lines of the form sendmail=YES or inetd=NO are appended to the /etc/rc.conf file. System defaults are sourced first from /etc/defaults/rc.conf and the user may open this file for finding all the available modifiable configuration knobs and then override them with entries in /etc/rc.conf.
Network interfaces are also slightly different in NetBSD. Instead of each ethernet like device being named eth0, eth1, eth2, etc., each device is named according to the actual device. On the TS-7200, the on-board ethernet is named “epe0”, short for EP93xx Ethernet. To set IP addresses, the ifconfigcommand is available with semantics similar to those in Linux. Alternatively, you may have the system set the device up at bootup by appending a line of the form ifconfig_epe0="192.168.0.50" to the /etc/rc.conf file. To use DHCP, append a line dhclient=YES to /etc/rc.conf. The default route is set with a line in /etc/rc.conf of the form defaultroute="192.168.0.1".