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