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). OBP may have disabled the fault, or it has not enabled fault generation. On SS-5, the physical address space should be only 31 bits, so you should see RAM aliased at 0x80000000. > 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? :-) 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? > 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? > 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. > 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/ >