Generated .bin file is too large

You have some large hole in your memory map.  The format of the .bin file produced by tiobj2bin has no mechanism by which it can represent such a hole in memory.  It fills the hole with 0, no matter how big it is.  

You have two choices.  One, find some other file format to use for programming the flash.  Two, change your memory configuration so there is no hole.

Thanks and regards,

-George

Thanks George!

I can't change the memory configuration. So the only choice is to use another format. Can you suguest what other formats I can use?

Chunjian Li said:

Can you suguest what other formats I can use?

Sorry, but no.  Programming the flash is beyond my expertise.  I suggest you start a new thread in one of the forums for the device you are using. Or, if you prefer, let me know which device you use and I'll move this thread into the related forum.

Thanks and regards,

-George

I am using EVMC6678. I have checked the usage of memory (cfg file). It seems like a heap is takeing a big chunk:

heapMemParams.size = 0x8000000;

 But even though I have reduced heap size to a very small value, the size of the .bin file only shrinks  marginally (from 2.2GB to 2GB). Is there another place I should look at?

Or, do you mean by 'holes', the unassigned memory blocks between those used? Does that mean the .bin file contains the whole memory dump even though only a small part of the DDR3 is actually in use?

Hi,

The tiobj2bin,bat utility should invoke ofd hex6x.exe utility with the "-image" option (see TMS320C6000 Assembly Language Tools §10 and §11).

To investigate, could be usefull to look at the ofd output and the hex6x command files generated by the tiobj2bin, but these files are normally delete after completition of tiobj2bin.

You could edit the tiobj2bin.bat, remove the command delete of temp files, execute and look inside them.

Note that tiobj2bin commands ofd6.exe to generate and XML output. For humans, it is better to generate a plain text description (you can edit the .bat and adding a second invoktion of ofd ("%ofdcmd% ....") to generate it).

Chunjian Li said:

Or, do you mean by 'holes', the unassigned memory blocks between those used? Does that mean the .bin file contains the whole memory dump even though only a small part of the DDR3 is actually in use?

A hole can be an uninitialized section, such as the heap.  A possible solution is to change the memory configuration so all the initialized sections are next to each other in memory.

Thanks and regards,

-George

I have managed to reduce the .bin file size to 200MB, but the NAND writer still complains the file is too large to fit into the device. Isn't here 512MB on the NAND?

Is there a way to load the .out file instead? I have seen posts saying that one can just rename the .out file to .bin. But it doesn't work for me. Anyone heard about the dynamic section loading supported IBL?

I'm sorry, but we who watch this forum can't help you with these questions.  I recommend you start a new thread in the Keystone Multicore Forum.  Or, if you prefer, I can move this thread into that forum.

Thanks and regards,

-George

Yes, please help me to move.

Hi David,

I am using the c6678EVM, and there is 128 MB NAND Flash according to the feature page. Can I trust that?

My question is still that, the .out file is only 18k and is way more efficient than the .bin file, why isn't there a way to burn this file into NAND and load it from there?

Regards,

Chunjian

Ok, I'll try to reformulate the question as follows:

Is it posible to make a system with a minimal size .bin file that is smaller than 128M (with only very basic BIOS functions)? I have tried to make a system with no custom code other than BIOS_start(), and the .bin file is already larger than 188M. I tried to remove HWI,SWI,TSK from the .cfg file, but that doesn't change the size of the .bin file.

Any idea on how to tailor BIOS for minimal code size?

BR

Chunjian

Hi,

I don't think the dimension of your bin depends on the size of the code. You can see that on your .out file, that is small.

The problem is relatated on the memory layout. I don't know why, but the bin converter thinks you need a big memory to arrange your image.

Since the bin image have no info about the section and their address, it have to fill any gap with dummy data. I thinks one have mapped at least two code (or const) sections very far in memory, so the binary inage became laerge.

For instance, supose that:

• there is one text section in MCSM (0x0C000000)
• there is another text section (or const section or similar) in DDR (0x80000000)

The conversion in binary image have to range from 0x0C000000 to 0x80000000 + sizeof of DDR section, generating a very big binary image.

Have you generated the executable with the ROM autoinitialization option?

Could you post the output of ofd6x, applyed on the elf file *.out) and the linker map?

Hi Alberto,

I tried both linker using ROM autoinitialization option and that with RAM, no difference.

I post the linker map here. But I am not sure what you mean by output of ofd6x?

0458.fap_32k_mobile.map.txt

Greate! That solves my problem! Thanks Alberto.

One following question, can one use both the .cmd file and the .cfg file to specify the memory allocation? 'cause it seems like the .cmd is not used as long as the .cfg exits.

BR

Chunjian

Chunjian Li said:

One following question, can one use both the .cmd file and the .cfg file to specify the memory allocation? 'cause it seems like the .cmd is not used as long as the .cfg exits.

I don't know, I don't use SYS/BIOS.

Maybe it is better to post the question on the SYS/BIOS forum or open a new discussion here so to make it more visible.