Lost in the OMAP-L138 world...

anobody?? At least a partial answer? Please...

Updated the original post to remove questions for which I now have answers. 2 more to go, if somebody can help me please...

Hi DT,

Based on my OMAP-L138 knowledge I am replying this.

Booting the OMAP: As it is a processor, we can't flash the image on to it. (For Microcontroller we can have access to on chip ROM. where as generally for processors they will not provide such facility, so it is not possible to flash your image into OMAP-L138 Processor itself.

When you load from CCS it loads into memory based on a file settings. The files extension is .cmd file for CCSv3.3. If the GEL file initializes SDRAM, the code can be loaded into SDRAM and it might be executing from there. If the .cmd file defines to use only On Chip RAM then the code will be loaded to Internal RAM and it will be executing from there. When you are loading code from CCS, I guess it is not loaded to ROM.

There is a tool called SFH for OMAP-L138. Using it you can flash the Primary Bootloader and Secondary Bootloader to SPI NOR Flash or NAND. There might be other options. But, I am aware of these two only. OMAP-L138 supports SD Boot also, for this you need to have Primary bootloader on one of the peripheral and the secondary bootloader in SD Card.

Gel, bootlaoder option.

Bootloader is either written in C Code or Assembly. What do you mean by have the SDRAM initialization in C code?

Regards,

GSR

First of all, thanks a lot for your answer. 

It explains well the difference between what I'm used to (microcontrollers) and processors (OMAP). Now you are saying that there can be 2 bootloaders, a primary and a secondary. I wrote a question in another thread but didn't get a complete answer, so I'll ask it here :) What I want to do for booting is have some kind of protection for field upgrades. Our product will have a factory image but we want to allow customers to upgrade the firmware (application running on the OMAP). But, I want to have a protection in place if an application update goes wrong, so the OMAP can still boot on factory firmware and the customer can try to updade the application again.

A TI member of this forum proposed me to use a secondary bootloader that could do checks, scan for new application, revert, etc. A lot of latitude in the secondary bootloader he said, but I don't know what is a secondary bootloader. The only thing I know at this point about bootloaders is what the AISgen tool can do, which doesn't give me a lot of latitude on scanning, checking, etc. Or there is something I don't understand (probably hehe).

For the last question, what I meant is that in my past, for example when I coded for the Atmel AVR32, all the initialization of peripherals was made in code (like in main()), but I guess it is not really important, since I'll want my peripherals to be up and running in the boot if I have the option.

Thanks again for taking the time to answer me!

DT

My experience has been on the OMAP-L137. On that chip, I believe the typical boot sequence is:

1) ROM Bootloader. This bootloader exists in the chip ROM. It is programmed at the factory and is not field programmable. Unclear which processor ARM or DSP is executes on. The code will read the boot pins to determine where the next bootloader resides, eg SPI flash, NAND, MMC, etc. Not all media are supported on all OMAPS and variants. Loads the code into SRAM. The next bootloader must be in an AISGEN format. I don't believe this bootloader has much programming ability. Not like the Atmel SAMBA programmer. There might be some special programmer loader via UART app out there.

2) DSP Bootloader. This bootloader must be in a special AISGEN format to be recognized by the ROM bootloader. Loads the ARM bootloader into SRAM. Enables the ARM and passes control to it. The source of the image is hard-coded into the code. Usually if this bootloader is in SPI flash, the next bootloader will be in SPI flash. Although it need not be.

3) ARM Bootloader. Configures DRAM. Loads U-Boot into DRAM.  Usually if this bootloader is in SPI flash, the next bootloader will be in SPI flash. Although it need not be.

4) U-Boot (on the ARM). Primary purpose is to load Linux into DRAM although it can load other OS. The source of the Linux image and filesystem can be from the same media as the bootloaders but seldom is. Network and SD/MMC are the most common media.

5) Linux. Can be used to load the DSP with an application or codec. I have a feeling that TI is moving towards a model where the DSP is strictly a numeric co-processor. It does not interact with any peripherals.

