Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address

[Bob Breuer <breuerr@mc.net>]

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