Re: The Firepower bugs - especially saving interrupt vectors?

[ws%kurt.tools.de@localhost (Wolfgang Solfrank)]

> Ooops, should have explained the problem.
> 
> The copy code assumes that the interrupt vectors were included in the
> virtual address space.  The `firmware' I'm running doesn't do this.

Hmm, what firmware do you use?  Or what machine for that matter?

The idea is (as you might guess from the test in locore.S before calling
ofwr_init) to call ofwr_init only on machines that are not able to run a
client program in real mode.  On machines that are able to run the client
program in real mode the whole mess in ofwreal.S isn't used.

> Doing the copy with VM disabled was just one possible way of getting
> around this.

Depending on the way your firmware sets VM up, the current version of
NetBSD/powerpc might not work with NetBSD/powerpc running as a virtual
mode client.  This ofwreal.S stuff is really only intended as a workaround
for the fact that Firmworks OpenFirmware implementation doesn't support
running client programs in real mode.  It is hacked together with the
way Firmworks OpenFirmware implements VM in mind.  I don't think that
it'll work with other implementations of OpenFirmware when using the
virtual client interface.  Actually I'm pretty sure that it will not work
in the general case.

However, if you really want to try to get the system running using this
hack (which to say it again is only necessary if you cannot run the client
program in real mode), try moving the initialization of the msr from behind
the call to _ofwr_init to before that.  Note that you are doing this on
your own risk :-).

> BTW, are the MMU trap vectors part of the VM state?  Perhaphs this is
> one to throw at p1275.

Hmm, I defined it to be part of the VM state.  Actually, I defined the
VM state to contain everything that I could think of that might be related
to the VM system.  All these things are saved on entry to the kernel and
restored before a call to the firmware.  This way the firmware sees the
same state of the VM it had when calling the client program.

I don't think that p1275 does define something similar to this VM state.
It's a construct I invented to work around the inability of Firmworks
OpenFirmware to run client programs in real mode.  It essentially creates
the missing real mode interface for client programs.

Note that the reason to use the real mode interface for client programs
in NetBSD/powerpc was that the implementation I used (and am still using)
doesn't use the specified client callbacks for memory management, and I
felt that using the real mode interface had a greater probability to
interfere less with the memory management of the NetBSD kernel.  (Plus the
specification of the callback interface for virtual mode clients (which
isn't implemented in the firmware I use either) IMHO does have some
deficiencies, too).

Ciao,
Wolfgang
--
ws%TooLs.DE@localhost     (Wolfgang Solfrank, TooLs GmbH)       +49-228-985800