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.

DSP load bug

Other Parts Discussed in Thread: OMAP3530

Hi,

While running the decode demo that came with the dvsdk package, the dsp load is always ~100% - in the release notes it is mentioned as a bug which can be fixed by "building the codec server without enabling PWRM". I was wondering if there is a quick guide on how to do this? what's the consequence with 'not enabling PWRM' then?

 

Thanks!

  • I believe there is a TCF file that has a line similar to

    bios.PWRM.ENABLE = true;

    this will enable or disable PWRM

  • As I understand from SPRU423f the PWRM module is only for C55x processors so it should not be doing anything with the OMAP3 which has no such core in it, thus I expect this is just a bug of having the support enabled without having the hardware there to utilize it. If it was usable on the OMAP3 it would just be doing power management procedures like handling clock domains, voltage/frequency scaling, sleep modes, etc. Essentially I dont think there are any consequences to not enabling the PWRM module in BIOS for the OMAP3.

  • I read an internal communication that this (TCF setting above) applies to OMAP3 as well, although I am not sure what happens from a hardware perspective when this value is changed.

  • I believe that the setting is in there, I will try to clarify what it really does that could cause the CPU load to break internally since currently the docs make it sound like it would not apply to the OMAP3, though they may just be out of date.

  • So there is actually PWRM support for the OMAP3, and there is an application note that discusses it within dvsdk_3_00_00_13\bios_5_32_02\packages\ti\bios\doc\spraa98b.pdf, note that although this mentions OMAP34x it still applies to the OMAP35x as they share the same basic power management capabilities. It also seems that this CPU load issue was just caused by a bug in the PWRM module itself which should be fixed in a newer BIOS release, namely 5.32.04, which should be integrated in a future DVSDK release.

  • Thanks for digging it up.

    So if I disable PWRM, it won't do bad, right? Any quick ways to make the demo show correct DSP load? Thx.

  • You are correct, it should not hurt performance or damage the board, though you will not have any of the power saving features. At the moment you would just have to rebuild the demo with the TCF option Juan mentioned, eventually when the newer DVSDK is released you should be able to just update to that.

  • I am not sure if I looked into the right file to modify: dvsdk_3_00_00_13/omap3530_dvsdk_combos_3_11/packages/ti/sdo/servers/omap3530_decode/decode.tcf, I changed to bios.PWRM.ENABLE = false;

    Then I tried to rebuild the demo and it seemed to me that the codec server could not be re-built since the server is given as "pre-built", no sources are there.

    Is there a way to get some free evaluation codecs to try out rebuilding the decode server? If not, when will be the next release of dvsdk?

     

    Thanks a lot!

  • You make a good point, since the DVSDK is in beta I am not sure that the codec servers are available for evaluation yet. Typically you can request codecs through www.ti.com/digitalmediasoftware though no OMAP codecs are listed it may be worth sending a request for the evaluation codec package so you could try to rebuild the server.

    As to the next release of the DVSDK I would expect it soon, though I could not say exactly when, I believe there are internal versions that have this particular issue fixed, though I am not sure when they will be ready to push to the updates site.