[Qemu-devel] Sparc system emulation in progress

[Qemu-devel] Sparc system emulation in progress

[Blue Swirl]

Hi,

Just to avoid any duplicate work, I'd like to announce that I've been 
working on Sparc system level emulation. The emulation is not yet usable, a 
modified Linux kernel binary is loaded, it reprograms MMU, jumps to high 
memory, but crashes when it tries to access openprom (not implemented).

What is implemented:
Privileged instructions (somewhat complete, but buggy)
Sparc reference MMU (complete)

To do:
Openprom (Is there a FOSS one or even documentation? Otherwise make minimal 
stubs to get Linux running)
Hardware (serial, ethernet, scsi, probably not graphics nor keyboard)

The HW part needs a little thought. Sparc HW is memory-mapped, but there are 
separate address spaces, for example user data address space identifier is 
ASI 10, supervisor (kernel) 11, mmu regs 4 etc. I'd like to design a generic 
interface like used for i386 register_ioport_write and _read.

Any hackers out there with plenty of free time and know Sparc architecture?

_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Qemu-devel] Sparc system emulation in progress

[Patrick Mauritz]

On Tue, 31 Aug 2004 20:12:00 +0200, Blue Swirl <blueswir1@hotmail.com> wrote:
> To do:
> Openprom (Is there a FOSS one or even documentation? Otherwise make minimal
> stubs to get Linux running)
> Hardware (serial, ethernet, scsi, probably not graphics nor keyboard)
www.openbios.org - I'm one of the developers.. we usually hang out on
irc.freenode.net, #openbios


patrick mauritz

Re: [Qemu-devel] Sparc system emulation in progress_/_Here my patch suggestions to add SPARC host support to vl.c

[Bochnig, Martin]

Blue Swirl wrote:

> 
> Any hackers out there with plenty of free time and know Sparc architecture?

Hi,

great work :)

Unfortunately I'm not a hacker.

However - what about the SPARC host side?
As I reported recently, I got qemu0.6.0 compiled both under Linux 
(Suse7.3, Debian3.0 r2) and Solaris10 both running on HyperSPARC and 
UltraSPARC_IIi.
Unfortunately the emulation engine libqemu.a doesn't appear to work.
The sdl window pops up, the monitor-cli works but eventually the whole 
process either hangs or segfaults (A few times it managed to load the 
linux-test kernel, but the guest kernel then crashed due to division by 
zero.)
After most compile sessions not even that one comes up.

I tried binutils 2.12/2.13/2.14, gcc 2.95/2.96/3.0/3.2/3.32/3.41, gmake 
3.79/3.80.
The scenario described (with a launched but crashing linux guest kernel 
in '-nographics' console io mode) was the very best I ever could get.

I did some research
And I began to realise, how the host cpu code in vl.c would have to be 
implemented for SPARC (I cannot speak for Fujitsu's implementation of 
sparcv9 or earlier.):

