Booting using tiobj2bin for the ARM for the OMAP-L138...

Mike,

This questions seems to be code-gen focused, so I went ahead and moved this thread over to the Compiler forum in hopes that it would get a faster response there.

Dave

Your problem is similar to the one discussed in this thread.  

It likely your .bin file is so large because of a combination of holes and uninitialized sections.  Either of these are zero filled in the .bin file.  The technique to avoid them is to put the uninitialized sections either at the start or end of memory, then have those uninitialized sections ignored when creating the .bin.  You'll see the details in that forum thread.  Since tiobj2bin has no way to exclude sections, you use arm-elf-objcopy, from ARM GNU toolset, instead.  

In that forum thread discussion, the end user has a simple link command file that is easily changed.  Such is not the case with your system.  Unfortunately, I don't know the details of how you change your build to put the uninitialized sections at the start or end of memory.  I'll ask for others to comment on that.

Thanks and regards,

-George

After reading the threads I am thinking it has something to do with the vector table that is at the end of memory.  The size almost works out between  0xFFFFFFFF - 0xC8000000 =  896 Meg.

I told the linker that the .vecs was NOLOAD, but I dont think I can tell the .vectorTable that?  How does the DSP do that on the C6000?  That side seems to work fine.

Adding the following to the SYSBIOS config file didnt have any effect on the binary file size:

Program.sectMap[".vecs"] = new Program.SectionSpec();

Program.sectMap[".vecs"].loadSegment = "IRAM";

Program.sectMap[".vecs"].type = "NOLOAD";

Program.sectMap[".vectorTable"] = new Program.SectionSpec();

Program.sectMap[".vectorTable"].loadSegment = "IRAM";

Program.sectMap[".vectorTable"].type = "NOLOAD";

Mike,
which workarounds from the linked threads have you tried? What happens if you try setting Hwi.vectorTableAddress=0?

I tried 1 and 3.  That one is the one I didnt know if it would work for the OMAP/ARM...

I will give it a shot and see what happens...

Hwi.vectorTableAddress=0;

Gives the error "ti.sysbios.hal.Hwi: no element named 'vectorTableAddress'.

I seareched the CDOCs in the HWI section for vector and didnt find anything.  A quick scan also revieled nothing about setting the vector Table.

We are using SYSBIOS 6 - 6.34.2.18

On both the ARM and DSP of the OMAP-L138

Hi Mike --

The "hal/Hwi" module does not let you reset the vectorTableAddress.  The "hal/Hwi" is a generic Hwi module that provides APIs that will work on all devices.  For family-specific Hwi support, you need to use "ti/sysbios/family/arm/da830/Hwi" module which does include the "vectorTableAddress" config parameter. 

Unfortunately, I don't think this is going to be much help for you.  On the OMAPL138/Arm9, the traps and reset are hard-wired to fetch from 0xffff0000.  You can remap the other vectors to another address, but the reset vector will always be placed at 0xffff0000.  So, you will always have that hole and probably still have this huge binary file problem.

I am not familiar with the tool that is causing this huge hole and I'm not sure what the next step is.

-Karl-

In this case it appears a large hole in the memory map, between initialized sections, is unavoidable.  Thus, I have to question whether use of this .bin file format is correct for this application.

The utility tiobj2bin.bat comes from the cg_xml package.  In the readme of that package is the following ...

How else do you load the ARM using SYSBIOS?  We dont want to use Linux on the ARM?

I suppsoe we can use an ELF loader and just feed it the .out striped of symbols?

Mike Geppert said:

How else do you load the ARM using SYSBIOS?

Unfortunately, we who watch this forum have no expertise in system startup questions like that.  This thread looks promising.  If you can't find your answer there, you can either ask me to move this thread into that forum, or start a new thread in that forum, whichever is easier.

Thanks and regards,

-George

Not sure the Hardware guys are the right people to ask about loading the image.

The thread you gave was pretty good.  The closest thing that I saw that would work for us was U-BOOT.

Where do I go to find out about the ELF format that is used for the ARM?  It looks like the Symbol tables are not coming out correctly from the ARM-ELF web pages I found.

Does TI have any source code available for the U-BOOT that I can snag their ELF loader?

Mike Geppert said:

Where do I go to find out about the ELF format that is used for the ARM?

