From: Snoopy <qiclab!sopwith!snoopy@uunet.uu.net>
Date: Wed,  6 Dec 95 20:23:36 PST
To: qiclab!steelhead.cs.wwu.edu!phil@uunet.uu.net
Fcc: outbox
Reply-To: snoopy%sopwith@schitzo.rain.com
Subject: rebooting 532 and the PROM code

Phil,
	Could you forward this to the appropriate netbsd list?
The machine with the addresses is not answering the phone.

	thanks,
	Snoopy

========================  snip  =======================

>   In 1.0 it jumped to the first byte of the ROM.  That worked for me
> only some of the time.  "Snoopy" told me that a possible reason was
> that double mapping was not enabled and the code to stop double mapping
> might be the problem.  So we set the jump address to be to a position
> in the code that was after the jump to high addresses.  This is for
> the Nov 1991 ROM code.  It is completely possible that the 1.1 jump
> address is wrong.  Is there a general way of discovering where to
> jump?

With 1.0 and whatever PROM image I'm running, rebooting would
never work.  Machine would hang every time.

Reason is that the Unix kernel was jumping to the first byte of
the PROM at the high-mapped address (0x10000000), but that one (or more?)
of the very early PROM instructions assumed that the PROM was also mapped low,
which is not the case when Unix is running.  The PROM code jumps to a low
address, and what happens next depends on what bits happen to be in that
memory address when you are rebooting.  This could explain the random behaviour
some of you are seeing.

The quick workaround was to find an address in the PROM to jump to
after the double mapping is turned off. ( 0x10000032 for my PROM)
With this fix, my machine reboots correctly every time.  (modulo
unrelated problems, that is!)

The problem with this approach, of course, is that the address to
jump to will depend on the version of PROM code you are running.
Yuck!

My suggested long-term fix:

The first instruction in the PROM should be jump 0x1000 0005 (assuming
1 byte for opcode and 4 bytes for address).  Then it would always be safe
to have the kernel jump to 0x1000 0000, and the PROM code would work
*exactly* the same regardless of whether it was powering up at address 0
or rebooting and jumping to 0x1000 0000.

Pros:

	All (new) kernels would work with all (new) PROM images.

	The machine would get initialized the same way all the time.

Cons:

	Old PROM images wouldn't work.

	Wastes 5 bytes in the PROM.

Some potential alternate solutions:

	Insure that all PROM addresses in the PROM code are the
	high-mapped ones.

	Find a way to allow Unix to yank on the hardware reset line.
	The box I'm typing this on does exactly this.  This way the
	hardware *really* comes up the same way every time.  This would
	require a hardware mod.

Snoopy
snoopy%sopwith@schitzo.rain.com



-- 
Phil Nelson
phil@steelhead.cs.wwu.edu (NetBSD/pc532 machine)
phil@cs.wwu.edu (work)
http://www.cs.wwu.edu/~phil