> Woo hoo!  I swapped the order of my 16 and 4 MB simms and now the
> system works great...

> Maybe we should mention this somewhere in install.txt?  I guess it is
> a hardware conifguration problem, but the previous configuration did
> work with 1.3.3 (without any hint of problems).

The problem is actually a conflict between various things.

On such systems, memory is physically noncontiguous - each SIMM appears
at a fixed physical base address regardless of its size.  So if (to use
the ELC as an example) you have 4M in the first slot and 16 in the
second, there's 4M between 00000000 and 00400000, a 12M hole with
nothing in it between 00400000 and 01000000, and 16M between 01000000
and 02000000.

This would not be a problem, except that the bootloader is not prepared
to deal with loading the kernel into noncontiguous memory.  The
bootloader used to relocate itself to 00300000 and load the kernel
below that.  But apparently some kernels got bigger than 3M, so someone
moved the bootloader to 00700000 (IIRC).  Of course, this falls over
hard on systems that don't have RAM at 00700000; presumably supporting
systems with only 4M in slot 0 was deemed less important than including
all the stuff that pushed the kernel past 3M.

I don't know *what* happens to the poor schlub who wants to install on
a system with 4x4M of RAM and hence no way to put 16M in slot 0.  I've
seen indicates that bootloaders based at other addresses are built, but
I've not seen them mentioned when addressing problems like yours, so
they may not help unless you want to "do it yourself".

Perhaps the bootloader should be built PIC and relocate itself to the
top of physical RAM, wherever that may be?

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B