From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NXLtG-0005yU-LL for qemu-devel@nongnu.org; Tue, 19 Jan 2010 16:45:34 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NXLtC-0005wd-M1 for qemu-devel@nongnu.org; Tue, 19 Jan 2010 16:45:34 -0500 Received: from [199.232.76.173] (port=39213 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NXLtC-0005wY-JL for qemu-devel@nongnu.org; Tue, 19 Jan 2010 16:45:30 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:46033) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NXLtC-0007ny-3D for qemu-devel@nongnu.org; Tue, 19 Jan 2010 16:45:30 -0500 Received: by yxe26 with SMTP id 26so3695964yxe.4 for ; Tue, 19 Jan 2010 13:45:29 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263581172-16129-1-git-send-email-atar4qemu@google.com> From: Artyom Tarasenko Date: Tue, 19 Jan 2010 22:44:48 +0100 Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Qemu-devel] Re: sparc32 do_unassigned_access overhaul List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Blue Swirl Cc: qemu-devel@nongnu.org 2010/1/19 Blue Swirl : > On Tue, Jan 19, 2010 at 5:30 PM, Artyom Tarasenko > wrote: >> 2010/1/15 Artyom Tarasenko : >>> 2010/1/15 Blue Swirl : >>>> On Fri, Jan 15, 2010 at 9:11 PM, Artyom Tarasenko >>>> wrote: >>>>> 2010/1/15 Blue Swirl : >>>>>> On Fri, Jan 15, 2010 at 6:46 PM, Artyom Tarasenko >>>>>> wrote: >>>>>>> According to pages 9-31 - 9-34 of "SuperSPARC & MultiCache Controll= er >>>>>>> User's Manual": >>>>>>> >>>>>>> 1. "A lower priority fault may not overwrite the >>>>>>> =A0 =A0MFSR 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= ) >>>>>>> =A0 has been written more than once by faults of the same class >>>>>>> 4. SuperSPARC will never place instruction fault addresses in the M= FAR. >>>>>>> >>>>>>> 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 potenti= ally 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: >>>> =A0- 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 thou= gh. >> 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. 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. > 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 =A0: 0800.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.ec20 =A00000.0000 Invalid >> ok 8000000 obmem 8000000 map-page >> ok 8000000 map? >> Virtual =A0: 0800.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.ec20 =A0001f.b231 >> Segment =A0: @ 0.01fb.2300 =A0001f.b221 >> Page =A0 =A0 : @ 0.01fb.2200 =A00080.001e Access : rwx--- >> Physical : 0.0800.0000 >> ok 8000000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> =A08000000 =A000 d1 e1 44 ff d1 e2 18 =A008 d1 e1 4e ff d1 e2 18 =A0.QaV= .Qb..QaV.Qb. >> =A08000010 =A000 d1 e1 44 ff d1 e2 18 =A008 d1 e1 4e ff d1 e2 18 =A0.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 v123456789abcde= f 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 =A0: 1000.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.ec40 =A00000.0000 Invalid >> ok 10000000 obmem 10000000 map-page >> ok 10000000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> 10000000 =A004 00 00 05 00 1f e0 00 =A004 00 00 05 00 1f e0 00 =A0......= `.......`. >> 10000010 =A004 00 00 05 04 00 00 05 =A004 00 00 05 04 00 00 05 =A0......= .......... > > IOMMU registers here... > >> ok 30000000 map? >> Virtual =A0: 3000.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.ecc0 =A00000.0000 Invalid >> ok 30000000 obmem 30000000 map-page >> ok 30000000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> 30000000 =A0Data Access Error >> ok 2fff0000 obmem 2fff0000 map-page >> ok 2fff0000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> 2fff0000 =A002 ff e1 44 ff d1 e2 18 =A02f d1 e1 4e ff d1 e2 18 =A0.QaV.Q= b..QaV.Qb. >> 2fff0010 =A000 d1 e1 44 ff d1 e2 18 =A02f d1 e1 4e ff d1 e2 18 =A0.QaV.Q= b..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 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 =A0: f000.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.efc0 =A00000.0000 Invalid >> ok f0000000 obmem f0000000 map-page >> ok f0000000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> f0000000 =A010 80 2f 66 a1 48 00 00 =A001 00 00 00 01 00 00 00 =A0../f!H= .......... >> f0000010 =A029 1c 00 04 a8 15 20 d0 =A081 c5 00 00 a1 48 00 00 =A0)...(.= 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 =A0: f7ff.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.efdc =A00000.0000 Invalid >> ok f7ff0000 obmem f7ff0000 map-page >> ok f7ff0000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> f7ff0000 =A0Data Access Error >> ok f6ff0000 map? >> Virtual =A0: f6ff.0000 >> Context =A0: @ 0.01ff.f000 =A0001f.eec1 # 0 >> Region =A0 : @ 0.01fe.efd8 =A00000.0000 Invalid >> ok f6ff0000 obmem f6ff0000 map-page >> ok f6ff0000 20 dump >> =A0 =A0 =A0 =A0 =A0\/ =A01 =A02 =A03 =A04 =A05 =A06 =A07 =A0 8 =A09 =A0a= =A0b =A0c =A0d =A0e =A0f =A0v123456789abcdef >> f6ff0000 =A0ff ff ff ff ff ff ff ff =A0ff ff ff ff ff ff ff ff =A0......= .......... >> f6ff0010 =A0ff ff ff ff ff ff ff ff =A0ff ff ff ff ff ff ff ff =A0......= .......... --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/