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).