Hi Stefan, i'm trying to verify your results, but I'm not able. I have used the mor1kx v2, running José's patch. The profiling test runs but at the end of it, an assertion error is occurring, so the gmon is not written.
OpenOCD side: Info : Profiling completed. 482 samples. target state: halted openocd: target.c:3566: write_gmon: Assertion `addressSpace >= 2' failed. Aborted So I have cloned Franck's openOCD using or1k-profile branch and edit or1k.c to insert the changes you made, but unfortunately, the "make" command is not running... cc -D_GNU_SOURCE -Wall -I. -g -O2 -c -o jim-subcmd.o jim-subcmd.c cc -D_GNU_SOURCE -Wall -I. -g -O2 -c -o jim-interactive.o jim-interactive.c jim-interactive.c: In function ‘Jim_InteractivePrompt’: jim-interactive.c:91:9: error: ‘JIM_VERSION’ undeclared (first use in this function) jim-interactive.c:91:9: note: each undeclared identifier is reported only once for each function it appears in make[2]: *** [jim-interactive.o] Error 1 make[2]: Leaving directory `/home/inigom/Desktop/openOCD/jimtcl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/inigom/Desktop/openOCD' make: *** [all] Error 2 Did you faced some of this errors?? Thanks in advance! Iñigo Muguruza 2014-06-22 16:31 GMT+01:00 Stefan Kristiansson < [email protected]>: > On Tue, Jun 17, 2014 at 11:59 PM, Stefan Kristiansson > <[email protected]> wrote: > > On Tue, Jun 17, 2014 at 6:00 PM, Iñigo Muguruza > > <[email protected]> wrote: > >> Dear OpenRISC community, > >> > >> I write this mail to inform about an issue I have found when I analyzed > the > >> outcome data coming from or1200 and mor1kx profiling. I am working in > making > >> a OpenRISC tutorial to help people install and execute the diverse > >> open-soruce SoC tools. In this tutorial a profiling test for > or1200/mor1kx > >> is made. Surprisingly, the results are really different, inducting to > think > >> about a fault/bug. (results in the attached txts) > >> > >> In the mor1kx, _reset and or1k_dmu_disable routines, takes really a big > >> percentage of the execution, while in or1200 is does not happen the > same. > >> > > > > It shouldn't ever end up in or1k_dmmu_disable, so obviously > > stalling/unstalling mor1kx at some particular spot triggers a bug. > > I can reproduce it even manually by hitting ctrl-c + c in gdb > > repeatedly many times. > > I'll take a closer look what's happening. > > > > I think I've got this sorted out now and have committed the related fixes > to: > https://github.com/openrisc/mor1kx > > I get an output like this now: > Each sample counts as 0.01 seconds. > % cumulative self self total > time seconds seconds calls Ts/call Ts/call name > 57.34 2068.55 2068.55 loop_b > 21.29 2836.67 768.12 __uart_putc > 16.75 3440.83 604.16 loop_a > 1.06 3479.23 38.40 __sfvwrite_r > 0.78 3507.39 28.16 memchr > 0.71 3532.99 25.60 _write > 0.43 3548.35 15.36 memmove > 0.43 3563.71 15.36 strlen > 0.28 3573.95 10.24 __sflush_r > 0.28 3584.19 10.24 __swrite > 0.14 3589.31 5.12 _fflush_r > 0.14 3594.43 5.12 _puts_r > 0.14 3599.55 5.12 puts > 0.07 3602.11 2.56 __reset > 0.07 3604.67 2.56 __sclose > 0.07 3607.23 2.56 __uart_init > > Please give it a go, and thanks a lot for bug reports like this, it's > much appreciated. > > On a related note, while applying the profiling patch mentioned in the > original mail, > I had some troubles with it. The "pc" register always read out as 0, > so I just bluntly changed it to "npc". > And while doing that, I noticed that you can apply your target > specific profiling routines, instead of the silly halt/resume default > one. > Since we can very well read the npc spr while the target is running, > this is a much better option. > Franck cooked together a tentative patch for it: > > https://github.com/fjullien/openOCD/commit/86ec95584aa239b0bb7fe8881a6582006487d31b > and I added this to make it work: > http://pastie.org/9304431 > > Stefan >
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
