[Qemu-devel] Fun with sparc (was Re: qemu-ppc can't run static uClibc binaries.)

[Rob Landley]

On Thursday 18 February 2010 05:21:16 Artyom Tarasenko wrote:
> 2010/2/17 Rob Landley <address@hidden>:
> > 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...)

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...

Thanks,

Rob
-- 
Latency is more important than throughput. It's that simple. - Linus Torvalds