Loading Linux Kernels Onto a Board
Contents
Background Information
The Linux kernel is at the core of EMAC's OE operating system. The kernel provides essential I/O interfaces, task management, and memory management to the user simplifying the development environment. Each embedded target has a Linux kernel image that is tailored to its specific hardware needs. For more information about the Linux kernel see the links in the About Linux page.
For EMAC's ARM Linux builds, the kernel is loaded onto boards separately from file systems, while on others the kernel is loaded with the filesystem. It should be noted that, regardless of how the kernel is loaded, many of the kernel's drivers can be compiled as modules which have to be included in the file system in the /lib/modules
directory. Building the Linux Kernel explains how to compile the Linux kernel and how to load the kernel modules onto an existing file system.
See the LILO Overview for more information on updating the kernel with X86 targets.
See the Loading_Images_with_U-Boot page for more information on updating the kernel on ARM targets.
General Information
As with the loading the JFFS2 file system, the kernel is loaded using TFTP and a serial connection to the boot loader. Once the boot loader and TFTP server are accessible the kernel is loaded into SDRAM and relocated to the target's embedded flash.
For instructions on installing a TFTP server on your development PC, see Installing TFTP server.
For details on connecting to the serial port for an embedded target, see Serial Connections.
The Loading Images with U-Boot page explains how to load a kernel onto a target. It is important to note the offset in SDRAM and Flash as setting them incorrectly could adversely affect the operation of the system. The current page details the utilization of U-Boot more specifically; for more information about Redboot see the Loading Images with RedBoot page.
Here is an example of configuring the networking for TFTP transfer and loading the kernel into the resident SDRAM on a SoM-9G45:
U-Boot> set autoload no U-Boot> dhcp U-Boot> tftp 0x70000000 uImage-2.6.30-9g45
Once the kernel is loaded into SDRAM, the kernel image can be either booted directly or loaded into the board's flash memory for deployment. Booting directly into the kernel can be especially useful during development as it allows for testing and debugging without committing the kernel to flash. To boot the kernel directly, use the bootm
command as follows:
U-Boot> bootm
The procedure for writing to the flash differs from board to board because of the different flash types that are used. For instance, the SoM-9G45 and SoM-9G20 use serial Dataflash to store the kernel, whereas the SoM-9260 uses NOR flash.
Here is an example for copying the the kernel image into the Dataflash on the SoM-9G45 using cp.b
:
U-Boot> cp.b 0x74000000 0xC0042000 ${filesize}
The $filesize variable is automatically set based on the size of the file loaded with the previous tftp load command. |
Here is an example of writing the kernel to the NOR flash on the SoM-9260:
U-Boot> protect off all U-Boot> erase 0x10100000 0x103fffff U-Boot> cp.b 0x20000000 0x10100000 ${filesize} U-Boot> set kernelsize $filesize
The protect off all
command unlocks NOR flash erasing and writing. NOR flash needs to be specifically erased before programming using the erase
command. Once the erase is complete the kernel image can be written to the flash. The kernelsize
variable is used in the boot script for the SoM-9260. To see the boot command sequence for a particular board, run the printenv
command on the system and note the bootcmd
variable.
The 0x numbers represent the hexadecimal value of the offset from the top of specific memories. These values vary from system to system. See the quick reference below for examples on the various EMAC ARM based systems. |
Another U-Boot variable that is important to the boot process of the kernel is the bootargs
. This variable contains the kernel parameters used during boot. The line of text it contains specifies the boot partition, serial console for the boot messages, and other possible boot parameters.
For example, here is the bootargs string on the SoM-9G45:
bootargs=console=ttyS0,115200 mtdparts=atmel_nand:128M(root),-(aux) root=/dev/mtdblock0 rootfstype=jffs2 ro video=LG
Everything after the first equals sign is contained within the bootargs
variable. The following explains each of the variables in the bootargs:
Table 1: bootargs parameters | |
---|---|
Parameter | Description |
console | The UART device node and baud rate for the boot messages. |
mtdparts | The size of the NAND flash partitions. NOTE: This could use more information |
root | Sets which MTD partition to mount as the root file system. |
rootfstype | The file system formatting used on the root partition. |
ro | Mounts the root partition read-only. |
video | Sets the video mode for the display. |
Table 2: video parameter values | |
---|---|
Value | Description |
LG | 4.3" LCD distributed with the SoM-200, SoM-210, and SoM-212 carriers. |
PRIMEVIEW | 7" LCD distributed with the SoM-250ES (PPC-E7+) |
AMPIRE | 10" LCD distributed with the SoM-250ES (PPC-E10) |
Quick Reference (By Target Type)
This section provides a quick reference for programming various targets with a kernel images.
SoM-9260M
U-Boot> tftp 0x20000000 uImage-som-9260m
U-Boot> protect off all
U-Boot> erase 0x10100000 0x103fffff
U-Boot> cp.b 0x20000000 0x10100000 ${filesize}
U-Boot> set kernelsize $filesize
SoM-9G20M
U-Boot> tftp 0x20000000 uImage-som-9g20m
U-Boot> cp.b 0x20000000 0xD0042000 ${filesize}
SoM-9G45M
U-Boot> tftp 0x74000000 uImage-som-9g45m
U-Boot> cp.b 0x74000000 0xC0042000 ${filesize}
SoM-9M10M
U-Boot> tftp 0x74000000 uImage-som-9m10m
U-Boot> cp.b 0x74000000 0xC0042000 ${filesize}
SoM-9307M
Redboot> fis unlock -f 0x60000000 -l 0x1fdffff
Redboot> load -r -v -b 0x80000 -h 10.0.2.60 zImage-som-9307m
Redboot> fis create -b 0x80000 -l 0x200000 zImage
IPAC-9302
Redboot> fis unlock -f 0x60000000 -l 0x1fdffff
Redboot> load -r -v -b 0x80000 -h 10.0.2.60 zImage-ipac-9302
Redboot> fis create -b 0x80000 -l 0x200000 zImage