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
