how to use ProcMgr_read and ProcMgr_map

Elron A Yellin

Other Parts Discussed in Thread: OMAPL138

I'm sending slave addresses to the ARM-Linux master using a MessageQ and need to read the data at that address. These addresses are not in a SharedRegion. ProcMgr_read() appears to require the the address be mapped, but it's not clear how ProcMgr_map works. Can someone provide some documentation or sample code to do this?

ProcMgr_map(proc, ProcMgr_AddrType_MasterPhys, &addrInfo, ProcMgr_AddrType_SlavePhys) returns ProcMgr_S_SUCCESS, but addrInfo.addr[ProcMgr_AddrType_MasterPhys] is 0xFFFFFFFF.

Thanks

over 13 years ago

0 GAnthony over 13 years ago

TI__Intellectual 2790 points

Elron:

Documentation on ProcMgr_map() is in the SysLink product doc

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_proc_mgr_8h.html#a01b69c0667c4375a59ac422002186e83

You can also take a look at the SharedRegion example in the SysLink product installation directory: packages/ti/syslink/samples/hlos/sharedRegion/usr/Linux/SharedRegionAppOS.c .

Regards,

- Gil

0 Elron A Yellin over 13 years ago in reply to GAnthony

Expert 1040 points

GAnthony said:

Documentation on ProcMgr_map() is in the SysLink product doc

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_proc_mgr_8h.html#a01b69c0667c4375a59ac422002186e83

Yes, I saw the header doc, of course, but it says almost nothing about how (or why) to use this function.

You can also take a look at the SharedRegion example in the SysLink product installation directory: packages/ti/syslink/samples/hlos/sharedRegion/usr/Linux/SharedRegionAppOS.c .

(Note: these samples have been removed from the latest syslink)

1            SharedRegionApp_addrInfo.addr [ProcMgr_AddrType_MasterPhys] = SharedRegionApp_sharedMem;
2            SharedRegionApp_addrInfo.addr [ProcMgr_AddrType_SlaveVirt] = SharedRegionApp_sharedMem;
3            SharedRegionApp_addrInfo.size     = SHAREDMEMSIZE;
4            SharedRegionApp_addrInfo.isCached = FALSE;
5            status = ProcMgr_map(SharedRegionApp_procMgrHandle,
6                    (ProcMgr_SLAVEVIRT | ProcMgr_MASTERUSRVIRT
                            | ProcMgr_MASTERKNLVIRT),
7                    &SharedRegionApp_addrInfo,
8                    ProcMgr_AddrType_MasterPhys);

Please explain line by line.

Anyway, I did this, and variations on it, but in one case ProcMgr_map succeeded yet ProcMgr_read still failed with

*** ProcMgr_read: Address is not mapped!
Error [0xfffffff3] at Line no: 1705 in file syslink_2_20_00_14/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/procMgr/common/ProcMgr.c
*** ProcMgrDrv_ioctl: Kernel-side ProcMgr_read failed
Error [0xfffffff3] at Line no: 1338 in file syslink_2_20_00_14/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/procMgr/hlos/knl/Linux/ProcMgrDrv.c

and in the other cases ProcMgr_map failed with an undocumented return code.

Thanks

0 GAnthony over 13 years ago in reply to Elron A Yellin

TI__Intellectual 2790 points

Elron:

The trace error at ProcMgr.c: Link 1705 is from a failure of the following call done in ProcMgr_read():

       /* Check if the address is already mapped */
        status = ProcMgr_translateAddr (handle,
                                        (Ptr *) &addr,
                                        ProcMgr_AddrType_MasterKnlVirt,
                                        (Ptr) procAddr,
                                        ProcMgr_AddrType_SlaveVirt);

This indicates that a mapping from ProcMgr_AddrType_SlaveVirt to ProcMgr_AddrType_MasterKnlVirt does not yet exist.

The ProcMgr_map() call specifies the mapping from a source address type (4rth argument), to one or more destination address types (2nd argument bit mask). The addrInfo struct must have a valid address set corresponding to the source address type (specified in the 4rth argument).

If you're reading from Linux user space, I suspect you need to specify ProcMgr_AddrType_MasterUsrVirt in the 2nd argument (and probably OR in ProcMgr_AddrType_MasterKnlVirt as well, since the real call is going to happen in the syslink kernel driver).

You might try this:

addrInfo.addr [ProcMgr_AddrType_SlaveVirt] = YOUR_SLAVE_VIRTUAL_ADDRESS;
addrInfo.size = YOUR_SLAVE_MEM_SIZE;

ProcMgr_map(procHandle,

ProcMgr_AddrType_MasterKnlVirt | ProcMgr_AddrType_MasterUsrVirt,

&addrInfo,

ProcMgr_AddrType_SlaveVirt);

ProcMgr_read(procHandle, YOUR_SLAVE_VIRTUAL_ADDRESS, &numBytes, buffer);

If you let me know the results, with trace enabled, I can debug further.

Regards,

- Gil

0 Elron A Yellin over 13 years ago in reply to GAnthony

Expert 1040 points

GAnthony said:

   You might try this:

        addrInfo.addr [ProcMgr_AddrType_SlaveVirt] = YOUR_SLAVE_VIRTUAL_ADDRESS;
        addrInfo.size     = YOUR_SLAVE_MEM_SIZE;

    ProcMgr_map(procHandle,

                                   ProcMgr_AddrType_MasterKnlVirt | ProcMgr_AddrType_MasterUsrVirt,

                                   &addrInfo,

                                    ProcMgr_AddrType_SlaveVirt);

        ProcMgr_read(procHandle, YOUR_SLAVE_VIRTUAL_ADDRESS, &numBytes, buffer);

