On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko <atar4q...@googlemail.com> wrote: > 2010/1/19 Blue Swirl <blauwir...@gmail.com>: >> On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko >> <atar4q...@googlemail.com> wrote: >>> 2010/1/15 Artyom Tarasenko <atar4q...@googlemail.com>: >>>> 2010/1/15 Blue Swirl <blauwir...@gmail.com>: >>>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >>>>> <atar4q...@googlemail.com> wrote: >>>>>> 2010/1/15 Blue Swirl <blauwir...@gmail.com>: >>>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko >>>>>>> <atar4q...@googlemail.com> wrote: >>>>>>>> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controller >>>>>>>> User's Manual": >>>>>>>> >>>>>>>> 1. "A lower priority fault may not overwrite the >>>>>>>> MFSR status of a higher priority fault." >>>>>>>> 2. The MFAR is overwritten according to the policy defined for the MFSR >>>>>>>> 3. The overwrite bit is asserted if the fault status register (MFSR) >>>>>>>> has been written more than once by faults of the same class >>>>>>>> 4. SuperSPARC will never place instruction fault addresses in the MFAR. >>>>>>>> >>>>>>>> Implementation of points 1-3 allows booting Solaris 2.6 and 2.5.1. >>>>>>> >>>>>>> Nice work! This also passes my tests. >>>>>> >>>>>> I'm afraid we still are not there yet though: Solaris 7 fails >>>>>> potentially due to >>>>>> another bug in the MMU emulation, and the initial [missing-] RAM >>>>>> detection in OBP fails >>>>>> very probably due to a bug in in the MMU emulation. >>>>> >>>>> Some guesses: >>>>> - Access to unassigned RAM area may be handled by the memory >>>>> controller differently (no faults, different faults etc.) than >>>>> unassigned access to SBus or other area. >>> >>> You are right! It seems to be true for the area larger than max RAM though. >>> On a real SS-5 with 32M in the first bank, no fault is produced at >>> least for the areas >>> 0-0x2fffffff, 0x70000000-0xafffffff (ha, this would solve problems >>> with SS-20 OBP >>> too) and 0xf0000000-0xf6ffffff. >> >> The fault may still be recorded somewhere else (MXCC, RAM/ECC >> controller or IOMMU). > > sfar and sfsr were empty, so it's definitely not MXCC. Don't know > where to look for the other two.
For SS-5 there is MFAR and MFSR in IOMMU (0x10001050, 0x10001054), see chapters 6.3.7 and 6.3.8 in "TurboSPARC Microprocessor User's Guide", Fujitsu, October 1996, version 1.0. SS-20 has M-S AFAR/AFSR (5.2.1 in Sun4m System Architecture Manual) and ECC EFSR and EFAR (5.5.2/5.5.3). With Viking there is also B.III.5.4.6. MXCC Error Register. > But how the fault would be generated? Don't know about Sun simms, but > PC ones don't have any handshake. IMHO the ECC can be the only > possibility. > >> OBP may have disabled the fault, or it has not >> enabled fault generation. > > NF bit is not set. Also, you can see the other faults. I meant memory parity etc. On TurboSparc, parity is enabled in MMU config register. The fault is registerd in MFSR/MFAR. >> On SS-5, the physical address space should be only 31 bits, so you >> should see RAM aliased at 0x80000000. > > No. The RAM can be aliased only within one bank or completely outside > the RAM area. Otherwise different banks would have interfered. > >>> Would you like to implement it? >> >> For RAM, there could be a new device which implements generic address >> space wrapping (base, length, AND mask, OR mask), it should be useful >> for embedded boards. Shouldn't be too difficult, want to try? :-) > > Minutes for you, days for me. :) > >> Dummy MMIO could be registered for the other areas in sun4m.c. I'm not >> sure this is the correct approach, if the fault is still handled >> somewhere else. >> >>> That's how I tested it: >>> >>> ok 8000000 map? >>> Virtual : 0800.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.ec20 0000.0000 Invalid >>> ok 8000000 obmem 8000000 map-page >>> ok 8000000 map? >>> Virtual : 0800.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.ec20 001f.b231 >>> Segment : @ 0.01fb.2300 001f.b221 >>> Page : @ 0.01fb.2200 0080.001e Access : rwx--- >>> Physical : 0.0800.0000 >>> ok 8000000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> 8000000 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. >>> 8000010 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. >> >> RAM? > > Looks like a white noise to me. The first byte is frequently > different. Also the mapped RAM is filled with 0's. The pattern can not > be found anywhere in the mapped RAM (0x1000-0x9fffff): > > ok create pattern hex 00 c, d1 c, e1 c, 44 c, ff c, d1 c, e2 c, 18 c, > ok pattern 8 1000 9effff sindex . > ffffffff > ok > > Hold on... I tested only the reading. Should have tested writing too: > > ok aa55aa55 8000000 l! > ok sfar@ . sfsr@ . > 0 0 > > no fault, no interrupt, but > > ok 8000000 10 dump > \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef > 8000000 00 d1 e1 44 ff d1 e2 18 08 d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. > ok > > no change either. And if I read it differently I get other contents: > ok 8000000 l@ . > f811bdd > > So it's either a noise or a random cache contents. > >>> ok >>> ok 10000000 map? >>> Virtual : 1000.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.ec40 0000.0000 Invalid >>> ok 10000000 obmem 10000000 map-page >>> ok 10000000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> 10000000 04 00 00 05 00 1f e0 00 04 00 00 05 00 1f e0 00 ......`.......`. >>> 10000010 04 00 00 05 04 00 00 05 04 00 00 05 04 00 00 05 ................ >> >> IOMMU registers here... >> >>> ok 30000000 map? >>> Virtual : 3000.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.ecc0 0000.0000 Invalid >>> ok 30000000 obmem 30000000 map-page >>> ok 30000000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> 30000000 Data Access Error >>> ok 2fff0000 obmem 2fff0000 map-page >>> ok 2fff0000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> 2fff0000 02 ff e1 44 ff d1 e2 18 2f d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. >>> 2fff0010 00 d1 e1 44 ff d1 e2 18 2f d1 e1 4e ff d1 e2 18 .QaV.Qb..QaV.Qb. >> >> RAM again? > > In theory it could be a RAM alias, as it is outside RAM area, but RAM > wouldn't be immutable. > And... should have tested this one for writing too: > > ok aa55aa55 2fff0000 l! > Level 15 Interrupt > ok sfar@ . sfsr@ . > 0 0 > ok > > No fault, but a NMI! Might be an ECC error as written on page 58 of > Sun4m architecture manual. But this particular SS-5 doesn't seem to > know anything about ECC. It's not in the device tree and reading the > fault address register via asi doesn't work either: > > ok 10 2f spacel! . > Data Access Error > ok No, SS-5 is very different from SS-10/20/600MP so there is no ECC. > > Viking CPU also produces NMI after the mmu trap (page 89), but this is > a SS-5, so no Vikings. Could be an asynchronous fault, but afar > doesn't match: > > ok afsr@ . afar@ . > 3820000 71100006 > > So, no idea who pulls the NMI. > >> >>> ok >>> ok f0000000 map? >>> Virtual : f000.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.efc0 0000.0000 Invalid >>> ok f0000000 obmem f0000000 map-page >>> ok f0000000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> f0000000 10 80 2f 66 a1 48 00 00 01 00 00 00 01 00 00 00 ../f!H.......... >>> f0000010 29 1c 00 04 a8 15 20 d0 81 c5 00 00 a1 48 00 00 )...(. P.E..!H.. >> >> This could be boot ROM aliased all over 0xf0000000 to 0xffffffff. > > Yes, probably a ROM alias, but not to 0xffffffff, only to 0xf6ffffff, > see the fault below. > >>> ok f7ff0000 map? >>> Virtual : f7ff.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.efdc 0000.0000 Invalid >>> ok f7ff0000 obmem f7ff0000 map-page >>> ok f7ff0000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> f7ff0000 Data Access Error >>> ok f6ff0000 map? >>> Virtual : f6ff.0000 >>> Context : @ 0.01ff.f000 001f.eec1 # 0 >>> Region : @ 0.01fe.efd8 0000.0000 Invalid >>> ok f6ff0000 obmem f6ff0000 map-page >>> ok f6ff0000 20 dump >>> \/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef >>> f6ff0000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ >>> f6ff0010 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ > > -- > Regards, > Artyom Tarasenko > > solaris/sparc under qemu blog: http://tyom.blogspot.com/ >
