> > Does anyone know what might be happening?  All that routine does is
> > copy a large block of code from some virtual address 'x' to virtual
> > address 0, then jump so some location (0x952).
> 
> The address 0x952 may well be into the cache...Try with a PFLUSHA
> instr...I apologize if this happens to be nonsense; I really *don't*
> know what is going on *inside* the booter... =)

Well, I've pounded on this a bit more...  It looks like it's dying in a
loop that looks something like this:

	move.l	from, A0	; This is something like 16MB of 20MB machine
	move.l	to, A1		; This is zero.
	move.l	len, D0		; This is 0x39000 or something close ;-)

@again:
	move.l	(A0)+, (A1)+
	subq.l	#1, D0
	bne	@again

The values all look alright (after all, it works on my SE/30 ;-).
As far as I can tell, it's dying somewhere near the beginning.
Right above that, it ORs 0x700 into the status register to knock
off any interrupts.  We *are* writing over the vector table, so if
we were getting some exception, we'd be rather hosed, but I can't
see how that's happening.  Then again, I can't see how it's not
happening.  I don't think I'm getting as far as the "jmp (A0)" that
follows the loop.  I've tried making that group of pages non-cacheable
by modifying the page tables.

Anyone have any other ideas?  Hmm.  I haven't tried this pflusha--I
can't see it helping, but I'll try that tonight, maybe...

Thanks,
-allen

-- 
Allen Briggs - end killing - allen.briggs@vt.edu ** MacBSD == NetBSD/Mac **
= Over the years you swam the ocean following feelings of your own [...]  =
== It's a shame to have to die to put the shadow on our eyes.  We don't  ==
=== want to care. Under the bridge. Over the phone. Wind on the Water.  ===

------------------------------------------------------------------------------