Configuring the Development System and Creating Our Custom KernelCreating Our Custom Kernel

One very useful side-effect of using a PC as the central system controller is that you can run all the development tools directly on the target hardware (or possibly a slightly expanded version of that hardware), eliminating the need for a complex cross-development system. The main reason I advocate doing this is because bit-ter experience has taught me that the build and install process for some third-party

118 Chapter 4

Linux drivers has only been tested in the “vanilla” case, that is, building and installing into the currently active system. Automatic configuration scripts that test for the avail-ability of specific libraries and/or hardware features (for example, CPU instruction set extensions such as MMX, SSE, 3DNow! and so on) will also require coercion if you’re running them on a system other than the target hardware. Debugging these sorts of issues with cross-compiling and manual installation of these components is a waste of your time. Thus, I suggest that you start by building your SBC into a fully-configured PC by adding a keyboard, mouse, hard disk and CD-ROM drive,¹⁹ and perform all your kernel and utility compilation directly on the SBC. You should install Fedora Core with a custom configuration; don’t install XFree86²⁰ or associated frippery (graphical In-ternet tools, games, GNOME, KDE, etc.) unless you specifically want them. Otherwise, just install the core operating system, development tools, and kernel development. If you want an exact list of what to select in the install dialogs, here is a painstakingly exact description of how to navigate the installation process (note: this information is correct for Fedora Core 1 “Yarrow.” The reason I am spelling it out in such painstaking detail is so that you can be certain you’re working with the exact same system configu-ration I was working with when I wrote and tested the code in this book):

■ Boot off the CD and type linux text to use the text-mode installer. Vagaries of the Geode graphics subsystem mean that the graphical installer probably will not work correctly.

■ Choose “Skip” to skip testing of installation media, and select “OK” in the welcome dialog.

■ Select “English,” then “us”. Choose the type of mouse, if any, connected to your system. If you selected a serial mouse, indicate the port to which it is at-tached (probably /dev/ttyS0).

19You can actually buy some of the SBCs on our recommended hardware list preassembled in a box with a power supply, CD-ROM drive and hard disk. However, it’s much cheaper—as much as 50%

cheaper – to put it together yourself. The system fits very elegantly into a housing from an external 5.25″ disk or tape drive, if you happen to have one lying about.

20If you install XFree86, the system will probably not boot correctly unless you first go into CMOS setup and ensure that the LCD resolution is set for 1024 × 768 and video memory size is set for 4.0 MB. With certain older BIOS versions, you need to do these steps even if you’re not using the digital-output LCD port on the board.

The Linux-Based Controller (A Soft Task)

■ Accept the default monitor settings, and select “Proceed” in the warning dialog that follows.

■ If you’re installing on a hard disk that already contains a Linux installation, Fedora will ask you if you want to upgrade the existing installation, or reinstall.

Select “Reinstall”.

■ Select the “Custom” installation type.

■ Select “Disk Druid” partitioning. The next dialog you see will be Disk Druid.

How you partition your system is up to your own preference, but for this sort of application I normally create a 256 MB swap partition and use the remain-der of the disk as the root partition. (No, this is not normally regarded as best practice; but unless you have special requirements, it’s the simplest partition-ing scheme for this spartition-ingle-function development system). Always force your partitions to be primary partitions. After partitioning, you’ll probably get a dialog warning that swap space is going to be turned on immediately; just select “OK”.

■ Select “Use GRUB Boot Loader”. In the next four dialogs (all of which are titled Boot Loader Configuration), you should not need to specify any spe-cial parameters; just select OK. This will install GRUB in the MBR, with no special options or password protection.

■ You now need to configure the built-in RTL8139 Ethernet adapter. Since the configuration we’re setting up now is only used for development, I suggest you leave it at the default settings, which activate the interface automatically on boot and attempt to acquire an IP address using DHCP.

■ In the next dialog (Hostname Configuration), you can either leave the set-tings at defaults, or manually enter a hostname for this system.

■ Since this is a development system that should already be isolated from net-work attacks, select “No firewall” in the Firewall dialog. Select “Proceed” in the warning dialog that will follow.

■ In the next dialog (Language Support), just select “OK”.

120 Chapter 4

■ In the Time Zone Selection dialog, select the timezone you’re working in and select “OK”.

■ Choose a root password and enter it twice in the Root Password dialog.

■ There will now be a LONG pause while the installer analyzes the list of installable packages. The system isn’t crashed; just be patient. Once the Package Group Selection dialog comes up, select only the following packages (deselect all others): “Editors,” “Text-based Internet,” “Windows File Server,”