6) DSP App. This usually uses SYSBIOS/SYSLink or the older DSPBIOS/DSPLink.

On the OMAP-L138, the ARM boots first. From my limited experience with the DSP and ARM bootloaders, the bootloaders are very low level. They tend to manually initialize peripherals and do not use the automagic GEL file.

A good place to check for info is TI's wiki, http://processors.wiki.ti.com

Thanks a lot, that help!

So if I understand this correctly, it means:

1- The first bootloader, or ROM loader is on-chip and checks the hardware pins to know from which peripheral it will boot. If I setup the hardware pins to boot on a SPI-flash memory, then it will check on this chip to start the secondary bootloader.

2- The secondary bootloader is built by me using AISgen, in which I define which component is enabled and configured. I also link my application in the secondary bootloader so when the AISgen file is loaded from the ROM bootloader, it will initialize whatever is needed and start my application. When the AISgen file is generated, I burn it into the memory using the TI tools.

Now, if I have a product that will use both the DSP and the ARM, I think I need 2 different application right? If yes, then do I need 2 AISgen files, one for each? Reading the documentation about the OMAP-L138 bootloader, I found out that the AISgen file must be at address 0x00 on the SPI Flash... I can't put 2 files at that address. So how does it work?

Some speculation on my part. I eventually got my OMAP-L137 project going. I didn't delve deep deeply into the parts that worked. Projects like this are not completed but abandoned out of exhaustion.

I think the first bootloader in ROM requires the second bootloader to be AISGEN'ed. Subsequent bootloaders do not need to pass through AISGEN. In TI documentation, the bootloader after the ROM bootloader is called the User Boot Loader, eg ARM UBL or DSP UBL. I'd be happy if someone corrected me on this.

The first UBL has to be at a known location in whatever media. You're ahead of me of me on this. Location 0 in SPI Flash. The first UBL will be hard coded to look for the second UBL at a specific address. Obviously not 0. From what I seen, the first UBL is written to just load the second UBL from a different location than 0 and jump to it. No AISGEN stuff. I could be totally wrong on this as well.

In your case, OMAP-L138, I'll reiterate your statements:

1 - ROM loader. Source of UBL controlled by boot pins.

2- ARM UBL. If SPI Flash, this code is at address 0. Has been passed though AISGEN. You decide what processor to load, where to get the image from and what is the image format. The next bootloader might be U-Boot in ARM. Could be a DSP ".out" app. In that case, your UBL would need all the code to understand a ".out" file and initialize the DSP.

Yeah I think we are not using the correct terms. I just re-read the OMAP-L138 Bootloader documentation and I was messing terms. I hope somebody else can confirm our thinking. 

It looks like that the OMAP-L138 only has 1 bootloader by default, which is the one in the ROM (RBL). The generated AISgen file that includes the application is just a script file read by the ROM bootloader, it is not the secondary bootloader automatically. If the application is just that (an application), the AISgen script file is not considered the secondary bootloader. However, is the "application" file used to create the AISgen output script file is a secondary bootloader, then it's called a UBL. The UBL is not mandatory in OMAP-L138.

So my question is now this: what is the content of a secondary bootloader (UBL)? is it C-code? How does it call the application that must run? Can it check, for example on the SPI flash memory at different addresses to see is the application is present or not and react accordingly? Can it check if a button is pressed and load a different application depending on this? How does it work?

For me on the OMAP-L137, the UBL was a DSP UBL. It is in C. I used the SPI flash programmer via Code Composer/JTAG to burn a single image file. Somewhere in the DSP UBL build, the AISGEN script file must have got merged in with the compiled code. No idea where. You might want to peruse the DVSDK for the OMAP-L138:

http://www.ti.com/tool/linuxsdk-omapl138
http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_4_00/latest/index_FDS.html

It's a big download and I think you need a Linux machine. Somewhere in that big blob of stuff is the source code for the UBL. In my case there was a ARM and DSP UBL. There should also be source for the flash programming utilities. That code will show where and what is programmed. I've found the documentation and webpages are sometimes wrong about the memory map.