< Exit > < Help > │To save on space, a hierarchical listing of options that must be selected is shown below.
Busybox SettingsTo build BusyBox, simply type in make at the command line.
After a few minutes the compile should be complete. When compilation is
complete install BusyBox to the target directory. The make and install
commands are show below:
[root@localhost busybox-1.2.2.1]# make # make CONFIG_PREFIX=/home/user/target install Configure the New Target Root File System
Looking at the newly built root file system, there are only three
subdirectories of binaries and a symbolic link of bin/busybox to
linuxrc. More directories must be created before the file system can be
used. Some device nodes should be created, too.
[root@localhost bin]# cd /home/user/target/ # dir Create the dev, dev/pts, etc, etc/init.d, lib, mnt, opt, proc, root,
sys, tmp, var, and var/log directories. Also create the device node for
the initial console.
[root@localhost target]# mkdir dev # mknod dev/console c 5 1 # mkdir dev/pts # mkdir etc # mkdir etc/init.d # mkdir lib # mkdir mnt # mkdir opt # mkdir proc # mkdir root # mkdir sys # mkdir tmp # mkdir var # mkdir var/log Since 2.6.11 the debugfs has been introduced and so you may
optionally create a directory called debug for mounting the debugfs.
[root@localhost target]# mkdir debug To have the /proc and /dev/pts file systems mounted at boot time, the
file etc/fstab must be created in the etc directory. Use an editor to
create the file. The example below uses vi to create the file. The two
lines to enter into fstab are shown below the vi fstab line.
[root@localhost target]# cd etc # vi fstab The login utilities use the files group, hosts, and passwd in the etc
directory for logging in. For now, only root needs to be defined in
group and passwd while hosts just needs to have localhost defined. The
contents of the three files are show below:
[root@localhost etc]# vi group # vi passwd # vi hosts The kernel starts “/sbin/init” after it boots (actually the kernel
attempts to execute several known programs until one succeeds). Init
reads the etc/inittab file to determine what to do at start up,
shutdown, or when a user logs in. These inittab files can get quite
complicated. A simple one is shown below:
[root@localhost etc]# vi inittab The “sysinit” line tells init to run the /etc/init.d/rcS script to set up the system. The rest are self explanatory.
A simple etc/init.d/rcS file could assume file systems existed in
the kernel and would simply mount the mount points as needed. A more
complicated one would test for the existence of file systems and if
found, mount them; if not found, find ways to still get the system
booted.
The author has taken the etc/init.d/rcS and mdev.conf files from
the V2.6.22.18-OMAP3 release for a simple example. The rcS script will
test for the existence of file systems and mount them accordingly. The
1.11.1 version of BusyBox does not create a link for /bin/sh so change
any /bin/sh to /bin/ash. The contents are shown below:
[root@localhost etc]# vi init.d/rcS Please note that in more recent kernels (2.6.29 and newer) the sysfs
entries shown above to disable power management and control the LCD
inactivity timeout shown above have been removed. For latest details on
using OMAP Power Management in Linux please refer to .
To automatically mount the debugfs on start-up the following can
be added to the above rcS file. Please note that the debugfs needs to be
selected in the kernel configuration and built into the kernel before
you can mount it. The below script checks to see if the debugfs is
supported by the kernel before attempting to mount the file-system. To
enable the debugfs run "make menuconfig" and go to "Kernel Hacking" and
select "Debug Filesystem".
cat /proc/filesystems | grep -q debugfsAfter saving the file, change its access permissions so that it is executable for all.
[root@localhost etc]# vi mdev.conf Add the Shared Libraries Applications will Require
Various applications will be built using the libraries in the tool
chain so the runtime libraries must be copied to the root file system.
Care should be taken to only copy the libraries that are required so
that the root file system does not grow based on unused libraries. This
note will simply demonstrate how to copy all the shared libraries to
the root file system and strip out any debug information from the
libraries.
In the Code Sourcery tool chain, most of the libraries are found
in the /opt/arm-2007q1/arm-none-linux-gnueabi/libc/lib directory.
Simply copy these files to the root file system, maintaining symbolic
links and then strip out unneeded debug information.
[root@localhost user]# cd /home/user/target/lib # cp –r /opt/arm-2007q1/arm-none-linux-gnueabi/libc/lib/* . # arm-none-linux-gnueabi-strip * Some libraries might be in other directories in the tool chain; those
would have to be found on a “trial and error” basis when applications
do not load because of a missing shared library.
A minimal, working root file system has now been built. It will
boot, but does not have kernel modules yet. These will be added later
after testing.
Mounting the Root File System over NFS
In this scenario, the target device and the host system are connected
via Ethernet, either directly through a crossover cable or to a hub or
switch. The host must export the target file system through NFS and the
NFS server daemon must be running. For configuring and running NFS on a
Linux PC, see the HOWTOs at any Linux Documentation Internet site. In
this simple example, the exported file system is /home/user/target and
anybody can mount it via NFS. The /etc/exports file is shown below
/home/user/target *(rw,no_root_squash)On the target side, the u-boot environment variable bootargs must be
set to boot from NFS and contain the mount address of the root file
system. In the example below, the NFS server is at IP address
192.168.1.104.
[root@OMAP3EVM /] # setenv bootargs mem=64M ip=dhcp noinitrd console=ttyS0,115200n8 root=/dev/nfs rw nfsroot=192.168.1.104:/home/user/target,nolock,rsize=1024,wsize=1024 # saveenv After booting the kernel, the final boot messages should look similar to below.
Sending DHCP requests .<6>eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1: '/etc/init.d/rcS' Creating and Booting a RAMDISK
A ramdisk is simply an ext2 file system. The tools to build one are
shipped with just about every Linux distribution. The steps to build
the ramdisk from the target file system are as follows:
Change directory to the /home/user directory.
Use the dd utility to create a 16M file of “zero” that will contain the file system.
Use mke2fs to create the empty file system in the file from 2.
Mount the file to a mount point using the loop device.
Use tar to create an archive from the target and pipe it into tar to extract the target to the mount point.
Un-mount the file.
Copy it to the /tftpboot directory so that u-boot can download it to the target device.
# cd /home/user # dd if=/dev/zero of=rd-ext2.bin bs=1k count=16384 # mke2fs –F –m0 rd-ext2.bin # mount –t ext2 rd-ext2.bin /mnt –o loop # tar –C target –cf - . | tar –C /mnt –xf – # umount /mnt # cp rd-ext2.bin /tftpboot To boot the kernel with the root file system on the ramdisk, the
u-boot environment variable “bootargs” must be modified. The “bootargs”
variable contains information that gets passed to the kernel at boot up
time and has information such as memory size, ip address, where the
root file system is, what kind of file system it is, etc. For this
note, a TI OMAP 3530 EVM is used so all RAM and flash addresses are
specific to that platform.
Start up a terminal program on the host and turn on the target.
It is assumed that u-boot has already been flashed to the target board.
The ramdisk will be downloaded to RAM at address 0x81600000 and is 16M
in size. At the u-boot prompt, change the bootargs variable as follows:
[root@OMAP3EVM /] # setenv bootargs mem=88M ip=dhcp console=ttyS0,115200n8 root=/dev/ram0 rw initrd=0x81600000,16M ramdisk_size=16384 # saveenv All the text should be entered as one line.
Now download the kernel to 0x80000000 and the ramdisk to 0x81600000 and then boot the kernel.
[root@OMAP3EVM /] # tftp 81600000 rd-ext2.bin # tftp 80000000 uImage # bootm After the kernel boots, the terminal should show the usual boot up
messages and then finally indicates that the filesystem is mounted as a
RAMDISK.
RAMDISK: ext2 filesystem found at block 0: '/etc/init.d/rcS' MTD Partitions
Before discussing flash file systems, “MTD partitions” must be
explained. A flash device must be partitioned on an embedded device
just as a hard disk must be partitioned on a Linux PC. On a Linux PC
there would be a partition for /boot, a swap partition, a /usr
partition, etc. For the embedded device the partitions are usually just
for the boot loader, its environment variables, the kernel, and a flash
file system.
There is no “fdisk” for flash devices like there is for a hard
disk. Instead, the partitioning is done in software. The exact file
that does the partitioning is different based on the chip, board, CPU,
and Linux source code. For this note, the board used is the TI OMAP
3530 EVM and the kernel source is from the SDK1.0.0 release. The file
containing the MTD driver and partitions is
linux/kernel_org/2.6_kernel/arch/arm/mach-omap2/board-omap3evm-flash.c.
Looking at the file, the structure omap_partitions[ ] contains the partition table for the H4 board.
static struct mtd_partition omap3evm_onenand_partitions[] = {};
The boot loader has a partition size of 256k. The u-boot environment
variables fit in a 128k partition for ES1.0 or 256k for ES2.0. The
kernel partion is 2M while what is left is used for a file system.
When the kernel boots and the driver loads, device nodes are
created based on the partitions. The device nodes take on the form
/dev/mtdblock/x or /dev/mtdblockx.
Flash The physical address is set by u-boot. Look at the file
u-boot/include/asm/arch/cpu.h to see the flash physical address
mappings:
/* GPMC Mapping */ Creating and Booting a JFFS2 Root File System
Since jffs2 is used only on flash devices, a standard Linux
distribution does not have the tools to make a jffs2 file system. The
Internet site
explains where and how to obtain the latest source to MTD code and file
systems. mkfs.jffs2 is the tool needed to build a jffs2 file system
and the source is in this code. All of the MTD code will be downloaded
but only the code to build mkfs.jffs2 is built.
The source code is maintained in a CVS tree. CVS is version
control software and is usually installed when the Linux distribution is
installed. CVS does not work across firewalls so a direct connection to
the Internet is required. From the command line enter the following:
[root@localhost user]# cd /home/user/build # cvs –d :pserver:anoncvs@cvs.infradead.org:/home/cvs login CVS password: anoncvs # cvs –d :pserver:anoncvs@cvs.infradead.org:/home/cvs co mtd There should now be a mtd directory under /home/user/build. The
source to mkfs.jffs2 is found in the util directory under mtd. To build
mkfs.jffs2 simply change directory to mtd/util and enter “make
mkfs.jffs2”. When the build is complete, copy the mkfs.jffs2 file to
the /sbin directory; that is where the other utilities that make file
systems reside.
[root@localhost build]# cd mtd/util # make mkfs.jffs2 # cp mkfs.jffs2 /sbin With the mkfs.jffs2 utility built and in place it is now time to make
the jffs2 file system from of the target directory. Change to the
/home/user directory and enter the mkfs.jffs2 command below. Probably
the most important argument to the utility is the erase block size. For
the NAND part on the OMAP3530 EVM board the erase block is 128k
Consult either u-boot, the kernel, or the data manual for the flash part
used to find the erase block size.
[root@localhost util]# cd /home/user # mkfs.jffs2 -lqnp –e 128 -r target -o /tftpboot/rd-jffs2.bin By building the file in the /tftpboot directory, the step of copying
it over is eliminated.
The file must now be written into flash at a specific location.
In u-boot, the flash file system will get flashed to the physical
address 0x780000 and will be mounted by the kernel from /dev/mtdblock4.
The steps to perform this are:
Unprotect the flash area where the file system will reside.
Erase that area.
Download the rd-jffs2.bin file.
Write it to flash.
Modify bootargs to support a JFFS2 file system as root on /dev/mtdblock4.
Save the environment variables.
NOTE: (Not up to date - based on a different kernel – see SDK1.0.0 reprogramming scripts:
C:\OMAP35x_SDK_1.0.0\board_utilities\scripts\ reflash-samsung.txt)
[root@OMAP3EVM /] # onenand unlock 0x0 0x8000000 # mw.b 0x81600000 0xff 0x1400000 # onenand erase block 60-1023 # tftpboot 0x81600000 rd-jffs2.bin # onenand write 0x81600000 0x780000 0x1400000 # setenv bootargs mem=88M noinitrd ip=dhcp console=ttyS0,115200n8 root=/dev/mtdblock4 rootfstype=jffs2 # saveenv Boot the kernel and near the end of boot-up the following messages should be seen:
IP-Config: Gateway not on directly connected network.: '/etc/init.d/rcS' Creating and Booting a CRAMFS Root File System
Since CRAMFS is another embedded file system, the host Linux
distribution might not have the mkcramfs utility. The source to the
cramfs tools can be found at . As usual, download, build, and install them.
The first step is to edit the etc/init.d/rcS file so that the
logging daemons do not get started. Since CRAMFS is a read-only file
system, the serial console would be filled with errors as these loggers
try to write messages to disk. After that, change to the /home/user
directory and use the mkcramfs utility to create the file image. The –v
argument only says to be verbose and display messages as the file
system is built.
[root@localhost home]# cd /home/user # mkcramfs –v target /tftpboot/rd-cramfs.bin By building the file in the /tftpboot directory, the step of copying it over is eliminated.
The file must now be written into flash at a specific location.
In u-boot, the flash file system will get flashed to the physical
address 0x780000 and will be mounted by the kernel from /dev/mtdblock4.
The steps to perform this are:
Unprotect the flash area where the file system will reside.
Erase that area.
Download the rd-cramfs.bin file.
Write it to flash.
Modify bootargs to support a CRAMFS file system as root on /dev/mtdblock4.
Save the environment variables.
# onenand unlock 0x0 0x8000000 # mw.b 0x81600000 0xff 0x1400000 # onenand erase block 60-1023 # tftpboot 0x81600000 rd-cramfs.bin # onenand write 0x81600000 0x780000 0x1400000 # setenv bootargs mem=88M noinitrd ip=dhcp console=ttyS0,115200n8 root=/dev/mtdblock4 rootfstype=cramfs # saveenv Boot the kernel and near the end of boot-up the following messages should be seen:
NOTE: (Not up to date - based on a different kernel)
VFS: Mounted root (cramfs filesystem) readonly. Enhancing the Root File System
The root file system built contains only the bare minimum files to
operate. Kernel driver modules have not been added yet. Also, as
applications are built and added, the shared libraries used by the
applications will need to be added. The file system will get larger
when these files are added.
Add the Kernel Driver Modules to the Root File System
Any drivers built as modules need to be added to the target root file
system. This is fairly simple; after building the kernel, build the
modules, and then use the same kernel Makefile to install the files to
the target.
[root@localhost 2.6_kernel]# make modules # make INSTALL_MOD_PATH=/home/user/target modules_install After the second make is performed, the kernel modules will be copied
to the /home/user/target/lib/modules directory. One problem still
exists – the modules still have debug information so they are larger
than they need to be. When debug information is no longer needed, use
the arm-none-linux-gnueabi-strip utility to remove it. Unfortunately
the strip utility does not have a recursive option to go into each
directory and strip the driver. If there are only a few drivers, the
find utility can be used to find each .o file recursively and then pass
the file name to strip. An example is shown below.
[root@localhost user]# cd /home/user/target/lib/modules # arm-none-linux-gnueabi-strip `find . –name “*.ko”` Note that the ` character is the “tick” key that is on the left-hand side of the keyboard and is a lowercase ~.
RAMDISK Considerations
As files get added to the target root file system, the image size
will grow beyond 16M. The kernel must be configured to the new RAMDISK
size and re-built. See section “3.3 Configure the Linux Kernel for
RAMDISK support” for more information on how to change the RAMDISK size
in the kernel. The amount of RAM used for the RAMDISK should not be too
big so that the kernel has enough RAM to load and run programs. For
example, on a board with only 32M RAM, a 20M RAMDISK would only leave
12M for the kernel to use. This could cause a shortage of memory for
programs to run.
If a development platform has more then 32M, then that should also be
reflected in the u-boot environment variable “bootargs”. For example,
assume a development platform now has 64M of RAM. The bootargs variable
could be changed from “mem=32M” to “mem=64M”. A RAMDISK of 20M would
no longer be a problem.
One last hint on keeping the RAMDISK image small. Use the
arm-none-linux-gnueabi-strip program to strip off unneeded headers and
debug information once an application or driver has been fully debugged
and ready for inclusion in the image.
Trouble Shooting
If you are having problems booting the kernel please refer to for help.
Comments
UBIFS Root
So, how can I configure e.g. my Beagle to have its 256 MByte NAND be
managed by UBI, root on UBIFS, and boot without an MMC card?
Naruto1980 said ...
SanjeevPremi said ...
The swap space can be enabled at run-time
Though most of the steps described in this page are 'host-side', this
information is related. Can be included appropriately in the topic
above:
Identify the space available for creating a swapfile.
A general guideline is to create this file 2x the size of available RAM; but it isn't rule.
Create a swap file (e.g. /swap/swapfile):
# dd if=/dev/zero of=/swap/swapfile bs=1024 count=256
# mkswap /swap/swapfile
# swapon /swap/swapfile
