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: Fri, 28 Aug 2009 22:28:57 +0300

On Fri, Aug 28, 2009 at 3:44 PM, Artyom
Tarasenko<address@hidden> wrote:
> 2009/8/27 Blue Swirl <address@hidden>:
>> 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.
>
> Layout for sun4u is sort of described here:
> http://www.openbios.org/viewvc/obp/pkg/confvar/hashdevice.fth?revision=1&root=OpenBOOT
>
> Does OpenBIOS have other structure? Or is sun4u structure not
> compatible with sun4m?

The OpenBIOS structure can be found here:
http://tracker.coreboot.org/trac/openbios/browser/trunk/openbios-devel/modules/nvram.c

>>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.
>
> Is 'eeprom' utility in *BSD compatible with OpenBIOS layout? Or does
> it just call firmware, so it's layout independant?
>

Like http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/eeprom/main.c?rev=1.18

Lines like
#if defined(__sparc__) && !defined(__sparc64__)
tell that the formats should be similar.




reply via email to

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