Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Okan Çalış wrote:

This TI wiki page says that the boot parameter must be incorrect, but I don't know how to fix it. What's the difference between the memory value after bootm and the one in bootargs? I tried changing "bootm c0700000" to c0000000, but it still gets stuck.

The bootm address is the memory location where you copied the kernel. Which must match the sf read 0xc0700000 ... address. The bootm command will then copy the kernel image to the Load Address before switching over to kernel execution.

U-Boot > bootm c0700000

    Booting kernel from Legacy Image at c0700000 ...
    Image Name: Linux-3.2.0
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2530168 Bytes = 2.4 MB
    Load Address: c0008000
    Entry Point: c0008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK
    OK

Search for "Loading" in u-boot common/cmd_bootm.c . To see what its doing.

I'd look into setting up earlyprintk.
Also double check that using the old bootargs still work.
Make sure your console= doesn't have any typos.
Try some of these: https://elinux.org/Debugging_by_printing#Debugging_early_boot_problems

Hi,

I was just about to build a new kernel to set earlyprintk, then I realized my bootargs were missing 0x prefixes. I fixed it and the kernel now boots. (Oddly, I never used 0x in my other U-Boot commands and I never ran into an issue.) And the ex01_helloworld example works as shown in SysLink Configuration.

Thanks again.

Thanks for the update. Glad you found the problem.

Hi,

Since I managed to run the example executables in MityDsp last week, I've been trying to modify the codes and understand how it works, but I couldn't even compile any of them yet.

The TI wiki has a Creating CCS Project for SysLink samples page, which I can't follow because the page is supposedly out-of-date (to be more specific, "samples" are said to be obsolete and replaced by "examples"). I looked for a similar page for importing "examples", but I couldn't find one. I asked this as a question at the E2E Forum nearly a week ago, but they are not responding.

• Target: ti.targets.elf.C674
• Platform: ti.platforms.evmOMAPL138
  (Both these fields come up empty and I'm not sure about these values.)

I also add the path "home/okancalis/ti/syslink_2_21_03_11/packages" as a repository and finish creating the project. At this state, I can build the project without trouble.

Then, I delete the default files main.c, app.cfg, and makefile.defs and copy the files main_dsp.c, Server.c, Server.h, makefile and Dsp.cfg from "examples/ex02_messageq/dsp" to the project directory. I also copy the directory "examples/ex02_messageq/shared" to the parent folder of the project. Then, when I try building the project, I get: "Cannot read property "base" from undefined (Dsp.cfg#88)"

I searched the web, but couldn't find a fix. What do you think could be wrong?

Another question: The example doesn't show how to read the inbound message; am I supposed to read the SharedRegionSRPtr field of the App_Msg struct? SysLink API is no way as simple as Critical Link's wrappers.

Thanks again,
Okan

Hi Okan,

We currently do not support SysLink in the capacity needed to answer your most recent questions. We recommend pursuing your project using our MDK (which utilizes DSPLink instead of SysLink), as we are more able to provide support related to such efforts.

If SysLink is a necessity for your project and you would like to enlist our services to help with the issues you are having, please contact info@criticallink.com to discuss this possibility.

Thanks,
Jonathan

Hi, Jonathan,

I understand that you do not support SysLink, and using your MDK for ARM-DSP communication is very easy for me, too, given the complexity of SysLink examples and the E2E forum's reluctance to respond to my questions.

But I'm confused about why you are supporting both Starterware (which is, oddly enough, listed under Linux Operation System in the wiki but incompatible with Linux) and DspLink (which does not let the Starterware examples run on DSP). So, are the Starterware examples not supposed to be used with multicore at all? Or is there a work around?

Thanks again,
Okan

We added minimal support for Starterware for a couple of specific customers that insisted on using it. In those cases, they were not really running multicore. They wanted to either run bare-metal ARM or bare-metal DSP code (not both). Startware applications are loaded from u-Boot via COFF or ELF format or directly from SPI via a custom AIS bootloading sequence. No linux or higher level OS is used.

If you want both CPU's running application software, the only real path that we support is ARM+Linux and DSP+DSPBIOS using DSPLINK, though some customers have successfully migrated our platform to SYSLINK without much help from Critical Link.

-Mike

Thanks, Mike,
That clarified things.

Regarding my earlier question, this forum thread has the answer, in case someone else needs it.

The SysLink examples are provided to be built on the command line, so it may be easier to just rebuild on the command line as opposed to using CCS

Okan