Booting from DOC2000 with GRUB loader

[John Sutton]

Ah, sweet success!

After a number of you made clear that you'd already blazed this trail, I
took the plunge and commented out the "I'm confused" check in nftl_format,
and ran it:

[root at spartam util]# ./nftl_format /dev/mtd0 98304
$Id: nftl_format.c,v 1.17 2001/08/29 14:28:48 dwmw2 Exp $
Phase 1. Checking and erasing Erase Zones from 0x00018000 to 0x01000000
Skipping bad zone (factory marked) #672 @ 0xa80000
        Checking Zone #1023 @ 0xffc000
Phase 2.a Writing NFTL Media Header and Bad Unit Table
Phase 2.b Writing Spare NFTL Media Header and Spare Bad Unit Table
Phase 3. Writing Unit Control Information to each Erase Unit

All looks good to me, and the stuff about skipping factory marked zones
and writing bad unit tables certainly give the impression that it knows
what it's doing!  So my previous concern re "You have erased the badblock
table on that DOC and it is no logner good for production" was probably
misplaced?  Anyway, in my application, once I've put this thing to bed, I
only expect to have to rewrite a small part of the doc, and only that say
half a dozen times in the lifetime of the system.  So with an expected
minimum rewrites of 100,000 (according to M-systems web site), I'm surely
in the clear.

After that I fdisked /dev/nftla and set up partitions, mke2fs, mkdir
/boot, put a kernel in it, mkdir /boot/grub and put a menu.lst in there,
reboot, bingo!

I realise with the benefit of hindsight that to avoid the danger of ending
up with an unbootable system when doing the nftl_format, all that's
necessary is to always follow it with (another) doc_loadbios.  So, even if
you can't figure out the numbers exactly, you'll get there eventually by
trial and error.

Some outstanding oddities with my grub on DoC:

1) At the command line (at least) the backspace key seems to have gotten
munged?  It seems to be emitting a single ^H rather than ^H<space>^H so
it's not clear that you've actually deleted a character (but you have). 
Maybe this is the same with vanilla grub (i.e. without mtd patch) but I
didn't notice it before?

2) More disconcerting, the TAB completion of valid devices in the "root"
command does not wholly recognise the "dc" prefix.  The behaviour, which
is rather complex, is as follows:

root (      hit TAB sees only my scsi disks hd0 and hd1
root (d
root (dc    hit TAB both give errors
root (dc0   hit TAB its happy with but it doesn't give you the comma
root (dc0,  hit TAB now its motoring!  It's shows me my 2 partitions 0 and
1 and, once I've selected one, TAB completion of filenames in the
partition when using the "kernel" command works fine.

Maybe both of these problems arise from the fact that I applied the latest
mtd patch (grub-2002-02-19-doc.patch) against a *later* grub source
(0.92)?  A few of the hunks were "shifted" (applied at different line
numbers) but they did stick.

Here are a few observations on the whole process which haven't come up
(explicitly at least) in this thread so far and which might be of help to
others:

1)  I've you've already gotten lilo going on your doc and are now trying
to get grub going, note the crucial difference: when you put grub on
the doc as opposed to putting it on a floppy or hard disk, you are putting
both stage1 AND stage2 on there.  Which is nice once you've understood
that ;-)  But if (like me) you thought you were just putting a 512 byte
boot loader on the grub which then knows the address of an mtd-aware
stage2 stored in an nftl partition, then it comes as a rather rude surprise
to find that you've trashed your existing efforts.

2)  Related to 1 (and here I'm only clear about the generalities and not
the details), note that the nftl format which exists on the doc when you
take it out of the wrapper - which is put on there by M-systems - is not
the same thing as that which you end up with (and need) to use grub. 
Quite why we've got 2 different implementations of this format on the go, I
don't know, but I became aware of it rather painfully ;-).

I started with the 2.4.18 kernel sources and using the help in make
menuconfig put together a kernel which looked like it would do the job. 
And it did, so far as it went - on booting the kernel I could see the
chip, fdisk /dev/nftla, mke2fs, everything sorted.  But then (no big
surprise) I found that vanilla lilo couldn't deal with it, so I downloaded
M-systems patched lilo, installed that and everything looked good.  The
point here however is that up to this point I am still using the nftl
format put on there by M-systems.  Once you want to have a go with grub,
this is no good.  (Presumably precisely because the mtd-patched grub
insists on putting stage2 onto the doc thus trashing this existing format?
 Can't see why you couldn't have a "standard" grub installation which
would only need to overwrite 512 bytes like lilo does?  Not that that
would have much merit in itself.)

Anyway, upshot of all this is that the kernel I'd built (and which I'd
imagined was everything needed because this far it had done everything
required of it) was no good because I'd omitted CONFIG_MTD_CHAR.  So when I
tried doc_loadbios /dev/mtd0 it wouldn't work because there was nothing
listening. (Cannot open device, or something like that.)  After some
digging about in the kernel sources, I realised what was missing, built a
new kernel, ran doc_loadbios and THEN, when I saw it erasing 96k instead
of 512 bytes, the penny finally dropped!

Here are the kernel config options which I've ended up with for my DoC2000
chip (and with everything paranoid switched on ;-) :

CONFIG_MTD=m
CONFIG_MTD_CHAR=m
CONFIG_NFTL=m
CONFIG_NFTL_RW=y

CONFIG_MTD_DOC2000=m
CONFIG_MTD_DOCPROBE=m
CONFIG_MTD_DOCPROBE_ADDRESS=0

CONFIG_MTD_NAND=m
CONFIG_MTD_NAND_ECC=y
CONFIG_MTD_NAND_VERIFY_WRITE=y

I started off with all this built in the kernel rather than as modules but
was getting fed up with docprobe (CONFIG_MTD_DOCPROBE) making a mess of my
console and syslog.  And on reading docprobe.c turns out that this probing
process is sometimes dangerous as well as messy, so I changed to building
as modules because then you can pass a single address in modules.conf:

options docprobe doc_config_location=0xcc000

Of course, YMMV in respect of the particular address at which your chip
presents itself.  (Mine is set with jumpers on the motherboard).  No doubt
this will end up being available as a kernel parameter in due course but
as best I can tell it has to be a module option at present.

So, happy grubbing and many thanks to all.  Hopefully I'll get this damn
thing out of the door pretty soon and will not be bugging you guys any
longer, but I'd be pleased to give assistance to any newbies out there. 
But note, I'm not subscribed to the list so be sure to copy any post to me
john at scl.co.uk if you think I can help you.

***************************************************
John Sutton
SCL Internet
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************