I had a lot of trouble with SysLink starting up properly. Sometimes my test app would start, but most times it would fail or the remote cores would fail to complete the startup sequence (attaching, opening heaps and connecting to message queues).
In the Linux-c6x release notes it says:
User memory Range
======================
NetCP MSMC 0x0C000000-0x0C003000
SysLink MSMC 0x0C008000-0x0C0F8000 (For SharedRegion 0)
Linux DDR 0x80000000-0x8FFFFFFF (Managed by Linux on core 0, assumes mem=256M on command line)
SysLink DDR 0X9FC00000-0x9FFFFFFF (For SharedRegion 1 and User specified SharedRegion)
While in the sample apps, the SysLink MSMC area is already defined differently at 0x0c080000 (notice that the 8 shifted left one position).
After a lot of debugging I began to suspect that the NetCP driver is using more memory than claimed in the release note, and more even than the sample app allow.
Before loading the syslink driver I read the MSMC memory where syslink starts with the command:
dd if=/dev/mem bs=1024 skip=197120 | hexdump -Cv -n 560 # could also use CCS attached to Linux core
By doing it repeatedly it is clear that something else is also writing to that memory.
I next put some printk's in the arch/c6x/platforms/include/mach/keystone_qmss.h file in the qm_mem_alloc() function. It gave me the following results when the Linux kernel boots:
qm_mem_alloc: size = 0x80000, addr = 0x2c000000
qm_mem_alloc: size = 0x400, addr = 0x2c080000
That second allocation is clearly at the start of the SysLink area.
I since moved my SysLink area to the end of the MSMC memory and all my boot problems disappeared. It now repeatedly starts up properly and all the remote cores are able to connect.