From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NixEQ-00071z-Nd for qemu-devel@nongnu.org; Sat, 20 Feb 2010 16:51:22 -0500 Received: from [199.232.76.173] (port=34951 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NixEO-0006xA-21 for qemu-devel@nongnu.org; Sat, 20 Feb 2010 16:51:20 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nix3D-0008U5-72 for qemu-devel@nongnu.org; Sat, 20 Feb 2010 16:39:47 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:40826) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nix3B-0008TL-VE for qemu-devel@nongnu.org; Sat, 20 Feb 2010 16:39:46 -0500 Received: by pwi4 with SMTP id 4so1154595pwi.4 for ; Sat, 20 Feb 2010 13:39:44 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <201002110520.07620.rob@landley.net> <201002171255.34570.rob@landley.net> <201002201117.41568.rob@landley.net> From: Artyom Tarasenko Date: Sat, 20 Feb 2010 22:39:24 +0100 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.) List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: Paolo Bonzini , qemu-devel@nongnu.org 2010/2/20 Blue Swirl : > On 2/20/10, Rob Landley wrote: >> On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: >> =A0> 2010/2/17 Rob Landley : >> =A0> > But it does imply that qemu is capable of decently running _somet= hing_ on >> =A0> > sparc, so the problems I'm seeing are more likely to be uClibc or >> =A0> > toolchain issues. >> =A0> >> =A0> qemu-sparc can decently run debian-40r8: gcc and all the other stuf= f >> =A0> seem to work. >> =A0> >> =A0> Most versions of the NetBSD boot. Some require the original OBP >> =A0> though. The only known to me version which definetely doesn't boot = is >> =A0> 3.0.2. >> =A0> >> =A0> Also since the last dma fix Solaris 2.4-2.5.1 seems to be also full= y >> =A0> functional. Don't have a suitable compiler to check whether it's >> =A0> working under Solaris though. >> =A0> >> =A0> Debian-40r8 should have all the necessary stuff to build the uClibc >> =A0> toolchain, right? >> >> =A0So I did a network install of that Debian image into a 4 gig disk ima= ge, and >> =A0made some progress. >> >> =A0First a quick bug report: qemu-system-sparc tries to set the video wi= ndow to >> =A0900 pixels vertical, but my laptop's display is only 800 pixels tall,= and the >> =A0window manager trims it a bit more than that for the toolbar. =A0The = kernel >> =A0booting up seems to think the graphics window is still its original s= ize >> =A0renders text off the bottom of it. =A0But for some reason I can grab = the window >> =A0and resize it, and when I do this the emulated kernel's frame buffer = gets the >> =A0update and resizes its console to show the correct number of lines of= text for >> =A0the new size! =A0(So my question is, why didn't it get the size right= when the >> =A0window manager first resized it before I manually resized it again?) >> >> =A0Anyway: yay emulated sparc debian, I installed it, got a reasonable >> =A0environment going, extracted my root filesystem image under there and= chrooted >> =A0into it... and everything worked fine. =A0(Well, trying to run a dyna= mically >> =A0linked "hello world" still died with a bus error, but using the stati= c busybox >> =A0I could mount a tmpfs and list its contents, which I never could befo= re.) >> >> =A0My plan had been to use sparc-debian's copy of gdb to track down why = the >> =A0binaries were going funky... but in that environment, they were behav= ing >> =A0themselves. =A0Same binaries, built with the same toolchain, same qem= u-system- >> =A0sparc, same -M and -cpu and so on... >> >> =A0So I think "A-ha! =A0Booting a different kernel! =A0That's gotta be i= t!" >> >> =A0The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.= 32 >> =A0kernel), but it installed the relevant .config in /boot, so I copied = that out >> =A0with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter= key until >> =A0it shut up), stripped out all the modules and disabled module support= , put >> =A0back in CONFIG_SERIAL_SUNZILOG_CONSOLE=3Dy and friends, procfs, sysfs= , and tmpfs >> =A0(strange things to have as modules?), and CONFIG_SQUASHFS (that's my = default >> =A0root filesystem format). >> >> =A0I booted the result up with init=3D/bin/ash, did a "mount -t tmpfs /t= mp /tmp", >> =A0and then: >> >> =A0 / # ls -l /tmp >> =A0 Illegal instruction >> >> =A0It's still misbehaving. =A0Huh. >> >> =A0This is as close as I can get to the debian kernel config without add= ing module >> =A0support to my images (which is unnecessary complication for what they= do). =A0I >> =A0can try an ext2 root filesystem image but I don't see how that would = cause >> =A0this. >> >> =A0The part I don't understand is that same busybox binary, built with t= he same >> =A0toolchain, worked just fine under the Debian kernel. =A0I'd blame my = toolchain, >> =A0but in a slightly different context THE BINARIES WORKED... >> >> =A0I don't understand what's going wrong here. =A0Did the kernel break o= n sparc >> =A0sometime between 2.6.18 and 2.6.32 and nobody noticed? =A0Is sparc us= ing >> =A0software emulated floating point at the kernel level and that's confi= gured as a >> =A0module? =A0(Except I don't think busybox ls uses floating point...) > > Sparc32 is not maintained anymore so maybe it broke at some point. > There was some discussion a few years ago. > >> =A0Do any sparc people understand what's going on here? =A0My next step = is to grab >> =A0a 2.6.18 kernel and try to get _that_ to work with the tweaked debian= config >> =A0(and an ext2 root filesystem since squashfs wasn't merged back then a= nd had a >> =A0format change when it was merged). =A0But I'm mostly flailing around = blind >> =A0here... > > I'm also trying different kernels using my .config. But already 2.6.12 > hangs in ESP probe. Does it work on a real hw? 2.6.18 definitely does. We still have bug(s) in ESP though: Solaris also hangs in ESP probe after a soft reset in OBP. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/