DiskOnChip (DOC) is a flash drive that is manufactured by M-Systems. The use of flash drives is emerging as a substitute for Hard Disks in embedded devices. Embedded Linux is gaining popularity as the operating system of choice in the embedded systems community; as such, there is an increased demand for embedded systems that can boot into Linux from flash drives.

Much of the documentation currently available on the subject is either incorrect or incomplete; the presentation of the information which is provided by such documents is likely to confuse novice users.

Another fundamental problem is that most of the documents assume the DiskOnChip to be a NFTL (NAND Flash Translation Layer) device, and proceed to describe the booting process for NFTL devices. DiskOnChip architectures come in two variants, each of which requires different booting procedures: NFTL and INFTL (Inverse NFTL). Dan Brown, who has written a boot loader known as DOCBoot, explains the differences between these variants in a README document, which is included with the DOCBoot package: http://ftp.arm.linux.org.uk/pub/people/dwmw2/mtd/cvs/mtd/docboot/.

An INFTL device is organized as follows:

Under Linux MTD partitions are created for each partition listed in the INFTL partition table. Thus up to 5 MTD devices are created.

By contrast the NFTL device is organized as follows:

Under Linux, normally two MTD devices will be created.

According to the above excerpt, the process used by the boot loader when fetching the kernel image for an INFTL device is different from the method used for NFTL devices, since both devices have different physical layouts. (repetitive)

Using a 2.4.x kernel for an INFTL DiskOnChip device is complicated by the lack of native support in pre-2.6.x kernels (although native NFTL support is present). Such functionality is only available by patching the kernel; an approach which is ill-advised.

Patching the kernel with external INFTL support is discouraged; the developers of the MTD driver, the open source driver available for DiskOnChip, are apprehensive of this approach as well. For more information on this matter, feel free to peruse the mailing list conversation on the subject at http://lists.infradead.org/pipermail/linux-mtd/2004-August/010165.html.

The drivers that provide native INFTL support in the 2.6.x kernels failed to identify the DiskonChip device used for this exercise, and the following message was reported by the system:

INFTL no longer supports the old DiskOnChip drivers loaded via docprobe.  
Please use the new diskonchip driver under the NAND subsystem.

So then we decided to use the drivers provided by M-Systems (manufacturer of DiskOnChip). However, according to the documentation provided by the vendor on these drivers, they were designed for NFTL devices only. As such, we decided to write this HOWTO which will address the use of INFTL devices. We have taken special care to remove any ambiguity in the steps and also tried to give reasons for the need of a particular step so as to make things logically clear. We have explained things in such a way that a person with less experience on Linux can also follow the steps.

This document aims to act as a guide to:

The method described here has been tested for DiskOnChip 2000 TSOP 256MB and DiskOnChip 2000 TSOP 384MB.

Download a fresh copy of Kernel 2.4.18 from http://www.kernel.org/pub/linux/kernel/v2.4.

The kernel that is downloaded from the site does not have support for the M-Systems driver so we need to add this functionality. This is done by adding a patch to the kernel.

The steps to conduct patching are as follows:

Before moving on to Step 2, do the following:

Complete the following tasks for compiling the kernel:

Check for lib/modules/2.4.18/kernel/drivers/block/doc.o. This is the M-Systems driver that we need to access DiskOnChip.

Now we will create block devices, which are required to access the DOC These block devices will use the M-Systems driver that was built in Section 4.2, “Step 2: Compile the Kernel” to access the DOC. The script mknod_fl in linux_binary.5_1_4/doc-linux-5_1_4_20/driver is used for this purpose.

We need to create the block devices with the major number of 62. For this purpose we will pass the argument 62 while creating the nodes:

This will create the following devices in /dev/msys with major number 62:

fla...fla4
flb...flb4
flc...flc4
fld...fld4

In order to have the DiskOnChip recognized by Linux OS, we need to insert the DOC driver module into the kernel. Since the currently running kernel doesn't have support for the M-Systems Driver, we need to boot into new kernel we just compiled in Section 4.2, “Step 2: Compile the Kernel”.

For this purpose we need to add the following entries in the /boot/grub/menu.lst file:

