Suggested improvement in linker for creating an application executing from flash (with a header)

Showing results for 
Show  only  | Search instead for 
Did you mean: 

Suggested improvement in linker for creating an application executing from flash (with a header)

Contributor II

We have a set of boards which each run a unique application.
They are loaded by a bootloader which needs to validate the application using a 256 byte header.

The header contains a 64 bit CRC with a proprietary algorithm 

We would like to have a common linker command file, which can be customized by
including an application specific header containing a section.

  • We need a way to include a linker command file
  • It should be possible to specify which directories which contain such included files.

The linker supports adding constant data with the BYTE, SHORT, LONG directives.

  • We need 64 bit integers in the same way. Easy to emulate with two LONG, but not so clean
    Also does not work when you supply a symbol.
  • You want to be able to supply a block of ASCII data.with a length
    ASCII("My App\n", 16)
    ASCIZ("My App", 32);

It is difficult to maintain MEMORY declarations since you have to compute the length.

  • The memory directives should support full expressions
  • It would be good with an "AFTER function with optional alignment.


    ROM_start          = 0x8000;
    HEADER_length = 0x100;
    FLASH_end       = 0x100000;

    MEMORY : {

          header :          org = ROM_start,                                   len = HEADER_length
          app_vectors : org = AFTER(header,0x4),                     len  = VECTOR_length
          flash :             org = AFTER(app_vectors,0x100),        len  = FLASH_end - ADDR(flash)


Since we need to compute CRC, it would be good with a way to do that in a linker.

  • CRC(begin, end, location, size, polynom);
  • CRC_ADD(begin, end, location);    Allow computation of CRC on multiple segments.
  • An alternative to this is to have an application which can read an ELF file 
    and insert a CRC and update the ELF file..


We have code space problems. The "_rom_copy_info" table contains entries for ALL segments.
Most of these are NOPs
They have the same source and destination so the "__start" routine will skip the copy.

  • _rom_copy_info should not contain 'dud' entries
  • The _rom_copy_info table should be listed in the map file.


The ARM linker contains the "AT" directive allowing the "data" segment to be stored in ROM
and copied to RAM.
I have not found anyway to populate the _rom_copy_info with an entry that actually
does a copy.
If there is a way, it is way to complex.
You need a way to easily specify  that a segment is linked to a certain location,
but is placed in another location, with an entry in teh _com_copy_info table.

Tags (1)
0 Kudos
2 Replies

NXP TechSupport
NXP TechSupport

What processor are your using?

Which version CodeWarrior are you using now?

0 Kudos

Contributor II


CodeWarrior 11.1

0 Kudos