From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Mh0oq-000118-Nv
	for qemu-devel@nongnu.org; Fri, 28 Aug 2009 08:44:41 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Mh0ol-0000zJ-S5
	for qemu-devel@nongnu.org; Fri, 28 Aug 2009 08:44:39 -0400
Received: from [199.232.76.173] (port=43273 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Mh0ol-0000yu-0n
	for qemu-devel@nongnu.org; Fri, 28 Aug 2009 08:44:35 -0400
Received: from mail-gx0-f211.google.com ([209.85.217.211]:36309)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <atar4qemu@googlemail.com>) id 1Mh0ok-0006So-Ki
	for qemu-devel@nongnu.org; Fri, 28 Aug 2009 08:44:34 -0400
Received: by gxk7 with SMTP id 7so2751391gxk.8
	for <qemu-devel@nongnu.org>; Fri, 28 Aug 2009 05:44:34 -0700 (PDT)
MIME-Version: 1.0
In-Reply-To: <f43fc5580908271122k1eccdbfat4452b9879abc7b63@mail.gmail.com>
References: <fb8d4f70908270558w168f899fr1972a1454c360dd8@mail.gmail.com>
	<f43fc5580908271122k1eccdbfat4452b9879abc7b63@mail.gmail.com>
From: Artyom Tarasenko <atar4qemu@googlemail.com>
Date: Fri, 28 Aug 2009 14:44:13 +0200
Message-ID: <fb8d4f70908280544m6825466eo6012be1e90d090bf@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Subject: [Qemu-devel] Re: sparc32 potential regression in
	513f789f6b187faf1fd533dc6972bbfa021c4381
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Blue Swirl <blauwirbel@gmail.com>
Cc: qemu-devel <qemu-devel@nongnu.org>, Robert Reif <reif@earthlink.net>

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?