SYSLINK configuration on Linux side with custom board using OMAPL138

Claudio,

You are on the right track, the config.bld file is what defines the Memory Map for the DSP.  Given the DSP memory map in the SysLink examples, we boot the board-up with the following uboot mem values (mem=32M@0xc0000000 mem=64M@0xC4000000).  This allows a memory hole (32MB) to be created on the Linux side to be reserved for the  DSP.

There is another DSP configuration file to consider based on the memory setup.  The file (Dsp.cfg) is located in the ex01_helloworld/dsp directory.  This file does the actually DSP configuration (using the config.bld) and sets the MAR bits to enable the correct range of memory to be cached.  Each MAR bit corresponds to a 16MB range.  Typical SR0 memory range has cache disabled.  Any additional DSP memory has it's memory range enabled.

You can take a look at the OMAP-L138 C6000 ARM+DSP Processor daatsheet (link below) to see the address range for the MAR-bit

http://www.ti.com/product/omap-l138

With all that said, our OMAP-L138 Evm board have 128MB of memory.  So I tried setting the same range as you specified above (in config.bld) and set my uboot mem to (mem=96M@0xc0000000).  The application ran as expected without touching the Dsp.cfg Mar bit setting (e.g cache is completely disable for range 0xc6000000 - 0xc8000000).  So there may be something else happening here.

You can trying setting your mem uboot args to the examples expected default value (mem=32M@0xc0000000 mem=64M@0xC4000000) to make sure your environment and build is setup correctly.

You can also try enabling SysLink kernel tracing to see if we can get insight on what may be happening (see http://processors.wiki.ti.com/index.php/SysLink_Install_Guide#SysLink_Kernel_Driver )

Arnie,

thank you for the answer. I didn't know that you could specify disjoint areas of memory for the Linux kernel on the bootargs (and in fact I was wondering how the standard configuration for the examples worked).

However I've tried to run my linux with mem=32M@0xc0000000 mem=64M@0xC4000000 and using the unmodified Dsp.cfg and config.bld in the example without any success.

What happens (with both mem=96M@0xc0000000 or mem=32M@0xc0000000 mem=64M@0xC4000000) is that the board locks up for good (power cycle required) so using TRACE=1 TRACEFAILURE=1 when loading the driver (which I do) is not useful as nothing is printed out and I cant look in /proc/kmsg as the board is dead (our linux does not start klogd)

Is there a specific reason why the examples are built to run with that memory configuration with that 'hole' in the middle of the Linux memory?

claudio potenza said:

Is there a specific reason why the examples are built to run with that memory configuration with that 'hole' in the middle of the Linux memory?

The reason for the hole is more legacy than anything else.  Early OMAP-L138 EVM boards came in both 64MB and 128MB options.  In order to support both, we carved up the memory so that the SysLink examples work on both versions of the board, without requiring the user to change anything beside how Linux is booted-up.

Is tracing enabled on the HLOS side?  By default, tracing should be enabled, unless explicitly turned off in the product.mak file (SYSLINK_TRACE_ENABLE=0) when SysLink was built.

You can also turn on different trace classes to get more info (E.g. TRACE=1 TRACECLASS=3 TRACEFAILURE=1) . See http://processors.wiki.ti.com/index.php/SysLink_UserGuide#Trace.2C_debug_and_build_configuration for more info.

Arnie,

I have indeed built SYSLINK with tracing enabled (SYSLINK_TRACE_ENABLE=1) and I call insmod with TRACE=1 TRACECLASS=3 TRACEFAILURE=1.

In fact when I load and run my DSP code (i.e: slaveloader startup DSP server_dsp.xe674) I can call dmesg and see the traces there.

But when I run the Linux side app (i.e. ./app_host DSP) the boards lock for good.

I have added some printfs to the Linux app and so I can see that it is calling Ipc_control(Ipc_CONTROLCMD_STARTCALLBACK), but after that the board is dead and requires a power cycle, so I cannot see any other trace from the kernel driver.

At the moment I am trying to recompile and run the same example using a previous version of SYSLINK (2.10.3.20) which I managed to run on the OMAP LCDK evaluation board.