[U-Boot] Is there a working 2011 version of u-boot on i.MX31?

[Stefano Babic]

On 05/26/2011 06:11 PM, Helmut Raiger wrote:
> Hi,
> 

Hi Helmut,

>      I tried to upgrade my 2010/09 version of u-boot for our i.MX31 
> board, fixed the stuff needed for the new relocation scheme and ... 
> nothing, ... no prompt, so I compiled for mx31pdk (without any change of 
> source code) as it is very similar (RAM setup, etc.) and this also shows 
> no action on the uart (DEBUG is on).

As Fabio already reported, last release is working on mx31pdk.

> 
> After some hours of JTAG debugging I finally found that not even 
> board_early_init_f is called (neither for mx31pdk nor for our board). 
> Tracking down the assembler stuff in start.S and board.c shows that:

This is ruled by CONFIG_BOARD_EARLY_INIT_F, that is set for the board
you mention and for qong, too. This is a second MX.31 board where I am
sure that the last u-boot release is running.


> 1) relocation is done at the end of 'board_init_f'
> 2) all early init functions are called at the very start of 'board_init_f'
> 3) these init functions are stored in an array of function pointers 
> 'init_sequence', which is initialized data and which is not initialized yet.
> 4) the C-code in general is linked using -pie, but the compiler flag 
> -PIE (or -PIC) is missing, so code is not really position independent. 
> It is linked for the RAM addresses (0x87f00000), but relocation is not 
> yet done.

It seems a problem related to your toolchain. Which gcc compiler are you
using ? This can explain what you are reporting.

> 5) uboot dies when the first function (board_early_init_f) should be called.
> 
> Adding -PIE in arch/arm/cpu/arm1136/config.mk and putting initialized 
> arrays (with constant values) into the text segment (__attribute__ 
> ((section (".text")) improves the situation, but butts out a little 
> further down the road. I stopped at this point.

Agree, it should run out-of-the-box.

> 
> There also seems to be a problem with the setup of gd in 'board_init_f' 
> which is placed at exactly the same position where start.S sets the 
> initial stack pointer (in internal RAM). I think this was not intended.

This can be another symptom that the problem is related to the
toolchain. Take care that what you are exponing is not strictly related
to the i.MX31, and most of ARM boards should be affected, and they are not.

Best regards,
Stefano Babic

-- 
=====================================================================
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: office at denx.de
=====================================================================