U-Boot SPL: can't jump to board_init_f

Michael Bubestinger

Other Parts Discussed in Thread: AM3703

We have a working U-Boot and Linuxsystem based on X-Loader, U-Boot 2011 and Linux 2.6. I'm trying to get the u-boot 2014.01 with spl running (using the current TI SDK).

The U-Boot SPL stucks after printing the version strings (U-Boot SPL 2014.01-00002-ge7b3284-dirty (Jan 24 2014 - 10:05:27) ). I tracked it down to a point in crt0.S -> board_init_f

ENTRY(_main)

/*
 * Set up initial C runtime environment and call board_init_f(0).
 */

	
#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
	ldr	sp, =(CONFIG_SPL_STACK)
#else
	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
	bic	sp, sp, #7	/* 8-byte alignment for ABI compliance */
	sub	sp, sp, #GD_SIZE	/* allocate one GD above SP */
	bic	sp, sp, #7	/* 8-byte alignment for ABI compliance */
	mov	r9, sp		/* GD is above SP */
	mov	r0, #0

		bl cairo_output
	bl	board_init_f
		bl cairo_output
#if ! defined(CONFIG_SPL_BUILD)

'Caus of a missing debuger, i had to add a few debug lines (only "puts("--");) for debugging with the serial port The first line in "board_init_f is: puts("\n>>entering board-init_f");

The core never jumps into board_init_f and I have no idea why. Any hints?

Regards,
Michael

over 11 years ago

0 Biser Gatchev-XID over 11 years ago

TI__Guru**** 393215 points

What processor are you using?

0 Michael Bubestinger over 11 years ago in reply to Biser Gatchev-XID

Prodigy 70 points

Oh sorry, deleted the first paragraph: I'm using an AM3703 processor on a custom (and working) board.

0 Miroslav Kiradzhiyski XID over 11 years ago

TI__Mastermind 25235 points

Hi,

If board_init_f() function is never called, then there may be something wrong while setting the initial C runtime environment inside the _main function, located in <u-boot_dir>/arch/arm/lib/crt0.S:

/*
* This file handles the target-independent stages of the U-Boot
* start-up where a C runtime environment is needed. Its entry point
* is _main and is branched into from the target's start.S file.
*
* _main execution sequence is:
*
* 1. Set up initial environment for calling board_init_f().
*    This environment only provides a stack and a place to store
*    the GD ('global data') structure, both located in some readily
*    available RAM (SRAM, locked cache...). In this context, VARIABLE
*    global data, initialized or not (BSS), are UNAVAILABLE; only
*    CONSTANT initialized data are available.
*
* 2. Call board_init_f(). This function prepares the hardware for
*    execution from system RAM (DRAM, DDR...) As system RAM may not
*    be available yet, , board_init_f() must use the current GD to
*    store any data which must be passed on to later stages. These
*    data include the relocation destination, the future stack, and
*    the future GD location.

Here is an excerpt of the main_ function:

_main:

/*
* Set up initial C runtime environment and call board_init_f(0).
*/

#if defined(CONFIG_NAND_SPL)
   /* deprecated, use instead CONFIG_SPL_BUILD */
   ldr   sp, =(CONFIG_SYS_INIT_SP_ADDR)
#elif defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
   ldr   sp, =(CONFIG_SPL_STACK)
#else
   ldr   sp, =(CONFIG_SYS_INIT_SP_ADDR)
#endif
   bic   sp, sp, #7   /* 8-byte alignment for ABI compliance */
   sub   sp, #GD_SIZE   /* allocate one GD above SP */
   bic   sp, sp, #7   /* 8-byte alignment for ABI compliance */
   mov   r8, sp       /* GD is above SP */
   mov   r0, #0
   bl   board_init_f

This excerpt is from U-Boot version 2013.01.01. Since step 2 (board_inti_f()) is never reached, you should check if there are any differences between your U-Boot and this one and search for the problem there.

Best regards,
Miroslav

0 Michael Bubestinger over 11 years ago in reply to Miroslav Kiradzhiyski XID

Prodigy 70 points

My Code differs from yours a little bit...I'm looking into the mailing list why it changed.

But: As far as I can see at the moment it looks fine as it is (and I believe it's working on other boards). I'm crosschecking the config files with various other omap3 boards...but can't find any differents. At this stage only a few SPL defines are used and they are looking fine :/

0 Michael Bubestinger over 11 years ago in reply to Michael Bubestinger

Prodigy 70 points

I'm still crosschecking my config header, but as far as I can see: At this stage of the boot process only a few #defines are critical (and enabled for me) at this stage:

#define CONFIG_SPL_TEXT_BASE	0x40200800
#define CONFIG_SPL_MAX_SIZE		(54 * 1024)		/* 8 KB for stack */
#define CONFIG_SPL_STACK		        LOW_LEVEL_SRAM_STACK

and:

get_board_mem_timings(struct board_sdrc_timings *timings) + mux settings

Not much what could break the code (should work like the beagle board). All additional hardware like DDR would be in board_init_f().

Maybe a miss configured build environment?

€dit: BTW I'm booting from MMC

Processors

Processors forum

U-Boot SPL: can't jump to board_init_f