[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Re: target-sparc/TODO

From: Robert Reif
Subject: Re: [Qemu-devel] Re: target-sparc/TODO
Date: Sat, 22 Aug 2009 09:30:24 -0400
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20090605 SeaMonkey/1.1.17 (Ubuntu-1.1.17+nobinonly-0ubuntu0.9.04.1)

Artyom Tarasenko wrote:
2009/8/22 Blue Swirl <address@hidden>:
On Sat, Aug 22, 2009 at 12:01 AM, Artyom
Tarasenko<address@hidden> wrote:
2009/8/21 Blue Swirl <address@hidden>:
On Fri, Aug 21, 2009 at 3:40 PM, Artyom
Tarasenko<address@hidden> wrote:
2009/8/21 Artyom Tarasenko <address@hidden>:
2009/8/20 Blue Swirl <address@hidden>:
On Thu, Aug 20, 2009 at 12:44 PM, Artyom
Tarasenko<address@hidden> wrote:
Particularly I'm interested if

jmp     %l1, %g4, %g0

may behave other than on a real hw.
No, if rd is %g0, the current PC will not be written anywhere (not by
real HW either).
The reason I asked is the two following pieces of code work
differently on a real and emulated SS-5. On a real one spacel! does an
asi write, and spacel@ does an asi read, and under qemu  spacel! seems
to do nothing, and spacel@ returns its second parameter multiplied by
4. Both of them don't even try to call an [unimplemented] asi
operation, I've runned the tests with mmu and asi debug turned on.

Real SS-5:

ok 0 0 spacel@ .
Data Access Error
ok 0 20 spacel@ .
ok 12345678 0 20 spacel!
ok 0 20 spacel@ .

qemu SS-5:

ok 0 0 spacel@ .
ok 0 20 spacel@ .
ok 12345678 0 20 spacel!
ok 0 20 spacel@ .

I don't know sparc asm good enogh, but qemu behavior seems to be
logical: in the first case I see no store op, and there are shifts
which would multiply by 4:

ok see spacel!
code spacel!
ffd26e0c     ld      [%g7], %l2
ffd26e10     add     %g7, 4, %g7
ffd26e14     ld      [%g7], %l0
ffd26e18     add     %g7, 4, %g7
ffd26e1c     sll     %g4, 2, %g4
ffd26e20     call    ffd26e24
ffd26e24     add     %g0, 14, %l1

ok ffd26e24 dis
ffd26e24     add     %g0, 14, %l1
ffd26e28     add     %o7, %l1, %l1
ffd26e2c     jmp     %l1, %g4, %g0
ffd26e30     ba      ffd26f68

ok see spacel@
code spacel@
ffd26830     ld      [%g7], %l0
ffd26834     add     %g7, 4, %g7
ffd26838     sll     %g4, 2, %g4
ffd2683c     call    ffd26840
ffd26840     add     %g0, 14, %l1

ok ffd26840 dis
ffd26840     add     %g0, 14, %l1
ffd26844     add     %o7, %l1, %l1
ffd26848     jmp     %l1, %g4, %g0
ffd2684c     ba      ffd26984

The code is identical on a real and emulated SS.

It must be the jump, which jumps differently on a real hw and under
qemu. Do you see from the code where the jump would jump to, or maybe
you have a suggestion how to check where the jump jumps to on the real
The target of the call instruction is also a delay slot instruction
for the call itself. Maybe this case is not handled correctly?
Good idea! Don't know how to test it though.

And what about "ba" in the delay slot of "jmp"? Is the correct
behavior described somewhere? Would jump just be ignored? Whould it
execute one instruction on jump destination and then branch? Would
branch be ignored?
Page 55 of The SPARC v8 Architecture Manual
(http://www.sparc.org/standards/V8.pdf) describes this case
cpu should execute one instruction on the jump target and then branch.
 Is it what qemu currently does?
I may be blind, I don't see the description of this case in that page.
I wasn't referring the call case, but jmp+ba case (two last ops in the
listing above). This DCTI is described on pages marked 55-56 (pages
54-54 in a pdf reader). That's the first case in the table 5-12.

Both QEMU and real (Sparc64) hardware exit with return value of 3, so
the inc is re-executed. If I add a nop in the call delay slot, the
return value is 2.
Can you make a similar test, but with ba in the jmp's delay slot?
Now, we have found a bug!

Looks better now!

Probing Memory Bank #0 64 Megabytes of DRAM
Probing Memory Bank #1 64 Megabytes of DRAM
Probing Memory Bank #2 64 Megabytes of DRAM
Probing Memory Bank #3 64 Megabytes of DRAM
Probing Memory Bank #4 Data Access Error

Used to be "Nothing there". What is a bit surprising, is that only 256
Mib found when started with -m 512. May be a next bug, this time in

With -m 128 :
Probing Memory Bank #0 64 Megabytes of DRAM
Probing Memory Bank #1 64 Megabytes of DRAM
Probing Memory Bank #2 Nothing there
Probing Memory Bank #3 Nothing there
Probing Memory Bank #4 Data Access Error

Here is a very old patch for the eccmemctl that fixes a bug
I found while trying to fix the memory probing problem
that is now fixed.

diff --git a/hw/eccmemctl.c b/hw/eccmemctl.c
index 28519c8..b2bff98 100644
--- a/hw/eccmemctl.c
+++ b/hw/eccmemctl.c
@@ -301,10 +301,11 @@ static void ecc_reset(void *opaque)
     if (s->version == ECC_MCC)
         s->regs[ECC_MER] &= ECC_MER_REU;
-    else
-        s->regs[ECC_MER] &= (ECC_MER_VER | ECC_MER_IMPL | ECC_MER_MRR |
-                             ECC_MER_DCI);
-    s->regs[ECC_MDR] = 0x20;
+    else {
+        s->regs[ECC_MER] &= (ECC_MER_VER | ECC_MER_IMPL | ECC_MER_DCI);
+        s->regs[ECC_MER] |= ECC_MER_MRR;
+    }
+    s->regs[ECC_MDR] = 0x40;
     s->regs[ECC_MFSR] = 0;
     s->regs[ECC_VCR] = 0;
     s->regs[ECC_MFAR0] = 0x07c00000;

reply via email to

[Prev in Thread] Current Thread [Next in Thread]