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

["François Legal" <francois.legal@thom.fr.eu.org>]

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
> <francois.legal@thom.fr.eu.org> wrote:
> 
>> Le 16-04-2013 14:19, Peter Maydell a écrit :
>> 
>>> On 16 April 2013 13:09, François Legal <devel@thom.fr.eu.org> 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/