From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mh78Y-00017s-5e for qemu-devel@nongnu.org; Fri, 28 Aug 2009 15:29:26 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mh78X-00017Z-4k for qemu-devel@nongnu.org; Fri, 28 Aug 2009 15:29:25 -0400 Received: from [199.232.76.173] (port=47984 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mh78W-00017U-Sh for qemu-devel@nongnu.org; Fri, 28 Aug 2009 15:29:24 -0400 Received: from ey-out-1920.google.com ([74.125.78.145]:14769) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mh78U-0003GS-7v for qemu-devel@nongnu.org; Fri, 28 Aug 2009 15:29:24 -0400 Received: by ey-out-1920.google.com with SMTP id 13so517617eye.14 for ; Fri, 28 Aug 2009 12:29:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Fri, 28 Aug 2009 22:28:57 +0300 Message-ID: Content-Type: text/plain; charset=UTF-8 Subject: [Qemu-devel] Re: sparc32 potential regression in 513f789f6b187faf1fd533dc6972bbfa021c4381 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: qemu-devel , Robert Reif On Fri, Aug 28, 2009 at 3:44 PM, Artyom Tarasenko wrote: > 2009/8/27 Blue Swirl : >> On Thu, Aug 27, 2009 at 3:58 PM, Artyom >> Tarasenko 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.