EmbDev.net

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


Author: Carlo (Guest)
Posted on:

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 
address 0x0000000?
I have a snippet of a linker script as following (taken from barebox 
bootloader sources)
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 Thomas (mthomas) (Moderator)
Posted on:

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
> address 0x0000000?

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
> bootloader sources)
>
>
> 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 
start-address or an initial remapping. You can not change the adresse 
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.

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.