| Message ID | 4E43FF4E.7080501@mc.net |
|---|---|
| State | New |
| Headers | show |
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<breuerr@mc.net> > --- > > 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. ATB, Mark.
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<breuerr@mc.net> >> --- >> >> 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
On 15/08/11 16:38, Bob Breuer wrote: > 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. Nice one - looks like I missed this when reading the documentation. At least the choice of default address now makes sense. > 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. Okay - I think I see ;) In that case, I'd say this patch should be applied if Blue hasn't already done it (*sigh* I really miss the git web interface on qemu.org). ATB, Mark.
Mark Cave-Ayland wrote: > On 15/08/11 16:38, Bob Breuer wrote: > >> 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. > > Nice one - looks like I missed this when reading the documentation. At > least the choice of default address now makes sense. It might also make sense to modify the dma address calculations to use only the top 8 bits from ledma. Not sure if anything will care about that though. >> 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. > > Okay - I think I see ;) In that case, I'd say this patch should be > applied if Blue hasn't already done it (*sigh* I really miss the git web > interface on qemu.org). http://repo.or.cz/w/qemu.git might be the next best thing, not sure if there is a mirroring delay with it or not. Bob
On Sat, Aug 20, 2011 at 5:04 AM, Bob Breuer <breuerr@mc.net> wrote: > Mark Cave-Ayland wrote: >> On 15/08/11 16:38, Bob Breuer wrote: >> >>> 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. >> >> Nice one - looks like I missed this when reading the documentation. At >> least the choice of default address now makes sense. > > It might also make sense to modify the dma address calculations to use > only the top 8 bits from ledma. Not sure if anything will care about > that though. But both ibiblio doc for MACIO and Sun4M System Architecture manual specify low bits 7:0. >>> 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. >> >> Okay - I think I see ;) In that case, I'd say this patch should be >> applied if Blue hasn't already done it (*sigh* I really miss the git web >> interface on qemu.org). I haven't applied the patches because OpenBIOS still can't boot due to the SCSI commits and I'd like to get that resolved first. I think ESP driver in OpenBIOS is buggy this time. > http://repo.or.cz/w/qemu.git might be the next best thing, not sure if > there is a mirroring delay with it or not. Right, the web interface situation annoys me too.
On Mon, Aug 15, 2011 at 5:38 PM, Bob Breuer <breuerr@mc.net> wrote: > 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<breuerr@mc.net> >>> --- >>> >>> 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. Ops. Apologises for sending you in the wrong direction. To my defence - are you sure the dbri stub is completely unnecessary? I vaguely remember that the initialization routine had no surrounding guard code. Completely missing dbri seemed to abort the further initialization at least for the devices in the same slot. Artyom > 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 > >
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 = {
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 <breuerr@mc.net> ---