From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYktl-0001Gf-Rt for qemu-devel@nongnu.org; Sat, 23 Jan 2010 13:39:54 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYktg-0001DU-PY for qemu-devel@nongnu.org; Sat, 23 Jan 2010 13:39:52 -0500 Received: from [199.232.76.173] (port=52484 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYktg-0001DN-77 for qemu-devel@nongnu.org; Sat, 23 Jan 2010 13:39:48 -0500 Received: from mail-px0-f189.google.com ([209.85.216.189]:58511) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYktf-0007pa-Jz for qemu-devel@nongnu.org; Sat, 23 Jan 2010 13:39:47 -0500 Received: by pxi27 with SMTP id 27so1520196pxi.4 for ; Sat, 23 Jan 2010 10:39:46 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263581172-16129-1-git-send-email-atar4qemu@google.com> From: Blue Swirl Date: Sat, 23 Jan 2010 18:39:26 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 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: Artyom Tarasenko Cc: qemu-devel@nongnu.org On Sat, Jan 23, 2010 at 4:46 PM, Artyom Tarasenko wrote: > 2010/1/23 Blue Swirl : >> On Fri, Jan 22, 2010 at 8:51 PM, Artyom Tarasenko >> wrote: >>> 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 Con= troller >>>>>>>>>>>> User's Manual": >>>>>>>>>>>> >>>>>>>>>>>> 1. "A lower priority fault may not overwrite the >>>>>>>>>>>> =C2=A0 =C2=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) >>>>>>>>>>>> =C2=A0 has been written more than once by faults of the same c= lass >>>>>>>>>>>> 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 po= tentially 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: >>>>>>>>> =C2=A0- Access to unassigned RAM area may be handled by the memor= y >>>>>>>>> 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. >>>>> >>>>> 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 addres= s >>>>>> space wrapping (base, length, AND mask, OR mask), it should be usefu= l >>>>>> 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. >> >> I'd still expect some aliasing if a bank has smaller chips than >> others. For example, if you have 40M of memory and bank size is 16M, >> there are two full banks and one bank with 8M. This 8M should be >> aliased within the 16MB area twice. >> >> Otherwise the DRAM controller must somehow know or be told the chip size= . >> >> So, the aliasing code could be useful to emulate more arbitrary memory >> sizes (with OBP), not just multiples of bank sizes. > > Yes, but do we need it? Nowadays 32M is small enough (and Classic/X/LX > have even smaller memory banks: 16M. Of course if we going to support > the Ross Technologies SS-20, it will make sense again, as it has > larger memory banks (128M iirc). > > But for now wouldn't it be better to focus on fully supporting full banks= ? Right, it's not unreasonable to fix some limits for OBP use case, like 'you must use 256M only'. >>> 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). >> >> Is memory parity enabled? > > ok mcr@ . > 43d1b01 > ok > > The 12th bit is set. Are there further parity switches on SS-5? Not that I know of.