• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 97 subscribers
  • Views 209 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.

Where to find details of Known Issues in MCSDK releases?

Geraldine Maclear
Expert 2145 points

Hello,

I'm looking through the Release Notes for BIOS MCSDK 2.1.2.  It contains a list of Known Issues. One of them is of interest and I'd like to get more details but I don't know where to look. It is SDOCM00096155 "DSP local reset via PCIE sometimes doesn't work".

Please let me know where to find details on this issue which may be affecting our reset over PCIe.

Thanks,
Geraldine

  • 0
    TI__Guru* 95265 points

    SDOCM is a TI issue track database, it is most likedly internal only. The 96155 is based on the following e2e forum issue:

    https://e2e.ti.com/support/dsp/c6000_multi-core_dsps/int-c66x_multi-core_dsps/f/513/p/215666/762739.aspx?Redirected=true

    The issue is reported by a China local FAE. The customer uses PG 1.0 6678 DSP on their own designed board. ROM bootloader with PCIE boot mode is used directly (there is NO IBL via I2C 0x51) in this case. The RC side is TI DM8168 Linux ARM, there is no issue for the EP (6678 DSP) enumeration. 

    They download their own code via PCIE to local L2, used for DSP local reset. Sometimes they got error when de-assert local reset.
    "Unhandled fault: Precise External Abort on non-linefetch (0x1028) at 0xd4000a4c".

    This issue is not reproduced in house due to the RC side we used for test is a Linux PC.

    In the pciedemo.c code for local reset, there are several chances we need to re-program the IB BARs to point to PSC or others bases (e.g., EDMA controler) from DDR3. It is assumed the operation (write a PCIE register on DSP from RC side) can be finished immediately. However, it seems not true in some slow RC (e.g, DM 8168).

    It is good to safegaurd the code by polling it to make sure the re-programing finished.

    Regards, Eric