This wiki article has the basics on TI object file formats, including ELF.  

The hardware guys are your best choice for U-BOOT questions.  I think starting a new thread would work best.  But, if you would like, I'll move this thread over to that OMAP-L138 forum.

Thanks and regards,

-George

I agree that getting help from the h/w guys on the OMAPL138 forum might be next.   I'll foward this link to someone in that team to have a look.

BTW, I did a quick experiment and added the following to my .cfg file to give the ".vecs" section a separate load and run address.  I believe that your binary file will be much smaller if you add the following to your .cfg file.   The trick will be to copy the data from 0xc30000000 to 0xffff0000 since the Arm expects the .vecs section to reside at 0xffff0000.    If you can load the big image, and then make a smaller image with the 0x40 bytes that are at 0xc3000000 to 0xffff0000 you should be OK.  This is probably not the correct approach.  Someone in the h/w team should hopefully be able to help.

Program.sectMap[".vecs"] = new Program.SectionSpec();
Program.sectMap[".vecs"].loadAddress = 0xc3000000;
Program.sectMap[".vecs"].runAddress =  0xffff0000;

var ti_sysbios_family_arm_da830_Hwi = xdc.useModule('ti.sysbios.family.arm.da830.Hwi');
ti_sysbios_family_arm_da830_Hwi.vectorTableAddress = 0xc3000040;

Rahul,

Thanks for the respons!  I did look at the stuff and have some questions.  But first let me tell you of some constraints I have placed on me.

1) We have a sub-contractor that is actually doing the HW and some of the software.  This is a common CPU card that is going  in different systems and I am only responsable for one of them.  This contractor is supply "Common" code amangst the different systems.  Because of this they are actually doing the booting to a point then they copy our "Binary" into ram and jump to the starting location.  They happen to be running on the DSP side when this jump occurse.

The origonal plan was to bind the 2 binaries together, have the DSP split them and then jump into their appropriate run locations.  Then each processor would look at a compressed image and uncompress the final binary into the run locations.  This works well on the DSP but we were ending up with a 900 Meg Binary on the ARM side.

So while trying to get an answer to this - I snagged some ELF code and started to work on an ELF loader for the ARM.  If it works I would do the same on the DSP side.

I can load the code but can not run to main.

Because of this I dont believe the AIS scripting will work for us.  I was under the impression that UBOOT used ELF, my bad for not understanding that part.

The "out2rprc" looks promissing.  May I ask why ELF wasnt used?  Mainly want to know if I am chassing something that just cant work or if there are other gotchas?

I have overcome the ELF file not being word aligned all the way through - I commented out all the relocation calls because the file is an executable.  But like I said I dont run...

Thansk so much for your response...

Mike,

The custom bootloader will have to be in AIS format as it will be loaded by the ROM  in dveice memory. This code then will load in your application which doesn`t have to contain an AIS parser to load the application image.  I am assuming the custom bootloader is where you are implementing the ELF/COFF binary loader to load your application.

I am not sure why uboot doesn`t use ELF, but Uboot is an open source primary boot loaders supported on various architectures so my guess would be that they used a binary format supported by all cores that use uboot.. If you are looking for a sample COFF loader implementation it is provided in the ProcMgr module in SYSLINK package as I mentioned in my earlier post.

How are you passing control from the custom bootloader to your main? Did you check the bl_main.c function in the Starterware bootloader to see how it is passing control to the application.

Regards,

Rahul

The Contractor has a Boot loader that uses the AIS.  Once they are done doing what they are responsable for, they memcpu our binary into RAM and then jump to a hardcoded start address..  We then do a simple memcpy of our compressed DSP image, and then memcpy our ARM ELF image to appropriate locations in memory. 

We force our _c_int00 to a know address (0xC0000000 for the DSP and 0xC8000000 for the ARM) and simple jump to the location.

I have done memory dumps between our ARM.out file loaded with the emulator (and not allowed to run) and the ARM.strip loaded by the ELF loader and seems the only differences are in the .bss sections?  This is supposed to be uninitalized memory?  The ELF Loader zeroed it out, but large sections of the Emulator loaded version has stuff in it.  Is that expected?  The Emulator loaded version runs to main, but mine gets lost.  I was thinking maybe I didnt have enough stack, but the stack is the same for both versions.

Thanks so much for you time...