[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