Contents
- Introduction and Prerequisites
- Preparing the Hardware and OS
- Compiling the kernel
- Installing and testing the kernel
- Working with the DOC
- Failures
- Links
Introduction and Prerequisites
This document goes through the process of setting up a Linux system
to recognize and use the M-Systems DiskOnChip (DOC). We have chosen not to use the M-Systems driver because (a) it is reportedly not stable or efficient, (b) The drivers are not done in the
"standard" Linux way, and are therefor confusing, (c) it is closed source, and as a result (d) it does not work well with kernels that are not the _exact_ match of the M-Systems build. Besides
that, the 2.4 kernel includes drivers for DOC anyway. The Linux Memory Technology Devices (MTD) package contains a well built set of drivers that are more effective and useful than the M-Systems suite. This
document will cover using the MTD package.
It is assumed that the reader is familiar with (a) Linux in general, (b) file systems, (c) generic block devices (d), mounting, formatting, and other file
system tasks. It is not assumed that the reader is a kernel hacker, storage expert, or low-level C coder. Those readers would probably do better reading the MTD source and READMEs. Any reader attempting to
tackle this project will need a Linux machine with root permissions and a board capable of supporting a DOC. I am using an Allwell STB3036 with an IDE drive and a second power supply. Preparing the Hardware and OS
Set up a hard disk with some
version of Linux. I recommend an out-of-the-box distro with the 2.4 kernel. Make sure you install the kernel source and headers, and everything you'll need to build the kernel. Systems using RPM or DEBs
should install all that stuff for you. The drive I am using now has Mandrake 8 on it, but the stuff we're doing is fundamental enough that it ought to work with just about any 2.4 system.
On the Allwell
3036 STB, I plugged the HDD into IDE1 (master on IDE1 = hdc) and the CDROM into IDE0. I removed the DOC from it's socket during the install. I just did a standard install and then tweaked and installed the
stuff I needed. I configured networking on mine (to use FTP), and set the initial runlevel to 3 (Multi-user, no X). I configured SSH so I could do most of the grunt work from my normal workstation. This is
not necessary, but I prefer doing things this way. Compiling the Kernel
Oh, yes! You of faint heart that fear the recompilation of the kernel will just have to get over it.
Most distros with 2.4 kernels now come with MTD support.
However, the flags set during compilation are usually wrong. I have yet to see a distro that supports DOC out of the box. Here, you have two choices for rectifying the situation: recompile the sources for
your distro, or download new copies of the source and MTD stuff and start over. Since the first is pretty similar to the second, I'm not really going to discuss it. If you want to just recompile the source
included with your distro, continue reading this, consult the directions included with your distro for recompiling the kernel, and try to arrive at a happy medium between the two.
Compiling the Linux
kernel is a well documented subject. I found it sufficient to read the README files included with the source. If that is not enough, there are How-To's, articles, and even manuals that cover the topic. I'm
just going to cover the parts important to this article.
Download the source for the kernel. I've been working with 2.4.5 recently, but the newest stable release will be the best (NOTE: 2.4.9 is the most
recent kernel. The MTD stuff in this kernel is much better. It is recommended that you use the most recent stable kernel.). Optionally, you may want to download the newest MTD package (links to both kernel
and MTD are at the bottom of this article). Create a directory for development. I'll call it $DOC for shorthand. Move the kernel source and MTD into this directory and untar/zip/bzip them:
$ cd $DOC
$ mv ../../kernel.tar.bz $DOC
$ mv ../../mtd-linux.tar.gz $DOC
$ tar xvjf kernel.tar.bz
$ tar xzvf mtd-linux.tar.gz
If you got the mtd source, cd to $DOC/mtd/patches and follow the instructions in the README. In most cases, this simply consists of running the
patchin.sh script. You also may want to cd to $DOC/mtd/util and make all the stuff in there.
Now configure the kernel. If you haven't done this before, read the $DOC/linux/README file first. Change to the
$DOC/linux directory and run 'make config' (or 'make menuconfig', or 'make xconfig' if you prefer) and start setting your kernel parameters. You will, of course need to know all about your particular
environment to compile the correct drivers, etc. I suggest that at least initially the MTD code be built as modules. This is much easier for debugging. If you are planning on booting from a DOC, at some
point you'll want to build a kernel with the DOC drivers built in.
The main section in the kernel config with which we are concerned is the MTD section. Most of the items in there are not a big concern,
and you should leave the defaults. But the following need to be set correctly:
Memory Technology Device (MTD) - Y or M
- Debugging (recommended)
- M-Systems Disk-On-Chip 2000 and Millennium (or whatever version you're using) - M or Y
- Direct chardevice access to MTD devices - M or Y
- FTL support - Y or M
- NFTL support - Y or M
- Write support for NFTL
Once 'make config' is done, you can do 'make dep && make bzImage && make modules && make modules install'. Read the $DOC/linux/README if you don't understand that last step.
Assuming that all compiled without error, you should have yourself a new kernel.
Before you go on to install the kernel, make sure you have the mtd and nftl devices in /dev. doing an 'ls | grep nftl'
should produce at least entries for nftla, nftla1, and nftla2... usually more. doing an 'ls|grep mtd' ought to show at least mtd0. If these are not there, either run MAKDEV (there is a special MAKEDEV in
$DOC/mtd/util) or mknod. Installing and Testing the new kernel
Installing kernels is a fine art. If you've never done so before, I HIGHLY
recommend that you at list skim read through some of the other available documentation. The Linux Bootdisk HOWTO, the Linux From Scratch Book, and the LILO documentation are all very useful.
In a
nutshell, move the new kernel and the System.map into the /boot directory, edit /boot/lilo.conf (or /etc/lilo.conf... wherever it is on your system), and run lilo.DON'T DELETE THE OLD KERNEL, and don't
remove the old kernel entry from LILO. If anything goes wrong, you'll need it.
It wouldn't hurt to back things up before doing this stuff, too. There is the very real possibility that you may screw up your system.
$ cp $DOC/linux/arch/i386/boot/bzImage /boot/bzImage-stb
$ cp $DOC/linux/System.map /boot/System.map-stb
$ ln -s /boot/System.map-stb /boot/System.map
When you change your lilo.conf file, be VERY careful. Don't change other entries or global settings unless you know what you are doing. Just add the entry for the
new kernel. It should look roughly the same as the kernel you usually boot to, except that the 'image' param will be different. It is a good idea to make a backup copy of lilo.conf before editing it.
your entry in lilo.conf should look something like this:
# Generic params are above here... stuff like 'map=/boot/map' #this is what the default looks like image=/boot/vmlinuz label=linux root=/dev/hdc1 read-only
#The one you write should look like this: image=/boot/bzImage-stb label=stb-linux root=/dev/hdc1 read-only #Might be other entries Run lilo: $ lilo
lilo will usually provide feedback on what images it added. As long as there are no error messages, you are relatively
safe. Now, the daring part (remember -- backup the system, don't remove the old kernel, make sure you will have a boot menu). Reboot the system: $ shutdown -r now If... I mean when
your system comes back up, select the new kernel in the Lilo menu and cross your fingers. Don't fret (too much) if the kernel doesn't boot or gives errors (especially if you're new to this). Sometimes it takes a try or five to get it right. Reboot to an old kernel, reconfig, recompile, and reinstall the kernel. Most things that go wrong with the standard kernel are pretty easy to fix... it just takes patience and a little problem solving. One gotcha that kept me stuck for a few hours is that the 2.4.5 kernel has to be built with SMP support. Sometimes little things like that can cause some annoyance.
There is a possibility that you will reboot and not even get a lilo prompt. This may be the result of a number of things. You will probably need to move the HDD to another system (as a secondary hard
drive) and fix and rebuild the boot sector on the disk. If the build worked and you made it through Init with most of your services running, you can test out the MTD DOC code. Get to a root prompt and try
the following: $ modprobe -a doc2000 nftl mtdchar mtdblock $ #Should see a comment about NFTL loading $ modprobe -a docprobe
When you modprobe docprobe (assuming you are on the console), you should see a message saying that the DOC was detected and
assigned to nftla. If the DOC has partitions, they should be assigned to nftla1, nftla2, etc. If you don't see messages on the command line, check the end of the system log (/var/log/syslog on mine) and see
if there are any messages. If these items are not here, check the following:
Is the DOC in its socket? Did you create the devices? Did you check /var/log/messages (or wherever it is on your distro) for errors?
If you enter 'cat /proc/mtd' do you see an entry in the file for a DiskOnChip?
Other problems may be more complex: the DOC may be hosed, in which case you will have to run $DOC/mtd/utils/nftl_format (read the documentation in $DOC/mtd and $DOC/mtd/util before doing this!), the
kernel modules may be built incorrectly -- re-compile it all. The DOC could be bad -- try another and reboot. If all else fails, there is an MTD mailing list on the official MTD page. Check there. A word
of encouragement: this process is not usually easy. It is rare to things working on the first or second time. Sometimes just doing the whole process a few times will unearth problems. And sometimes fixing on
problem will unearth another. Don't get discouraged about having to rework things a few times. Working with the DOC
Now that we can see the DOC driver, we should probably do something useful with it. It can be partitioned with fdisk.
It can be formatted: (example assumes at least nftla1 exists as a partition) $ mke2fs /dev/nftla1 (NOTE: formating /dev/nftla is more efficient, in most cases, than trying to partition the device.) And it can be mounted as a driver: $ mount -t ext2 /dev/nftla1 /mnt $ ls /mnt lost+found $ touch /mnt/test
$ ls /mnt lost+found test Troubleshooting
As I've said before, the process is long and error prone. Different versions of the kernel and MTD source have different
configurations. Hardware will vary, too. More often than not, the process of getting the system working takes more work than following these steps. Check the documentation for the kernel and MTD packages.
They change frequently and are more up to date than this document. Also, if booting is the problem, try the LILO documentation. It's very good and very thourough. Try rebuilding the kernel a few times.
There are a lot of parameters, and it's very possible to set some incorrectly. I mentioned earlier that one of my kernels wasn't working at all, and the problem was that I hadn't compiled smp support, which
has nothing at all to do with the MTD stuff. Look on the web. The MTD home page has a large archive of past mailing list messages. If you don't find answers there, subscribe to the mailing list and ask
there. And finally, if you find any errors in this document, please email me, the author. Links
Author: Matt Butcher (mbutcher [at] aleph-null [dot] tv; mbutcher@aleph-null.tv )
Copyright © 2000, 2001 Aleph-Null, Inc. M-Systems and DiskOnChip are trademarks of M-Systems.
Linux is a trademark of Linus Torvalds. This document may be reproduced for personal use
without permission. Commercial use or publication without permission is strictly forbidden. |
