From owner-freebsd-sparc64@freebsd.org Sun Sep 27 23:06:31 2015 Return-Path: Delivered-To: freebsd-sparc64@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0D009A0A2AC for ; Sun, 27 Sep 2015 23:06:31 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from s16892447.onlinehome-server.info (s16892447.onlinehome-server.info [82.165.15.123]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BC1FCCC9; Sun, 27 Sep 2015 23:06:29 +0000 (UTC) (envelope-from mark.cave-ayland@ilande.co.uk) Received: from [94.9.62.106] (helo=[192.168.1.87]) by s16892447.onlinehome-server.info with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.76) (envelope-from ) id 1ZgL1O-0004yi-9B; Mon, 28 Sep 2015 00:06:19 +0100 Message-ID: <56087660.6070408@ilande.co.uk> Date: Mon, 28 Sep 2015 00:06:08 +0100 From: Mark Cave-Ayland User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.8.0 MIME-Version: 1.0 To: Marius Strobl CC: Alexey Dokuchaev , "freebsd-sparc64@freebsd.org" References: <20150916211914.GD18789@alchemy.franken.de> <20150917082817.GA71811@FreeBSD.org> <55FBB662.4080708@ilande.co.uk> <20150919211420.GK18789@alchemy.franken.de> <55FDEA3C.1010804@ilande.co.uk> <20150920043630.GA36162@FreeBSD.org> <20150922221404.GA81100@alchemy.franken.de> <560260A9.9010505@ilande.co.uk> <20150923204336.GO18789@alchemy.franken.de> <56044B9C.8030105@ilande.co.uk> <20150924195603.GT18789@alchemy.franken.de> In-Reply-To: <20150924195603.GT18789@alchemy.franken.de> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 94.9.62.106 X-SA-Exim-Mail-From: mark.cave-ayland@ilande.co.uk X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on s16892447.onlinehome-server.info X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, URIBL_BLOCKED autolearn=ham version=3.3.2 Subject: Re: PCI range checking under qemu-system-sparc64 X-SA-Exim-Version: 4.2.1 (built Sun, 08 Jan 2012 02:45:44 +0000) X-SA-Exim-Scanned: Yes (on s16892447.onlinehome-server.info) X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 23:06:31 -0000 On 24/09/15 20:56, Marius Strobl wrote: > On Thu, Sep 24, 2015 at 08:14:36PM +0100, Mark Cave-Ayland wrote: >> On 23/09/15 21:43, Marius Strobl wrote: >> >>> On Wed, Sep 23, 2015 at 09:19:53AM +0100, Mark Cave-Ayland wrote: >>>> >>>> I've had a quick look through the relevant PDFs and the definitions I >>>> have for tick/stick are this: >>>> >>>> tick: >>>> bit 63: NPT (Non-Privileged Trap enable - defaults to 1) >>>> bits 62 - 0: CPU cycle counter >>>> >>>> tick_cmpr: >>>> bit 63: Interrupt disable (1 = no interrupt) >>>> bits 62 - 0: counter compare value >>>> >>>> stick: >>>> bit 63: Reserved (reads 0, no write) >>>> bits 62 - 0: stick register count value >>> >>> I cannot confirm that, the specification for the first sun4u CPU >>> having a %stick register (UltraSPARC III, see 1, p. 6-105) up to >>> the latest architecture specification (see 2, p. 60) say that bit >>> 32 of %stick is NPT, just as with %tick. Same for the specification >>> the Fujitsu SPARC64 processors follow (3, p. 90). >> >> Interesting. The document I'm referring to in my local collection is the >> UltraSPARC IIe specification which you can find a copy at >> http://www.coris.org.uk/misc/Sundocs/USIIe_ext_1.1.pdf (see page 29). I >> don't see this as necessarily being a conflict, it just seems that the >> IIe allows unprivileged access to %stick. > > Err, we are taking about different STICK registers. The one I was > referring to is the ASR24 CPU register, i. e. the thing QEMU tries > to emulate. It works akin to TICK (%tick in GCC assembly) but is > driven by a different clock in real machines. The STICK frequency > is guaranteed to be the same across all CPUs (which unfortunately > doesn't imply that the STICK registers are synchronized). ASR24 > and the accompanying compare register (ASR25) were introduced with > the UltraSPARC III as systems built on these were the first sun4u > machines allowing to mix different CPU speeds (which results in > different TICK clocks). > > UltraSPARC IIe had sort of a predecessor to that STICK register. > The main difference is that the UltraSPARC IIe version has been > implemented in I/O space (see page 42 of the PDF file you are > citing), IIRC as part of the Hummingbird host-PCI-bridge built > into the actual UltraSPARC IIe chips. That also explains why it > has no NPT functionality (and why the UltraSPARC IIe user manual > may be confusing as it doesn't solely document the CPU core; I > think this isn't that different with UltraSPARC IIi, though). > The UltraSPARC IIe STICK register was introduced to ease time > keeping when the CPU clock is throttled (referred to as E-Star > operation here; STICK frequency is unaffected by it). > In short: You can ignore the UltraSPARC IIe documentation for > the STICK CPU register QEMU tries to emulate. Now I see - I didn't quite appreciate the difference between IIe and II %stick registers. Given that the default processor for QEMU is the TI UltraSPARC IIi, does that mean that %stick should even be implemented in the default configuration? In other news, as of this weekend I've finally got my FreeBSD VM set up with -CURRENT and generating a SPARC64 .iso for test. I've got a basic patchset for kb_ps2 and kdmouse that attaches under all of the BSDs but causes my test Linux kernel to reference a NULL pointer. I'll post the patchset onto the OpenBIOS list and a test binary as soon as I have something that passes all of my local tests. ATB, Mark.