[OMAPL138] hex470 boot table format

I have kind of reverse engineered the format by looking at the generated bin file. I use -boot option with hex470 so that all initialized sections are boot sections.

I think the format is as follows

20 bytes - undefined??

4 byte - entry point address ( in a 2 byte format with most significant 2 bytes followed by least signficant 2 bytes)

2 bytes  - size of section in multiples of 2 bytes i.e. this value*2 gives the total length of section in bytes

4 bytes - address of the desitination ( in a 2 byte format with most significant 2 bytes followed by least signficant 2 bytes)

n bytes -  section data

I still dont see the definition of this boot table in anydocumentation, can someone confirm the above format.

Thanks

Angelo

The hex470 tool does not officially support any boot format. The option is hidden for the tool and is not documented in the latest ARM compiler documentation. The format you describe above is an undocumented format that was added in the past. We make no guarantees to support this format in the future, and it may not be the same in older releases of the compiler.

This is a bug in hex470 tool that you were able to generate this boot table. The documentation should also be updated to remove any mention of boot tables

Why are you trying to generate a boot table using the hex470 tool?

I am using the OMAPL138 processor. I am not using Linux. For the DSP core code I use the -boot option and the hex6x to create the binary image file from COFF output. I would like to do something similar for the ARM core code. If I should not be using the hex470 tool what tool do I use to convert the ARM .out file to a binary image file that can be flashed.

Please advise.

I am not familiar with the details of how to flash a program on the OMAPL138, so I can't answer if the hex470 tool is the right tool for the job. I was interested in why you are using the -boot option.

Here is a link to a wiki article about flashing the device. If this is not helpful we probably should move your post over to the OMAP forums to see if they have any ideas.

http://wiki.davincidsp.com/index.php/Serial_Boot_and_Flash_Loading_Utility_for_OMAP-L138

I know how to flash the part. I already have everything flashed and working. Just tell me what the alternative to hex470 is? I am using that currently and I have the code flashed on to the SPI flash. No problems there. I think I explained why I am using the hex470 tool. It creates a binary image from the .out file. And when creating the binary image you need to use -bott option to know where the destination addresses and sizes are. My flash program takes care of that. I have evrythign working.

My concern is if I am using an undocumented featuire of hex470 what is my alternative?

I'm no OMAP expert.  But I have never heard of anyone using OMAPL138 without running Linux on the ARM.  While I don't know, I just want to point out the possibility that you have stumbled into a unsupported combination.  I'll move this entire thread to the OMAP Application Processors forum.

Thanks and regards,

-George

People are using FreeRTOS (on the ARM9).  I built (with CCS3.3) and ran the following distribution on my OMAP-L137 Starter Kit a while ago:

http://e2e.ti.com/support/arm174_microprocessors/omap_applications_processors/f/42/p/29869/103825.aspx#103825

I do remember proving that it also worked on the OMAP-L138 Exp Kit (at some point) but did not do much with it.

A working example might help with some of the above tool chain and ARM9 issues. 

To gene

Angelo Joseph said:

I know how to flash the part. I already have everything flashed and working. Just tell me what the alternative to hex470 is? I am using that currently and I have the code flashed on to the SPI flash. No problems there. I think I explained why I am using the hex470 tool. It creates a binary image from the .out file. And when creating the binary image you need to use -bott option to know where the destination addresses and sizes are. My flash program takes care of that. I have evrythign working.

My concern is if I am using an undocumented featuire of hex470 what is my alternative?

To generate a boot image you should reference the boot loader app note (and associated tools) for the part you are using.  For the OMAP-L138 part, see the following:

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=sprab41b

You should not be using the hex470 tool to create a binary from the .out file, as the boot image format (called AIS) is more complicated than a simple boot table.

Regards, Daniel

I think my question is not clear to you. I have a boot loader which is in the AIS format that I generated using the AISGEN tool. That is fine. It works.

I have two other application loads one for the DSP core and one for the ARM core. These also need to be flashed. I am talking about these loads not the boot loader. For these flash loads I used hex6x to convert the DSP .out file to a binary file using -b and -boot option on hex6x. I use hex470 to convert my ARM application's .out file to a binary file using the -b and -boot option.  I am talking about this -boot option. These should create a binary image with information on the initialized sections so that I can easily use my bootloader to copy the sections from flash to RAM. I am using TI compilers for comiling and building both my DSP and ARM applications.

As I have said I have evrything working. But the binary image file created by hex470 I figured out the format by reverse engineering the generated binary image file.

So I was looking for that documentation.

Hope you can now answer my question.

I understand now that you are using a secondary bootloader that relies on the boot table format produced by the hex tool.  As was posted above, the boot option does not appear to be supported for the hex470 tool.  You could try using the hex6x tool on the ARM .out file.  That may work if the hex6x tool does not do a check for the architecture type. If that doesn't work, you may be out of luck, or you can risk using the unsupported feature of the hex470 tool.  Maybe someone who has more internal knowledge of the codegen tools can comment on the best course of action

Regards, Daniel

Thanks for the response. Yes you are correct in your assessment of how I am using the tool. I tried hex6x on the ARM .out file. hex6x outputs an error message stating that the architecture is incompatible. Hope someone can provide me the info on hex470. Is there any other alternative?

Unfortunately, we codegen tools folks are not aware of any alternative.

-George

Could you at least confirm that my assessment of the format output by hex470 is correct? Just the first 20 bytes seem to be undefined but I have everything without using those bytes.

Angelo,

This may not be a particular desirable alternative, but you can use the AIS tools to generate an AIS file for each of your .out files.  Then you can modify your secondary loader to interpret those AIS files.  They should just consist of a starting magic number, and a collection of section load commands, which contain the section load address, section size, and section data.  So that format would actually contain all the same info the boot table format would. That tool supports both ARM and DSP COFF files.

Regards, Daniel

Actually barring any other alternative I think I will use the option that you suggested. At least it guarantees that I am using a format that is well documented. Thanks for the idea.

Angelo,

Have you looked at using linker generated copy tables? I'm not sure if this solves your problem or not, but it is worth a look. This feature is designed to allow you to copy code from one location to another in memory. You can find the documentation in section 7.15 of the Assembly Language Tools Guide. The link is below.

http://focus.ti.com/general/docs/litabsmultiplefilelist.tsp?literatureNumber=spnu118h

Those I would need to do as part of C/C++ initialization by processing cinit and pinit. My issue was more to deal with the secondary boot loader. As per David Allred's suggestion I updated my secondary boot loader to process the AIS script files. So now I use AISgen to convert the DSP and ARM COFF files to a bin file and I flash this bin file. This solves my problem and it also allows us to combine both the COFF files (DSP and ARM) into one bin file which is nice as well. So I dont need to use hex6c or hex470 now. I use AISGEN to create binary images of both my primary boot loader and my application code files.

Thanks for all the help.

Angelo,

FYI, we've added an enhancement request to get this feature officially supported in the codegen tools.  SDSCM00038229

Best regards,
Brad