• State TI Thinks Resolved
  • Locked Locked
  • Replies 4 replies
  • Answers 2 answers
  • Subscribers 98 subscribers
  • Views 1344 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM5728: DSP usage/loading

Lawrence Wong
Genius 16260 points

Part Number: AM5728
Other Parts Discussed in Thread: TMDSEVM572X

Tool/software: Linux

Customer trying to measure DSP usage for thier program, which uses OpenCV with SDK 03.01.00.06. They run dsptop in console and thier program in telnet session. If their program uses one of these functions - cvGaussian() and cvErode() - they get the following error and system hangs:

 

[ 836.364891] omap_l3_noc 44000000.ocp: L3 application error: target 3 mod:2 (unclearable)

[ 836.373082] omap_l3_noc 44000000.ocp: L3 debug error: target 3 mod:2 (unclearable)

 

If they put ocl::setUseOpenCL(false); before these calls, forcing OpenCV to not use OpenCL during these calls - program works fine and dsptop shows DSP usage. Is there any way to get dsptop to work with the above functions?

 

  • 0
    TI__Guru**** 161600 points
    Hi Lawrence,

    Can you share what exactly are they doing? I.e. they're running:
    # ./<their_program> &
    # dsptop

    I guess, they're using a custom board & modified linux kernel, right? Is it possible to send their binary, so that I can test it on my board?

    They can try dumping the bellow listed registers:
    • L3_FLAGMUX_CLK1MERGE_MASK0 is used to mask (enable) application error sources
    • L3_FLAGMUX_CLK1MERGE_REGERR0 is used to check which application error sources are active
    • L3_FLAGMUX_CLK1MERGE_MASK1 is used to mask debug error sources
    • L3_FLAGMUX_CLK1MERGE_REGERR1 is used to check which debug error sources are active

    To see if they'll get any useful info out of the kernel.. They can also check section 14.2.3.5 Flag Muxing & 14.2.3.8.3 Flag Mux Error Logging of the device TRM.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 90 points

    Hi!

    Yordan Kovachev said:
    Can you share what exactly are they doing? I.e. they're running:
    # ./<their_program> &
    # dsptop

    No, I'm running dsptop in one session (main console over USB-UART) with this command:

    dsptop -s0 -d1

    At the same time, I open another session via telnet and start our program there.

    Yordan Kovachev said:
    I guess, they're using a custom board & modified linux kernel, right?

    No, at the time I'm testing our program on TMDSEVM572X evaluation board and unmodified linux kernel from Linux Processor SDK 03.01.00.06.

    Yordan Kovachev said:

    They can try dumping the bellow listed registers:
    • L3_FLAGMUX_CLK1MERGE_MASK0 is used to mask (enable) application error sources
    • L3_FLAGMUX_CLK1MERGE_REGERR0 is used to check which application error sources are active
    • L3_FLAGMUX_CLK1MERGE_MASK1 is used to mask debug error sources
    • L3_FLAGMUX_CLK1MERGE_REGERR1 is used to check which debug error sources are active

    Do you mean I should try to dump these registers before or after program crash? Because if you want me to do it after program crash - I can not, because system hangs and needs power reset. Or may be there is a way to make system print out these registers in the moment of crash?

    Thanks in advance, Alex.

  • 0 in reply to Alexey Mamonov
    TI__Guru**** 161600 points
    Hi Alex,

    Do you mean I should try to dump these registers before or after program crash?

    These should be read after the crash or the moment it happens... This could be done by modifying the l3_noc driver, located in drivers/bus/l3_noc.c l3_interrupt_handler(). But I noticed that this is already implemented in the kernel driver:
    application error: target 3
    debug error: target 3
    However, this doesn't seem to make much sense, because flag mux input 3 corresponds to EVE2, according to Table 14-24. Interconnect Flag Mapping, see:
    flag_mux = l3->l3_flagmux[i];
    err_reg = readl_relaxed(base + flag_mux->offset +
    L3_FLAGMUX_REGERR0 + (inttype << 3));

    err_reg &= ~(inttype ? flag_mux->mask_app_bits :
    flag_mux->mask_dbg_bits);
    ......
    if (err_reg) {
    /* Identify the source from control status register */
    err_src = __ffs(err_reg);

    ret = l3_handle_target(l3, base, flag_mux, err_src);

    if (ret) {
    dev_err(l3->dev,
    "L3 %s error: target %d mod:%d %s\n",
    inttype ? "debug" : "application",
    err_src, i, "(unclearable)");
    Can you test running your program on the background using & and then start dsptop -s0 -d1? I feel that running two debug sessions (tellnet & console) could have something to do with your issue.

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 90 points
    Hi Yordan,

    I tried to run program with & and start dsptop -s0 -d1 after that. The dsptop screen was displayed for some time, then the system hung:

    dsptop - Elapsed Time 00:00:29
    Total Mode
    Average DSP Usage: 4.22% Accuracy 99.99%
    External Mem Code/Data 163840 KB Total, 8.4% Used

    >
    DSP %USAGE RUN TIME+ IDLE TIME+
    DSP_0 4.17 00:00:00.623 00:00:14.327
    DSP_1 4.27 00:00:00.638 00:00:14.316

    No system error messages this time.