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