The kernel is only one part of a Linux system. The root file system is a necessary component for a running system and is frequently overlooked when assessing a Linux distribution supplied with a board. Because you have many more degrees of freedom when creating a root file system, making an inventory of what's present is important along with making sure the source code is available. The most common accounting unit for a root file system is a package. The package contains a set of files that provide certain functionality. Although there are package managers that aid in building desktop distributions, such as dpkg and RPM, a package need not be more than a tar file. The goal of the packaging system is to make it easy to build a root file system from packages so that the root file system can contain the necessary functionality while being as small as possible. Technologies like dpkg and RPM rely on technologies like tar to gather files into a single binary and keep track of metadata like how to build the package, what types of files it contains, and scripts to run at installation to ensure the package is ready to use. RPM and dpkg contain package dependency information, meaning that each package can state what other packages must be installed for it to work correctly. This dependency information is perhaps the driving reason to use these systems over tar. You must know three critical things about an RFS, each of which is summarized here:
• The format of the file system: How is the root file system packaged and made available to the kernel?
• Sources, patches, and build instructions: Where are the sources so the software can be rebuilt? If there are patches, how should they be applied?
• Suitability for your project: Can what's supplied serve as the core of the project, or what else is necessary?
The root file system for an embedded board can be delivered in the following forms. The second and third options are about the same but are different enough to merit some separate discussion. The first case, where the root file system is delivered as a large file with the expectation that it will be copied onto a flash device, is a little more difficult to look at without booting the board:
• As a file system image: This is a file that is designed to be burned into flash on the board. File systems in this format are usually cramfs, jffs2, or yaffs2 file systems but can be any file system type.
• As a tar file, probably compressed: If delivered like this, the engineers who created the file system used the tar create command to put everything together. • As a directory containing the files for the root file system: If the root file system is small enough and the distribution is on some type of CD media, the step of compressing the RFS was skipped.
• Integrated with the kernel: Initial RAM disks are becoming popular ways to include a root file system with a kernel, and for good reason, because they do the booting process. An initial RAM disk is a file system stored with the kernel and uncompressed into memory at boot time.
In all cases, booting the board and using the on-board tools to view the contents is the fastest way to seeing what's in the root file system. However, the first three methods easily allow inspection of the file system without booting the board, which may be preferable if the vendor didn't include a working kernel. Extracting the root file system that is an initial RAM disk involves dissecting the kernel and extracting the root file system. You can do so as follows:
$ mkdir ~/board-rfs $ cd ~/board-rfs $ s<cross-tools>-objdump -j .init.ramfs -O binary <kernel image> \ /dev/stdout | gunzip -cd | cpio -i
The last command uses the objdump tool to extract the part of the binary .init.ramfs where this data resides and write the output to /dev/stdout, which is the console. That output is piped to gunzup, which uncompresses it and then sends the results to cpio; cpio extracts the contents and writes them on the disk. Extracting the data from the tar file is also easy. Do the following to put the RFS into the ~/boardrfs directory:
$ mkdir ~/board-rfs $ cd ~/board-rfs $ tar zxf ~/<file-with-rfs>.tar.gz
If the root file system is a file that's ready for burning onto flash, the process of viewing the content is a little more complex. The root file system is mounted via a loopback device instead of being unpacked into a directory. The notion of a loopback is simple: it makes the contents of a file appear to be a block device. You mount a cramfs file system via a loopback device like so:
# mount –o loop –t cramfs ~/board-rfs-file ~/board-rfs
However, mounting a jffs2 or yaffs2 file system the same way doesn't work. The jffs2 and yaffs2 file systems expect to mount a memory technology device (MTD), which isn't the block device that using -o loop creates. MTDs are different from block devices and can't be treated as such. MTDs are flash memory, similar to what is used on a USB drive, but an MTD doesn't have the additional software to provide wear-leveling that's present on a USB drive. In order not to wear out flash memory, you must take care not to write to one area of the flash device much more frequently than another. The action of spreading writes over the flash media is called wear leveling; this is done by specialized file systems geared for using flash media. Note that USB flash drives contain wearleveling software in the drive hardware. To mount this sort of file system, the host system needs a mechanism for making a file look like it's a MTD device; the thing that does that is the mtdram module. This software emulates how an MTD device works in software and is available as a kernel module that is installed when you add the mtd-tools package:
# modprobe mtdram total_size=65536 erase_size=128
Check to make sure this works.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Josh Booth at 01232010
1. Basics to understanding the structure of an embedded Linux system
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.