title Debian GNU/Linux,Kernel 2.4.18
root (hd0,7)
kernel /boot/vmlinuz-2.4.18 root=/dev/hda8
safedefault
boot

Where (hd0,7) is the partition holding the kernel image vmlinuz-2.4.18 and /dev/hda8 is the partition holding the root filesystem. These partitions may vary from one system to another. Now reboot and choose the kernel 2.4.18 option (the kernel that has been compiled in Step 2) in the grub menu to boot into the new kernel.

The M-Systems driver by default gets loaded with major number 100, but our newly created nodes (see Section 4.3, “Step 3: Create Nodes”) have a major number 62. Therefore we need to insert this module with a major number 62. This can be done in either of two ways:

Check for the correct loading of the module using the lsmod command without options.

Before we can start using DiskOnChip we need to create a filesystem on it. We will create an ext2 filesystem since it is small in size.

This involves a hidden step of making partitions on the DOC using fdisk. The actual steps are as follows:

Create a new mount point for the DiskOnChip in the /mnt directory:

Mount the DOC partition on the newly created directory:

You will now be able to read and write to the DOC as an additional storage drive.

When you reboot your system, make the DOC available by inserting the driver into the kernel (see Section 4.5, “Step 5: Insert M-Systems Driver/Module in the new Kernel”) and mounting the device.

We will use the dformat utility from linux_binary.5_1_4/dformat_5_1_4_37.

M-Systems does not provide the firmware for using the DOC on Linux platforms. We address this problem by making a copy of the firmware shipped with the M-Systems dos utilities into this directory (“dos utilities” is the term used by the M-Systems people so we have also used this name). On our system we copied it by mounting the windows partition and extracting it from there:

Now format the drive, using the dtformat from linux_binary.5_1_4/dformat_5_1_4_37/:

D000 specifies the address of the DiskOnChip in the BIOS.

The following is the BIOS (RTD Enhanced Phoenix - AwardBIOS CMOS Setup Utility (v6.00.04.1601)) setting on our system.

The Integrated peripherals of the BIOS menu should have:

SSD Socket #1 to Bios Extension
Bios Ext. Window size 8k
Bios Ext. window [D000:0000]
Fail safe Boot ROM [Disabled]

The Bios Ext. Window denotes the address for your DiskOnChip.

Now shutdown the system and boot into Windows XP.

From now on you will notice the TrueFFS message and some time delay before the Grub Menu appears.

Boot into Windows XP. We will use the M-Systems Dos Utilities for formatting the DiskOnChip. The Dos utility dformat will copy the firmware to the DOC, and then format it as a fat16 device.

Using the command prompt, run the following command from the DOS utilities folder (assuming that you have already downloaded the DOS utilities):

Check the DOC partition using another utility called dinfo. A sample dinfo output is given in the appendix.

Again shutdown the system and now boot into Linux.

Even though Step 1 and Step 2 seem to be the same, the only difference being that Step 1 is done from Linux and Step 2 from Windows XP, they both have to be done.

This has to be performed in exactly the same manner as described in Section 4.1, “Step 1: Patch the Kernel” and Section 4.2, “Step 2: Compile the Kernel”.

Also add an entry for the new kernel in /boot/grub/menu.lst as described in Section 4.4, “Step 4: Reboot with the new kernel”.

This is done using the ame procedure as described in Section 4.3, “Step 3: Create Nodes”.

The file /etc/modules.conf has to be modified, adding this line at the end of the file:

options doc major=62

This is required since our nodes use a major number of 62, while the doc driver module uses a major number of 100. When creating the initrd image, the driver will be loaded with major number value of 100 (instead of 62) if you do not edit the module configuration file. This will make it impossible for the nodes to use the driver. The reason for using the initrd image will be explained in the next step.

The mkinitrd_doc script from linux_binary.5_1_4/doc-linux-5_1_4_20/driver reads the /etc/modules.conf file and looks for anything that has been mentioned for the DOC driver regarding the major number. By default, mkinitrd_doc will create an initrd image that loads the DOC module with a major number of 100. However, with the modifications we have made to the /etc/modules.conf file, the initrd image will load the module with a major number of 62.

