[Qemu-devel] sparc32 potential regression in 513f789f6b187faf1fd533dc6972bbfa021c4381

[Qemu-devel] sparc32 potential regression in 513f789f6b187faf1fd533dc6972bbfa021c4381

[Artyom Tarasenko]

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?

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

[Blue Swirl]

On Thu, Aug 27, 2009 at 3:58 PM, Artyom
Tarasenko<atar4qemu@googlemail.com> 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'.

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

[Artyom Tarasenko]

2009/8/27 Blue Swirl <blauwirbel@gmail.com>:
> On Thu, Aug 27, 2009 at 3:58 PM, Artyom
> Tarasenko<atar4qemu@googlemail.com> 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?

>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?

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

[Blue Swirl]

On Fri, Aug 28, 2009 at 3:44 PM, Artyom
Tarasenko<atar4qemu@googlemail.com> wrote:
> 2009/8/27 Blue Swirl <blauwirbel@gmail.com>:
>> On Thu, Aug 27, 2009 at 3:58 PM, Artyom
>> Tarasenko<atar4qemu@googlemail.com> 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.