2010/2/20 Blue Swirl <blauwir...@gmail.com>: > On 2/20/10, Rob Landley <r...@landley.net> wrote: >> 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...) > > 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. -- Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/