How to build Linux for a
Bright Star Engineering
This board is a tiny, embeddable StrongARM computer.
This web page is for propeller-heads like me who want everything
built from pristine sources. If you don't want to spend
two hours and 800 Meg of disk on this process, you can
probably use the the CD-ROM from BSE (which cost you
While this documentation and kit are customized, tuned, and debugged for the nanoEngine, nearly all of it applies to any embedded Linux target, and especially other StrongARM embedded Linux targets. Contact me if you adapt this kit for something other than the nanoEngine, I'd love to make this more general.
Previous releases were labed a "WORK IN PROGRESS". While that is obviously still true, this snapshot is also fully functional, and the basis for serious application deployment. The todo list is still there, but there are no known show-stoppers.
The nanoEngine hardware brings out the StrongARM pins that can implement a PCMCIA bus. Miguel Freitas posted instructions for hooking that up and making it work; its software is a follow-on to this work.
To start, you need a working general-issue GNU-based development system, with a lot of disk space (about 800 Meg should do it). A fast CPU would be nice, too: the build steps take about 80 minutes on my 400 MHz Pentium-II. I used a Red Hat 5.2 system, although I did have to update GNU make (it was 3.76.1, and I went all the way to 3.79.1; the documentation says 3.77 is enough). This version of the kit was tested with gcc upgraded to 2.95.3 (as the host native compiler); earlier versions used the stock gcc-188.8.131.52. There's no reason to think this process would not work on Solaris, AIX, etc. I hope to test that Real Soon Now.
The information on this page should be roughly consistent with other ARM-Linux toolchain documentation on the net:
This script will do all the unpacking and patching from the above listed reference files. All scripts referenced on this page are included in the nanoengine-kit-0.8, listed above. If you're serious about performing the builds described on this page, you will download that file, and carefully read the enclosed README. That gives additional context and example usage of all the scripts.
As a security-minded individual, I strongly recommend that you take all steps as a non-root (mortal) user. That includes this download step, unpacking, and the building steps as well. That minimizes the security exposure of your development machine. If many people on one development machine want to use the tools, the traditional approach is to install as root. Instead, I recommend dedicating a userid for the build process, and then have all users direct their path to the resulting tools.
Of course, the security of your embedded target is intimately tied to the quality of the source code that goes into it; nothing can avoid that. At least this build-from-source process can let you document all the people who have their "finger in the pie."
The source directories for most of the packages (e.g., binutils, gcc, glibc, strace, busybox, and ntpclient) are not touched by the installation process, and belong in a "pristine" area. Occasional program trees have to be built in the same directory as the sources. The primary offender here is the Linux kernel itself. People recognize the problem, and have tackled it in the linux-2.5 tree. If and when that effort stabilizes, I will happily change over. For now, this meta-kit puts up with linux-2.4. Also, note there is a bug in the pristine-ness of glibc or gcc, I forget which. Try building a toolchain based on sources owned by a different user, you'll see the problem.
I didn't enable a gcc (GNU Compiler Collection) build of Objective-C, Fortran, or Java, because I don't plan on testing them. You can enable them yourself with a one-line change in the script. Testing is then up to you, of course.
bload mondo c0800000; go c0800000I made a "screen shot" of a successful nanoEngine boot, using the results of the build process exactly as described.
Assuming you want persistent storage using the Flash chip on your nanoEngine, you need to erase a section of Flash, and mount a JFFS2 system on it. As you can see by the output of "cat /proc/mtd", I have set aside 1 Mbyte for this purpose (if you want to change this allocation, see linux/drivers/mtd/maps/sa1100-flash.c). Do "eraseall /dev/mtd2", then "mount -t jffs2 /dev/mtdblock2 /mnt/flash". This second step could be added to the boot process. Please read the important notice in the README file about how using the Flash can prevent a hardware reset from rebooting properly. If your console gets cluttered up with "MTD_open" and similar messages, you can silence them with "echo 5 >/proc/sys/kernel/printk".
At some point, you should probably review the kernel configuration that I picked out for this board. Go to the build/linux-* directory, and "make xconfig". If you change anything, you should play it safe and "make dep && make zImage" to get a new kernel to try out.
June 26, 2002