DSP Quick Start¶

If you're primarily interested in getting started in writing code for the DSP and would like to put off getting the ARM build environment and DSPLINK setup then this guide should help. This guide does not cover the "normal" case of writing DSP code that will interact with the ARM running linux, using the DSPLINK framwork.

Quick Start using JTAG emulator to load Application (No linux required)¶

If you are are solely interested in prototyping DSP code without IPC communication to the ARM or the ARM running linux, you can use a JTAG emulator such as the Spectrum Digital USB510 to download DSP code from Code Composer Studio. The idea is to allow the ARM to power up and boot up into u-Boot and stop. You can force u-Boot to not autoboot (if you get the 3 second countdown timer) by clearing the bootcmd variable with

U-Boot > setenv bootcmd "" 
U-Boot > saveenv

The factory programmed User Boot Loader and u-Boot are executed by the ARM and setup the memory and basic device interfaces. At this point the DSP is powered up and sitting in an IDLE spin loop, the external memory and EMIFA busses are configured, and the ARM is in a spin loop monitoring (polling) the UART console device. The ARM does not use any peripheral IRQ's in u-Boot. The DSP can be loaded (via JTAG) and run freely provided:

1. It does not use the console port for terminal I/O
2. It avoids the DDRAM region that the ARM is using to run u-Boot (0xc1000000-0xc1200000)
3. You don't run any commands that would attempt to use peripherals or memory on u-Boot (the ARM) that your DSP software is using (i.e., don't run u-Boot commands while prototyping your DSP code).

At the moment, the main ARM and DSP CPU clocks are configured to run at 300 MHz out of cold boot. Increasing the CPU speed requires interfacing with the onboard PMIC to up the core voltage. This is normally done by a driver in the ARM linux code, so you'll need to scale your performance numbers up to assess 456 MHz operation as u-Boot does not have any provisions to increase the core voltage and/or main clock divisors.

We recommend that you use memory above address 0xC2000000 for DSP prototyping.

NOTE : another option to this procedure is to shutdown the ARM and tailor the DSP gel file to setup the RAM, PLLs, etc. from code composer manually. However, Critical Link does not provide a gel file that supports this mode of operation.

Quick Start using u-Boot to load a DSP application up and launch DSP (no linux required)¶

A recent patch to Critical Link's Das U-Boot Port for the MityDSP-L138F family of SOMs supports using the ARM u-Boot application to load and launch a DSP legacy common-object-file-format executable as generated by Code Composer Studio. This will effectively allow you do use a MityDSP-L138 module as if it were a MityDSP-6748 module; you can develop a full application using only the DSP core and use the DSP core to control/manage all of your peripherals. This may be desirable for folks that do not want to leverage linux or other OS's available for the ARM at this time, but may want to in the future.

Note that if you load the DSP from UBoot and then boot the ARM processor with an OS that process will likely result in the DSP being Reset and will require it to be reprogrammed from your OS. As such the instructions below for storing into SPI NOR Flash memory expect that no OS Kernel image will be needed.

This utility requires the coff image to be present in memory out of place, so that the loader can place the embedded sections in the correct locations. The utility command is "bootdsp [loadaddr]". When run, it will assume a coff a.out file is stored in memory at loadaddr. If a valid image is found, the coff file will be parsed and the necessary sections (text, data, etc) will be extracted and placed into memory. Once the sections are populated, the ARM will generate a reset vector in the base of shared memory (0x80000000) that issues a branch instruction to the entry point indicated by the coff image and enable/reset the DSP (which will start operation).

Note the u-Boot image that includes this feature is not yet included in any Board Support Package, so you'll need to build the image and flash it in (make sure to reset after you do!) until the image makes it into the production pipeline images at our manufacturer's location. A copy of a recent build of u-Boot that includes this feature is included on this page for convenience, but you should check for newer versions or consider building it yourself as we may not update this file with future u-Boot releases / improvements.

