Questions running "Hello World" SysLink example in the DM814x EZSDK 5.04

Mark Utter said:

I replaced he slaveloader call by firmware_loader to pass our 512 MB memory map to the firmware

./ firmware_loader 0 /home/root/dsp/server_dsp.xe674 start -mmap /home/root/dsp/mm_dm81xxbm_512M.bin -i2c 0

Mark,

Does the DSP memory map need to change when using the 512 MB memory map?

I don't know the EZDSK firmware_loader, but can see from the syslink.ko tracing that SysLink expects SR0 to be at 0x8e000000:

Mark Utter said:

handle->slaveSRCfg[0].entryBase 8e000000

  Does the DSP .cfg file configure SR0 at 0x8e000000?

Regards,

- Rob

Robert

Did you delete my post? Mark Utter's note was actually my original question addressed to the TI FAE (which he posted on this site for me) and which I completed with additional information from my second post after having registered into E2E

To answer the firmware loader question: firmware_loader  is not the right binary loader for the hello_world DSP example (the firmware_loader expects a handshake which the DSP hello_world software will not do); that is why we have to use slaveloader.

Now I suggest, if your have the time, to bring my original post back and ignore the first one. And please in the future do not delete posts. It is quite annoying.

The thread can be closed.

The output from the hello_world example should look something like this

root@dm814x-evm:~/dsp# ./app_host DSP
--> App_exec:
App_exec: event received from procId=0
<-- App_exec: 0

The solution for the 8148 with 512MB of DDR consists on

1. recompile slave_loader from the EZSDK (dont use the one in the rootfs)

2. modify the DSP clock frequency for the 8148 (patch below)

[jramirez@nautilus no_git ex01_helloworld]$ git diff dsp/Dsp.cfg
diff --git a/dsp/Dsp.cfg b/dsp/Dsp.cfg
index b49dee4..17d6b1a 100644
--- a/dsp/Dsp.cfg
+++ b/dsp/Dsp.cfg
@@ -177,3 +177,7 @@ loggerBufP.bufType = LoggerBuf.BufType_FIXED;
 var appLogger = LoggerBuf.create(loggerBufP);
 appLogger.instance.name = "AppLog_Core1";
 Defaults.common$.logger = appLogger;
+
+// Change timer frequency for Linux server
+var timer = xdc.useModule('ti.sysbios.timers.dmtimer.Timer');
+timer.intFreq.lo = 20000000;

3. modify the SR_0 address and mmu

[jramirez@nautilus no_git ex01_helloworld]$ git diff shared/config.bld
diff --git a/shared/config.bld b/shared/config.bld
index 92281b8..b488025 100644
--- a/shared/config.bld
+++ b/shared/config.bld
@@ -50,18 +50,28 @@ var Build = xdc.useModule('xdc.bld.BuildEnvironment');
  *  8FE0_0000 - 8FFF_FFFF    20_0000  (   2 MB) VPSS_PROG (code, data)
  */
 
-var SR_0 = {
+/*
+ *
+ * var SR_0 = {
+ *       name: "SR_0", space: "data", access: "RWX",
+ *       base: 0x8E000000, len: 0x10000,
+ *       comment: "SR#0 Memory (64 KB)"
+ *   };
+ */
+
+  var SR_0 = {
         name: "SR_0", space: "data", access: "RWX",
-        base: 0x8E000000, len: 0x10000,
-        comment: "SR#0 Memory (64 KB)"
+        base: 0x9F700000, len: 0x10000,
+        comment: "SR#0 Memory"
     };
 
+
 Build.platformTable["ti.platforms.evmTI814X:dsp"] = {
     externalMemoryMap: [
         [ SR_0.name, SR_0 ],
         [ "DSP_PROG", {
             name: "DSP_PROG", space: "code/data", access: "RWX",
-            base: 0x8F000000, len: 0xC00000,
+            base: 0x99500000, len: 0xC00000,
             comment: "DSP Program Memory (12 MB)"
         }]
     ],
@@ -102,7 +112,7 @@ Build.platformTable["ti.platforms.evmTI814X:vpss"] = {
 };
 
 var ammu = {
-    ctrlBaseAddr: 0x8E000000,   /* align on 256 KB */
+    ctrlBaseAddr: 0x9F700000,   /* align on 256 KB */
     prgmBaseAddr: 0x80000000    /* align on 512 MB */
 };
 
@@ -113,3 +123,6 @@ var ammu = {
 var C674 = xdc.useModule('ti.targets.elf.C674');
 C674.ccOpts.suffix += " -mi10 -mo --gcc ";
 Build.targets.$add(C674);
+
+
+

And actually firmware_loader does work as well (not sure why the TI EZSDK representative said it wouldnt during a conference call yesterday).; in a complex ecosystem like the EZSDK, maintainers would actually help more if they acknoledged ignorance rather than guiding users down the wrong path...it is only logical that they can't control this massive code base....anyhow....

Jorge Ramirez said:

Did you delete my post? Mark Utter's note was actually my original question addressed to the TI FAE (which he posted on this site for me) and which I completed with additional information from my second post after having registered into E2E

Jorge,

Your post was not deleted, it was moved to a separate thread: http://e2e.ti.com/support/embedded/bios/f/355/p/195194/696818.aspx#696818 .  I think the "disconnect" here was that perhaps you had no way of knowing that it moved.  Did you not see my reply to your (moved) original post?

It did not appear to be related to Mark's original post, at least diagnostics-wise.  Even if it stemmed from the same work flow (which was not clear to me), your issue contained different symptoms and therefore seemed to warrant a different thread.  TI wouldn't delete a customer post.   We're trying to maintain an ordered database of knowledge.

Regards,

- Rob

Jorge Ramirez said:

The solution for the 8148 with 512MB of DDR consists on

1. recompile slave_loader from the EZSDK (dont use the one in the rootfs)

2. modify the DSP clock frequency for the 8148 (patch below)

Jorge,

Thankyou for replying with your modifications to make it work.  This is very useful information for others that might run into the same problem and come here to the Forums to find a solution.

While you may have become frustrated with your TI-related issues, please know that you are helping others alleviate similar frustrations, and TI (and its "community") appreciate your perseverence.  It's a complicated, rapidly changing development world today with which we're all trying to keep up.

Regards,

- Rob

Hi Rob

Thanks but this is not what we understand as a "community". This is only a problems database. A community in a software context is a rather different  thing. I invite you to join the FSF to understand the differences (this trend has been going on for the last couple of decades though). The EZSDK code quality would improve greatly  by allowing people to contribute and following the peer-review path just like GNU/Linux and many other open source projects

thanks

Jorge