*v7 (gcc's default), v8 do not seem to have any equivalent for x86's 
rdtsc instruction.

*v9 (as well as v8plus) seem to offer %tick as alternative.

Now we SPARC-host users are on the horns of a dilemma: QEMU's existing 
SPARC support is optimized for SPARCv7 only.
While we are required to build for v9 / SPARC64, the build process gives 
tons of errors caused by invalid type definitions/invalid size castings 
and doesn't complete.
The whole sources may need to be adjusted (by a real hacker, not me).
I edited Makefile.target, Makefile and configure and tested several 
'-mcpu=' and '-m32' vs. '-m64' settings - including '-mcpu=ultrasparc 
-m32' which is to produce so called sparcv8plus ELF 32 binaries.
I tried to build statically.
I enabled bigendian and gprof in 'configure'.
The build did NEVER complete with '-mcpu=ultrasparc' - no matter how all 
the other variations looked like.
So I could never test or even tune my theoretical %tick code (BTW: The 
vl.o object builds fine).
op.o seemed to be broken and dyngen complained and was unable to 
generate op.h. :-((

../dyngen -o op.h op.o
dyngen: ret; restore; not found at end of op_setbe_T0_subl
gmake[1]: *** [op.h] Error 1
gmake[1]: Leaving directory 
`/export/home/bochnig/QEMU_SOLARIS_SPARC_HOST/0.6.0/qemu-0.6.0/i386-softmmu'
gmake: *** [all] Error 1


Compiling w/o SDL support increased the chance to make QEMU the 
guest-linux kernel loading ('-nographics').
But only on a linux host - on Solaris10 it didn't help and I never 
managed to get it doing anything but freezing or segfaulting.
No idea.


Here my patch suggestions to add SPARC host support to vl.c :


#elif defined(__sparc__)

  /* Derived from: "m68k updates #2" by Richard Zidlicky
  "crude hack to get some sort of rdtsc support" */

#include <sys/time.h>
static int64_t cputicks=0;
static struct timeval lastcptcall={0,0};

// assume 5 MHz Pentium, min 80 ticks between rdtsc calls

int64_t cpu_get_real_ticks(void)
{
      struct timeval tp;
      gettimeofday(&tp,(void*)0);
      if (tp.tv_sec == lastcptcall.tv_sec &&
         tp.tv_usec == lastcptcall.tv_usec ){
        cputicks += 1;
      } else {
        cputicks=0;
        lastcptcall=tp;
      }
      return ((int64_t)tp.tv_sec*1000000+tp.tv_usec)*5+cputicks;
}


#elif defined(__sparc64__)

/* I'm not sure it was worth it, personally.
*
*UltraSparc:
*
*  unsigned long x;
*  asm volatile ("rd %tick, %0" : "=r"(x));
*
* Earlier Sparcs do not have this feature.
*
*
*/

int64_t cpu_get_real_ticks(void)
{
     int64_t val;
    asm volatile ("rd %%tick, %0" : "=r"(val));
     return val;
}

#else
#error unsupported CPU
#endif

Any ideas would be appreciated.

Martin

Re: [Qemu-devel] Sparc system emulation in progress

[Blue Swirl]

Thank you for the tip, but Openbios does not support Sparc.

On your page was a link to Proll (Sparc Prom code for Javastations to enable 
booting Linux). It looks more promising, I may even get a graphical console 
running soon.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail

Re: [Qemu-devel] Sparc system emulation in progress

[Patrick Mauritz]

On Sun, 05 Sep 2004 23:11:43 +0200, Blue Swirl <blueswir1@hotmail.com> wrote:
> Thank you for the tip, but Openbios does not support Sparc.
it's pretty portable, actually, for emulation it's especially easy to
adapt (as you can avoid the lowlevel init stuff - no-one cares for
that part as long as the state is right, which you can accomplish
differently in an emulator).

what do you need - a firmware image built for SPARC for a certain
start address (easy) and fcode images to initialize the "hardware"
(more work), anything else?

for the fcode images, the interfaces to use is important. I guess you
want to emulate some real chipsets, as most operating systems don't
rely on the services of openfirmware at all, not even as fallback -
which is a shame.

looking at proll, it seems like linux is a bad choice for the first
iteration of a port as it seems to rely on inofficial firmware
properties - netbsd should be more compliant

patrick mauritz

Re: [Qemu-devel] Sparc system emulation in progress

[Blue Swirl]

I agree that Openbios route would be cleaner, but the uglier Proll+Linux 
combination enables me to focus more on the Qemu side, instead of learning 
Netbsd and implementing the bottom half of Openbios. On the bad side, Proll 
fixes the hardware configuration, but then it is something known (Sun4m with 
TCX).

Maybe some Proll code could be lifted to arch-specific part Openbios? Both 
are GPL.

_________________________________________________________________
Help STOP SPAM with the new MSN 8 and get 2 months FREE*  
http://join.msn.com/?page=features/junkmail