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 at 0x0.
As a starting point, have you tried booting any other OS with this change?
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: http://www.openfirmware.info/pipermail/openbios/2014-May/008244.html but I'll need to fix it to work on big endian systems.
For my OpenBIOS tests I have a collection of various NetBSD, FreeBSD, Linux, Darwin and HelenOS that I use to check for regressions.
It would be appreciated if you could do some tests with these.
Regards, BALATON Zoltan