Design consideration for firmware update on OMAP-L138

Given that the ROM boot loader inside the chip will start running first and load code from your peripheral memory, it will be important to satisfy any requirements that it has.  In general, the ROM does not have much in the way of recovery features, so it might be advisable to have the initial code that the ROM loads be fixed (never changes even if firmware upgrades take place).  Then that code can be a secondary loader that can load the actual desired firmware from the flash or other memory. That secondary loader code (which again would be your code, but would never change in any future firmware upgrade) could be written to search for as many copies of the main firmware in as many places as you wanted it to look, could recover from bad flashes, could detect a button press on the device to select a default boot image (a factory firmware), or any other scheme you could dream up.

You should review the ROM boot loader app note to make sure you comprehend what the ROM can or cannot do for you.

Regards, Daniel

Thanks for the answer. In your example, the secondary loader is part of the boot also? If not, I currently have no idea how to implement that (having 2 firmwares, 2 "mains"), etc. ). But I'll probably learn more when I'll read the application note.

Your comment actually gave me an idea. Could it be possible in the ROM to detect on which device the code should be loaded based on hardware configuration?

Let's say I press a button and hold it pressed, then turn the power on, this could change the hardware configuration to tell the OMAP to boot from a specific memory which would contain a factory firmware. And if the button is not pressed prior to power on, the OMAP could boot from another specific memory?

My idea is maybe not the best implementation, I'm just looking at the options. I still prefer the flexibility of yours, but as I stated above, I'm not sure what is the "secondary loader" in terms of code.

Thanks!

DT said:

Let's say I press a button and hold it pressed, then turn the power on, this could change the hardware configuration to tell the OMAP to boot from a specific memory which would contain a factory firmware. And if the button is not pressed prior to power on, the OMAP could boot from another specific memory?

There are device pins that are sampled when the chip leaves the reset state that determine the boot mode, i.e. the peripheral interface from which to boot. so using a button could change the state of one of those pins and let you switch between two different boot modes.  But there five to eight pins that can affect boot, so only having one button as you describe may not let you select between the exact modes you want.  This is not a design choice I would recommend - in general you would want to tie the pins off via pull-up or pull-down resistors (our EVMs do this through switches that can be configured when the board is powered off).

Regards, Daniel

ok, thanks for the advice. So I guess your first idea is the one to keep. Could you elaborate a little more on the "secondary loader", this would give me a path to follow. It's my first TI chip experience, so I'm starting from nothing.

My question may seems odd, it's just that I'm used to program a single output file application that is written on the chip itself (or an external memory), an application having a main. I'm not sure how to connect 2 applications together in a embedded environment. That's why I'm a little lost on what is the secondary loader. Is it a secondary boot ROM, or is it an application with a main that will scan different places then somehow call another main?

Regards,

DT

DT said:

I've read your suggested application note and here is what I understand so far about the bootloaders.

1- The primary bootloader is the ROM and it's on the OMAP-L138. This bootloader scans the hardware pins to detect where is the secondary bootloader. In my case, I would want it to be the SPI flash memory.

Correct, the primary boot loader (the ROM Boot Loader or RBL) will detect where to look for a boot image and try to go load it from there.  The boot image might be a secondary boot loader (an application whose job it is to get and load and another (typically larger and more complex) application) or it might be the final application you want to run.  Historically, a small secondary loader of some kind was required to enable to do low-level system init such as enabling external memory and clocks so that the larger, more complex applications, that could not fit in the device's internal memory, could be loaded.

The ROM boot loader on this device is somewhat more complex and provides more advanced capabilities to the end user.  There are functions in the ROM that can setup the external memory, the system clocks, adjust the peripheral clocks, set any random location in memory, and even jump to code in other parts of the system.  The AISGen tool gives the user the ability to specify options for some of these commands (such as PLL/clock init and DDR setup).  The parameters you specify could conceivably be derived from the GEL file. Beyond that, your understanding is correct.

You aren't required to use DSPLink  - you could use whatever method you create to have the two cores talk to one another.  If you did use DSPLink from a high level OS like Linux on the ARM, typically your DSP executable would be loaded by the DSPLink PROC_load API.  But could create a boot image that contains the contents of both a DSP program and an ARM program that could be loaded at boot time.  Just rememeber that only one of the cores will start from the ROM boot loader, and you would then need code to start up the other code to get it to run what you loaded during boot (these two wiki articles do a good job showing this: http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L138 http://processors.wiki.ti.com/index.php/Boot_Images_for_OMAP-L137 )

DT said:

1- The AISgen tool doesn't give me a lot of options (or I don't see them) to perform what you suggested in your reply: "That secondary loader code (which again would be your code, but would never change in any future firmware upgrade) could be written to search for as many copies of the main firmware in as many places as you wanted it to look, could recover from bad flashes, could detect a button press on the device to select a default boot image (a factory firmware), or any other scheme you could dream up." . So I'm not sure what is the secondary bootloader you have in mind. Is it a C application I write? If yes, how can I instruct the bootloader to load a firmware image into RAM to start the application?

You would need to create your own secondary loader.  It is a typically a bare-metal C application (with a little bit of assembly code required to setup the C environment).  We actually have quite a bit of code that can be used as a starting place for this effort.  The secondary loader code we have is called the UBL (or user boot loader), and a lot of the instructions you find out there show how to use the UBL (which must be put into an AIS format) along with another loader like u-boot.  The UBL source is available in the TI flash and boot utility package. It is licensed under an open source BSD license, so you are free to take it and do whatever you want with it.

Regards, Daniel