qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH V2] ARM Cortex A9 Global Timer


From: François Legal
Subject: Re: [Qemu-devel] [PATCH V2] ARM Cortex A9 Global Timer
Date: Tue, 16 Apr 2013 16:06:43 +0200
User-agent: Roundcube Webmail/0.8.5

Hi Peter,

Le 16-04-2013 15:23, Peter Crosthwaite a écrit :

Hi Francois,

On Tue, Apr 16, 2013 at 10:50 PM, François Legal
<address@hidden> wrote:

Le 16-04-2013 14:19, Peter Maydell a écrit :

On 16 April 2013 13:09, François Legal <address@hidden> wrote:
Ugh. Your mail client has completely mangled things (it's run all the
lines of code into each other and it's still posting as multipart
text+HTML). Please could you look at fixing its configuration -- it
makes it hard to reply in response to individual things you've said.
Sorry !

Anyway, you may be right about needing multiple qemutimers, I think I
misunderstood that part. We set up one timer for each comparator,
right? (ie it fires when the comparator would fire). In that case I
think that is correct.

I had this problem with timer/cadence_ttc.c, which is a single timer
with multiple comparators. Went the other way implementation wise
though, using a single QEMUTimer and each trap of the timer it
computes which event is going to occur next and qemu_mod_timer with
the MIN of the comparators.


That's another solution, but I found out that, given my poor knowledge on Qemu, the other way was easier ;-)

At least, that's how I understood the stuff.

You might like to try having each gTimerBlock have an
ARMMPGTimerState* field, so you get at the non-banked parts of the
control register with 'gtb->gtimer.gtimer_control' rather than via an
anonymous uint32_t*. I think that would be clearer.
Ok.

Regarding gdb access to memory mapped registers causing a crash due
to NULL cpu_single_env -- I think this is a general issue with the
gdb support code. I suggest you drop those parts of your patch for
now; we should look at fixing it in a coherent way separately and
later (eg by having gdb memory accesses always look as if they are
from CPU 0, or something).
Alright. I'll drop that from the p

quote>PS: I didn't mention it, but the struct names and so on should
also change in line with my suggested new device name/> te> Done.
ks -- PMM New patch follows.

Use git to create and send patches. Check out the commands:

git format-patch
git send-email

This will send you patch as plain text as well.

I wish I could, unfortunately, my corporate VPN/proxy blocks GIT.


Regards,
Peter



Links:
------
[1] http://www.gnu.org/licenses/



reply via email to

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