From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NixPv-00007X-Sd for qemu-devel@nongnu.org; Sat, 20 Feb 2010 17:03:15 -0500 Received: from [199.232.76.173] (port=34321 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NixPv-000074-At for qemu-devel@nongnu.org; Sat, 20 Feb 2010 17:03:15 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NixPu-0006ZN-0K for qemu-devel@nongnu.org; Sat, 20 Feb 2010 17:03:14 -0500 Received: from mail-pw0-f45.google.com ([209.85.160.45]:65059) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NixPt-0006Z3-HR for qemu-devel@nongnu.org; Sat, 20 Feb 2010 17:03:13 -0500 Received: by pwi4 with SMTP id 4so1163214pwi.4 for ; Sat, 20 Feb 2010 14:03:12 -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> Date: Sun, 21 Feb 2010 00:03:08 +0200 Message-ID: From: Blue Swirl Content-Type: text/plain; charset=UTF-8 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: Artyom Tarasenko Cc: Paolo Bonzini , qemu-devel@nongnu.org On 2/20/10, Artyom Tarasenko wrote: > 2010/2/20 Blue Swirl : > > > On 2/20/10, Rob Landley wrote: > >> On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote: > >> > 2010/2/17 Rob Landley : > >> > > But it does imply that qemu is capable of decently running _something_ on > >> > > sparc, so the problems I'm seeing are more likely to be uClibc or > >> > > toolchain issues. > >> > > >> > qemu-sparc can decently run debian-40r8: gcc and all the other stuff > >> > seem to work. > >> > > >> > Most versions of the NetBSD boot. Some require the original OBP > >> > though. The only known to me version which definetely doesn't boot is > >> > 3.0.2. > >> > > >> > Also since the last dma fix Solaris 2.4-2.5.1 seems to be also fully > >> > functional. Don't have a suitable compiler to check whether it's > >> > working under Solaris though. > >> > > >> > Debian-40r8 should have all the necessary stuff to build the uClibc > >> > toolchain, right? > >> > >> So I did a network install of that Debian image into a 4 gig disk image, and > >> made some progress. > >> > >> First a quick bug report: qemu-system-sparc tries to set the video window to > >> 900 pixels vertical, but my laptop's display is only 800 pixels tall, and the > >> window manager trims it a bit more than that for the toolbar. The kernel > >> booting up seems to think the graphics window is still its original size > >> renders text off the bottom of it. But for some reason I can grab the window > >> and resize it, and when I do this the emulated kernel's frame buffer gets the > >> update and resizes its console to show the correct number of lines of text for > >> the new size! (So my question is, why didn't it get the size right when the > >> window manager first resized it before I manually resized it again?) > >> > >> Anyway: yay emulated sparc debian, I installed it, got a reasonable > >> environment going, extracted my root filesystem image under there and chrooted > >> into it... and everything worked fine. (Well, trying to run a dynamically > >> linked "hello world" still died with a bus error, but using the static busybox > >> I could mount a tmpfs and list its contents, which I never could before.) > >> > >> My plan had been to use sparc-debian's copy of gdb to track down why the > >> binaries were going funky... but in that environment, they were behaving > >> themselves. Same binaries, built with the same toolchain, same qemu-system- > >> sparc, same -M and -cpu and so on... > >> > >> So I think "A-ha! Booting a different kernel! That's gotta be it!" > >> > >> The debian-sparc image is using a 2.6.18 kernel (and I'm using a 2.6.32 > >> kernel), but it installed the relevant .config in /boot, so I copied that out > >> with scp, did a "make oldconfig" up to 2.6.32 (holding down the enter key until > >> it shut up), stripped out all the modules and disabled module support, put > >> back in CONFIG_SERIAL_SUNZILOG_CONSOLE=y and friends, procfs, sysfs, and tmpfs > >> (strange things to have as modules?), and CONFIG_SQUASHFS (that's my default > >> root filesystem format). > >> > >> I booted the result up with init=/bin/ash, did a "mount -t tmpfs /tmp /tmp", > >> and then: > >> > >> / # ls -l /tmp > >> Illegal instruction > >> > >> It's still misbehaving. Huh. > >> > >> This is as close as I can get to the debian kernel config without adding module > >> support to my images (which is unnecessary complication for what they do). I > >> can try an ext2 root filesystem image but I don't see how that would cause > >> this. > >> > >> The part I don't understand is that same busybox binary, built with the same > >> toolchain, worked just fine under the Debian kernel. I'd blame my toolchain, > >> but in a slightly different context THE BINARIES WORKED... > >> > >> I don't understand what's going wrong here. Did the kernel break on sparc > >> sometime between 2.6.18 and 2.6.32 and nobody noticed? Is sparc using > >> software emulated floating point at the kernel level and that's configured as a > >> module? (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. > > > >> Do any sparc people understand what's going on here? My next step is to grab > >> a 2.6.18 kernel and try to get _that_ to work with the tweaked debian config > >> (and an ext2 root filesystem since squashfs wasn't merged back then and had a > >> format change when it was merged). But I'm mostly flailing around blind > >> here... > > > > 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. Haven't tested. ESP actually seems to work on 2.6.13, at least CD-ROM is identified without hang. There is some problem with initrd though.