From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mgjd0-0002tJ-E1 for qemu-devel@nongnu.org; Thu, 27 Aug 2009 14:23:18 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mgjcw-0002n0-RN for qemu-devel@nongnu.org; Thu, 27 Aug 2009 14:23:18 -0400 Received: from [199.232.76.173] (port=56075 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mgjcw-0002ms-OJ for qemu-devel@nongnu.org; Thu, 27 Aug 2009 14:23:14 -0400 Received: from mail-ew0-f223.google.com ([209.85.219.223]:59629) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mgjcw-0006nD-LJ for qemu-devel@nongnu.org; Thu, 27 Aug 2009 14:23:14 -0400 Received: by ewy23 with SMTP id 23so1686036ewy.8 for ; Thu, 27 Aug 2009 11:23:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Blue Swirl Date: Thu, 27 Aug 2009 21:22:52 +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 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. 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'.