From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QszEC-0005Wf-CN for qemu-devel@nongnu.org; Mon, 15 Aug 2011 11:37:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QszEA-0000CM-Um for qemu-devel@nongnu.org; Mon, 15 Aug 2011 11:37:24 -0400 Received: from mail.mc.net ([209.172.128.24]:36977) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QszEA-0000C8-Py for qemu-devel@nongnu.org; Mon, 15 Aug 2011 11:37:22 -0400 Message-ID: <4E493D74.6020303@mc.net> Date: Mon, 15 Aug 2011 10:38:28 -0500 From: Bob Breuer MIME-Version: 1.0 References: <4E43FF4E.7080501@mc.net> <4E48F1A0.3080904@siriusit.co.uk> In-Reply-To: <4E48F1A0.3080904@siriusit.co.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Mark Cave-Ayland wrote: > On 11/08/11 17:11, Bob Breuer wrote: > >> The ledma base address defaults to 0xff000000 on reset. This >> fixes a bug with Solaris and SS-20 OBP when boot net is skipped. >> >> Signed-off-by: Bob Breuer >> --- >> >> diff --git a/hw/sparc32_dma.c b/hw/sparc32_dma.c >> index e75694b..61812fb 100644 >> --- a/hw/sparc32_dma.c >> +++ b/hw/sparc32_dma.c >> @@ -252,6 +252,9 @@ static void dma_reset(DeviceState *d) >> >> memset(s->dmaregs, 0, DMA_SIZE); >> s->dmaregs[0] = DMA_VER; >> + if (s->is_ledma) { >> + s->dmaregs[3] = 0xff000000; >> + } >> } >> >> static const VMStateDescription vmstate_dma = { > > Oh that's interesting indeed. This corresponds to the fix I added to > OpenBIOS here: > http://lists.openbios.org/pipermail/openbios/2011-April/006350.html. > > I guess that we should just assume a fixed address of 0xff000000 based > upon the evidence we have to date. > Depends on the rom. The SS-5 rom always sets it correctly, whereas the SS-20 rom only sets it when you do "boot net". Also, this is just the top 8 bits of the address. The DMA2 documentation[1] for E_BASE_ADDR states that these upper address bits default to 0xff, even though it seems to incorrectly define it as bits 7:0 in the register instead of 31:24. If you follow Artyom's blog, at [2] it was assumed that the bogus dbri device was the culprit (which is also why I went down the path of implementing the dbri device), when in reality, the selftest failure was preventing "boot net" from running and fixing the ledma register settings. Bob [1] http://www.ibiblio.org/pub/historic-linux/early-ports/Sparc/NCR/DMA2.txt [2] http://tyom.blogspot.com/2010/05/sx-framebuffer-emulation.html