NFS Load of DSP.out File From UBoot¶

A typical load sequence from an NFS server at u-Boot would look like like the code below. Additional storage / retrieval options for SPI FLASH, NAND, SATA, MMC, serial load, and Network TFTP area also possible.

U-Boot > nfs c0700000 10.0.0.87:/path/to/dsp_program.out
U-Boot > bootdsp c0700000

SPI NOR Flash Load of DSP.out File From UBoot¶

If you want to permanently flash the DSP image to SPI NOR FLASH (8MB total size of the memory) for programming of the DSP from UBoot we recommend you use the memory space allocated for the OS/Kernel.

By doing so you will erase any stored Kernel image typically used to boot the ARM processor.

Follow the steps below using either NFS like above to transfer the image to memory or TFTP as shown below:

u-Boot> tftp 0xC0700000 192.168.0.23:/dsp_program.out
u-Boot> sf probe 0
u-Boot> sf erase 0x100000 0x300000
u-Boot> sf write 0xC0700000 0x100000 ${filesize}

Note: If your DSP size is larger than 0x300000 (~3MB), then you will of course need to change the erase size above as well as the bootcmd environment string (which is used to load the kernel from the SPI FLASH on startup, if this is your preferred approach).

Autoload DSP during boot from SPI NOR¶

Once you have your DSP image stored in SPI NOR FLash memory you can then edit your "bootcmd" so that the image is pulled from the SPI NOR into RAM and then boot the DSP with that image.

You will then need to change your bootcmd to load the DSP from SPI FLASH by:

u-Boot> set bootcmd "sf probe 0; sf read 0xc0700000 0x100000 0x300000;bootdsp 0xc0700000" 
u-Boot> saveenv

At this point you can reboot the module and it will automatically load the DSP.

DSP Implementation Notes for No-ARM operation¶

If you choose to use the DSP load-and-go technique from u-Boot, there are a couple of guidelines that you should consider for your DSP-only application:

1. You do not need to do any low level memory initialization. The mDDR along with a fair amount of pin-mux setup for EMIFA, UART1, I2C, etc. is already configured by u-Boot.
2. There are memory areas that should be avoided during load time. The u-Boot application, stack and heap, is running in DDR2 in the memory region 0xC10000000 through 0xC12000000. You will need to avoid loading code or the initial a.out file into this area of memory. Also, the bottom 128 bytes of memory of internal SRAM (0x80000000) are used for a temporary reset vector by the ARM, so you will need to avoid using this area for code in your .out file. Once the DSP is running, this memory may be reclaimed by shutting down or resetting the ARM core and setting up new reset vectors for the DSP.
3. If you need to use the console UART, you should shut down the ARM code. See the Local Power and State controller section of the TI OMAP-L138 Technical Resource Manual for details.

Quick Start using ARM/linux to load Application via DSPLINK¶

Required files¶

• dsplinkk.ko
  • Can be found in the latest MDK release (MDK/images/modules/) or you can rebuild DSPLink. See details at DSP Link Configuration.
• HelloWorld
  • The compiled ARM executable for the Hello World example. This code can be used to load the DSP. This code will also setup a debug DSPLink message queue that you can use to write debug messages to the console.
• A compiled DSP .out file
  • See the second section of DSP_Hello_World for details on setting up a project to work with the supplied ARM executable.

Usage¶

• See the last section of DSP_Hello_World for details on starting the application.
  • The ARM executable will load the supplied DSP .out file and will exit once 'q' has been entered on the terminal.
  • A debug queue is setup and will print debug messages to the terminal. See dsp_main.cpp in DSP_Hello_World for more details.
  • Debugging with the emulator can most easily be accomplished by adding an infinite loop in your DSP code:
    

    bool lbWaitForMe = true;
    while(lbWaitForMe);
    

    • Once you have broken in with the emulator and loaded the symbols for your code you can change the value of this boolean to exit the infinite loop and step through the desired portion of your code.