[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: sparc slavio_timer or ptimer bug (was sparc mmu)
From: |
Blue Swirl |
Subject: |
[Qemu-devel] Re: sparc slavio_timer or ptimer bug (was sparc mmu) |
Date: |
Mon, 5 Jul 2010 17:36:52 +0000 |
On Sat, Jul 3, 2010 at 1:34 PM, Artyom Tarasenko
<address@hidden> wrote:
> 2010/5/30 Blue Swirl <address@hidden>:
>> On Sat, May 29, 2010 at 9:33 PM, Artyom Tarasenko
>> <address@hidden> 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!