From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYQTn-00066G-Tz for qemu-devel@nongnu.org; Fri, 22 Jan 2010 15:51:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYQTi-00063o-VA for qemu-devel@nongnu.org; Fri, 22 Jan 2010 15:51:43 -0500 Received: from [199.232.76.173] (port=42980 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYQTi-00063g-SQ for qemu-devel@nongnu.org; Fri, 22 Jan 2010 15:51:38 -0500 Received: from mx20.gnu.org ([199.232.41.8]:30017) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NYQTi-0006Yn-CG for qemu-devel@nongnu.org; Fri, 22 Jan 2010 15:51:38 -0500 Received: from mail-pw0-f43.google.com ([209.85.160.43]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYQTh-0005qZ-4s for qemu-devel@nongnu.org; Fri, 22 Jan 2010 15:51:37 -0500 Received: by pwj11 with SMTP id 11so1136415pwj.2 for ; Fri, 22 Jan 2010 12:51:35 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263581172-16129-1-git-send-email-atar4qemu@google.com> From: Artyom Tarasenko Date: Fri, 22 Jan 2010 21:51:15 +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/22 Blue Swirl : > On Tue, Jan 19, 2010 at 9:44 PM, Artyom Tarasenko > wrote: >> 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 Contro= ller >>>>>>>>> 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 th= e MFSR >>>>>>>>> 3. The overwrite bit is asserted if the fault status register (MF= SR) >>>>>>>>> =A0 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 poten= tially 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 th= ough. >>>> 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. :) > > Here's my patch. It implements mapping of bottom 2G to upper 2G. Could > you play with the patch and try to implement RAM aliasing so that OBP > is content? It's a nice patch, but I'm confused. I thought that in my last mail I proved that we don't observe any RAM aliasing on SS-5. We see some ROM aliasing, but I'm not sure whether it's worth implementing. Also we see no synchronous faults on SS-5 when accessing missing memory. Haven't tested it on SS-20 yet. I'll try to get an access to a real SS-20 next week (can't have a simultaneous access to the both of them). --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/