[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: booting qemu sparc gives black window



On 18/05/16 12:22, Romain Dolbeau wrote:

> 2016-05-18 13:06 GMT+02:00 Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk <mailto:mark.cave-ayland@ilande.co.uk>>:
>> The short version is that the QEMU NVRAM format is different from that
>> of a real SS-5 machine (and indeed QEMU doesn't support NVRAM
>> persistence for that interface yet)
> 
> It's quite easy to fix this if you're willing to patch qemu.
> 
> IIRC: After starting with the SS5 PROM file, reset the (virtual) nvram
> like you would do on a real SS5 with a failed nvram battery. Then from
> the qemu monitor, dump the physical memory for the nvram (now with a
> 'valid' content) in a file. Then just patch qemu to load the data from
> that file after the nvram is initialized (file hw/sparc/sun4m.c, 
> function nvram_init()).
> 
> It also saves a lot of time when you give qemu the full 256 MiB of
> memory, since with a valid nvram the PROM won't check all of the memory.

Last time I looked the problem was that the fw_cfg interface has a fixed
header across all architectures (i.e. some locations towards the
beginning of NVRAM are already accounted for) and there were some
specific issues with the implementation - if you search the QEMU
archives you can find the detail there.

TBH as OpenBIOS will now boot most things (including Solaris) on
qemu-system-sparc, the need for improved NVRAM is greatly reduced as the
main complaint was having to type into the PROM at boot time. IMO time
is better spent elsewhere e.g. improving qemu-system-sparc64 emulation
which is currently where I try and spend my time where possible.


ATB,

Mark.


Reply to: