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.
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.
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
An example
ramdisk.image.gz is already included in the
HardHat?
kit.
A simple ramdisk for use with
ppcboot is available at the
Denxftpsite?.
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.
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
Search for
[[http://lists.linuxppc.org/cgi-bin/wilma/wilma_glimpse/linuxppc-embedded?query
=romfs][ROMFS]].
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.
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.
http://www.developer.axis.com/software/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.
