• Locked Locked
  • Replies 8 replies
  • Subscribers 120 subscribers
  • Views 4357 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DS-5 Gator Module Customization

David Bercovitz
Note: This was originally posted on 30th November 2011 at http://forums.arm.com

Hello,
I have the default DS-5 and Streamline setup working fine using a Pandaboard. I have the gator.ko 5.7 source code and I'm trying to add some new traces to gator.ko. Using the mmaped exemple, I'm returning always the same 'int' value=300 from my function which I trace through a "printk" too. The printk shows the value is good and always equal to 300. However, going to the DS-5 Eclipse IDE, the Streamline interface shows some strange values in the range of 145 to 427 when zooming to the 1ms on the graphical Timeline view. It looks like the values displayed are not constant but around my original 300 value. Can anyone explain how this should be working to display a constant value in the IDE?
Thanks a lot,
David.
  • Note: This was originally posted on 30th November 2011 at http://forums.arm.com

    In mmaped_simulate(), adding something like,


    case 2:
    result = 300;
    break;

    produces a constant 300 value every millisecond for the simulated counter #2.
    Can you share your source code, including the updated events .xml file to enable the counters? Were you able to produce the simulated PWM, Triangle, and Sine wave examples? The examples would be the best way to understand how the driver event relates to the IDE timeline.
  • Arm Employee Badge
    Note: This was originally posted on 1st December 2011 at http://forums.arm.com

    As Wade mentioned, you can use the "gator_events_mmaped.c" as an example - it contains "pseudocounters" generating different shapes on the timeline, as shown here: http://infocenter.ar...e/CIHBADHB.html

    I have also just added a "const 300" value to that driver and it works fine - see attached screenshot. To replicate what I did:

    1. Apply attached "gator-constant-value.patch" (it adds the "const 300" value generator) to your gator sources, build it and transfer to your target as usual.
    2. Copy the attached "events.xml" to your target, to the same directory as your gatord (that's really important).
    3. Launch the gatord (you may have to load the gator module first).
    4. When you click "Counter configuration" in Streamline, you should see 4 "Simulated" available counters (and only those, as the example events.xml I attached doesn't contain others).
    5. If you add the "Simulated: Constant" to the "Events to Collect" list and launch the capture you should get result similar to the attached screenshot.

    Now, getting back to your problem... The fact that you are getting random values suggest that you fill the buffer in a wrong way and, in effect, Streamline is getting random data. If you post your code here, we can try to find the problem together.
  • Note: This was originally posted on 15th February 2012 at http://forums.arm.com

    Sorry for the late answer. I did test your suggestions and I faced the same issue as I previously saw with my changeset. I  think something is wrong with TI kernel or maybe with our kernel timers.

    Here is a snapshot of what I see with my setup (in the debug log, I always see "cpufreq=350"):


    And the source code I use: https://gitorious.or...-omap/arm-gator
    I  just added an event file in the daemon tree and a  gator_events_cpufreq.c file for my changes. It basically mimics what's  in mmaped.c file.

    Let me know if you have any suggestion.
  • Arm Employee Badge
    Note: This was originally posted on 20th February 2012 at http://forums.arm.com

    Hello again!

    I've just tried your code () with this small change (I have no cpufreq "enabled" board on my desk right now):


    diff --git a/driver/gator_events_cpufreq.c b/driver/gator_events_cpufreq.c
    index edf9797..83e5bba 100644
    --- a/driver/gator_events_cpufreq.c
    +++ b/driver/gator_events_cpufreq.c
    @@ -68,7 +68,8 @@ static void gator_events_cpufreq_stop(void)

    static int cpufreq_simulate(void)
    {
    -    int freq = (int)(cpufreq_quick_get(smp_processor_id())/1000);
    +    //int freq = (int)(cpufreq_quick_get(smp_processor_id())/1000);
    +    int freq = 350;
         //printk("cpufreq=%d MHz\n", freq);
         return freq;
    }


    and this is what I got in Streamline (5.8):



    So it looks fine for me - could you try the same (replacing the call to cpufreq with a constant?). If I was to guess I'd say that the data you get from cpufreq is not as constant as you may think ;-)

    Good luck and let me know how's it going.

    Paweł
  • Note: This was originally posted on 20th February 2012 at http://forums.arm.com

    Hi Pawell,

    Unfortunately I have the same issue although I always return a constant.
    I think the problem is somewhere else. Are you testing on Pandaboard / OMAP4 platform?

    Thanks
    David
  • Arm Employee Badge
    Note: This was originally posted on 20th February 2012 at http://forums.arm.com


    Unfortunately I have the same issue although I always return a constant.

    Just to make sure that I understood correctly:

    1. You did replace int freq = (int)(cpufreq_quick_get(smp_processor_id())/1000); with int freq = 350;
    2. The chart you see in Streamline is still not flat.

    3. You are using Streamline 5.8 and corresponding gator daemon and driver (I assume you've cloned the git at linaro.org?).

    Am I correct?

    If so, can you capture some short example (10 seconds max.) with minimal set of counters configured (let's say cycles counter and your cpufreq data), compress the directory with captured data and send them to me? (pawel.moll at arm.com) I'll have a look inside.


    I think the problem is somewhere else.

    No argument here :-)


    Are you testing on Pandaboard / OMAP4 platform?

    No, I have a Versatile Express here, but it really (really :-) shouldn't matter. The theory is simple - what you put (the "350" constant values) into the pipe at one end (the target) should come out at the other end, unchanged (still a lot of "350"s) and then visualized by Streamline as such.
  • Note: This was originally posted on 21st February 2012 at http://forums.arm.com


    Just to make sure that I understood correctly:

    1. You did replace int freq = (int)(cpufreq_quick_get(smp_processor_id())/1000); with int freq = 350;
     
    YES. I made the exact same change to my code locally. I rebuilt the kernel module, copied it over to my board where my gatord daemon resides and then started the daemon again.


    2. The chart you see in Streamline is still not flat.
     
    The chart looks similar to what I already posted. This forum doesn't allow me to upload anymore files. Looks like a quota issue. Sorry I cannot post my new snapshot here but I will send it to you along with the data.


    3. You are using Streamline 5.8 and corresponding gator daemon and driver (I assume you've cloned the git at linaro.org?).
     
    Yes, I simply cloned the tree from git://git.linaro.org/arm/ds5/gator.git and checked out the DS5.8 tag. Then, I made my minor changes and comitted them to my gitorious tree for reference.


    Am I correct?

    If so, can you capture some short example (10 seconds max.) with minimal set of counters configured (let's say cycles counter and your cpufreq data), compress the directory with captured data and send them to me? (pawel.moll at arm.com) I'll have a look inside.

    I just sent you the captured data.


    No argument here :-)
     
    I meant I don't think the problem resides in the return value as I mentioned earlier the printk show the returned value is correct.


    No, I have a Versatile Express here, but it really (really :-) shouldn't matter. The theory is simple - what you put (the "350" constant values) into the pipe at one end (the target) should come out at the other end, unchanged (still a lot of "350"s) and then visualized by Streamline as such.
  • Note: This was originally posted on 29th June 2012 at http://forums.arm.com

    The issue is dependent on the version of Gator/Streamline used.
    Gator has migrated from a tick-based system to a time-based system, which will cause the const value X to show in the timeline as something other than X unless the read function is called *exactly* in 1ms increments.
    Also, the .read functions are now called at various times, not just based on a 1ms tick. For example, they are now called whenever a context switch happens. In order to produce a flat timeline in Streamline, the value returned by the read function must be a function of time.
    The latest version, DS-5 v5.10, has updated examples, see gator_events_mmaped.c on http://git.linaro.org/gitweb?p=arm/ds5/gator.git;a=summary
    Sorry for the late response but hope this makes sense.