simon
Begin forwarded message:
From: Ilguiz Latypov <[EMAIL PROTECTED]>
Date: Tue Feb 11, 2003 12:30:34 PM America/Montreal
To: [EMAIL PROTECTED]
Cc: S Woodside <[EMAIL PROTECTED]>
Subject: Re: [WaterlooWireless] Fwd: [BAWUG] Felsenstein Linux crisis in Laos! :)
On Sun, 9 Feb 2003, S Woodside wrote:
Anyone at UW know anything about getting Millenium MD2203-D576 flashIt seems they are mixing up 2 approaches to using the DiskOnChip NAND
cards to work on linux? It's a pretty kick-ass project in Laos
(third-world country) with 802.11 repeaters up in trees, the whole nine
yards. Also, Lee Felsenstein is pretty famous hacker :-)
flash memory.
1. The original approach was to install a BIOS disk handler as part of the
M-Sys proprietory firmware. Many bootloaders including lilo and MS-DOS
will see DiskOnChip as a usual hard drive by means of software BIOS
interrupt int 0x13. [This is not to be messed with so-called IDE flash
disks that contain extra hardware logic converting the IDE interface
commands into flash memory operations internally. These will look to O/S
as IDE drives even at lower level down to port I/O so Linux can handle
them by means of the standard IDE driver without BIOS calls].
Once the regular bootloader fetched Linux kernel with BIOS disk calls, the
Linux kernel starts up. M-Sys provides a proprietory O/S Abstraction
Kernel compatibility driver in a binary only form. The open source M-Sys
driver relies on that proprietory layer driver. In the end, I think the
M-Sys BIOS extension stored in the flash memory is reused by the Linux
M-Sys driver. The device node names to be used with M-Sys drivers are
/dev/ftla*, if my memory serves me.
2. Another approach is to install a bootloader that can fetch the kernel
image from the flash memory. The kernel would contain the open source
Memory Technology Drivers (part of pristine kernel source tree). The MTD
DiskOnChip drivers (doc2000 will work with both DoC 2000 DoC Millennium)
are able to access the flash memory "directly" over port I/O.
The MTD maintainer provided a patch against the GRUB bootloader, and I
enhanced that. See detailed instructions at
http://lakeshoremicro.com/diskonchip-grub-howto.html
The patch should be available at
http://www.infradead.org/cgi-bin/cvsweb.cgi/mtd/patches/
Once the kernel is booted, the device nodes responsible for DiskOnChip are
/dev/mtd* and /dev/nftla*. One can't start fdisk against /dev/mtd*
because the /dev/mtd* driver represents the raw NAND memory. The NAND
memory characteristic is that the zero value bit can not be changed into
one without issuing the erase sector command.
The /dev/nftla* driver will hide these details by implementing an extra
NFTL layer implemented by David Woodhouse after the earlier M-Sys NFTL
format. The nftlformat is similar but not identical to the M-Sys dformat
as far as the NFTL format is concerned (I don't know the exact
difference). The NFTL driver will also spread the sector usage across the
chip so that the flash memory will be re-used uniformly. I heard that
even a read-only NFTL file system will still be writing something into the
flash memory.
A different, simpler kind of bootloader could fetch the kernel image *and*
a RAM root file system into the memory. Then the kernel doesn't have to
include any flash memory support as long as the flash memory is not
accessed.
--
Ilguiz Latypov
Montreal, Quebec
Canada
home tel. +1 (514) 526-6911
work tel. +1 (514) 281-9191 x 117
--- www.simonwoodside.com <http://ThisURLEnablesEmailToGetThroughOverzealousSpamFilters.org>
-- general wireless list, a bawug thing <http://www.bawug.org/> [un]subscribe: http://lists.bawug.org/mailman/listinfo/wireless
