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)
>
>

1

> OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")

2

> OUTPUT_ARCH(arm)

3

> ENTRY(exception_vectors)

4

> SECTIONS

5

> {

6

>          . = TEXT_BASE;

7

> 

8

>          PRE_IMAGE

9

> 

10

>          . = ALIGN(4);

11

>          .text      :

12

>          {

13

>                  _stext = .;

14

>                  _text = .;

15

>                  *(.text_entry*)

16

> ...

17

>

>
> With the code for reset handler in .text_entry section:
>
>

1

> void __naked __section(.text_entry) exception_vectors(void)

2

> {

3

>          __asm__ __volatile__ (

4

>                  "b reset\n"                             /* reset */

5

> ...

6

>

>
> 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.