[U-Boot] How/Where does "_start" get assigned a value ?

[U-Boot] How/Where does "_start" get assigned a value ?

[djoker]

Hi Everyone,

I have a armv7 board and am looking at the "_start" symbol address, using
the following command:
*nm u-boot | grep -w _start*

It returned the following:
*67000020 T _start*

I couldn't help notice that the the _start value is very "close" in vlaue to
the value of CONFIG_SYS_TEXT_BASE defined in my board file:
*#define CONFIG_SYS_TEXT_BASE 0x67000004*

But, I have searched through the source code, but not found where _start
gets assigned a value.. Could someone please help me understand this ?

Thanks,
~vj



--
View this message in context: http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] How/Where does "_start" get assigned a value ?

[Arvid Brodin]

On 2013-10-09 18:07, djoker wrote:
> Hi Everyone,
> 
> I have a armv7 board and am looking at the "_start" symbol address, using
> the following command:
> *nm u-boot | grep -w _start*
> 
> It returned the following:
> *67000020 T _start*
> 
> I couldn't help notice that the the _start value is very "close" in vlaue to
> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
> *#define CONFIG_SYS_TEXT_BASE 0x67000004*
> 
> But, I have searched through the source code, but not found where _start
> gets assigned a value.. Could someone please help me understand this ?

This symbol is declared in arch/<...>/start.S, as the entry point for the
u-boot code, if I understand things correctly.


> 
> Thanks,
> ~vj
> 
> 
> 
> --
> View this message in context: http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
> Sent from the U-Boot mailing list archive at Nabble.com.
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 


-- 
Arvid Brodin | Consultant (Linux)
XDIN AB | Knarrarn?sgatan 7 | SE-164 40 Kista | Sweden | xdin.com

[U-Boot] How/Where does "_start" get assigned a value ?

[Djoker]

On Wed, Oct 9, 2013 at 12:54 PM, Arvid Brodin <arvid.brodin@xdin.com> wrote:
> On 2013-10-09 18:07, djoker wrote:
>> Hi Everyone,
>>
>> I have a armv7 board and am looking at the "_start" symbol address, using
>> the following command:
>> *nm u-boot | grep -w _start*
>>
>> It returned the following:
>> *67000020 T _start*
>>
>> I couldn't help notice that the the _start value is very "close" in vlaue to
>> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
>> *#define CONFIG_SYS_TEXT_BASE 0x67000004*
>>
>> But, I have searched through the source code, but not found where _start
>> gets assigned a value.. Could someone please help me understand this ?
>
> This symbol is declared in arch/<...>/start.S, as the entry point for the
> u-boot code, if I understand things correctly.
>

Arvid, I know that the symbol is declared under that file.
But, how is it getting assigned a value equal to or greater than
CONFIG_SYS_TEXT_BASE ?
Basically, I am seeing a similar issue as below:

u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SYS-TEXT-BASE-td4134.html#none

There really was no conclusion as to why the padding of 0's happened ?



>
>>
>> Thanks,
>> ~vj
>>
>>
>>
>> --
>> View this message in context: http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089.html
>> Sent from the U-Boot mailing list archive at Nabble.com.
>> _______________________________________________
>> U-Boot mailing list
>> U-Boot at lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>
>
> --
> Arvid Brodin | Consultant (Linux)
> XDIN AB | Knarrarn?sgatan 7 | SE-164 40 Kista | Sweden | xdin.com
>

[U-Boot] How/Where does "_start" get assigned a value ?

[Albert ARIBAUD]

Hi Djoker,

On Wed, 9 Oct 2013 16:02:43 -0700, Djoker <thelonejoker@gmail.com>
wrote:

