Futher to John's report of next_grab_slot not changing value within the
PPC MMU hash_page_32() function, I've done some more experimentation and
determined that there is indeed a problem with all OpenBIOS static
variables on PPC.
The issue is that OpenBIOS uses static variables in several places to
keep track of various bits of information, and at compile-time these
variables are given addresses within the OpenBIOS image itself, e.g.
(gdb) p &next_grab_slot
$1 = (int *) 0xfffdd000
However as John points out, the MemoryRegion associated with OpenBIOS is
set to read-only. Single-stepping using gdb shows that while the store
to update the value is executed, it is discarded by QEMU and so
therefore static variables never change from their initial value.
Rather amusingly, it seems that setting the variable value via gdb
bypasses the MemoryRegion read-only check which made this more
interesting to debug.
I've done a quick hack on QEMU which is to comment out the following
line from hw/ppc_oldworld.c in order to make the region read/write again:
I've confirmed in gdb that this fixes the issue with static variables
being able to update their value, and now with the latest round of OS X
patches applied, the Darwin kernel boots although panics fairly early on.
At this point, it seems that we have a decision to make. Is the bug here
that the OpenBIOS ROM is marked as read-only for PPC, or OpenBIOS's use
of static variables? If it's the latter, I think there is going to have
to be a fairly major patch to remove static variables completely from
the target image codebase.