[Qemu-devel] sparc slavio_timer or ptimer bug (was sparc mmu)

[Qemu-devel] sparc slavio_timer or ptimer bug (was sparc mmu)

[Artyom Tarasenko]

2010/5/30 Blue Swirl <blauwirbel@gmail.com>:
> On Sat, May 29, 2010 at 9:33 PM, Artyom Tarasenko
> <atar4qemu@googlemail.com> wrote:
>> For me is also interesting what do we miss in the microSPARC implementation.
>> If I switch off POST (which crashes due to the known FPU problems)
>> LX/CX/X OBPs hang. Looks like it's expecting some interrupt (the SS-5
>> OBP escapes a similar endless loop on a timer irq), but not getting
>> it.
>> Do you know anything obvious qemu is missing in LX machine?
>
> I don't have a device tree for LX, but unimplemented interrupt sources
> could be audio, parallel port, video, modem. Floppy may be buggy.

Nice try. :) But it was really waiting for the timer irq.  The
following patch solves the problem, but I'm not sure if it's the
proper place for the fix.

--- a/hw/slavio_timer.c
+++ b/hw/slavio_timer.c
@@ -232,6 +231,12 @@ static void slavio_timer_mem_writel(void *opaque,
target_phys_addr_t addr,
                 } else {
                     ptimer_set_limit(t->timer, LIMIT_TO_PERIODS(t->limit), 1);
                 }
+                if (t->running) {
+                    ptimer_stop(t->timer);
+                    ptimer_run(t->timer, 0);
+
+                }
+
             }
         }
         break;

The interrupt is not generated if the timer has been running at the
time ptimer_set_limit() is called. Not sure what is the
ptimer_set_limit()'s contract. Should it handle changing the limit on
a working timer?

The patch makes LX OBP v2.10 sort of functional (it fails on DBRI and
cg6 init, but gets up to the "ok" prompt), and SS-10 OBP v2.10 fully
functional (with some cpu models).

The later is interesting: it autodetects SX/cg14, so can work with the
Bob's cg14 patch, as well as without it.

-- 
Regards,
Artyom Tarasenko

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

[Qemu-devel] Re: sparc slavio_timer or ptimer bug (was sparc mmu)

[Blue Swirl]

On Sat, Jul 3, 2010 at 1:34 PM, Artyom Tarasenko
<atar4qemu@googlemail.com> wrote:
> 2010/5/30 Blue Swirl <blauwirbel@gmail.com>:
>> On Sat, May 29, 2010 at 9:33 PM, Artyom Tarasenko
>> <atar4qemu@googlemail.com> wrote:
>>> For me is also interesting what do we miss in the microSPARC implementation.
>>> If I switch off POST (which crashes due to the known FPU problems)
>>> LX/CX/X OBPs hang. Looks like it's expecting some interrupt (the SS-5
>>> OBP escapes a similar endless loop on a timer irq), but not getting
>>> it.
>>> Do you know anything obvious qemu is missing in LX machine?
>>
>> I don't have a device tree for LX, but unimplemented interrupt sources
>> could be audio, parallel port, video, modem. Floppy may be buggy.
>
> Nice try. :) But it was really waiting for the timer irq.  The
> following patch solves the problem, but I'm not sure if it's the
> proper place for the fix.
>
> --- a/hw/slavio_timer.c
> +++ b/hw/slavio_timer.c
> @@ -232,6 +231,12 @@ static void slavio_timer_mem_writel(void *opaque,
> target_phys_addr_t addr,
>                 } else {
>                     ptimer_set_limit(t->timer, LIMIT_TO_PERIODS(t->limit), 1);
>                 }
> +                if (t->running) {
> +                    ptimer_stop(t->timer);
> +                    ptimer_run(t->timer, 0);
> +
> +                }
> +
>             }
>         }
>         break;
>
> The interrupt is not generated if the timer has been running at the
> time ptimer_set_limit() is called. Not sure what is the
> ptimer_set_limit()'s contract. Should it handle changing the limit on
> a working timer?

I think it does. In fact, the only difference that
ptimer_stop()/ptimer_run() sequence adds to the previous
ptimer_set_limit() is that s->delta is calculated with
ptimer_get_count() instead of the limit being set. I wonder if the
96/64 bit division in ptimer_get_count() is correct or if
ptimer_set_limit() should do something differently.

>
> The patch makes LX OBP v2.10 sort of functional (it fails on DBRI and
> cg6 init, but gets up to the "ok" prompt), and SS-10 OBP v2.10 fully
> functional (with some cpu models).
>
> The later is interesting: it autodetects SX/cg14, so can work with the
> Bob's cg14 patch, as well as without it.

Great!