OMAPL137-HT: Boot Bare Metal Application Clarification

Marius,

We do provide a secondary bootloader application for reference that will load and run both the DSP and the ARM cores on OMAPL137 using the SBL running on C674x core. you can look at the documentation on how to test this setup here:

https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_Foundational_Components.html#omapl137-omapl138-c6748

Rahul,

Thanks for the fast response.

I am still studying the documentation, maybe this is why I couldn't find a solution to boot both cores on OMAPL137 - each core with its own application. I have studied "OMAP-L137 Bootloader":

where is mentioned: "Do I need a secondary bootloader (UBL)?[edit]

A secondary bootloader, AKA User Bootloader (UBL), was required on older devices, where the bootloader could not parse AIS files. By using the AISgen tool with the OMAP-L137 bootloader, most of the functions previously performed by the UBL can be done instead by the bootloader."

I suppose this is an old documentation vs the new one, Processor SDK RTOS.

In the link you sent it is explained how to boot ONLY one application using the SPI FLASH. Maybe the second application is part of the SBL/MLO but I cannot see/understand this in the documentation.

Thanks,

Marius Raducanu

The OMAPL137-HT is a processor with a lot of potential for the high temperature applications. Even at the price tag of $550 could be a good choice for a control system rated at 175C.

Unfortunately, I still cannot make my evaluation board to boot from SPI0, two simple applications: one in DSP that put some characters to the serial and one in ARM that blinks the LEDs.

I can run/put these applications in DSP and ARM with the board emulator and ran them in the same time. I can boot each application from SPI0 but not in the same time. I suppose, this is essential if I want to acquire data in ARM and process the data (FFT) in DSP.

The documentation is poor and I couldn't find an example how to boot from SPI0 these minimal applications in the same time.

If nobody can help, I will start studying in more detail the documentation and eventually, I will post my findings.

My plan is to use the OMAPL137-ARM-LED.zip in the documentation that has one application on DSP that starts the ARM (blink LEDs) and then goes in a infinite loop. I will try to change the DSP and instead going in the infinite loop to do something else (send char to serial).

Regards,

Marius Raducanu

I tried to boot from SPI in two ways:

1 - Using the newest Processor SDK RTOS 06_03_00_106:

A – I created the spi_flash_writer.out, MLO and app according to the documentation:

C:\ti\pdk_omapl137_1_0_11\packages\ti\boot\sbl\tools\flashWriter\spi\bin\evmOMAPL137\spi_flash_writer.out

C:\ti\pdk_omapl137_1_0_11\packages\ti\boot\sbl\binary\evmOMAPL137\spi\bin\MLO

C:\ti\pdk_omapl137_1_0_11\packages\MyExampleProjectsDSP\GPIO_LedBlink_evmOMAPL137_c674xTestProject\Debug\app

B – Copied MLO and app in the same folder with spi_flash_writer.out.

C – Ran spi_flash_writer.out in CCS8.

D- Got this error in Hyperterminal:

*** PDK SPI Flash Writer ***

Opening SPI handle...

       SPI init failed!

2 – Using DaVinci-PSP-SDK-03.20.00.14.tgz, I put successfully the u-boot in FLASH (SPI0):

Ran spiflash_writer.out (arm) in CCS8 one at a time for all three files:

dsp-spi-ais.bin (“dspais”), ubl-spi.bin (“armubl”), u-boot.bin (“uboot”) – Files verified, all matched.

I got the u-boot prompt in Hyperterminal (I2C not SPI0):

U-Boot 2009.11 (Oct 05 2010 - 15:34:39)

I2C:   ready

DRAM: 64 MB

*** Warning - bad CRC, using default environment

In:   serial

Out:   serial

Err:   serial

ARM Clock : 300000000 Hz

Net:   More than one PHY detected.

Hit any key to stop autoboot: 0

4096 KiB W25X32 at 0:0 is now current device

Wrong Image Format for bootm command

ERROR: can't get kernel image! – Not a SPI0 booting problem because it tries to boot from I2C not SPI

U-Boot >

3 – Using DaVinci-PSP-SDK-03.20.00.14.tgz, I tried to replace u-boot with my application (bilking LED in arm):

Got this error:

Booting with TI UBL

Device OPP (300MHz, 1.2V)

I've tried unsuccessfully to write in FLASH the MLO and app with spi_flsh_write.out in CCS (according to Processor SDK RTOS 06_03_00_106 documentation). Got this error:

*** PDK SPI Flash Writer ***

Opening SPI handle...

       SPI init failed!

C:\ti\pdk_omapl137_1_0_11\packages\ti\boot\sbl\tools\flashWriter\spi\bin\evmOMAPL137\spi_flash_writer.out

C:\ti\pdk_omapl137_1_0_11\packages\ti\boot\sbl\binary\evmOMAPL137\spi\bin\MLO

C:\ti\pdk_omapl137_1_0_11\packages\MyExampleProjectsDSP\GPIO_LedBlink_evmOMAPL137_c674xTestProject\Debug\app

I was able to write them in flash using another flash writer (spiflash_writer.out - from DaVinci-PSP-SDK-03.20.00.14.tgz) at addresses 0 (MLO) and 80000 (app).

After booting I got this error in Hyperterminal:

**** PDK SBL ****
SBL Revision: 01.00.09.02 (Sep 30 2020 - 17:12:59)
Begin parsing user application
Invalid magic number in Single image header
Jumping to user application...

The app is from:

C:\ti\pdk_omapl137_1_0_11\packages\MyExampleProjectsDSP\GPIO_LedBlink_evmOMAPL137_c674xTestProject\Debug\app

Does TI still support this processor (OMAPL137BPTPH)?

I am able to buy it from DigiKey ($558.6) and the "Part status" is still active.

I've checked the header of the app file and it has the magic number:

4d 53 54 52 01 20 20 20 37 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 20 4d 45 4e 44 

My conclusion is that the 0x80000=524288 offset in flash (MLO offset=0, app offset is 0x80000) is not correct in MLO.

Can somebody confirm this?

Thanks