Date: Mon, 28 Sep 2015 00:06:08 +0100 From: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> To: Marius Strobl <marius@alchemy.franken.de> Cc: Alexey Dokuchaev <danfe@FreeBSD.org>, "freebsd-sparc64@freebsd.org" <freebsd-sparc64@freebsd.org> Subject: Re: PCI range checking under qemu-system-sparc64 Message-ID: <56087660.6070408@ilande.co.uk> In-Reply-To: <20150924195603.GT18789@alchemy.franken.de> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56087660.6070408>