+Stephen who will know more

Hi,

On 13 February 2016 at 18:52, quantumlight peter.feifan.chen@gmail.com wrote:

I am trying to modify the bootloader code for NVIDIA's jetson board.

So I am looking at crt0.S. It seems that two builds happen, one with CONFIG_SPL_BUILD and one without. So you end up with two file, u-boot.bin and spl/u-boot-spl.bin.

SPL is built with ARMv4t U-Boot proper is built with ARMv7

That's why SPL is used on Tegra. The SPL does not actually load U-Boot. In fact both are bundle together and loaded at the same time. SPL simply jumps to U-Boot when needed.

However, I am unable to find the code path that calls board_init_r() after board_init_f() finishes, although there are several candidates:

1. crt0.S - if CONFIG_SPL_BUILD was not defined, then it would fall straight

through to board_init_r() - HOWEVER, for u-boot.bin, isn't CONFIG_SPL_BUILD defined in autoconf.h? Or is this some clever magic between how u-boot.bin and spl/u-boot-spl.bin are stitched together?

For U-Boot, CONFIG_SPL_BUILD is not defined. That define means you are building SPL.

The clever magic is mostly 'cat'. SPL is padded a little and then U-Boot is added on the end.

2. _weak board_init_f in arch/arm/lib/spl.c - HOWEVER, shouldn't this be

overloaded by board_init_f in common/board_f.c?

The latter is only used in U-Boot proper. SPL has its own board_init_f().

3. board_init_f_r in common/board_f.c - HOWEVER, nothing calls

board_init_f_r().

No, that is not used on ARM.

Can someone illuminate me on how this happens?

See the README under Board Initialisation Flow. In brief, the link between board_init_f() and board_init_r() is generally the crt0.S that you found. The catch is that some boards don't implement board_init_f() in SPL, and so use the weak one, which in fact calls board_init_r() directly.

See also arch/arm/mach-tegra/board.c which I think contains the code to jump to SPL.

Regards, Simon