This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

What is AIS (Application Image Script)?

Anonymous
Anonymous

Hi,

 

I would like to ask a question on AIS booting script.

 

For C/C++ main() to execute, c_int00() needs to be run first to prepare its global and static variables. Therefore, it seems to me that the role of bootloader is to load all the compiled and linked instructions from external memory into RAM.

 

Bootloader needs the following information:

1.    On which device does the code and data reside? By setting voltages of pins this can be informed to the CPU.

2.    The starting location of code/data is should extract from the external device: Bootloader by default loads 1K byte starting at the default address on the external device.

 

But here remains an unsolved problem: If the code is longer than 1K byte, say, 1KK = 1M, what can we do? If this is the case, the 1K code it loads from external memory cannot be the actual code itself, but should be sort of a “carrier” that would move the actual 1M code from external memory into RAM.

 

How should this “carrier” be written? It can of course be written in assembly code, which would be essentially a loop that would load the 1M code into RAM.

 

 

Question 1:

Can the “carrier” be written in C? C require its run-time environment be set first, so if the “carrier” is written in C, then its associated c_int00() needs also be load by the bootloader at first. This means both the “carrier” and its c_int00() needs to be placed at the default on the external memory for bootloader to retrieve, and their total size should not exceed than 1K byte.

 

Is this correct?

 

But what about error-detecting? If one writes completely in assembly or C by himself, then he should also write the necessary error-detecting routine using such as the standard CRC algorithm. Probably not everyone is skilled in that.

 

I guess, this is where AIS comes into play. AIS has its own 32-bit opcode which are different from opcode of the CPU instruction set, and should be only recognizable by the bootloader. So essentially AIS encodes the most common operations during booting, including GET, SET memory-mapped address (PLL, registers, etc.), CRC check and so on.

 

So essentially it is just another layer of encapsulation, just like GEL used by the emulator, and its commands would be translated into CPU instructions by the bootloader, which would then be executed and perform all the necessary loading + setting + error-detecting operation.  At last, when JUMP_CLOSE is encountered, it jumps to the starting address of cint_00() of the 1M (see above) actual code.

 

I am new to booting and AIS, and eagerly expecting comments on the above points.

 

    

 

Zheng

  • Which TI part are you using?

    Regards, Srirami.

  • Anonymous
    0 Anonymous in reply to srirami

    Srirami,

    I am using DM6437.

     

    Zheng

  • Anonymous
    0 Anonymous in reply to srirami

    Srirami,

    I have posted this question under C6000 Multicore forum.

     

    Zheng

  • Zheng Zhao said:
    For C/C++ main() to execute, c_int00() needs to be run first to prepare its global and static variables. Therefore, it seems to me that the role of bootloader is to load all the compiled and linked instructions from external memory into RAM.

    Correct.

    Zheng Zhao said:

    The starting location of code/data is should extract from the external device: Bootloader by default loads 1K byte starting at the default address on the external device.

    Older legacy devices did exactly as you describe, and in these cases there was no actual boot loader (no ROM code) in the device.  There was just some reset hardware that could copy data from the start of the Ansynchronous memory interface.

    Zheng Zhao said:
    But here remains an unsolved problem: If the code is longer than 1K byte, say, 1KK = 1M, what can we do? If this is the case, the 1K code it loads from external memory cannot be the actual code itself, but should be sort of a “carrier” that would move the actual 1M code from external memory into RAM.
    How should this “carrier” be written? It can of course be written in assembly code, which would be essentially a loop that would load the 1M code into RAM.

    The 1K of code that was copied would typically be a bootloader (what you called a carrier).  It would have to be written to either load another more complicated bootloader, or the main application itself.  It is easiest to look at a bootloader as just an application written to load and start running another application.

    Zheng Zhao said:

    Question 1:

    Can the “carrier” be written in C? C require its run-time environment be set first, so if the “carrier” is written in C, then its associated c_int00() needs also be load by the bootloader at first. This means both the “carrier” and its c_int00() needs to be placed at the default on the external memory for bootloader to retrieve, and their total size should not exceed than 1K byte.
     
    Is this correct?

    The bootloader (which is just an application)that is written can be in C or assembly, just like any other application.  If written in C, yes there will be components of the RTS Library (including the _c_int00 entry point) that must be part of the application to get it to build and run.

    Zheng Zhao said:
    But what about error-detecting? If one writes completely in assembly or C by himself, then he should also write the necessary error-detecting routine using such as the standard CRC algorithm. Probably not everyone is skilled in that.

    A boot loader can be written with error detection/correction, if one were so inclined.

    Zheng Zhao said:
    I guess, this is where AIS comes into play. AIS has its own 32-bit opcode which are different from opcode of the CPU instruction set, and should be only recognizable by the bootloader. So essentially AIS encodes the most common operations during booting, including GET, SET memory-mapped address (PLL, registers, etc.), CRC check and so on.
    So essentially it is just another layer of encapsulation, just like GEL used by the emulator, and its commands would be translated into CPU instructions by the bootloader, which would then be executed and perform all the necessary loading + setting + error-detecting operation.  At last, when JUMP_CLOSE is encountered, it jumps to the starting address of cint_00() of the 1M (see above) actual code.

    On more recent devices, TI has included an on-chip ROM with a fixed bootloader application (the ROM boot loader, or RBL).  The form of the boot loader varies across different TI devices, but its job is what you would expect.  It starts running after the device leaves the reset state, attempts to detect where it needs to boot code/data from (usually based on pin values), then goes to that source and loads/parses a boot image.  ROM boot loaders that use the AIS format for boot images, are more featureful than most ROMs, as they include the ability to recieve AIS commands from the boot image itself, to do specific things, rather than simply loading a binary blob of data to some memory location (though obviously the AIS Section Load commands give us this required functionality).  So, yes, a boot image that is in AIS format can provide information to the ROM boot loader so that it can do many things that might typically be done by a GEL file during application development under CCS (such as PLL and clock settings, external memory configuration, etc.)

    For any particular device, you should consult the datasheet or any applicable boot loader app notes for more details on booting.  Not all TI devices use the AIS format.

    Regards, Daniel

  • Anonymous
    0 Anonymous in reply to Daniel Allred

    Daniel,

     

    Many thanks for the detailed explanation, they resolved many of my questions.

     

     

    I read from DM643x Flashing Instructions.pdf - TI E2E Community that HexAIS is required to convert genAIS result into HEX format, which can then be loaded.

     

    However, I checked the result of genAIS.pl, and it was already in binary format. Isn’t binary format the same as HEX format? Why does it still require HexAIS to convert?

     

     

     

    Zheng

  • Binary format and hex format are not the same.  Binary format is just the raw data that you intend to flash.  Hex format is that raw data encoded as ASCII text, including addresses where the data should be loaded and line by line checksums.  The flashburn tool uses the hex format.

    Regards, Daniel

  • Anonymous
    0 Anonymous in reply to Daniel Allred

    Daniel,

    I eventually found it at http://en.wikipedia.org/wiki/Intel_HEX#Format. Thanks for the clarification.

     

    Zheng