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.

OMAP5912 migration

Other Parts Discussed in Thread: OMAP5912

Normal 0 false false false EN-AU X-NONE X-NONE MicrosoftInternetExplorer4

I am supporting a product that was developed using the OMAP5912 OSK as a reference design, and using the 2.4 series Linux kernel provided in the Montavista starter kit.

The code compilation is done on a Linux host machine, not using CCS.

We are now looking at moving over to a 2.6 series Linux kernel while doing a product update, and I was wondering what is the recommended latest combination of DSP/BIOS, DSP/BIOS Link, XDIAS, CSL, RF6, tool versions, etc that is known to work together for this platform.

From what I can see, the TI website has moved on from the OMAP5912, and seems to only have information regarding the DaVinci products (I realise the 5912 is not recommended for new designs and is quite old now)

 

Any help would be greatly appreciated.

  • James,

    As you say, the OMAP5912 is an older part and the OSK is tagged as "obsolete".  You mention RF6 in your list of components, but that framework is also obsolete and nobody is maintaining that any longer.  Theoretically, you *may* be able to upgrade the components yourself, but I think this will present a number of difficulties and the support you get from TI will be limited.

    I did check the DSP/BIOS 5.x release notes and saw that OMAP5912 is still listed as a supported device in the latest 5.x release.  However, OMAP5912 is not listed in the newer SYS/BIOS 6.x releases, so I think you would need to stay with BIOS 5.x.

    I'll ask representatives from the Multimedia Frameworks and Link teams to comment on this as well.

    Best Regards,

    Dave

  • Not much to add here other than I'd recommend you stick with what's working for you as much as possible.  You may hit a bump with DSP Link - the version you're currently using might not work with a 2.6 kernel... dunno.  But if you can limit your updates to just DSP Link, I think that'll be best.

    If it ain't broke, don't fix it.  :)

    Chris

  • James

    DSPLink does not support OMAP5912 for the newer kernels. I would second Chris's recommendation.

    Deepali

  • Hi Dave,

    I am still really keen to migrate to a Linux 2.6 kernel to take advantage of the improved driver support on the Arm side, so I will persevere...

    I have worked out the mix of packages that is most likely to get me there:

    DSP/BIOS v5.20.05

    DSP/BIOS Link v1.30.08

    Linux Kernel 2.6.11

    Reference Framework v3.11

     

    Now, starting with DSP/BIOS, the version we were using is 5.03. 

    When trying to compile our app on the DSP side, I get link errors due to multiple  definitions of _MSGQ.  After reading the release note for BIOS v5.20.05, I found this paragraph:

    ---

    DSP/BIOS Kernel Package 5,1,0,22 (cuda-n22) Release Notes

    MSGQ/RF6 -- The MSGQ module was originally delivered as a stand-alone module to be used in the RF6 application.  Minor changes have been made to MSGQ for inclusion with DSP/BIOS.  You will have to remove the MSGQ libraries from your RF6 build environment and make minor changes to the source code and configuration.  Contact customer support and ask for help migrating RF6 to use DSP/BIOS 5.10 and new MSGQ.  An update to the DSP/BIOS Link product should be available shortly after DSP/BIOS 5.10 ships which should help with this migration.

    ---

    Does someone still have this "help migrating RF6 to use DSP/BIOS 5.10 and new MSGQ" information ?

    Cheers,

    James

     

  • Hi James,

    Attached is the  "MSGQ V1.01 Vs. MSGQ in DSP/BIOS 5.10" doc.

    2604.MSGQv1_01_vs_BIOSv5_10.pdf

    Todd

  • Hi Todd,

    Thanks for the info, that's what I was looking for.

    Next on the list:

    When building our application on the DSP side (RF6 based) using Linux tools (not CCS), it gets to the final link stage, and complains about:

    error: absolute symbol GBL_A_VERSION in /opt/ti_dsptools/bios_5_20_05/packages/ti/bios/lib/bios.a55L is defined multiple times

    Now I have tracked this down to a symbol definition clash between the BIOS library bios.a55L (GBL_A_VERSION 0x00005200) and the RTA Link library lnkbioslink.a55L (GBL_A_VERSION 0x00000500).

    The RTA Link library is part of the DSP/BIOS RTA SDK 5.00.00.09 Install. 

    Is there a later version of this, or has it been combined into another component?  Is it possible to rebuild the library, I can't find source for it.

    I can't find more information or any mention of it anywhere....

    Regards,

    James

  • James,

    RTA was integrated into BIOS. Take a look at the BIOS TextConf User Guide. It discusses how to enable RTA (e.g. bios.enableRealTimeAnalysis(prog);)

    Todd