StarterWare¶
TI's OMAP-L138 / AM1808 StarterWare package can be used with the MityDSP-L138 and MityARM-1808 SOMs with some modification to the EVM code provided.
Critical Link has been able to build, debug, and load from u-Boot the UART example in Starterware. This page outlines the various steps performed for the various steps.
All of the examples /steps below were performed using on TI's Starterware version 1.10.03.03. Code Composer Studio version 5.1.0.09 (under Windows 7) was used with the TI provided ARM5 code generation tools (TI v4.9.1). For debugging, a Spectrum Digital USB-510 emulator was used.
Building and Debugging the Application¶
In code composer studio, import the projects from the following directories (assuming starterware is installed in C:\ti\OMAPL138_StarterWare_1_10_03_03\):
C:\ti\OMAPL138_StarterWare_1_10_03_03\build\armv5\cgt_ccs\omapl138\system_config
C:\ti\OMAPL138_StarterWare_1_10_03_03\build\armv5\cgt_ccs\omapl138\evmOMAPL138\uart
Modify startup.c in system_config and rebuild¶
The start_boot() method in the system_config library needs to be modified to force the interrupt vector table (IVT) back to 0xFFFF0000 (the default at reset). TI's UBL (used in loading up u-Boot) sets this to 0x00000000, for reasons unknown. The start boot method should look like this. A copy of the file is provided on this page for reference.
unsigned int start_boot(void)
{
/* Enable write-protection for registers of SYSCFG module. */
SysCfgRegistersLock();
/* Disable write-protection for registers of SYSCFG module. */
SysCfgRegistersUnlock();
asm(" mrc p15, #0, r0, c1, c0, #0\n\t"
" orr r0, r0, #0x00002000\n\t"
" mcr p15, #0, r0, c1, c0, #0\n\t");
PSCModuleControl(SOC_PSC_1_REGS, HW_PSC_UART2, 0, PSC_MDCTL_NEXT_ENABLE);
PSCModuleControl(SOC_PSC_0_REGS, HW_PSC_AINTC, 0, PSC_MDCTL_NEXT_ENABLE);
/* Initialize the vector table with opcodes */
CopyVectorTable();
/* Calling the main */
main();
while(1);
}
Modify uartEcho.c to use UART1 instead of UART2¶
The EVM uses UART2 as the default console port. For the MityDSP-L138 SOMs, the default console should be UART1. All references to UART2 need to be changed to UART1, the uartEcho.c program attached has the necessary changes.
Modify the linker command file to stay away from the u-Boot runtime memory region.¶
By default, the uartEcho project linker will put the executable code at 0xC1080000. That is where the u-Boot runtime application resides and will cause problems during the u-Boot execution. The location of the application can actually reside anywhere from 0xC0000000 through 0xC7FFFFFF (for 128 MByte options, 0xCFFFFFFF for 256 MByte options). So we will modify the linker file to start loading code at 0xC2080000. A copy of the command file is included. The relevant changes are highlighted below:
MEMORY
{
DDR_MEM : org = 0xC2080000 len = 0x2F7FFFF /* RAM */
}
/* SPECIFY THE SECTIONS ALLOCATION INTO MEMORY */
SECTIONS
{
.init : {
system_config.lib<init.obj> (.text)
} load > 0xC2080000
.text : load > DDR_MEM /* CODE */
.data : load > DDR_MEM
.bss : load > DDR_MEM /* GLOBAL & STATIC VARS */
RUN_START(bss_start),
RUN_END(bss_end)
.const : load > DDR_MEM /* SOFTWARE SYSTEM STACK */
.cinit : load > DDR_MEM /* SOFTWARE SYSTEM STACK */
.stack : load > 0xC3FF7FFC /* SOFTWARE SYSTEM STACK */
}
Compile and Download the application¶
Compile the uart example application (make sure you are generating an ELF file format executable).
To download the application via the debugger, startup the MityDSP-L138 board and stop execution in the factory installed u-Boot (hit a key) application.
At this point, the low level bootloaders (installed at factory) have configured the DDR memory, the PMIC, and most key pin-muxing routines. u-Boot does not use interrupts, so they are all disabled and it is fairly safe to connect and download your code for testing.
Add the OMAPL138-ARM.ccxml debugger session. You should not need a GEL file associated with the session as all of the low level initialization, etc., should be done by the load level u-Boot code, or by your Starterware application.
Launch the debug session and run the application. If everything works, you should get the following text on the screen and anything typed on the terminal should be echo'ed back.
StarterWare UART echo application
Flashing and Loading the Application from u-Boot¶
Basically, once you have a working ELF (a ".out") image that can be loaded and executed from the debugger you are ready to (optionally) save the image to FLASH and load it from u-Boot. The .out image should be located in C:\ti\OMAPL138_StarterWare_1_10_03_03\build\armv5\cgt_ccs\omapl138\evmOMAPL138\uart\Debug\uartEcho.out.
In order to start the ELF application from u-Boot, you will need a recent version of the u-Boot image for the MityDSP-L138 family of SOMs (attached on this wiki page, see the u-Boot section for details about upgrading your copy of u-Boot). The recent image contains a compiled in copy of the "bootelf" command. If you don't have a "bootelf" command in your installed u-Boot image, you will need to upgrade.
Using teraterm to download your code via serial port, you can download and run the program with the following commands:
U-Boot > loadb c0700000 # send the uartEcho.out file via kermit U-Boot > bootelf c0700000
If you want to save the image to non-volatile memory, then you can store it to SPI NOR flash, NAND, or MMC in a similar way as you might store the linux kernel (see Linux_Kernel page for reference).
Booting a Starterware Application with embedded bootloader¶
Currently, this is not yet supported. The main reason for this is that the project, which includes the low level bootloader library which includes the DDR configuration as well as some of the low level SPI and I2C control and pin-muxing must be modified to account for differences between the MityDSP-L138 SOM and the TI OMAP-L138 EVM SOM. Until this activity is complete, the low level boot code will not properly initialize the SOM.
Critical Link recommends, at least for the near term, that users use u-Boot to save and boot ELF starterware images.
You can create "scripts" with u-boot to execute several programs on boot up.
u-Boot will (by default) start a count down timer and run the commands stored in the environment variable "bootcmd" by default. Multiple commands can be stored in the same environment string by separating them with a semicolon. You can also run other environment "string scripts" using "run ${env_var_name}".
For example, you could do something like the command below to load a 512K ARM ELF app stored on NOR flash at offset 0x100000 into 0xC0000000, load a 512k DSP COFF (a.out) app at offset 0x200000 into 0xC6000000 and then launch the DSP, then the ARM. This command would then be executed after the count down timer expired.
setenv bootcmd "sf probe 0; sf read c0000000 100000 80000; sf read c6000000 200000 80000; bootdsp c6000000; loadelf c0000000"
Additional Starterware Examples for the MityDSP-L138¶
A zip file is attached on this wiki page that contains TI's OMAP-L138 / AM1808 StarterWare package with additional examples for the MityDSP-L138 and MityARM-1808 SOMs.
The following examples have been implemented for the MityDSP-L138:
- cache_mmu
- dsp_exception
- enet_echo
- enet_lwip
- edma
- gpio
- i2c
- ipc_buffer_io
- ipc_interrupt
- ipc_polling
- nand
- rtc
- spi
- spi_edma
- timer
- uart
- uart_edma
- wdt
- open CCS 5 and choose [BASE_DIR]\ OMAPL138_StarterWare_1_10_03_03\build\armv5\cgt_ccs\omapl138\MityDSPL138 as the workspace, where
To work with the enet_echo and enet_lwip examples :
- [BASE_DIR] is the directory where the OMAPL138_StarterWare_1_10_03_03 folder resides.
- These are GCC builds and are makefile-based, not CCS projects. So you’ll need a GCC toolchain (we recommend CodeSourcery G++ Lite v2009q1) and a terminal that can run make (I use Cygwin).
- CD to [BASE_DIR]\ OMAPL138_StarterWare_1_10_03_03\build\armv5\gcc\omapl138\MityDSPL138\[EX_NAME], where
- [BASE_DIR] is the directory where the OMAPL138_StarterWare_1_10_03_03 folder resides
- [EX_NAME] is the example that you want to build. The makefiles reside in these directories.
- The process for building the code is available on this wiki: http://processors.wiki.ti.com/index.php/StarterWare_Getting_Started_01.10.XX.XX#GCC_With_Cygwin_2
usb_dev_serial Starterware Example for the MityDSP-L138¶
The file usb_dev_serial.tar.gz is attached on this wiki page that contains TI's OMAP-L138 / AM1808 StarterWare usb_dev_serial example for the MityDSP-L138 and MityARM-1808 SOMs.
This example passes data received from the serial to the usb, and data from the usb to the serial. This is only the usb_dev_serial files and does not contain the libraries and support code, you need to replace / update the files in the Starterware with these files. This example code is derived from OMAPL138_StarterWare_1_10_03_03.
To build the code, extract these files over the old ones, go to build/armv5/gcc/omapl138/evmOMAPL138/usb_dev_serial, update your build environment variables
and run make. The USB COM port drivers provided from the TI StarterWare. The driver is provided by the TI OMAPL138_StarterWare under tools/usb_inf.
Go to top