> On Wed, Oct 9, 2013 at 12:54 PM, Arvid Brodin <arvid.brodin@xdin.com> wrote:
> > On 2013-10-09 18:07, djoker wrote:
> >> Hi Everyone,
> >>
> >> I have a armv7 board and am looking at the "_start" symbol address, using
> >> the following command:
> >> *nm u-boot | grep -w _start*
> >>
> >> It returned the following:
> >> *67000020 T _start*
> >>
> >> I couldn't help notice that the the _start value is very "close" in vlaue to
> >> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
> >> *#define CONFIG_SYS_TEXT_BASE 0x67000004*
> >>
> >> But, I have searched through the source code, but not found where _start
> >> gets assigned a value.. Could someone please help me understand this ?
> >
> > This symbol is declared in arch/<...>/start.S, as the entry point for the
> > u-boot code, if I understand things correctly.
> >
> 
> Arvid, I know that the symbol is declared under that file.
> But, how is it getting assigned a value equal to or greater than
> CONFIG_SYS_TEXT_BASE ?
> Basically, I am seeing a similar issue as below:
> 
> u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SYS-TEXT-BASE-td4134.html#none
> 
> There really was no conclusion as to why the padding of 0's happened ?

That's a 2010 issue and it contains hardly enough information to know
what happened, considering the person who asked had modified the source
code to match unusual constraints, and could just as well have caused
the padding by his own changes.

Regarding your question, it is the linker which is responsible for
assigning addresses to symbols, and it does so based on a linker script
(.lds file) and on the object files provided to it. It will align
symbols if instructed to. In most, if not all, ARM cases, _start will
be equal to CONFIG_SYS_TEXT_BASE because the .lds file specifies that
the .text section of start.o be the first section output, and _start is
the first label in that section.

HTH.

Amicalement,
-- 
Albert.

[U-Boot] How/Where does "_start" get assigned a value ?

[djoker]

I am running into the issue as described below:

http://u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SYS-TEXT-BASE-td4134.html#none

But am unable to figure out what the reason could be



--
View this message in context: http://u-boot.10912.n7.nabble.com/How-Where-does-start-get-assigned-a-value-tp165089p165110.html
Sent from the U-Boot mailing list archive at Nabble.com.

[U-Boot] How/Where does "_start" get assigned a value ?

[Gerhard Sittig]

On Wed, Oct 09, 2013 at 09:07 -0700, djoker wrote:
> 
> Hi Everyone,

Why do you "re-send" your request without giving readers time to
respond (first message at 17:00 and second on 09:00 the very next
morning)?

This unnecessarily splits the same subject across several
threads, hinders discussion and prevents easy lookup in archives
(and reduces your score and thus the willingness to help such a
"demanding" person) ...

> I have a armv7 board and am looking at the "_start" symbol address, using
> the following command:
> *nm u-boot | grep -w _start*
> 
> It returned the following:
> *67000020 T _start*
> 
> I couldn't help notice that the the _start value is very "close" in vlaue to
> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
> *#define CONFIG_SYS_TEXT_BASE 0x67000004*

As with any ARM based CPU, I'd expect the "executable" to start
with a vector table, before the actual body of the start()
routine follows.

The "reset vector" only has a few bytes in the vector table, and
should consist of a branch to the actual initialization code.

So I'd rather be baffled if the _start symbol would reside at the
very start of the binary, since it then would clobber all the
vectors.

> But, I have searched through the source code, but not found where _start
> gets assigned a value.. Could someone please help me understand this ?

The linker (sometimes referred to as the loader) is the entity to
assign addresses to symbols.  So check the linker command line
and control files when in doubt.

Optionally tell the compiler to "save temp files", and/or check
whether the resulting *.o files or executables match what you'd
expect from looking at the C/assembly source.


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot] How/Where does "_start" get assigned a value ?

[Djoker]

I am sorry Gerhard, I am newbie to the list.
I will keep in mind the etiquette of the list.
Thanks for the help.

