On Mon, 26 May 2014, Mark Cave-Ayland wrote:
Just as a general comment: I know that some OSs using
Sun's PROM expect
to be able to write to the trap table (which is why it is copied to RAM)
so you'd need to check this thoroughly. Or, if MSR_IP uses virtual
addresses you could do some MMU twiddling so that the virtual address
actually points into a safe area of RAM rather than ROM.
As far as I understand MSR_IP just selects between exception vectors at
0x0 or 0xfff00000. Clients normaly use the vectors at page zero while the
latter is typically used for ROM based boot code. Also I think the ROM is
already copied to RAM anyway so it can be overwritten by the clients
(MorophOS does this later after finished calling OF client interface
functions or maybe it maps some RAM over it I'm not sure). In any case,
clients should not modify the firmware code and I think they use vectors
As a starting point, have you tried booting any other
OS with this
Yes but not very throughly. The Darwin images boot as far as before and
Finnix has a different issue due to the change in cuda to via pmu where
the IRQ is handled differently. I intend to fix that later by adding a USB
driver to OpenBIOS and use that as the real hardware has USB instead of
ADB anyway. This would also fix qemu-system-ppc64 with -M mac99. I already
have a version here:
but I'll need to fix it to work on big endian systems.
For my OpenBIOS tests I have a collection of various
FreeBSD, Linux, Darwin and HelenOS that I use to check for regressions.
It would be appreciated if you could do some tests with these.