Re: LIL- caused by a DiskOnChip? and other SSD questions.

Darren Senn (sinster@scintilla.darkwater.com)
Sat, 22 Mar 1997 14:37:44 -0800 (PST)


I have a lot of experience with all this embedded systems crap, especially
M-Systems, the AMD single-chip boards, etc.

My recommendation is to boot with the DiskOnChip disabled, and add code to
LILO to support the DOC. THen You also have to add a device driver to
Linux to support the DOC, and you're set.

The reason I say this is that first, the DOC is purely a software phenomenon,
that exists in the BIOS. The EEPROM is just an EEPROM, there is nothing
magical that ties it to the DOC setup. Alos, the M-Systems TFFS is a
load of schlock. I've got the spec somewhere in my files, and it is
hopelessly fragile and wasteful. Don't ever make an embedded system
depend on something fragile.

In order to write the drivers, you'll need to find the I/O level
programming for this. There are likely some special opcodes and/or
I/O ports that you'll have to write to in order to drive the memory
mapping. If I remember correctly, these are special opcodes you'll
have to use. I highly recommend using #define macros.

You'll also have to carefully consider which EEPROM you use and how that
meshes with the filesystem. You won't want to use any Intel-type EEPROM or
Flash chips: they have huge erasable blocks, so you'll be stuck either
making a huge RAM cache or dedicating one (or more) erasable blocks for the
cache. THat's nasty. I'd recommend an Atmel 29C040. it's got a 256 byte
erasable block, and since Linux never writes to a hard disk in less than 512
byte increments, you won't need any caching beyond what Linux already gives
you.

I don't know if you'll have to do special stuff to bar the kernel from
accessing the D00000h range or not. I depends on if you want to be
repeatedly remapping the EEPROM or not. That's up to you.