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

[Artyom Tarasenko <atar4qemu@googlemail.com>]

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?