From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Ip4Or-0002xB-Fr
	for qemu-devel@nongnu.org; Mon, 05 Nov 2007 11:02:05 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Ip4Oo-0002vw-QD
	for qemu-devel@nongnu.org; Mon, 05 Nov 2007 11:02:05 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ip4Oo-0002vt-N9
	for qemu-devel@nongnu.org; Mon, 05 Nov 2007 11:02:02 -0500
Received: from nf-out-0910.google.com ([64.233.182.184])
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <blauwirbel@gmail.com>) id 1Ip4On-0003Zr-SQ
	for qemu-devel@nongnu.org; Mon, 05 Nov 2007 11:02:02 -0500
Received: by nf-out-0910.google.com with SMTP id 30so1328313nfu
	for <qemu-devel@nongnu.org>; Mon, 05 Nov 2007 08:02:01 -0800 (PST)
Message-ID: <f43fc5580711050802p23633375s6b65d5894901bef5@mail.gmail.com>
Date: Mon, 5 Nov 2007 18:02:00 +0200
From: "Blue Swirl" <blauwirbel@gmail.com>
Subject: Re: [Qemu-devel] sparc hflags support?
In-Reply-To: <200711042347.48438.paul@codesourcery.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <472E5919.80307@earthlink.net>
	<200711042347.48438.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

On 11/5/07, Paul Brook <paul@codesourcery.com> wrote:
> On Sunday 04 November 2007, Robert Reif wrote:
> > I'm looking at adding more complete support for different sparc32
> > CPUs, MMUs,  cache controllers and systems.
> >
> > Each CPU/MMU/cache controller combination is slightly different and
> > requires its own unique state.  For example the two CPUs currently
> > supported save the boot mode in different bits in the MMU control
> > register: 0x2000 for the SuperSparc and 0x4000 for the TurboSparc.
> > Others bits will need to be saved in the MMU and cache controllers
> > as better hardware emulation is added.
>
> If it's something that only changes rarely (e.g. when switching from early
> boot to a real OS environment) you can just do a tb flush.

Boot mode is used even earlier. It's enabled on reset and it forces
the boot rom to occupy all of the address space. Boot rom disables it
after relocating itself and enabling the MMU. On Sparc the MMU is
never disabled after that, even during boot.

> Does mmu/cache mode actually effect the instruction semantics?

No, only instruction fetches, though I don't know about the cache controllers.