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

[Blue Swirl]

On 2/20/10, Artyom Tarasenko <address@hidden> wrote:
> 2010/2/20 Blue Swirl <address@hidden>:
>
> > On 2/20/10, Rob Landley <address@hidden> wrote:
>  >> 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...)
>  >
>  > 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.