From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NVu29-0008Rd-Om for qemu-devel@nongnu.org; Fri, 15 Jan 2010 16:48:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NVu25-0008N5-Vs for qemu-devel@nongnu.org; Fri, 15 Jan 2010 16:48:45 -0500 Received: from [199.232.76.173] (port=47632 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NVu25-0008Mv-RP for qemu-devel@nongnu.org; Fri, 15 Jan 2010 16:48:41 -0500 Received: from mail-yw0-f176.google.com ([209.85.211.176]:34966) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NVu25-0001dk-G5 for qemu-devel@nongnu.org; Fri, 15 Jan 2010 16:48:41 -0500 Received: by ywh6 with SMTP id 6so926321ywh.4 for ; Fri, 15 Jan 2010 13:48:40 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1263581172-16129-1-git-send-email-atar4qemu@google.com> From: Artyom Tarasenko Date: Fri, 15 Jan 2010 22:48:20 +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/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 Controller >>>> 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 MFS= R >>>> 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 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 potentiall= y 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. It is possible, but may not be the only reason: -M SS-20 -cpu "TI SuperSparc 50" detects missing RAM properly, and -cpu "TI SuperSparc 51" doesn't. Looks like the problem has to do with the cache. Also Solaris 2.5&2.6 hang with -M SS-20 very early, at the place where they say "vac: enabled in write through mode" on SS-5. Unfortunately I don't know any cacheless SS-5 cpu, which would have helped to prove the hypothesis. > =A0- Real RAM banks have aliasing effects (which could be emulated by > mapping the aliased RAM areas many times). They do, but afaics it should be relevant only for sizes < max RAM bank siz= e. > =A0- OBP on machines with ECC controller may detect missing RAM using ECC= checks. There is a special message in OBP for ECC failures. (I know it is a weak argument, but still). --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/