[Qemu-devel] Patch: Sparc system support

[Qemu-devel] Patch: Sparc system support

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 702 bytes --]

Hi,

This version of Sparc system emulation can load ELF kernels (see 
screenshot), like Linux or *BSD using a hacked (patch attached) Proll.  The 
kernels won't run very far, there is still much work to do.  Also new to 
previous patch is m48t08 NVRAM chip support, based on the PPC's newer 
m48t59.

How to try: Patch Proll, compile, convert mrcoffee/proll.elf to binary with 
objdump -O binary.  Configure Qemu with ./configure 
--target-list="sparc-softmmu".  Run qemu-system-sparc with -L path_to_proll 
-kernel vmlinux or bsd.

_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

[-- Attachment #2: proll.patch.bz2 --]
[-- Type: application/octet-stream, Size: 900 bytes --]

[-- Attachment #3: snapshot5.png --]
[-- Type: image/png, Size: 6474 bytes --]

[-- Attachment #4: qemu-0.6.0-sparc.patch-7.bz2 --]
[-- Type: application/octet-stream, Size: 32360 bytes --]

Re: [Qemu-devel] Patch: Sparc system support

[Fabrice Bellard]

I applied your patches with some modifications. Please update your 
sources with the CVS version and tell me if you see problems in my 
modifications.

You should provide at least a binary BIOS image so that I can make 
regression tests. I can also put a link on the web site so that you can 
give specific information about the SPARC port.

A few notes:

- The 'env->access_type' you used (as in the PowerPC version) will soon 
be deprecated as it is too complicated and broken. I will make the 
appropriate modifications.

- 'magic-load.c' is not acceptable as it uses GPL code. Moreover, the 
user ELF loader code is too complicated, so it is better to rewrite it 
from scratch. You can still use the ELF swap functions as I wrote them.

Thank you for your work !

Fabrice.

Blue Swirl wrote:
> Hi,
> 
> This version of Sparc system emulation can load ELF kernels (see 
> screenshot), like Linux or *BSD using a hacked (patch attached) Proll.  
> The kernels won't run very far, there is still much work to do.  Also 
> new to previous patch is m48t08 NVRAM chip support, based on the PPC's 
> newer m48t59.
> 
> How to try: Patch Proll, compile, convert mrcoffee/proll.elf to binary 
> with objdump -O binary.  Configure Qemu with ./configure 
> --target-list="sparc-softmmu".  Run qemu-system-sparc with -L 
> path_to_proll -kernel vmlinux or bsd.
> 
> _________________________________________________________________
> The new MSN 8: smart spam protection and 2 months FREE*  
> http://join.msn.com/?page=features/junkmail
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel

Re: [Qemu-devel] Patch: Sparc system support

[Renzo Davoli]

On Fri, Oct 01, 2004 at 12:23:07AM +0200, Fabrice Bellard wrote:
> I applied your patches with some modifications. Please update your 
> sources with the CVS version and tell me if you see problems in my 
> modifications.
Yes, I do ;-)

With the latest cvs I get stuck during the compilation inside
sparc-user. (I am working on a linuxppc host)

In file included from
/....... /qemu/translate-all.c:41:
op.h: In function `dyngen_code':
op.h:4781: error: parse error before ')' token
op.h:4782: error: parse error before ')' token
op.h:4797: error: parse error before ')' token
op.h:4798: error: parse error before ')' token

In fact there is something wrong in the op.h file:

Line 4778:
case INDEX_op_fitos: {
    extern void op_fitos();
    memcpy(gen_code_ptr, (void *)((char *)&op_fitos+0), 56);
    *(uint16_t *)(gen_code_ptr + 26) = ((long)(&) + 0 + 0x8000) >> 16;
    *(uint16_t *)(gen_code_ptr + 30) = ((long)(&) + 0);
    gen_code_ptr += 56;
}

(long)(&) .... the operand is missing.

The same error appears again some lines below:

Line 4794:
case INDEX_op_fitod: {
    extern void op_fitod();
    memcpy(gen_code_ptr, (void *)((char *)&op_fitod+0), 52);
    *(uint16_t *)(gen_code_ptr + 26) = ((long)(&) + 8 + 0x8000) >> 16;
    *(uint16_t *)(gen_code_ptr + 30) = ((long)(&) + 8);
    gen_code_ptr += 52;
}

ciao
	renzo

Re: [Qemu-devel] Patch: Sparc system support

[Johannes Schindelin]

Hi,

On Fri, 1 Oct 2004, Renzo Davoli wrote:

> In fact there is something wrong in the op.h file:
>
> Line 4778:
> case INDEX_op_fitos: {
>     extern void op_fitos();
>     memcpy(gen_code_ptr, (void *)((char *)&op_fitos+0), 56);
>     *(uint16_t *)(gen_code_ptr + 26) = ((long)(&) + 0 + 0x8000) >> 16;
>     *(uint16_t *)(gen_code_ptr + 30) = ((long)(&) + 0);
>     gen_code_ptr += 56;
> }
>
> (long)(&) .... the operand is missing.

This most likely means that your op.o has a relocation without a proper
symbol name. This can happen if a relocation is split into loword
and hiword on some architectures. What host are you compiling for?

Looking at target-sparc/op.c, I see that op_fitos does not take any
__op_param parameters, but rather just stores env->ft1 into env->ft0. So
maybe those relocations are not necessary. You can try that by hacking
dyngen.c after the "/* patch relocations */" line to just ignore
those without a proper name. YMMV.

Hth,
Dscho

Re: [Qemu-devel] Patch: Sparc system support

[J. Mayer]

On Fri, 2004-10-01 at 18:00, Johannes Schindelin wrote:
> Hi,

Hi,

> On Fri, 1 Oct 2004, Renzo Davoli wrote:
> 
> > In fact there is something wrong in the op.h file:
> >
> > Line 4778:
> > case INDEX_op_fitos: {
> >     extern void op_fitos();
> >     memcpy(gen_code_ptr, (void *)((char *)&op_fitos+0), 56);
> >     *(uint16_t *)(gen_code_ptr + 26) = ((long)(&) + 0 + 0x8000) >> 16;
> >     *(uint16_t *)(gen_code_ptr + 30) = ((long)(&) + 0);
> >     gen_code_ptr += 56;
> > }
> >
> > (long)(&) .... the operand is missing.
> 
> This most likely means that your op.o has a relocation without a proper
> symbol name. This can happen if a relocation is split into loword
> and hiword on some architectures. What host are you compiling for?

I also had issues like this with PPC some opcodes. I noticed that this
happened when gcc uses local variables. The solution I found was to
rewrite some micro-operations to make them simpler to compile and make
others helper functions (so the micro-op is just a function call), for
the more complex ones.

-- 
J. Mayer <l_indien@magic.fr>
Never organized

Re: [Qemu-devel] Patch: Sparc system support

[Johannes Schindelin]

Hi,

On Sat, 2 Oct 2004, J. Mayer wrote:

> > This most likely means that your op.o has a relocation without a proper
> > symbol name. This can happen if a relocation is split into loword
> > and hiword on some architectures. What host are you compiling for?
>
> I also had issues like this with PPC some opcodes. I noticed that this
> happened when gcc uses local variables. The solution I found was to
> rewrite some micro-operations to make them simpler to compile and make
> others helper functions (so the micro-op is just a function call), for
> the more complex ones.

I guess that the current CVS reflects your work, right? Anyway, after
working a bit on an IRIX host port, I am quite confident that all
relocations which don't concern variables beginning with "__op_" are
irrelevant, and could be left alone. Those relocations are almost
definitely handled by the linker already.

The file op.o *is* linked into libqemu.a, because there would be no code
to actually be dynamically copied. I will explain the dynamic translation
in an other post very soon.

Ciao,
Dscho

Re: [Qemu-devel] Patch: Sparc system support

[Blue Swirl]

Most of your changes are ok, except for the DHCP one. It's idea is to 
respond to BOOTP clients which use no extensions added by DHCP.

The magic address-banging loader is a quick & dirty hack anyway, I'm 
thinking of a better way to initialise Proll and implement kernel loading.

What are you planning for env->access_type? Sparc MMU needs to know whether 
the memory access is for data or instructions, did the access come from user 
or kernel code and is it read or write.

I'll send updates etc. soonish.

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. 
http://join.msn.com/?page=features/junkmail

Re: [Qemu-devel] Patch: Sparc system support

[Fabrice Bellard]

Blue Swirl wrote:
> Most of your changes are ok, except for the DHCP one. It's idea is to 
> respond to BOOTP clients which use no extensions added by DHCP.
> 
> The magic address-banging loader is a quick & dirty hack anyway, I'm 
> thinking of a better way to initialise Proll and implement kernel loading.

OK. So you mean I must reverse your patch in bootp.c or implement a 
correct bootp server ?

> What are you planning for env->access_type? Sparc MMU needs to know 
> whether the memory access is for data or instructions, did the access 
> come from user or kernel code and is it read or write.

rw == 2 in cpu_handle_mmu_fault() will mean 'code access'. I made the 
patch in my repository for i386 and PowerPC, but I need to test it more 
before commiting.

Fabrice.

Re: [Qemu-devel] Patch: Sparc system support

[Blue Swirl]

>OK. So you mean I must reverse your patch in bootp.c or implement a correct 
>bootp server ?

For example like this:
diff -ruN qemu.orig/slirp/bootp.c qemu/slirp/bootp.c
--- qemu.orig/slirp/bootp.c     2004-10-01 00:22:08.000000000 +0200
+++ qemu/slirp/bootp.c  2004-10-02 16:40:07.000000000 +0200
@@ -138,7 +138,8 @@

     if (dhcp_msg_type != DHCPDISCOVER &&
         dhcp_msg_type != DHCPREQUEST)
-        return;
+        dhcp_msg_type = DHCPREQUEST; /* Force reply for old BOOTP clients 
*/
+
     /* XXX: this is a hack to get the client mac address */
     memcpy(client_ethaddr, bp->bp_hwaddr, 6);

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