Run the mkinitrd_doc script from linux_binary.5_1_4/doc-linux-5_1_4_20/driver/:

This may give warning messages similar to the following, which can be safely ignored:

  cp: cannot stat ./sbin/insmod.static.: No such file or directory
  cp: cannot stat ./dev/systty.: No such file or directory

Check for the newly created initrd image, initrd-2.4.18.img, in the /boot directory.

Running the mkinitrd_doc script produces this image. The reason for making an initrd image is that the provided M-Systems driver cannot be added as a built-in support in the kernel, which leaves no other option than adding it as a loadable module. If we want to boot from DOC, the kernel should know how to access the DOC at the time of booting to search for /sbin/init in the root filesystem on the DOC (the root filesystem is necessary to get the Linux system up).

In the booting sequence of the Linux, /sbin/init is the file (a command actually) that the kernel looks for in order to start various services and, finally, give the login shell to the user. The figure below illustrates the problem:

Figure 1. Why we need an initrd image

Reboot the system and boot into the newly created kernel.

Now insert the doc module:

This will give the following messages:

fl : Flash disk driver for DiskOnChip
fl: DOC devices(s) found: 1
fl: _init:registed device at major 62
.
.
.
.

To access the DOC, ensure that the major number assigned to the nodes is 62.

In case of a major number of 100 is assigned, check if the /etc/modules.conf was successfully modified. If it was not, then repeat Section 5.5, “Step 5: Modify the /etc/module.conf file”. You must then also repeat Section 5.6, “Step 6: Create the initrd image” because the initrd image depends on /etc/modules.conf. If the DOC entry were incorrect in this file, the initrd image will be useless.

Perform Section 4.6, “Step 6: Create a filesystem on the DiskOnChip”. This is required to create partitions on the DOC.

Before starting with this step make sure that you have not mounted /dev/msys/fla1 on any of the mount points, as this step will involve reformatting the DiskOnChip.

Also, in order to understand the details of Root File system refer to The Linux Bootdisk How To available at http://www.tldp.org.

We will use the mkdocimg script located in linux_binary.5_1_4/doc-linux-5_1_4_20/build.

We will also use the redhat-7.1.files directory, located in the same directory (i.e. build), which contains the list of the files that will be copied in the root filesystem that will be created on the DOC.

This step will take a few minutes to complete.

Now mount the /dev/msys/fla1 partition on the mount point /mnt/doc and check the files that have been created:

The following directories are created on the DOC as a result of running the script:

bin dev sbin etc lib usr home mnt tmp var boot

The most important is the boot directory. This contains the vmlinuz-2.4.18 and initrd-2.4.18.img which gets copied from the /boot directory. This directory is required when booting from DiskOnChip.

Apart from these files there are some other files which must be deleted:

These two files are created later by LILO.

The redhat-7.1.files directory contains a list of files and directories that will be created when we use the mkdocimg script.

This script does not create all the files that are necessary for creating the root filesystem on the DOC. So replace the directories created by the mkdocimg script, with the directories of the / filesystem (root filesystem that is currently running).

The directories under /, such as etc, sbin, bin and so on contain lot of files that are not useful and ideally should not be copied while building the root filesystem for DOC. But since we have not discussed the files that are essential and the files that can be removed, we therefore suggest that one should copy the entire contents of the directories. We know that it is a clumsy way of building the root filesystem and will unnecessarily take lot of memory; bear with us as in the next section we will explain how to put the development tools on the DOC. We will then remove the useless files from the root filesystem of DOC.

If you are aware of how to build the root filesystem we would encourage you to copy only the essential files.

The following is the set of commands we used to modify the root filesystem:

Now our filesystem is ready.

The total size occupied by this filesystem will be about 35Mb.

This step is required to specify the location of the DOC root filesystem to the kernel we compiled in the step 3. The step can be avoided by giving the details of the root filesystem location in the Boot Loader configuration file, but we had some problems in making the kernel locate the root filesystem at the time of booting so we recommend executing this command:

We are going to use LILO as the boot loader since this is the only BootLoader that can read an INFTL device without many changes to be done to the BootLoader source code.

