# Forum: ARM programming with GCC/GNU tools reset code and ENTRY in linker script

 Author: Carlo (Guest) Posted on: 2011-06-10 09:44

Rate this post
 0 ▲ useful ▼ not useful
Hi,
Why do we specify in linker scripts the entry point using ENTRY(symbol)
when for example the ARM architecture always starts its reset code at
I have a snippet of a linker script as following (taken from barebox

 OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") OUTPUT_ARCH(arm) ENTRY(exception_vectors) SECTIONS { . = TEXT_BASE; PRE_IMAGE . = ALIGN(4); .text : { _stext = .; _text = .; *(.text_entry*) ... 

With the code for reset handler in .text_entry section:

 void __naked __section(.text_entry) exception_vectors(void) { __asm__ __volatile__ ( "b reset\n" /* reset */ ... 

Now, since TEXT_BASE is different from 0x00000000, how can reset be at
location 0x00000000 where it is expected to be? (i.e. if TEXT_BASE is
0x80000000, then reset is at 0x80000000 according to the linker script
whereas the first instruction to be executed by the CPU should be
located at 0x00000000).
Is there memory aliasing in this case or the ENTRY is used for this
purpose?

Thank you,

--
Carlo

 Author: Martin T. (mthomas) (Moderator) Posted on: 2011-06-13 16:26

Rate this post
 0 ▲ useful ▼ not useful
Carlo wrote:
> Hi,
> Why do we specify in linker scripts the entry point using ENTRY(symbol)
> when for example the ARM architecture always starts its reset code at

On reason is to tell the linker where the execution starts. When
garbage-collection is enabled (gc-sections) I have seen that the linker
removed all code since it did not 'see' any used code. The linker does
not 'know' "always 0x0", which is not true anyway for some devices where
the start-adress can be configured by external connection or
non-volatile memory.

> I have a snippet of a linker script as following (taken from barebox
>
>
 > OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") > OUTPUT_ARCH(arm) > ENTRY(exception_vectors) > SECTIONS > { > . = TEXT_BASE; > > PRE_IMAGE > > . = ALIGN(4); > .text : > { > _stext = .; > _text = .; > *(.text_entry*) > ... > 
>
> With the code for reset handler in .text_entry section:
>
>
 > void __naked __section(.text_entry) exception_vectors(void) > { > __asm__ __volatile__ ( > "b reset\n" /* reset */ > ... > 
>
> Now, since TEXT_BASE is different from 0x00000000, how can reset be at
> location 0x00000000 where it is expected to be? (i.e. if TEXT_BASE is
> 0x80000000, then reset is at 0x80000000 according to the linker script
> whereas the first instruction to be executed by the CPU should be
> located at 0x00000000).

If the core should not start at 0x0 you have to look into the devices
manual to see if there are pins which can be used to determine the
where the core start just by modifing the linker-script. More important
than the start-adress is the location of the exceptions vector-table and
the configuration of this location in to the core. Usually the
vector-table is expected to start at address 0x0.

> Is there memory aliasing in this case or the ENTRY is used for this
> purpose?

There is usually some kind of "aliasing". On 'small' controllers
internal FLASH-memory and RAM have different ranges in the address-space
and for most devices one of the ranges can be mapped so it also is seen
by the core as starting from 0x0, usually FLASH-memory is initially
mapped to 0x0. If the initial vector-table is not at this location it
can be copied to RAM and the core can be configured to expect the table
there.

Since the used target is not mentioned its difficult to help with
detailed information.

• $formula (LaTeX syntax)$