| Message ID | 4A8FF2F0.2090108@earthlink.net |
|---|---|
| State | Superseded |
| Headers | show |
2009/8/22 Robert Reif <reif@earthlink.net>: > 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. > > > 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; > 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?
Artyom Tarasenko wrote: > 2009/8/22 Robert Reif <reif@earthlink.net>: > >> 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. >> >> >> 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; >> >> > > 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? > > > > It's for the ss10/20. I just found the bug by stepping through the code and compairing what it was doing with the chip manual. I'm not suprised it didn't help. It's just a correctness fix. You have to be careful when specifing a memory size on the ss10/20 because a SIMM slot uses 64M reguardless of the actual size of the SIMM. A smaller size will be mirrored to fill the entire space and OBP checks for mirrioing to determine the actual size. QEMU doesn't do any mirroring for small SIMMS which will confuse OBP. I don't think that is the issue are seeing but just something to keep in mind.
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;