An Introduction to Embedded Linux Development, Part 3

Part 3 explores different scenarios for updating and/or replacing the root filesystem, the kernel image or even the bootloader on our embedded development system.

At the end of the second article in this series, which outlines a step-by-step process for embedded Linux development, we had the LBox up and running, ready to use for application development. On some occasions, however, the developer needs to modify the underlying system. Any Linux system can be considered to consist of three parts: the root filesystem, the kernel image and the bootloader (the BIOS plays this role in the desktop system). Typically, we leave the bootloader alone--at least we hope to--and modify the root filesystem, the kernel image or both.

With this need for modification in mind, Part 3 of this article series consists of four sections:

  • Memory organization and filesystem layout

  • Replacing the kernel and root filesystem

  • Replacing the JFFS2 filesystem

  • Replacing the bootloader

Some of these activities can be dangerous and may result in a non-functional system. Recovery from that state will be discussed in the fourth and final installment of this introductory sequence.

We continue to work with the SBC (single-board computer) we used in Parts 1 and 2 of this series, the LBox from Engineering Technologies Canada Ltd. Nevertheless, much of the material has broader applications and should be useful for a variety of target platforms.

Memory Organization and Filesystem Layout

To replace the root filesystem and/or kernel image intelligently, it is useful both to understand the boot-up process in a general way and to have a grasp of memory organization. Useful details can be obtained from the SBC vendor; if Linux is resident, the operating system itself can be a source of information. In particular, when connected to the LBox we found these Linux commands to be informative: dmesg, df, cat /proc/mtd, cat /proc/meminfo and cat /proc/mounts.

The memory and filesystem layout differ in their details, depending on the SBC. Using the aforementioned commands and information from the vendor, the following information emerges. Our LBox memory consists of 4MB of Flash memory and 8MB of SDRAM. At the start of the boot process, the RAM is not yet deployed and the Flash organization is as follows:

Bootloader (colilo)

  • device is /dev/mtd0

  • space provided = 0x0000E000

  • location: 0x00000000 -> 0x0000E000

Config

  • device is /dev/mtd1

  • space provided = 0x00002000

  • location: 0x0000E000 -> 0x00010000

Image (root filesystem and kernel image, both compressed)

  • device is /dev/mtd2

  • space provided = 0x00100000

  • location: 0x00010000 -> 0x00110000

JFSS2 (Journaling filesystem to be mounted during boot)

  • device is /dev/mtd3

  • space provided = 0x002F0000

  • location: 0x00110000 -> 0x00400000

At boot, the typical SBC with Linux resident has a bootloader that finds the compressed kernel image and root filesystem in Flash, decompresses them into RAM and transfers control to the decompressed kernel in RAM. The kernel then completes the initialization of the system.

The LBox provides a specific example of the foregoing. When it powers up, the bootloader, in Flash, begins executing. It decompresses the root filesystem and the kernel image and moves them into the 8MB of SDRAM. In addition, part of the SDRAM is used for the root filesystem, which is set up as a ROM filesystem. Then, a ramdisk, /dev/ram1, is mounted on /var. Finally, the JFFS2 filesystem, /dev/mtdblock3, is mounted on /etc/config. As a result, the root filesystem, originally a totally ROM filesystem, has been modified by the mount events to include read/write areas--a ramdisk and a JFFS2 area. Things to notice:

  • The ROM filesystem intrinsically is read-only and its contents will be reconstituted at the next boot sequence.

  • The ramdisk is volatile and its contents will be lost at power down.

  • The JFFS2 filesystem is on Flash and its contents will persist through power-down events, so that it emulates a hard drive.

The filesystem organization of a pristine system, after boot, looks like this:

  • root file system (romfs) in RAM, read-only

    /dev/root mounted on /

    size = 1113 kbytes

  • ramdisk (ext2 file system) in RAM, read/write

    /dev/ram1 mounted on /var

    size = 115 kbytes

  • emulated hard drive (JFFS2 filesystem) in Flash, read/write

    /dev/mtdblock3 mounted on /etc/config

    size = 3008 kbytes

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Embedded Linux Development, Part 4

Ashish's picture

Hello,

When will the next and final installment of this series,
i.e, Part 4 of this article, be available ?

Thanks.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState