• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 484 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.

Porting JPEG decoder for DM365/no-Os

Miguel Fides
Prodigy 70 points
Other Parts Discussed in Thread: TMS320DM365

Hello,

In the past weeks, I've had great success in porting our custom, no-Os application to Ti tms320dm365.

- we have working system controller, psc, interrupts and timers.

- the gcc toolchain compiles everything gracefully and is correctly deployed to DDR via jag.

Even though, we need to implement the codec engine to benefit from the davinci multimedia accelerators. I have successfully added the jpeg decoder package (obtained via the windows installer):

- added the (non-Linux) code from the test app

- linked the jpeddec and imx libraries

- added needed include files from the xdais and fc packages

- added custom vicpsync implementation over our interrupt system

Jpeddec decoder compiles and runs nicely until the activate call:

- alg_create, init allocations and control (getbufinfo, setparams) runs ok.

When the activate call is done, however, it hangs after using some initialized pointer (zero) and write on low address space. As there is no more external references, I presume that there is a missing piece to the codec engine which should provide buffer initialization.

I thought that there would be no need for anything more as there are no real dsps in the dm365, only hardware which should be directly accessible for the main arm9 task. But now I'm not sure if there is need for a bios/link or other mechanism for HW setup. As no unresolved references arise from eg codec, that mechanism must perform the buffer initilization according to the hardware before the actual codec is invoked or, at least, be ready for some request when the buffer need to be initialized before (or in the begginning) of the activate call.

Do you know what this mechanism consist of or the system modules needed?

I'm pretty sure that no HW is invoked from the Jpeg decoder now, as it bangs the the first word of memory before as a a result of the null pointer not initialized before (in alg_create() or the control calls).

Even though, I have:

- enabled all dma controllers and both coprocessors in the PSC

- disabled the data cache

- we are not using virtual addresses

Please, if you can explain the inner workings or refer to a Ti document to be able to run the codec engine on minimum Os resources.

Thank you very much!

NOTE: I have helped the reading correcting the line returns in the post text, as the plain text editor seem not to work for me. 

  • 0
    TI__Genius 17215 points

    Hi Miguel,

    Will look into this, seems to be tricky problem. As a first step - Have you tried seeing the standloone test app shipped with the package ? It should work in CCS environment and can act as reference to to check your application.

    2. Is the memTab[] buffer pointers at create time OK ? Can you check the pointers passes to the codec for the buffers it has requested ?

    regards

    Yashwant

  • 0 in reply to Yashwant Dutt
    Prodigy 70 points

    Hello Yashwant,

    In response to your recommended first step, I've tried to make a project in CCS with the test app shipped with the decoder package but the linker complains about differences in the architecture for the libraries. I've fc_2_26 and fc_tools for vicpsync / vicp module references. I'm new to CCS so I've not found the way to continue yet but I'd like to debug and see if the values returned are different than my gcc version. I'm attaching the CCS project, in case you want to have a look.

    Regarding the point 2:

    After_ALG_allocMemory1(), in ALG_create(), memTab[] (0 and 1) contain valid base addresses inside my provided (extern, to alg_malloc) ExternalGlboalMemPool.

    memTab[0].base = 0x80044f80 : (size = 0x2394, align = 0x80, IALG_EXTERNAL, IALG_PERSIST)

    memTab[1].base = 0x80047380 : (size = 0x200, align = 0x80, IALG_EXTERNAL, IALG_PERSIST)

    - both base addresses are in DDR2 (ExternalGlobalMem is at 0x80044f1c)

    Then algInit() call is done and a returns IALG_OK.

    Back in the main test app function, a couple of calls to control() are done. One for getting buffers info and then another to ser params. 

    My params include the size value (0x10, sizeof(IIMGDEC1_DynamicParams) I'm using the base class interface) and the maxWidth.

    Returned bufInfo (in status_base) is:

    -minNumInBufs = 1 (minInbufsize[0] = 0x384000)

    -minNumOutBuf = 1 (minOutBufSize[0] = 0x258000)

    which seems correct to me, and then inArgs_base, outArgs_base, inputBufDesc and outputBufDesc are initialized accordingly:

    - inArgs with my jpeg file length

    - inputBufDesc: numBufs = 1, desc[0] = (buf = <jpeg buffer>, bufSize = 0x384000, accessMask = 0)

    - outputBufDesc:  numBufs = 1, desc[0] = (buf = <decodedYcc buffer>, bufSize = 0x258000, accessMask = 0)

    Both calls return 0 (sucess), but It doesn't matter because the next call, algActivate() fails and we don't supply any buffers to it. Doing some debugging through the assembly code inside the failing point is quickly reached:

    - First a register is made to point at offset 0x38 from the alg handle and is used as a pointer and 2nd argument for a function called JPEGDEC_TI_HWSET_Copc_SwitchMemToDMA. Inside this function, another pointer is read from a further offset (0x1e08).

    - That pointer is still inside the memory block that was requested in memTab[0] and provided the alg handle, but has a null value (0) so It has probably not been initialized yet. 

    - Immediately, a sequence of writes follow to short offsets relative to the null pointer, crashing.

     

    Please, let me apologize for the complex and long issue description but I'm new to the CCS build system and TI libraries and I don't have a manner to compare with the original results. 

    Faithfully,

    Miguel

    EDIT: Corrected the ExternalGlobalMem address.

     

     

     

    test2.rar
  • 0 in reply to Yashwant Dutt
    Prodigy 70 points

    Hello Yashwant,

    It seems that the jpeg decoder package I have downloaded may not be the correct one for standalone/CCS build.

    dm365_jpegdec_01_00_00_10_production.exe

    So may be I need a different library or a different approach.

    May I need to port more codec engine features? Please tell me If you need more information, I'm willing to provide it and help you but I need You to give me some directions.

    Thank you very much,

    Miguel