From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MeuM4-0004cg-QO for qemu-devel@nongnu.org; Sat, 22 Aug 2009 13:26:16 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MeuLz-0004b3-G7 for qemu-devel@nongnu.org; Sat, 22 Aug 2009 13:26:15 -0400 Received: from [199.232.76.173] (port=36896 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MeuLz-0004b0-7C for qemu-devel@nongnu.org; Sat, 22 Aug 2009 13:26:11 -0400 Received: from mail-gx0-f211.google.com ([209.85.217.211]:60029) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MeuLy-0003D8-Rq for qemu-devel@nongnu.org; Sat, 22 Aug 2009 13:26:11 -0400 Received: by gxk7 with SMTP id 7so1828771gxk.8 for ; Sat, 22 Aug 2009 10:26:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4A8FF2F0.2090108@earthlink.net> References: <4A8FF2F0.2090108@earthlink.net> From: Artyom Tarasenko Date: Sat, 22 Aug 2009 19:25:50 +0200 Message-ID: Subject: Re: [Qemu-devel] Re: target-sparc/TODO Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Robert Reif Cc: Blue Swirl , qemu-devel 2009/8/22 Robert Reif : > Artyom Tarasenko wrote: >> >> 2009/8/22 Blue Swirl : >> >>> >>> On Sat, Aug 22, 2009 at 12:01 AM, Artyom >>> Tarasenko wrote: >>> >>>> >>>> 2009/8/21 Blue Swirl : >>>> >>>>> >>>>> On Fri, Aug 21, 2009 at 3:40 PM, Artyom >>>>> Tarasenko wrote: >>>>> >>>>>> >>>>>> 2009/8/21 Artyom Tarasenko : >>>>>> >>>>>>> >>>>>>> 2009/8/20 Blue Swirl : >>>>>>> >>>>>>>> >>>>>>>> On Thu, Aug 20, 2009 at 12:44 PM, Artyom >>>>>>>> Tarasenko wrote: >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Particularly I'm interested if >>>>>>>>>>> >>>>>>>>>>> jmp =A0 =A0 %l1, %g4, %g0 >>>>>>>>>>> >>>>>>>>>>> may behave other than on a real hw. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> No, if rd is %g0, the current PC will not be written anywhere (n= ot >>>>>>>>>> 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! do= es >>>>>>>>> an >>>>>>>>> asi write, and spacel@ does an asi read, and under qemu =A0spacel= ! >>>>>>>>> seems >>>>>>>>> to do nothing, and spacel@ returns its second parameter multiplie= d >>>>>>>>> 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 shift= s >>>>>>>>> which would multiply by 4: >>>>>>>>> >>>>>>>>> ok see spacel! >>>>>>>>> code spacel! >>>>>>>>> ffd26e0c =A0 =A0 ld =A0 =A0 =A0[%g7], %l2 >>>>>>>>> ffd26e10 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>>>>>>>> ffd26e14 =A0 =A0 ld =A0 =A0 =A0[%g7], %l0 >>>>>>>>> ffd26e18 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>>>>>>>> ffd26e1c =A0 =A0 sll =A0 =A0 %g4, 2, %g4 >>>>>>>>> ffd26e20 =A0 =A0 call =A0 =A0ffd26e24 >>>>>>>>> ffd26e24 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>>>>>>>> >>>>>>>>> ok ffd26e24 dis >>>>>>>>> ffd26e24 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>>>>>>>> ffd26e28 =A0 =A0 add =A0 =A0 %o7, %l1, %l1 >>>>>>>>> ffd26e2c =A0 =A0 jmp =A0 =A0 %l1, %g4, %g0 >>>>>>>>> ffd26e30 =A0 =A0 ba =A0 =A0 =A0ffd26f68 >>>>>>>>> ok >>>>>>>>> >>>>>>>>> ok see spacel@ >>>>>>>>> code spacel@ >>>>>>>>> ffd26830 =A0 =A0 ld =A0 =A0 =A0[%g7], %l0 >>>>>>>>> ffd26834 =A0 =A0 add =A0 =A0 %g7, 4, %g7 >>>>>>>>> ffd26838 =A0 =A0 sll =A0 =A0 %g4, 2, %g4 >>>>>>>>> ffd2683c =A0 =A0 call =A0 =A0ffd26840 >>>>>>>>> ffd26840 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>>>>>>>> >>>>>>>>> ok ffd26840 dis >>>>>>>>> ffd26840 =A0 =A0 add =A0 =A0 %g0, 14, %l1 >>>>>>>>> ffd26844 =A0 =A0 add =A0 =A0 %o7, %l1, %l1 >>>>>>>>> ffd26848 =A0 =A0 jmp =A0 =A0 %l1, %g4, %g0 >>>>>>>>> ffd2684c =A0 =A0 ba =A0 =A0 =A0ffd26984 >>>>>>>>> >>>>>>>>> >>>>>>>>> The code is identical on a real and emulated SS. >>>>>>>>> >>>>>>>>> It must be the jump, which jumps differently on a real hw and und= er >>>>>>>>> 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 instructio= n >>>>>>>> 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 branc= h. >>>>>> =A0Is 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. > > > 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) > > =A0 =A0 if (s->version =3D=3D ECC_MCC) > =A0 =A0 =A0 =A0 s->regs[ECC_MER] &=3D ECC_MER_REU; > - =A0 =A0else > - =A0 =A0 =A0 =A0s->regs[ECC_MER] &=3D (ECC_MER_VER | ECC_MER_IMPL | ECC_= MER_MRR | > - =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ECC_MER_DCI); > - =A0 =A0s->regs[ECC_MDR] =3D 0x20; > + =A0 =A0else { > + =A0 =A0 =A0 =A0s->regs[ECC_MER] &=3D (ECC_MER_VER | ECC_MER_IMPL | ECC_= MER_DCI); > + =A0 =A0 =A0 =A0s->regs[ECC_MER] |=3D ECC_MER_MRR; > + =A0 =A0} > + =A0 =A0s->regs[ECC_MDR] =3D 0x40; > =A0 =A0 s->regs[ECC_MFSR] =3D 0; > =A0 =A0 s->regs[ECC_VCR] =3D 0; > =A0 =A0 s->regs[ECC_MFAR0] =3D 0x07c00000; > The piece of code is still there, but the patch makes no visible effect on SS-5, 10 and 20: Probing Memory Bank #0 64 Megabytes of DRAM ... Probing Memory Bank #3 64 Megabytes of DRAM Probing Memory Bank #4 Data Access Error ok Do you remember, for which machine/OBP was it intended?