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: off...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
