Phil Nelson <phil@steelhead.cs.wwu.edu> writes:

  > As for getting back to the rom monitor ... 

  >   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?

  > One problem that now exists for me and some others is that even when
  > you get the ROM monitor prompt, without a real hardware reset, the
  > kernel hangs just before the autoboot code should start and NOTHING
  > happens.

I spent quite a bit of effort on this for the 1.1 monitor. Basically
you can trap to the rom monitor with a halt or reboot code and the rom
monitor tidies up, sets some devices to known states etc. For this to
work, it is necessary to preserve the rom monitors data and stack
space as well as some registers (notably intbase). Mach does this (the
ram is only a few pages), but I imagine what is happening is that the
boot loader has already changed something before mach gets it.
Of course, this breaks if the kernel goes totally off the rails, but
I think there is no way around that.

I did wonder whether the idea of trapping with codes (essentially
primative system calls) might not be better done by the
rom monitor providing an array of entry points to programs it
executes. This is how I believe the Sun 4 monitors work, but am not sure
about the Sun 3. I think that the Sun 4 monitor is supposed to be the
basis for some sort of standard, so copying the idea might not be
a bad thing. Of course, for the call backs to work, at least some effort
has to go into ensuring things are properly mapped etc anyway.

Ian