Embedded Linux System Design From Software Perspective

Embedded Linux System Design From Software Perspective

by cawan (cawan[at]ieee.org or chuiyewleong[at]hotmail.com)

on 9/11/2012

In embedded linux system design, the software concepts and issues are normally a
little bit confusing and hard to understand. However, it is actually simple if we
try to categorize it different abstraction layer. In general, there are only 3
pieces of image files to be generated in order to build an embedded linux system.

1. Bootloader
2. System (kernel + rootfs)
3. User Application

Bootloader has 2 functions.

1. Initialize Peripherals
2. Bring Up the Kernel

Besides, in most of the times, bootloader will come with a monitoring and
configuration interface to let users have certain level of control to the hardware,
such as,

1. Check Peripherals Status (NAND Flash exist ?)
2. Perform Operations to Peripherals
     - Erase / Format NAND Flash
     - Load Image File from TFTP or NFS
     - Burn Image File to NAND Flash
     - Verify Flash Checksum
     - Make Partition to Flash
3. Determine How to Bring Up the Kernel (TFTP / Flash ?)

Bootloader is normally processor architecture dependent, for example, ARM is normally
bind to u-boot.

System image is the combination of kernel image and rootfs image. Kernel image is
something to be loaded by bootloader into memory, and run in memory. On the other
hand, rootfs image is the archive of necessary files and directories to run the
system. For those system default applications with no requirement to be updated can
be stored in rootfs. Besides, it is important to note that rootfs is normally run as
ramdisk. For those who new to the concept of ramdisk, please refer my next paper
about ramdisk explaination.

User application is normally an executable to be run by the system to provide
services. It also has requirement to be updated frequently. The user application
package is used to be archived as a specific file system image file, for example
SquashFS, which is going to be copied onto the embedded system. So, it will be
mounted by the system and run accordingly.

Well, based on those 3 pieces of software image files, we suppose have no problem to
build a fully functional embedded system now, but how ? Yes, this is the main issue
to be discussed in this paper. Bootloader image is always put into block 0 of the
flash chip. In terms of address abstraction, the unit in block is the lowest level,
which is close to physical layer. Block 0 is defined as the first block of the flash
chip, which is almost similar to the first sector of hard disk. So, bootloader image
should be located at this area to ease the processor to start at the very initial
boot stage. For the case of hard disk, the first sector is usually for master boot
record (mbr). Fine, once the system has successfully initialized by the bootloader,
it should understand logical address, which has higher abstraction level than the
physical address in the unit of block. So, with logical address, the respective
associated physical block can be assigned at any location within the flash chip.
Thus, the system image should place at a specific logical address, which is making
sense to the bootloader. Hence, the bootloader can easily bring up the kernel and
mount to the rootfs as ramdisk. Well, once the system is up with kernel and rootfs,
it should understand the concept of file system right now. The user application image
is usually placed at certain partition of the flash chip, and as all of us knew,
partition is expressed as device file in /dev directory. So, the user application
image should map onto the partition and get ready to be mounted and run by the
system. As comparison to bootloader and system image, the user application image has
highest abstraction level which is represented as a device file in file system. So,
as summary, bootloader has lowest abstraction level (in the unit of block), following
by system image (in the unit of logical address), and finally the user application
image (in the unit of file system).

pdf version:

http://www.scribd.com/doc/112733417/Embedded-Linux-System-Design-From-Software-Perspective