On 29.06.2013, at 15:14, Mark Cave-Ayland wrote:
On 29/06/13 14:04, Alexander Graf wrote:
Am 29.06.2013 um 13:27 schrieb Mark Cave-Aylandmark.cave-ayland@ilande.co.uk:
Some older OS (particularly Darwin) will get stuck in a timing loop upon boot if the CPU clock-frequency and timebase-frequency aren't set close enough to "real" values.
The clock-frequency property is already fairly realistic, so create a new boolean NVRAM variable "force-real-tbfreq?" which when set to true will override the timebase-frequency value supplied by QEMU/KVM with that similar to a real Mac.
Hence it is possible to boot these old OS from QEMU by adding the following to the QEMU command line: -prom-env 'force-real-tbfreq?=true' (although of course the guest timing may be inaccurate).
Signed-off-by: Mark Cave-Aylandmark.cave-ayland@ilande.co.uk CC: Alexander Grafagraf@csgraf.de
I think I'd prefer a QEMU option to modify the timebase for real. That would change the emulated frequency as well as the one it exposes to OpenBIOS.
Hmmm okay - that's something that's reasonably beyond my level of QEMU knowledge to do at the moment :/ Although I have seen that some patches for throttling QEMU in the past have been rejected...
The throttling is already in place :). Check out cpu_ppc_tb_init() in hw/ppc/ppc.c. Actually it almost looks like the only thing we're doing wrong is the exported tbfreq value...
hw/ppc/mac_oldworld.c: cpu_ppc_tb_init(env, 16600000UL); hw/ppc/mac_newworld.c: cpu_ppc_tb_init(env, 100UL * 1000UL * 1000UL);
Alex