[linuxkernelnewbies] RootFilesystem < PPCEmbedded < DENX

Sun, 08 Mar 2009 08:02:23 -0700

http://www.denx.de/wiki/PPCEmbedded/RootFilesystem

13. Root Filesystem

The kernel needs a root filesystem to mount at startup. There are many options, and the best one will generally depend on whether your system needs to be able to store persistent data (which must survive power cycling) in the field.

See http://lists.linuxppc.org/listarcs/linuxppc-embedded/200003/msg00067.html

Your best bet is likely to be the root filesystem from HardHatLinux. Extract all the RPMs matching *.noarch.rpm, and use the image in opt/hardhat/devkit/ppc/8xx/target as the root filesystem.

13.1. NFS Mounted

During development, the embedded system can NFS-mount its root filesystem from your file sever to provide a complete diskless Linux system. The file server need not be the same architecture as the embedded client. Answer "Y" to the kernel configuration questions regarding NFS client and root filesystem via NFS, and "make zImage". The embedded system will attempt to mount its root filesystem from the server as /tftpboot/<ipaddress>, where <ipaddress> is its IP address. Install your root filesystem image in this directory as root on the server, and export the directory tree with an entry in /etc/exports on the server, like: 

/tftpboot   (rw,no_root_squash)

If your system has a hard disk, you can start by using NFS then build a root file system on the disk and boot from that.

If your system has no network, you may want to start developing on a board that does.

13.2. Initial Ramdisk: initrd

To make a diskless system standalone, you need an initial ramdisk image containing an ext2 filesystem to put in arch/ppc/mbxboot/ramdisk.image.gz. Then, build with make zImage.initrd and the ramdisk image will be mounted as the root filesystem at startup. See Documentation/initrd.txt in the kernel source tree.

You need to select both CONFIG_BLK_DEV_RAM and CONFIG_BLK_DEV_INITRD to build zImage.initrd. You also need a file in arch/ppc/mbxboot called ramdisk.image.gz. When you build zImage.initrd, the secondary boot loader is re-compiled with INITRD_OFFSET and INITRD_SIZE set, which are used to locate the start and end of the ramdisk.image.gz file in memory. The start and end are passed to the kernel in registers (r4/r5??), which it saves into the variables initrd_start and initrd_end. The secondary boot loader also changes the kernel command line arguments so that 

root=/dev/ram
instead of 
root=/dev/nfs

The kernel does various things if initrd_start is non-zero, but the main one is to decompress the ramdisk.image.gz data into ramdisk 0, and because 

root=/dev/ram
this is then mounted as the root filesystem.

If your ramdisk is larger than 4 MB, you will need to add 

ramdisk=xxxx
to the kernel command line at boot time, or modify drivers/block/rd.c.

Beware that the CPU6 workarounds in the MontaVista? 2.2.x kernel clobber the kernel command line, and cause the initial ramdisk mount to fail. See the thread at http://lists.linuxppc.org/listarcs/linuxppc-embedded/200004/msg00103.html

A number of ways to create an initial ramdisk image are described below. For more information on building a root filesystem, see the Bootdisk HOWTO at http://www.linux.org/docs/ldp/howto/Bootdisk-HOWTO/buildroot.html

13.2.1. Examples

An example ramdisk.image.gz is already included in the HardHat kit.

A simple ramdisk for use with ppcboot is available at the Denxftpsite.

13.2.2. Using a ramdisk

You can also create your own on your development machine in a filesystem on /dev/ram. If your ramdisk is larger than 4 MB, you will need to increase the default ramdisk size on your development machine accordingly.

LILO users can do this by adding the following line to the first section of /etc/lilo.conf: 

ramdisk=65536

There is no real harm in asking for an excessive size, as /dev/ram* only allocates pages it actually needs to the ramdisk. However, you should use the blocks-count parameter to limit the filesystem size when you run mke2fs to prevent it creating unnecessarily large filesystem structures.

13.2.3. Using the loop device

Another approach is to use the loop device on your Linux development host to mount the ramdisk image as a local filesystem, and then copy the files you require into it. To allow users to mount the ramdisk.image on /mnt/loop with 

mount /mnt/loop
dd the following entry to your /etc/fstab: 
/path/to/ramdisk.image  /mnt/loop       auto    user,noauto,rw,loop     0 0

Note that the minix file system code in Linux is not endian-independant, so you can't build a minix file system image on an x86 machine and expect to read it on a PowerPC machine. ext2 does not suffer from this problem.

For more info, see the Loopback-Root-FS HOWTO at http://linuxdoc.org/HOWTO/mini/Loopback-Root-FS.html

13.3. ROMFS Flash Filesystem

Search for ROMFS.

13.4. cramfs

The 2.4 kernel series has a compressed read-only filesystem (cramfs) aimed at embedded systems, which can be back-ported to 2.2 kernels. If you're cross- developing, you need to modify mkcramfs to swap between little and big endian.

It turns out that cramfs is not supported for a root fs or initrd. Basically, the kernel checks a hardcoded list of supported filesystems and if the MAGIC number doesn't match it bails.

13.5. ramfs

ramfs from the 2.4 kernel is a simple filesystem ideal for use in a ramdisk. It can be used in combination with a cramfs read-only root filesystem, to mount writable filesystems on /tmp and /var, which typically need to be writable. This combination is ideal for systems which don't require persistent storage.

13.6. Journaling Flash FileSystem?(JFFS)

JFFS allows persistent storage, optimised for flash memories rather than block devices like hard disks. It is aimed at providing a crash/powerdown-safe filesystem for disk-less embedded devices and is a better option than the cramfs/ramfs combination if your application requires persistent storage. You use it with the MTD subsystem.

Reply via email to