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

[Peter Crosthwaite]

Hi Francois,

On Wed, Apr 17, 2013 at 12:06 AM, François Legal
<address@hidden> wrote:
> 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.
>

It is very difficult to work on this project without git.

But git remotes also work over http, so that could be usable to do
clones and pulls. If QEMU still has an up-to-date github mirror, you
should be able to clone from there.

So once you have your http clone you can use git locally to create and
format your patches. You are most of the way there, you just need a
way to send email. Just need a smtp server and config git send-email
to talk to it.

Ultimately, none of this requires the git network protocol - so git
can be done even with a proxy/firewall that blocks git.

Regards,
Peter


>>
>> Regards,
>> Peter
>
>
>
>
> Links:
> ------
> [1] http://www.gnu.org/licenses/
>