On Thu, Oct 10, 2013 at 8:37 AM, Gerhard Sittig <gsi@denx.de> wrote:
> On Wed, Oct 09, 2013 at 09:07 -0700, djoker wrote:
>>
>> Hi Everyone,
>
> Why do you "re-send" your request without giving readers time to
> respond (first message at 17:00 and second on 09:00 the very next
> morning)?
>
> This unnecessarily splits the same subject across several
> threads, hinders discussion and prevents easy lookup in archives
> (and reduces your score and thus the willingness to help such a
> "demanding" person) ...
>
>> I have a armv7 board and am looking at the "_start" symbol address, using
>> the following command:
>> *nm u-boot | grep -w _start*
>>
>> It returned the following:
>> *67000020 T _start*
>>
>> I couldn't help notice that the the _start value is very "close" in vlaue to
>> the value of CONFIG_SYS_TEXT_BASE defined in my board file:
>> *#define CONFIG_SYS_TEXT_BASE 0x67000004*
>
> As with any ARM based CPU, I'd expect the "executable" to start
> with a vector table, before the actual body of the start()
> routine follows.
>
> The "reset vector" only has a few bytes in the vector table, and
> should consist of a branch to the actual initialization code.
>
> So I'd rather be baffled if the _start symbol would reside at the
> very start of the binary, since it then would clobber all the
> vectors.
>
>> But, I have searched through the source code, but not found where _start
>> gets assigned a value.. Could someone please help me understand this ?
>
> The linker (sometimes referred to as the loader) is the entity to
> assign addresses to symbols.  So check the linker command line
> and control files when in doubt.
>
> Optionally tell the compiler to "save temp files", and/or check
> whether the resulting *.o files or executables match what you'd
> expect from looking at the C/assembly source.
>
>
> virtually yours
> Gerhard Sittig
> --
> DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de

[U-Boot] How/Where does "_start" get assigned a value ?

[Gerhard Sittig]

On Thu, Oct 10, 2013 at 17:37 +0200, Gerhard Sittig wrote:
> 
> On Wed, Oct 09, 2013 at 09:07 -0700, djoker wrote:
> > 
> > I have a armv7 board and am looking at the "_start" symbol address, using
> > the following command:
> > *nm u-boot | grep -w _start*
> > 
> > It returned the following:
> > *67000020 T _start*
> > 
> > I couldn't help notice that the the _start value is very "close" in vlaue to
> > the value of CONFIG_SYS_TEXT_BASE defined in my board file:
> > *#define CONFIG_SYS_TEXT_BASE 0x67000004*

Something else bubbled up in my mind:

Your text base address (ending in ...04) is rather odd, and does
not at all fit the expectation of those ARMv7 CPUs which mainline
U-Boot supports (that is: Cortex-A, i.e. traditional ARM).

Your "armv7 board" isn't by any chance an ARMv7-M variant,
meaning that mainline U-Boot does not support it?  And more
importantly that the vector table "preamble" might get setup in
different ways than what is done for ARMv7-A.  ISTR that on v7-m
the stack top is the first entry, and the reset vector is only
the second entry in the table, and the number and meaning of
vectors may differ from v7-a.

You really should tell us more than "an armv7 board" if you want
to receive more specific help.  And about your code base (version
and origin), as none of the boards in current 'master' has a
reference to a '6700' number (except for leon, which is SPARC).


> As with any ARM based CPU, I'd expect the "executable" to start
> with a vector table, before the actual body of the start()
> routine follows.
> 
> The "reset vector" only has a few bytes in the vector table, and
> should consist of a branch to the actual initialization code.
> 
> So I'd rather be baffled if the _start symbol would reside at the
> very start of the binary, since it then would clobber all the
> vectors.

For the record:  Here I was wrong, having not looked at the
start.S source code.  The layout is similar but the names are
different from what I said:

'_start' _is_ the very first symbol in start.S, and marks the
start of the vector table (the entry point).  'reset' is the name
of the init routine (the actual code which does something), and
the reset vector (residing at the _start address) directly
branches to the reset() label.  Optionally the start.S file may
have dummy or default handlers, which then are located between
the vector table and the reset() init routine.  Reset vectors may
not directly encode target addresses but could need intermediate
data as well which usually follows the vector table.  So the
'reset' label need not be at offset 0x20.


As has been written elsewhere, the linker script specifies that
start.o is the first file to load, and thus the _start symbol
should be at the very start of the text section.

But notice that linker script specs can get overridden at the
command line, so you should check that in the build progress
output as well.

And build instructions optionally may add more build steps after
linking the executable (format conversion, checksum stamps,
padding, containers/envelopes).


virtually yours
Gerhard Sittig
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: office at denx.de