• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 53 subscribers
  • Views 1685 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Exclude sections in .bin file

Andy8086940
Intellectual 620 points

Is there a way to exclude specific sections when generating a .bin file from a .out file?  I can use the tiobj2bin to generate the bin file with all sections included just fine.  I tried adding --exclude "fltext" to the %hexcmd% argument list in tiobj2bin.bat to try to exclude the fltext section, but it still includes it.  I have played around with it a bit and it looks like the --exclude "fltext" switch only seems to work for me when I'm not using the --image switch.  But I need an image, just an image without the fltext section.

My map is something like this.  The fltext section is not valid memory and is only used as an indicator that it's that particular section during bootloading.  I can create the proper binary by declaring the fltext section as type = NOLOAD and running the default tiobj2bin command, but I don't want to have to generate two separate out files just to get a bin file with fltext removed.

0x00000000 .text
0x20000000 .bss
0x70000000 .fltext 

Any suggestions?

Thanks,

Andy

  • 0
    TI__Guru**** 244930 points

    The fltext section should get excluded.  But, when you are using the -image switch, the entire range of memory, as indicated by the ROMS directive in the auto-generated hex utility command file, is output to the binary file.  For any memory range that does not correspond to a section in the .out file, a fill value of 0 is used.  With regard to the fltext section, the corresponding memory range should be filled with 0.  Are you seeing something else?

    Thanks and regards,

    -George

  • 0 in reply to George Mock
    Intellectual 620 points

    George,

    My ROMS directive does include all memory (all_mem: o = 0x0, l = 0x700003dc) and the fltext section is filled with 0 in the final binary.  I suppose you could consider the fltext section excluded in that case, but that's not really what I want.  This still generates a 1.8GB bin file (mostly filled with 0).

    I can generate the 256 KB bin file that I'm looking for by not linking in the fltext section in the first place, but my goal is to generate these 3 files using only one linker command script:
    app.out with or without fltext
    app.srec with fltext
    app.bin without fltext

    I didn't see a way to generate the srec file without linking in fltext, so I linked it in.  But I want to also be able to generate app.bin as if app.out did NOT have fltext linked in.

    I can see that the ROMS directive is generated by mkhex4bin, but there don't seem to be any command line options available that would let me exclude the fltext section from the ROMS range.  I think being able to do that would solve my problem.

    Thanks for your help.

  • 0 in reply to Andy8086940
    TI__Guru**** 244930 points

    I see an issue you may not have considered.  If the flext section is both skipped and not filled in the .bin file, then you have a hole in the output.  How should such a hole be represented?  How will the consumer of app.bin handle such a hole?  

    Thanks and regards,

    -George 

  • 0 in reply to George Mock
    Intellectual 620 points

    The only real ROM sections are between 0x00000 and 0x3FFFF, with fltext being the only thing placed beyond 0x3FFFF.  If fltext is removed, it should be possible to shring the image to only what's left.

    It turns out I can get the desired image using the gcc arm-elf-objcopy as follows:

    arm-elf-objcopy.exe -O binary -R .fltext app.out app.bin

    If the TI toolchain can do the same, that would be great.

  • 0 in reply to Andy8086940
    TI__Guru**** 244930 points

    Andy8086940 said:
    The only real ROM sections are between 0x00000 and 0x3FFFF, with fltext being the only thing placed beyond 0x3FFFF.  If fltext is removed, it should be possible to shring the image to only what's left.

    Ah, I didn't think of that.  Even though you are skipping a section, you don't end up with a hole in the output.  That's because the skipped section is, in address order, at the end.

    Andy8086940 said:
     It turns out I can get the desired image using the gcc arm-elf-objcopy as follows:

    arm-elf-objcopy.exe -O binary -R .fltext app.out app.bin

    Well, one of the advantages of ELF object file format is that it enables use of non-TI tools just like this.

    Andy8086940 said:
    If the TI toolchain can do the same, that would be great.

    I'm pretty sure I could get hex470 to do the same thing, but not as clean as that.  I think you should stick with the GCC solution.

    Thanks and regards,

    -George