[U-Boot] How/Where does "_start" get assigned a value ?
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-... Sent from the U-Boot mailing list archive at Nabble.com.
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-... Sent from the U-Boot mailing list archive at Nabble.com. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
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-... Sent from the U-Boot mailing list archive at Nabble.com. _______________________________________________ U-Boot mailing list U-Boot@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
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,
I am running into the issue as described below:
http://u-boot.10912.n7.nabble.com/U-Boot-ARM-gap-between-start-and-CONFIG-SY...
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-... Sent from the U-Boot mailing list archive at Nabble.com.
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
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@denx.de
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
participants (5)
-
Albert ARIBAUD -
Arvid Brodin -
Djoker -
djoker
-
Gerhard Sittig