Booting two AIS applications

Hi Eran,

I'm not sure that your idea would work or not.

Why don't you combine these two apps into one app ?

Combine the 2 codes into single which read the GPIO value and depends on the GPIO value, the code jump to the app2 (function) work & execute if not expected value from GPIO then app1 (function) would execute.

What do you say ?

Hi Stalin ,

One of my application is a proprietary loader application which communicates with a PC and enables flashing the NOR flash.

The other one is the “real” application.

By splitting to 2 applications, I prevent a “brick” situation, where something goes wrong while flashing (power down for example) and the hardware is left with no operative software. (It is very important to give our customers a product which has ~0% risk of getting a brick).

I thought two options :

1.      Program flash 0x0 address with App1

In its AIS insert the AIS jump operation. It would jump to a function inside App1.

This function will look at the GPIO and decide what to do. If GPIO = 0 than return from function (app1 would be running). If GPIO = 1 than somehow to tell the BOOTROM to continue parsing from another address when returning (so app2 would be loaded after returning from jump).The missing part of this plan is that I don’t know where the BOOTROM keeps its parsing address index.

2.      Same as (1) but maybe using the Software reset option. I just need to know if I could “tell” the bootrom to start parsing from another address. (for example , if TI could expose the header/interface of the bootrom….).

Any ideas ?

Thanks ,

Eran

I don't think there is any way to specify a load address to the ROM bootloader. It will always looks zero address or offset or fixed file name. The AIS jump command looks promising but I have doubt it intent was to jump and never return. Stack management is an issue. The TI's guys can say for sure. Also AISGEN does not have an option to add the jump command. You would have to write a utility.

If you've the spare pins and the board space, put your two images on two different boot mode devices. Put your user application in NOR and put your proprietary loader in some other media like a small I2C or SPI EEPROM. Or use UART boot to put your proprietary loader into memory without storing it on the board at all. Your GPIO would control the boot pins to select the boot mode.

If you want to do it code, then you will have to either

1) Create a mini-bootloader that will load either the proprietary loader or user application depending on the GPIO. This code will have to parse the AIS commands.

2) The ROM bootloader always loads your proprietary loader first. The proprietary loader then decides to load the user application depending on the GPIO. Your proprietary loader will need code to parse AIS commands.

Some AIS code is available from a number of places:

1) As part of the flash programming utilities here http://sourceforge.net/projects/dvflashutils/ or here http://dvflashutils.sourceforge.net/. The code is rather complicated C#.

2) In the AISGEN install directory, there should be a C# file called AIS_Util.cs. It is not a stand-alone file. It appears to be an earlier verion of a file in the dvflashutils.

3) A Python port by Eliot Blenner Hassett
http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/119062.aspx
Eloit points out and fixes bugs in the dvflashutils implementation.

4) As a u-boot tools. See source tools/aisimage.* at the u-boot git.denx.de.

Or you could use your own image format instead of AIS. That will require your own tool to convert a ".out" to ".bin"

I know I can write an AIS parser or port it from C#. I was trying to save this effort, and have a more elegant solution which uses TI boot rom parser.

I came out with a new Idea:

Well , again both of the software pieces are AIS.

What happens if the 1^st software will check if it has to jump to the 2^nd software? If it does , it will set the highest emif address pinmux with 1 as a GPIO and then perform reset.

The 2^nd software would be programmed on the 2^nd half of the flash so by applying 1 to the highest address , 0x0 address would be the first address of the 2^nd half of the flash.

The only question left is what happens to the pinmux registers while applying SW reset.

What do you say ?

I've never tried SW invoked reset (POR or soft) on a C6748. The TRM is not clear on what happens to the GPIO and PINMUX registers during a soft reset. Section 19.2.8.1, Software Reset Considerations, implies that GPIOs get default states. The PINMUX doc does not say. Your proposal sounds likes it can be tested on EVM or LCDK. Give a try to see what happens on soft reset.