|
What to Do After Unpacking the Board
The best way to assess what is supplied with the board is to plug in the board and get Linux up and running. If you have problems locating what's necessary to boot the board, that fact is a good indication of the work that lies ahead. The board contains a guide with important information regarding the physical configuration of the hardware: what the DIP switches do and the location of the serial, video, USB, and other ports. In the trade, this is called a data sheet, leaving you with the impression that it's one page; but it's usually 50 to over 100 pages long. Depending on the board, these ports may not have connectors. The guide also contains information about how the board's serial port is configured: this is important information, because figuring out the communication parameters is a trial and error process otherwise. These guides are usually very well organized.
Have Linux? Boot It!
The easiest way to see what the kernel supports is to boot the board and have it tell you what it supports. To boot Linux, you need to check whether the distribution contains the following in binary form:
• Compiled Linux kernel with an initrd
• Root file system There isn't a dependable way to determine by inspection what these files are, so the documentation is key at this point. Here are some conventions:
• Kernels are frequently in zImage format, so file names have these patterns:
• zFileName
• FileName.zimage
• If the kernel is for an x86 board, it's usually in bzImage format. A bzImage is a compressed image that looks like a x86 boot sector, only it's larger than the boot sector size. It's compressed with gzip, not bzip2, as the bz leads some to believe. Here are the file name patterns:
• bzFileName
• FileName.bzImage
• If the board uses the U-Boot boot loader (the board's manual explains if it does), the kernel is named like the following. A uImage is a zImage with some additional information for the U-Boot boot loader:
• uFileName Copy the kernel file into the /tftpboot directory. This is the default location where the TFTP server looks for files. If this is an x86 using PXE boot, copy the file to the /tftpboot/default directory. The root file system is easier to find. It's usually a compressed tar file. Tar means tape archive and is a holdover from the early days of Unix when it was a tool for creating backups on reel-to-reel media. There are two ways to compress a tar file but several ways to name the file for each compression type. Unlike with the kernel, you can determine if a tar file contains a root file system by inspection. Use the view-contents command to output the list of files in the archive to the console, and use the less pager to look at the contents:
# tar tzf <file> | less
It should contain what looks like the file system on your desktop. It should have the /dev, /etc, /bin, and /sbin directories. If this appears to be the root file system, extract it into the directory exported in the /etc/exports directory. The board now needs to be cabled-up, usually via the serial connector. Start minicom:
# minincom –o
Minicom usually does the right thing by default. Press the spacebar a few times, and the boot loader should appear. Nothing on the display? Make sure the following are correct: 1. Check the cables. Are they securely attached? Is the cable a null modem? A null modem is a cable in which the send and receive lines have been crossed along with the clear-to-send and ready-to-send lines. Two serial ports can be connected with this cable; when data is transmitted by one, it appears as input on the other. The clear-to-send and ready-to-send pins handle flow control, so the machine at the receiving end can ask the sender to wait as it processes data. 2. Working with the right port and settings? Press Ctrl+A, O to open the configuration menu, and select Serial Port Setup. Make sure the serial device is the one that the board is attached to and that flow control is off (although your null modem cable may be configured to handle flow control, it isn't frequently implemented in a boot loader). After updating, select Save as dflt so the changes are stored as the default options. 3. Check the communication speed. Adjust it by pressing Ctrl+A, P. You can choose a few other options: start at the slowest speed and work upward. After you select a speed, press the spacebar a few times to see if that made a difference. 4. Still having problems? Check the cables again, and consult the data sheet. Chances are, you skipped checking everything thoroughly the first time. The communication configuration for the board may also be nonstandard: you may have attached the cable to the wrong port if the board has several serial connectors.
The board should include instructions for using the boot loader and what commands to use to load the kernel into memory and start execution. This is different for every board. You need to know the following, though, no matter what boot loader is being used:
• The IP address of the machine running the TFTP server
• The IP address of the machine running the NFS server, if the board includes a file system suitable for mounting via NFS
• The name of the kernel
• The location of the root file system if it isn't packaged as part of the kernel binary When Linux boots, a few pages of information scroll past. Those diagnostic messages tell you what hardware is discovered, what drivers are loaded, and much more. Chances are, the scroll-back buffer doesn't have enough room for all these messages. Use the following command to retrieve this information for review:
# dmesg | less
The less command results in a nice pager that lets you move forward and backward through the output. I explain critical parts of this output next; other noise output has been clipped. The dmesg command prints the contents of the kernel's ring buffer, which is the accumulated output from printk (the kernel analog to printf) function calls. You can configure the size of this buffer to just a few kilobytes to conserve space. A ring, or circular, buffer is one where capacity is fixed; when it's reached, the data at the start of the buffer is overwritten. This sort of buffer is failsafe in that it can't overflow in exchange for data fidelity. The following tells you when the kernel was built and with what compiler. What appears here is completely under the control of the person building the kernel:
Linux version 2.6.17-rc3 (paul@wren) (gcc version 4.1.0 (CodeSourcery ARM)) #53 Thu May 4 15:05:18 BST 2006
Then get the CPU information. It's the same data, more or less, that's contained in the /proc/cpuinfo file. After the kernel starts, print out the contents of /proc/cpuinfo to check. The data here isn't read from the chip: the programmer working on the chip-specific parts of the kernel populates a data structure containing this information. As you'll see later, the /proc file system contains information about the system hardware, kernel configuration, and networking information as well as information for all the processes running on the system. The /proc file system isn't really a file system—it's a view into the kernel's data structures structured as a file system. The kernel can be passed parameters by the boot loader. This is done by having the boot loader and kernel agree on an area of memory where the parameters are placed by the boot loader before running the kernel. You can configure the kernel not to accept kernel parameters as well; however, this isn't usually the case, because the parameters let you control some parameters of the boot process that change frequently, like the location of the root file system or console device without a rebuild. You can also compile the kernel with default parameters. The parameters passed in during boot are appended to the ones compiled into the kernel. Being able to see this line make it obvious what the command-line parameters were when the kernel booted.
Kernel command line: console=ttyAMA0
This means the kernel found a valid initramfs image:
CPU: Testing write buffer coherency: ok checking if image is initramfs... it is
The initramfs is a file system attached to the kernel that lets the kernel load additional device drivers if necessary. Some embedded systems use the initramfs as the only file system. The kernel always checks to see whether this file system exists and uses it if it does. The kernel, as it's booting, is nice enough to tell you the device names for these ports. The kernel continues being nice by creating these device nodes for you in a little, temporary /dev file system that allows the kernel command line to refer to a console or fixed-storage device node before a /dev file system is properly mounted. This can be a source of confusion if you're learning about embedded Linux, because there are references to device nodes (/dev/something); however, because / hasn't been mounted, how does the kernel interact with a device in an unmounted file system? This kernel has been configured for RAM disks:
RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize
RAM disks are convenient when you have a flash-based file system because the /tmp directory can be mounted to a RAM disk. This reduces wear on the flash memory while increasing performance, because frequent create/delete cycles are slow in flash and many programs store small cache files in /tmp for the purpose of increasing performance. RAM disks waste space if they aren't used in the system. Make a note of this when you're optimizing the kernel for size.