The problem I am currently having is centered around what is known as a
DiskOnChip. It is a Solid State EEPROM socketed to the board which,
through BIOS, acts exactly like a hard drive.
With this socket and chip disabled through CMOS everything works fine
and I can get linux up and running no problems from a laptop harddisk.
However, this platform eventually has to go towards being diskless and
wireless so I have to use the DiskOnChip eventually. (Or some other
EEPROM solution, discussed below)
I figured the first step towards running would be to enable the
DiskOnChip and ignore it. (I understand linux won't see it because linux
ignores/chucks/disables?? or does something to render BIOS routines
unusable)
When I enable the DiskOnChip it gets recognized by BIOS and things
proceed normally to the boot sequence. All I get is:
LIL-
I understand this means the descriptor table has an incorrect checksum.
I don't know what a descriptor table is or why this DiskOnChip would
cause a change in the descriptor table.
The DiskOnChip is basically accessed by mapping 64K from the chip onto
the memory starting at 0xD0000 if that is of any help. I didn't think
this area would be a problem since all the boot/kernel stuff is below
0xA0000.
No matter what I tried with lilo.conf I couldn't get this to boot off
the harddisk with the DOC enabled. I can boot from the floppy drive
fine, either by a raw kernel image or by installing lilo and the kernel
on the floppy disk.
On the harddisk I have tried putting LILO on /dev/hda4 (my root
partition for linux) and on the MBR using various LILO options without
any success.
Does anybody have any ideas on what the trouble is and what I have to do
to fix the problem?
I would really like to get a fully embedded, diskless system working
with linux because I know a lot of researchers and other people who
would like to use linux with these single board machines.
I already saw the article in the Linux Journal about doing this but it
has two flaws:
1) it uses MS-DOS at some point, and
2) The root device is a read-only ramdisk image. I need a machine
which
can save information as well between shutdowns.
How do I go about booting from a Solid State DiskOnChip or other EEPROM
device?
One of the problems I see with getting the DiskOnChip running smoothly
is that it is produced by a company named M-Systems and uses the
TrueFlash FileSystem (TFFS). This is a proprietary technology so I
doubt I can get the technical information I need to get it to work
without BIOS routines, and even if I did I wouldn't be allowed to
release the drivers publicly. I'ld like to get this functionality added
to the linux kernel at some point.
At what point during the boot process does the BIOS stop being used and
what happens to it? Why can't we use BIOS stuff under linux? (I
realize there are good reasons like its inefficient, but I would like to
know what those reasons are).
If the DiskOnChip is not a workable solution I may have other options.
The Ampro CoreModule socket can accept EPROMS, Flash EPROMs, SRAM and
NOVRAM chips. Would it possibly be easier to use a NOVRAM chip and then
not worry about the TFFS crud? I guess then I would just have to write a
block device driver for the chip and then we could use the plain old
ext2 filesystem? What happens for a boot sector in such cases? Will
LILO be usable with such an environment?
Lastly, a lot of the special functionality of this board (such as the
watchdog timer and the mapping of EEPROM segments is controlled through
the usage of "extended BIOS" function calls.
i.e.
MOV AH,0CDH ; AMPRO function call
MOV AL,03 ; select the EEPROM socket S0
MOV BL,01 ; Turn the socket on
MOV BH,70H ; select the eigth 64K segment
MOV CX,414Dh ; AMPRO idnetifier ('AM')
INT 13H
this piece of code is used to select which page of EEPROM should be
visible at 0xD0000.
If linux gets rid of BIOS do I loose the ability use the above type of
code in device drivers for the EEPROM devices and other special things?
My current thinking is that the best plan is to use a Nonvolatile SRAM
chip, write a simple block device driver so linux can see/use it. put
the ext2 filesystem on it and use it like any disk. However, I have no
clue how to modify the boot sequence to boot from this device. any
ideas?
Am I missing some huge factor that has prevented anybody else from doing
this before me? What are your opinions on this matter and advice that
you can give me?
I'm a little out of my league here (as you can tell) but I have my boots
on and climbing gear in hand and I'm ready for that steep learning
curve.
Thanks,
- Jeff Wiegley
kernel weenie