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

[Robert Reif <reif@earthlink.net>]

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

Artyom Tarasenko wrote:
> 2009/8/22 Blue Swirl <blauwirbel@gmail.com>:
>   
>> On Sat, Aug 22, 2009 at 12:01 AM, Artyom
>> Tarasenko<atar4qemu@googlemail.com> wrote:
>>     
>>> 2009/8/21 Blue Swirl <blauwirbel@gmail.com>:
>>>       
>>>> On Fri, Aug 21, 2009 at 3:40 PM, Artyom
>>>> Tarasenko<atar4qemu@googlemail.com> wrote:
>>>>         
>>>>> 2009/8/21 Artyom Tarasenko <atar4qemu@googlemail.com>:
>>>>>           
>>>>>> 2009/8/20 Blue Swirl <blauwirbel@gmail.com>:
>>>>>>             
>>>>>>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom
>>>>>>> Tarasenko<atar4qemu@googlemail.com> 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@ .
>>>>>>>> 0
>>>>>>>> ok 12345678 0 20 spacel!
>>>>>>>> ok 0 20 spacel@ .
>>>>>>>> 12345678
>>>>>>>> ok
>>>>>>>>
>>>>>>>>
>>>>>>>> qemu SS-5:
>>>>>>>>
>>>>>>>> ok 0 0 spacel@ .
>>>>>>>> 0
>>>>>>>> ok 0 20 spacel@ .
>>>>>>>> 80
>>>>>>>> ok 12345678 0 20 spacel!
>>>>>>>> ok 0 20 spacel@ .
>>>>>>>> 80
>>>>>>>> ok
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>>> 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
>>>>>>>> hw?
>>>>>>>>                 
>>>>>>> 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
>>>>> explicitly:
>>>>> 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
> ok
>
> 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
> ASI.
>
> 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
> ok
>
>
>
>   
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.


[-- Attachment #2: eccmemctl.diff.txt --]
[-- Type: text/plain, Size: 665 bytes --]

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;