“Network Servers,” “Development Tools,” “Kernel Development,” and “Sys-tem Tools.” Note that in some cases, when you press Space to enable an option, the system will become unresponsive for up to 30 seconds; this is the install script analyzing the packages you’ve selected. After you select OK in the Package Group Selection dialog, select OK in the “Installation to begin”

dialog, select “Continue” in the Required Install Media dialog, and the install process will commence. At the end of the installation, select “Reboot” and you’re done.

The process I just described yields a system on which you can build and test your embedded kernel directly. You can also assemble your bootable CompactFlash image and write it to a CF card on this same piece of hardware, then test booting off it simply by altering the CMOS settings on the SBC—which is a big time-saver while you’re debugging CompactFlash startup issues. However, if you’re unwilling or unable to use the target SBC as your development system (for instance, if it’s physically installed into a piece of equipment and it’s difficult to attach development peripherals), there is an alternative method you can use. This method can be summarized as follows:

■ Take the source for the kernel version you intend to use on the SBC, and configure and build it for your development system.

■ Install the kernel and modules on your development system, and modify your bootloader so that it loads this kernel. For the sake of this discussion, I’ll assume that you named the active, booting kernel image “/boot/bzimage-2.4.24”. Edit your bootloader’s configuration appropriately.

■ Reboot so that you’re running the same kernel version that you intend to use on the SBC.

The Linux-Based Controller (A Soft Task)

■ Archive the kernel and its configuration. You can back up the important parts of the active Linux environment simply with the command:

tar cvfz /activekernel.tar.gz /lib/modules/* /boot/bzImage-2.4.24 /etc/modules.conf

■ Clean up the kernel and module directories by executing the commands

make clean in the kernel source directory and rm -rf /lib/mod-ules/2.4.24 to remove the active kernel modules.

■ Configure the kernel for your SBC, build and install it. If you’re using the Ad-vantech board or a compatible device, you can use the kernel configuration I have supplied on the CD-ROM. Don’t use the same path for the kernel image file (bzImage) as you’re using for the real kernel that boots your development system, or you might not be able to start the development system easily if something goes wrong and you have to reboot. I suggest you install the SBC-specific kernel as /boot/bzImage-sbc. If you’re using the mate-rials supplied on the CD-ROM, here’s the exact set of commands you’ll need to execute:

cd /usr/src

tar zxvf /mnt/cdrom/linux/linux-2.4.24.tar.gz cd linux-2.4.24

cp /mnt/cdrom/linux/geode-config .config

make dep ; make bzImage ; make modules ; make modules_install cp arch/i386/boot/bzImage /boot/bzImage-sbc

■ Configure, build and install any additional drivers you need (for example, LIRC, mentioned later in this text, drivers for WLAN devices, and so on).

■ Archive the SBC’s kernel configuration:

tar cvfz /sbckernel.tar.gz /lib/modules/* /boot/bzImage-sbc / etc/modules.conf

■ Immediately after you finish archiving up the completed kernel installation for the SBC, restore your development system’s bootable kernel set with the following commands:

122 Chapter 4

rm -rf /lib/modules/2.4.24 cd /

tar zxvf activekernel.tar.gz

This way of doing things is not quite as desirable as development on the real hardware, because you still have to hand-tweak configuration files for applications and libraries that auto-configure for installed hardware. You may also have some (usually very minor) problems with module dependencies, requiring manual editing of the modules.dep file, and you obviously can’t actually test the kernel and drivers on your alien development hardware. However, this system does allow you to build the kernel and all the installable kernel modules in a reasonably robust and simple way. Note, by the way, that many installable driver packages place daemons, libraries, utilities and other files in various directories other than /lib/modules/kernelversion, and some of these packages modify startup scripts to load daemons automatically on boot. You’ll have to identify and copy these extra files and script modifications across to the SBC by hand.

The reason I advocate this somewhat tortuous process in lieu of performing a true

“cross-build” (coercing install scripts to use a kernel build tree different from the active one reported by uname(1)) is because I have frequently encountered bugs in the scripts and makefiles for various third-party kernel drivers and other software, which only manifest if you are installing to a destination other than the current (booted) kernel directory. It would appear that most such drivers are developed and tested under the assumption that you will be building and installing the driver into the currently active environment. Rather than analyzing and testing the configure scripts and makefiles for each third-party driver on a case-by-case basis (and perhaps risking that a critical component won’t be transferred correctly to your target system), it is much simpler simply to build “live.” If you can’t or won’t build on a truly live installation on the real target hardware, the next best thing is to simulate, on your development PC, the same kernel environment that will be running on the SBC.

All of this complexity is avoided if you build your Linux environment directly on the target platform, so I reiterate: if at all possible, build up your SBC into a semi-complete, usable system so you can build your software directly on the real hardware.

It will save you a vast amount of time and frustration.

The Linux-Based Controller (A Soft Task)