qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Artyom Tarasenko
Subject: Re: [Qemu-devel] sparc32_dma: correctly initialize ledma base address
Date: Fri, 26 Aug 2011 11:54:51 +0200

On Mon, Aug 15, 2011 at 5:38 PM, Bob Breuer <address@hidden> 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<address@hidden>
>>> ---
>>>
>>> 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
>
>



-- 
Regards,
Artyom Tarasenko

solaris/sparc under qemu blog: http://tyom.blogspot.com/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]