>> IPX [...] current boot loader doesn't work

> Try building the boot program (in `/sys/arch/sparc/stand/boot') with
> a smaller `RELOC' value, say 0x340000 as it used to be until
> recently.

> It just may be that the machine has no physical memory bank at the
> address where `boot' is currently linked to run at.

That's a physical address?  Then it needs changing or it won't work on
an ELC with a 4M SIMM in the first slot.

I don't know the IPX memory subsystem to speak of, but I know a bit
about the ELC one.  The ELC has four SIMM sockets, and each socket can
take a 4M or 16M SIMM (possibly others, I don't know, but nothing over
16M).  And socket #N appears as physical memory at address N<<24 (ie,
0x0N000000, 16M * N). So if the first socket contains a 4M SIMM, then
regardless of what the other sockets contain, there is physical memory
at [00000000..00400000) but nothing from [00400000..01000000).  So in
that case trying to put a bootloader at 00700000 won't work very well.

(Why and how do I know so much about ELC memory?  If you tell the PROM
"setenv diag-switch? true", it prints information suggestive of this,
and a few printfs in the memory subsystem code confirmed it.  In fact,
even if some memory fails selftest it still appears; it's just omitted
from the memory map the kernel obtains from the ROMs.  I have an
adapter that takes 30-pin SIMMs and plugs into a 72-pin socket; if I
leave some 30-pin sockets empty, some bytes end up "missing" in the
emulated 72-pin SIMM.  Such memory fails POST, of course, but if I frob
arch/sparc/sparc/mem.c, mmrw() for /dev/mem, to allow access below
64<<20 regardless of pmap_pa_exists(), then userland accesses to that
range of /dev/mem see memory that works in some bytes and spaces out in
others, according to which 30-pin sockets are filled...which is good
enough confirmation for me. :)

					der Mouse

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