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

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

[Bob Breuer]

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 = {

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

[Mark Cave-Ayland]

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 - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

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

[Bob Breuer]

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

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

[Mark Cave-Ayland]

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 - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs

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

[Bob Breuer]

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

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

[Blue Swirl]

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.

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

[Artyom Tarasenko]

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
>
>



-- 
Regards,
Artyom Tarasenko

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