For more information on how LILO and other boot loaders operate, refer to Section 7, “References”.

We need to compile the lilo-22-3.2 source code to get the executable file for LILO.

We will use the source code from linux_binary.5_1_4/doc-linux-5_1_4_20/lilo/lilo-22.3.2.

Before starting the build we need to do the following:

Now we can start the build process. Run

This will create a new LILO executable, linux_binary.5_1_4/doc-linux-5_1_4_20/lilo/lilo-22.3.2/lilo. Copy this LILO executable into /sbin/lilo and /mnt/doc/sbin/lilo:

We need to copy the file boot.b from linux_binary.5_1_4/doc-linux-5_1_4_20/lilo/ to /mnt/doc/boot.

The file contains the essential stage1 and stage2 of the LILO boot loader.

First, remove the existing /etc/lilo.conf:

Now create a new /etc/lilo.conf, using a text editor, and add the following lines to it:

boot=/dev/msys/fla
compact
install=/boot/boot.b
map=/boot/System.map
disk=/dev/msys/fla
bios=0x80
prompt
delay=50
timeout=50
image=/boot/vmlinuz
label=linux
root=/dev/msys/fla1
initrd=/boot/initrd.img
read-only

According to the above lines added to /etc/lilo.conf, one needs to create soft links for vmlinuz-2.4.18 and initrd-2.4.18.img in /mnt/doc/boot:

Copy the newly created /etc/lilo.conf to mnt/doc/etc/lilo.conf.

This step will configure LILO in the MBR of the DiskOnChip and hence make the DiskOnChip bootable.

Ensure that /dev/msys/fla1 (root filesystem partition for the DOC) is mounted on the mount point /mnt/doc.

Execute the following command to store the LILO configuration on the DOC:

/mnt/doc denotes the location where the BootLoader will be installed, so it is installed on the DiskOnChip, as /mnt/doc is the mount point for the primary partition of DOC where LILO was configured.

It will create the following two files in the boot directory of DOC (i.e. /mnt/doc/boot):

Now you should make a backup of the entire DiskOnChip to allow for easy restore of the files damaged by possible fatal errors:

This will create a compressed copy of all the contents of DiskOnChip with the name docimg.tgz in /home.

Open the /mnt/doc/etc/fstab file and edit the line where the mount point is /. Change that line to:

/dev/msys/fla1  /  ext2  rw.noauto 0 1

This step is required to update the firmware of the DiskOnChip. We will use the dformat utility from linux_binary.5_1_4/dformat_5_1_4_37:

The above command will cause the DiskOnChip to boot in the absence of any other bootable device. So we need to remove the Hard Disk in order to allow the DOC to boot.

Check your BIOS manual for enabling booting from a BIOS extension device i.e. DiskOnChip. On our system we had to disable the Hard Disk and CDROM and set the first bootable device as HDD-0.

Reboot the system after making the necessary changes in the BIOS.

You will get the LILO menu and on pressing enter Linux gets booted from DiskOnChip.

Download root_fs_i386.ext2.tar.gz from www.uclibc.org/downloads/root_fs_i386.ext2.tar.gz.

It is around 22MB in size. This actually gets decompressed to a 100MB size file.

Untar the file in /usr/src:

This will create a file root_fs_i386.ext2.

We need to mount this file using a loopback device. Do the following steps:

Now you can access the content of the file root_fs_i386.ext2 through the root_fs directory. The root_fs directory contains a number of directories which makes the root filesystem, like bin, var, sbin, opt, root, home, etc, usr, lib, tmp, dev, and proc.

The usr and lib directories contain the development tools like gcc and g++.

Replace the bin, var, sbin, etc, lib, usr, proc, mnt, home and opt directories of the DiskOnChip with the ones of the root_fs image.

Open the newly replaced /mnt/doc/etc/fstab and edit the line where the mount point is /. Change that line to:

/dev/msys/fla1  /  ext2  rw.noauto 0 1

Reboot from DiskOnChip and enjoy the uClibc development environment.

You will get the message

Welcome to the Erik.s uClibc development environment.

The entire root filesystem + boot directory + development tools take 84Mb of space.