First off, I assume you meant ProcMgr_MASTERKNLVIRT | ProcMgr_MASTERUSRVIRT for the mask argument. Also I assume I need to also initialize the other indices of addrInfo.addr so the ProcMgr knows how the addresses map in each space (in this case, one-to-one I assume).

According to _ProcMgr_map in syslink/procMgr/common/procMgr.c, if the mask includes ProcMgr_MASTERKNLVIRT, the only legal src address type is ProcMgr_AddrType_MasterPhys.

Removing ProcMgr_MASTERKNLVIRT, ProcMgr_map succeeds, but still ProcMgr_read fails with

I realize your message was off the cuff; can you try again please, or copy/paste some working code. You must have some unit test code for ProcMgr_map/read/write...

Thanks

0 Ramsey over 13 years ago in reply to Elron A Yellin

TI__Genius 12025 points

Elron,

Give this a try:

1. Translate SlaveVirt to MasterPhys by calling ProcMgr_translateAddr
2. Then map the master physical address into both MasterUserVirt and MasterKnlVirt with ProcMgr_map
3. Use the MasterUserVirt address returned above in the call to ProcMgr_read

You might not need the MasterKnlVirt mapping. Don't forget to unmap before your program exits. The mappings would persist and leak kernel resources.

~Ramsey

0 Elron A Yellin over 13 years ago in reply to Ramsey

Expert 1040 points

Ramsey said:

1. Translate SlaveVirt to MasterPhys by calling ProcMgr_translateAddr

That succeeds, and yields the same value for MasterPhys as SlaveVirt, as expected.

2. Then map the master physical address into both MasterUserVirt and MasterKnlVirt with ProcMgr_map

This returns 0x97d2000, which is MEMORYOS_S_SUCCESS, returned by MemoryOS_map(). ProcMgr_map should probably be converting MEMORYOS return codes into PROCMGR codes before returning them.

3. Use the MasterUserVirt address returned above in the call to ProcMgr_read

This seems counter to the ProcMgr_read header doc:

"Function to read from the slave processor's memory... procAddrAddress in space[sic] processor's address space of the memory region to read from. "

I've been assuming that "space" was supposed to be "slave"

In any case, it returned ProcMgr_E_TRANSLATE

0 Ramsey over 13 years ago in reply to Elron A Yellin

TI__Genius 12025 points

Elron,

I have mixed news for you. You have found a bug in our software. In our implementation of ProcMgr_read(), it attempts to verify that the requested address has been mapped on the host processor before accessing the address. This is a safety check to ensure we don't generate an MMU fault. Unfortunately, this check is performed incorrectly and will always fail even when the request address has been properly mapped. I will file a bug on this. It should be fixed in the next SysLink 2.20 release.

The good news is that you don't really need the ProcMgr_read() function anyway. What device are you on? I'm guessing that your device is using shared memory. This means that after you have called ProcMgr_map() to map the physical address into user virtual address space, you can directly use the virtual address returned from ProcMgr_map(). Just cast that address into a pointer of your data type.

The reason for having the ProcMgr_read() API is that not all devices have shared memory between the host and slave processors. For example, the slave memory might be accessible only over Rapid-IO or PCI bus. The implementation of ProcMgr_read() would comprehend this and perform the necessary steps to read the slave memory. However, on a device with shared memory, the implementation of ProcMgr_read() simply reads from the mapped address (as your code could do directly). Using the ProcMgr_read() API makes your code more portable, but for now I suggest you simply read the memory directly.

Elron A Yellin said:

This returns 0x97d2000, which is MEMORYOS_S_SUCCESS, returned by MemoryOS_map(). ProcMgr_map should probably be converting MEMORYOS return codes into PROCMGR codes before returning them.

Yes, you are correct and have found another bug. In ProcMgr_map(), we are not translating the return code correctly; it should be a ProcMgr_S_* code. I will file another bug on this.

Elron A Yellin said:
This seems counter to the ProcMgr_read header doc

Yes, you are correct again. I incorrectly told you to use the MasterVirt address in this call; it should indeed be the SlaveVirt address (which in your case is the same as SlavePhys). Yes, "space" does mean "slave" in this context. Sorry.

Thank your for your patience and helping us find these bugs. I hope the work around above will work. Please let us know.

Thanks
~Ramsey

0 Elron A Yellin over 13 years ago in reply to Ramsey

Expert 1040 points

If I don't use ProcMgr_read, I suppose I have to manually handle cache invalidation on the master, no?

Thanks for your help and thanks in advance for fixing the syslink bugs.

0 GAnthony over 13 years ago in reply to Elron A Yellin

TI__Intellectual 2790 points

Elron:

Tracing through ProcMgr_read() (for OMAPL138), it doesn't appear it manages the cache. So, either way, you would have to manage the cache yourself.

Cache APIs in SysLink are here: http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/syslink/latest/docs/html/_cache_8h.html Then, you need to be careful about placing buffers on cache line boundaries, etc.

Another option, if your application design allows, since you're not using SharedRegion, would be to use CMEM to allocate a buffer into, and access the shared memory. This is part of the LinuxUtils download:

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/linuxutils/index.html

CMEM APIs also support Cache management: See: http://processors.wiki.ti.com/index.php/CMEM_Overview

Regards,

- Gil

0 Ramsey over 13 years ago in reply to GAnthony

TI__Genius 12025 points

Elron,

As Gil pointed out, you need to manage the cache yourself. I would simply map the memory as non-cached to avoid any issue (or just for debugging if needed). Set the isCached property of the ProcMgr_AddrInfo struct to false before calling ProcMgr_map().

~Ramsey

Processors

Processors forum

how to use ProcMgr_read and ProcMgr_map