• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 613 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.

Problem with address translation using syslink in DM814

Brandon Yates
Prodigy 70 points

Hi,

I am attempting to use the Proc_Mgr module in syslink for reading and writing of shared memory areas. I am Opening a proc handle, attaching to it, and then trying to write our code text to L1D(0x10f0 0000) Ram. I'm running into two problems with this. One, I sometimes get the error that this address is not mapped. Do I have to do something to manually map the address spaces?  Two, ProcMgr_write and ProcMgr_read are returning large numbers (For example: 695308,-1090672432) that I am not expecting and don't see explained in the doxygen anywhere.

 

Thanks

  • 0
    TI__Mastermind 18260 points

    SysLink is supposed to support what you're trying to do.

    What version of SysLink are you using?

    What device are you using?

    You should not have to do anything manually to map DSP internal memories.  SysLink has a table of internal memories and sets up memory translations during ProcMgr_attach(), so after calling that function you should be able to do it.

    Can you provide the "not mapped" errors?

    As for the "large numbers" being returned by ProcMgr_write() and ProcMgr_read(), are you saying that ProcMgr_read() and ProcMgr_write() are returning those values as the function return value (vs. contents of buffer)?  Those numbers are not in the range returned by those functions.  The ProcMgr functions return either a small "success" integer or a small "failure" negative integer. Even after converting your "example" large return values to hex format they don't seem to make any sense, they appear to be some virtual addresses (-1090672432 = 0x41025730, 695308 = 0xa9c0c)

    Regards,

    - Rob

     

  • 0 in reply to Robert Tivy
    Prodigy 70 points

    Hi Rob,

     

    Thank you for the reply. I'm using syslink 2_00_02_80 with a dm814x.

     

    I think I may be able to characterize my problem a little bit better now. It seems the source of my problem is with attaching to the proc.

    procMgrReturn = ProcMgr_attach(procHandle, NULL);

    is returning ProcMgr_E_OSFAILURE and trace is showing "ProcMgrDrv_ioctl: copy_from_user call failed."

     

    Alternatively, if I try to use

    ProcMgr_getAttachParams(NULL, &attachParams);
    procMgrReturn = ProcMgr_attach(procHandle, &attachParams);

    attach is returning '1591' and all future API calls also return undefined values.

     

    I feel like there must be something I'm overlooking here. Any advice is much appreciated

     

    Thanks,

    Brandon

  • 0 in reply to Brandon Yates
    Prodigy 70 points

    Just to add, I have also tried attaching with the slaveloader sample app and in that case attach is returning "75886592". I'm not sure where these values are originating from. I would expect it to be 0 for success as defined in the API. However looking through the syslink code it seems any value greater than or equal to 0 is accepted.

  • 0 in reply to Brandon Yates
    Prodigy 70 points

    Anyone available to look into this?

  • 0 in reply to Brandon Yates
    TI__Genius 17205 points

    FWIW, 75886592 decimal is 0x0485F000.  Which, if you do the math in packages/ti/syslink/inc/knl/Loader.h, is LOADER_SUCCESS.

    Chris

  • 0 in reply to Brandon Yates
    TI__Mastermind 18260 points

    Brandon Yates said:

    procMgrReturn = ProcMgr_attach(procHandle, NULL);

    is returning ProcMgr_E_OSFAILURE and trace is showing "ProcMgrDrv_ioctl: copy_from_user call failed."

    Something seems fundamentally wrong with your system.  I have never seen a copy_from_user() call fail.  You're getting bizarre return codes from user-level APIs.

    Please describe your system more.  Is it Linux?  If so, what kernel are you running?

    Regards,

    - Rob

  • 0 in reply to Robert Tivy
    Prodigy 70 points

    Yes it is linux-2.6.37. I agree that something seems fundamentally wrong with my setup, I just haven't been able to put my finger on it yet.

  • 0 in reply to Chris Ring
    Prodigy 70 points

    Chris - is LOADER_SUCCESS supposed to indicate attach was successful? I've been expecting a 0 as was defined in the API doxygen, but looking at the code that doesn't seem to be the case.

  • 0 in reply to Brandon Yates
    TI__Mastermind 18260 points

    Yes, LOADER_SUCCESS indicates the API was successful.

    The 'loader' modules were not developed under the SysLink design standards, hence they use a different "return value" namespace, with ((module ID's << 12) | return_code) resulting in large return values.

    SysLink design standards have 0 for generic success, < 0 for failure (with a small negative number), and > 0 for "success w/ a caveat" (with a small positive number).

    However, both SysLink and the 'loader' modules share the common fact that return codes are < 0 for failure and >= 0 for success.  If you're interested in a particular "kind" of success you can check specifically for that too.

    In general, and we need to document this better, checking a return value should be:
        if (retval < 0)
            fail
        else
            success

    Regards,

    - Rob