• State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 349 subscribers
  • Views 5673 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[A53] Hex file is Huge when generated fromo ELF

AshishK

Hi , 

If I generate the elf file from the Default bootcode and pagetables , I get a very small size but 

after mapping the Stack pointer to SRAM , I am getting a huge HEX file. 

Here is the  loader file  code 

============================================================

MEMORY
{
rom (r) : ORIGIN = 0x00000000, LENGTH = 0x3FFFF
/* pageTable (rw) : ORIGIN = 0x0B000000, LENGTH = 0x3FFF */
heap (rw) : ORIGIN = 0x02001000, LENGTH = 0x1FFF
/* stack(rw) : ORIGIN = 0x0B120000, LENGTH = 0xFFFF */
/* data_mem (rw) : ORIGIN = 0x02020000, LENGTH = 0xFFFF
bss_mem (rw) : ORIGIN = 0x02020000, LENGTH = 0xFFFF */
ram (rw) : ORIGIN = 0x02004000, LENGTH = 0x3FFF
}


SECTIONS
{

/* Code starts with bootcode, then the vector table, then the
* remainder of the code */
.text :
{
*bootcode.o(boot)
*vectors.o(vectors)
/* *(.text) /* remainder of code */
} > rom

.heap : { *stackheap.o(stackheap) } > heap
. = ALIGN(4);

/* Data */
/* __data_start = .; */
.data : AT (_sdata )
{
. = ALIGN(4);
_sdata = .;
*(.data)
*(.data*)
} > ram

MEMORY
{
rom (r) : ORIGIN = 0x00000000, LENGTH = 0x3FFFF
/* pageTable (rw) : ORIGIN = 0x0B000000, LENGTH = 0x3FFF */
heap (rw) : ORIGIN = 0x02001000, LENGTH = 0x1FFF
/* stack(rw) : ORIGIN = 0x0B120000, LENGTH = 0xFFFF */
/* data_mem (rw) : ORIGIN = 0x02020000, LENGTH = 0xFFFF
bss_mem (rw) : ORIGIN = 0x02020000, LENGTH = 0xFFFF */
ram (rw) : ORIGIN = 0x02004000, LENGTH = 0x3FFF
}


SECTIONS
{

/* Code starts with bootcode, then the vector table, then the
* remainder of the code */
.text :
{
*bootcode.o(boot)
*vectors.o(vectors)
/* *(.text) /* remainder of code */
} > rom

.heap : { *stackheap.o(stackheap) } > heap
. = ALIGN(4);

/* Data */
/* __data_start = .; */
.data : AT (_sdata )
{
. = ALIGN(4);
_sdata = .;
*(.data)
*(.data*)
} > ram

============================================================

I dont understand what is the Issue here.

The size of the Hex generated is 79MB. 

Thanks

Aashish 

  • 0

    The HEX file contains all the data. If you have a gap, then it will end up in the HEX file. If you look at it you will likely find a lot of zeroes.

  • 0 in reply to 42Bastian Schick

    Thanks for the info. 

    I see lot many 00000000 in the hex 

    Is there a way I can skip adding all the 00000000  from the hex

  • 0

    It seems that the usage of the AT keyword, as applied to the data section, is erroneous - it sets LMA=VMA (_sdata tracks VMA, but what was intended by AT(_sdata) was to set LMA as /distinct/ from VMA of the corresponding section). 

    Assuming that we agree to copy the sections to their link-addresses (VMA) at runtime, a sample script such as below can be utilized for a simple project. 

    MEMORY
{ 
        rom (rx) : ORIGIN = 0, LENGTH = 32k
        ram (rw) : ORIGIN = 0x02000000, LENGTH = 16k
}

SECTIONS
{
        .text : {
                *(.text)
        } >rom

        .code : {
                _code_load = LOADADDR(.code);
                _code_start = .;
                *(.code)
                _code_end = .;
        } >ram AT>rom
}

    The .code section is adjacent to the .text section, when viewed through their load addresses (LMAs). objcopy should locate them as such in the '-O binary' copy.

    At runtime, the .text section must run a piece of code to copy the .code section (src address == load address == _code_load) to the address where it has been linked (0x02000000).