qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: sparc32 potential regression in 513f789f6b187faf1fd533d


From: Blue Swirl
Subject: [Qemu-devel] Re: sparc32 potential regression in 513f789f6b187faf1fd533dc6972bbfa021c4381
Date: Thu, 27 Aug 2009 21:22:52 +0300

On Thu, Aug 27, 2009 at 3:58 PM, Artyom
Tarasenko<address@hidden> wrote:
> qemu-0.10.{5,6} start OBP tests with ss5/170 rom, and master doesn't.
> I'm not sure if it is a real regression (don't know if a real ss5/170
> would start these tests), but it definitely looks like a regression to
> me.
> It would be nice to have a way for starting OBP tests (ss5/170 is the
> largest test set for SS machines I have seen).
>
> The regression comes with the commit
> 513f789f6b187faf1fd533dc6972bbfa021c4381 "Use firmware configuration
> instead of NVRAM".
>
> Would it be possible to introduce a switch simulating old behavior?
>

Before the commit, we used to put a structure which describes the
hardware at the beginning of NVRAM and after this OpenBIOS partitions.
The commit moved the HW information to firmware configuration device
and relocated the partitions to start of NVRAM. QEMU uses the
partitions to pass variables to OpenBIOS, for example -prom-env
'auto-boot?=false' prevents automatic boot.

Neither the HW structure nor OpenBIOS partitions are designed to be
compatible with Sun OBP format (which is not documented), the previous
layout just happened to work somehow.

It should be easy to prevent QEMU from using NVRAM with a switch (or
new machine type), but my estimate on the number of users for the
switch is about two. Maybe this can be done some day more discreetly
with qdev, like -device-config 'sun4m.m48t59.format=sun'.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]