From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Meqfw-0000PC-Ts for qemu-devel@nongnu.org; Sat, 22 Aug 2009 09:30:32 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Meqfs-0000OY-BJ for qemu-devel@nongnu.org; Sat, 22 Aug 2009 09:30:32 -0400 Received: from [199.232.76.173] (port=48676 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Meqfs-0000OV-6H for qemu-devel@nongnu.org; Sat, 22 Aug 2009 09:30:28 -0400 Received: from pop-satin.atl.sa.earthlink.net ([207.69.195.63]:42272) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Meqfr-0007is-Rl for qemu-devel@nongnu.org; Sat, 22 Aug 2009 09:30:28 -0400 Message-ID: <4A8FF2F0.2090108@earthlink.net> Date: Sat, 22 Aug 2009 09:30:24 -0400 From: Robert Reif MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: target-sparc/TODO References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040204080007030505060607" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Artyom Tarasenko Cc: Blue Swirl , qemu-devel This is a multi-part message in MIME format. --------------040204080007030505060607 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 %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. --------------040204080007030505060607 Content-Type: text/plain; name="eccmemctl.diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="eccmemctl.diff.txt" 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; --------------040204080007030505060607--