From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeroen Hofstee Date: Tue, 23 Sep 2014 09:51:25 +0200 Subject: [U-Boot] Newbie question In-Reply-To: References: Message-ID: <5421267D.2030309@myspectrum.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Donald, On 23-09-14 05:03, Donald Dade wrote: > I recently bought a Jetson TK1 with the intent of learning all about ARM > board bring up; essentially everything that happens between the reset > vector and the spawning of the init process (in Linux). I've got a good > understanding of this for x86, and I'd like to similarly understand what > happens with an ARM SoC. > > I've been having a rough go of it, for example I cannot even find in > explicit terms what the reset vector address is. I began to think that > maybe I'm presupposing too many x86 artifacts and that that's not at all > how ARM works. x86 has a lot of cruft left over from the 70s, after all. > > So I know that there is a u-boot port for the Jetson, so I cloned the > source, started swimming through it, and quickly started to drown :) > > So, my questions are these: > > Can anyone briefly explain how the build system works, i.e. how the source > is configured to build for Jetson The supported boards have a defconfig file in /configs nowadays. In your case it is jetson-tk1_defconfig. (or ./MAKEALL -l arm | grep jetson) # build export CROSS_COMPILE=arm-linux-gnueabi- make jetson-tk1_defconfig make all You should end up with two binaries, spl/u-boot-spl.bin and u-boot.bin. The former loads the latter one. spl is build from the same sources tree but the object files are placed in the spl directory (and tweaked for size). and how I find where u-boot's entry point is, - Look at the output to see which start.S is compiled. - find start.o - objdump the obtained elf file (with the .bin) and search for reset There is no universal memory map / startup sequence for ARM if that is what you were looking for. You need google or a datasheet to figure out how (might depend on gpio e.g.) and where code execution begins on the target. Note versatileqemu_defconfig can be run with qemu / gdb, so you can just step through it. You need to load symbols for the location u-boot relocates itself to as well. Google knows how to do that. > so I can just look at what it does? A small note. There are two "boards" at the moment for ARM, if grep points you to arch/arm/lib/board.c ignore it since this boards uses common/board_f.c / common/board_r.c. Good luck, Regards, Jeroen