From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38749 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PUcsy-0002Wh-BM for qemu-devel@nongnu.org; Mon, 20 Dec 2010 05:22:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PUcsx-0005uX-0Q for qemu-devel@nongnu.org; Mon, 20 Dec 2010 05:22:32 -0500 Received: from mail-qy0-f180.google.com ([209.85.216.180]:49433) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PUcsw-0005uQ-Qa for qemu-devel@nongnu.org; Mon, 20 Dec 2010 05:22:30 -0500 Received: by qyk29 with SMTP id 29so2764001qyk.4 for ; Mon, 20 Dec 2010 02:22:30 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4D0E5F16.3090905@mc.net> References: <4D0CEAB0.9030706@mc.net> <4D0E5F16.3090905@mc.net> From: Artyom Tarasenko Date: Mon, 20 Dec 2010 11:22:09 +0100 Message-ID: Subject: Re: [Qemu-devel] Re: [PATCH] sparc32: ledma extra registers Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bob Breuer Cc: Blue Swirl , =?ISO-8859-1?Q?Andreas_F=E4rber?= , QEMU Developers On Sun, Dec 19, 2010 at 8:37 PM, Bob Breuer wrote: > Andreas F=E4rber wrote: >> Am 18.12.2010 um 19:53 schrieb Blue Swirl: >> >>> On Sat, Dec 18, 2010 at 5:09 PM, Bob Breuer wrote: >>>> ledma has 0x20 bytes of registers according to OBP, and at least >>>> Solaris9 >>>> reads the 5th register which is beyond what we've mapped. =A0So let's >>>> setup >>>> a flag (inspired by a previous patch from Blue Swirl) to identify ledm= a >>>> from espdma, and map another 16 bytes of registers which return 0. >>>> >>>> Signed-off-by: Bob Breuer >> >> I'm not familar with that part of code but... >> >>>> diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c >>>> index e78f025..56be8c8 100644 >>>> --- a/hw/sparc32_dma.c >>>> +++ b/hw/sparc32_dma.c >> >>>> @@ -165,6 +169,9 @@ static uint32_t dma_mem_readl(void *opaque, >>>> target_phys_addr_t addr) >>>> =A0 =A0 DMAState *s =3D opaque; >>>> =A0 =A0 uint32_t saddr; >>>> >>>> + =A0 =A0if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) { >>>> + =A0 =A0 =A0 =A0return 0; /* extra mystery register(s) */ >> >> Wouldn't it be a good idea to trace these "mystery" reads... >> >>>> + =A0 =A0} >>>> =A0 =A0 saddr =3D (addr & DMA_MASK) >> 2; >>>> =A0 =A0 trace_sparc32_dma_mem_readl(addr, s->dmaregs[saddr]); >>>> =A0 =A0 return s->dmaregs[saddr]; >>>> @@ -175,6 +182,9 @@ static void dma_mem_writel(void *opaque, >>>> target_phys_addr_t addr, uint32_t val) >>>> =A0 =A0 DMAState *s =3D opaque; >>>> =A0 =A0 uint32_t saddr; >>>> >>>> + =A0 =A0if (s->is_ledma && (addr > DMA_MAX_REG_OFFSET)) { >>>> + =A0 =A0 =A0 =A0return; /* extra mystery register(s) */ >> >> ...and writes? We return just before the tracepoints fire. >> > > Ok, I'll put together a patch to add the trace calls just before the > returns. =A0How about I also call it undocumented instead of mystery. > None of the BSD's or Linux know about or use anything beyond the 4 > registers. I'd use "aliased" instead of mystery. On a real SS-5: ok 78400020 20 spacel@ . a4240050 ok 78400000 20 spacel@ . a4240050 ok 78400024 20 spacel@ . fc004000 ok 78400004 20 spacel@ . fc004000 Addresses 0x7840002x are aliases for 0x7840000x. As well as 0x7840004x. And so on up to ok 787fffe4 20 spacel@ . fc004000 78800004 20 spacel@ . 0 Or a real SS-20 ef0400000 is aliased up to ef37fffe0 Fwiw I think it's a bug in the later Solaris versions: http://tyom.blogspot.com/2010/10/bug-in-all-solaris-versions-after-57.html On the bare metal it works because of address aliasing. If you want to emulate the hw precisely, the Blue's generic aliasing patch can be used here. The question is though do we want to do a generic aliasing for all the SBUS devices, or just in the single case(es) where we know is necessary. On the other hand Solaris seems to be fine with a 0 stub too. --=20 Regards, Artyom Tarasenko solaris/sparc under qemu blog: http://tyom.blogspot.com/