[U-Boot] QSPI XIP boot on am437x

[R, Vignesh <vigneshr@ti.com>]

Hi Albert,

Thanks for the response!

On 11/10/2015 5:44 PM, Albert ARIBAUD wrote:
> Hello Vignesh,
> 
> On Tue, 10 Nov 2015 14:29:54 +0530, Vignesh R <vigneshr@ti.com> wrote:
>> Hi,
>>
>> With commit 7ae8350f67eea("ti: armv7: Move SPL SDRAM init to the right
>> place, drop unused CONFIG_SPL_STACK") QSPI XIP boot appears to be broken
>> on AM437x SK EVM.
>>
>> Following UART initialization code (as indicated by TODO) causes the XIP
>> boot failure.
>>
>>
>> In arch/arm/cpu/armv7/am33xx/board.c:
>> @@ -275,9 +275,9 @@ void s_init(void)
>>  #if defined(CONFIG_NOR_BOOT) || defined(CONFIG_QSPI_BOOT)
>>         /* TODO: This does not work, gd is not available yet */
>>        gd->baudrate = CONFIG_BAUDRATE;
>>        serial_init();
>>        gd->have_console = 1;
>>  #endif
>>
>>
>> I was able to boot successfully from QSPI by commenting out the above code.
>> But, could you suggest me what needs to be done as part of TODO in order
>> to get QSPI XIP boot working?
> 
> Can't answer specifically on am437x, but basically, the problem you
> have here may be that the code is running in a C runtime environment in
> which only the global data is writable. This global data is a struct
> global_data (see include/asm-generic/global_data.h) which is supposed
> to be pointed to by the variable GD.
> 
> Can you detail the failure you are encountering?
> 
> Typically, GD is set up from within function board_init_f_mem(), before
> calling board_init_f(), or from arch/arm/lib/crt0.S.
> 
> So all depends on whether s_init() is executed before or after
> board_init_f_mem().
> 
> If s_init() runs before board_init_f_mem(), then you must move it to
> run after board_init_f_mem(). :)
> 
> If s_init() runs after board_init_f_mem() and you still have the issue,
> then your problem would be that gd is badly initialized. Is your board
> built for Thumb with a recent compiler, by any chance? I any case, can
> you test the value of gd when reaching the gd->baudrate line above?

Yes, s_init() is being called before call to _main(in
arch/arm/lib/crt0.S that sets up GD) but all these calls are from arm
generic files and nothing specific to am437x:
reset (arch/arm/cpu/armv7/start.S)
-> cpu_init_crit(arch/arm/cpu/armv7/start.S)
 -> lowlevel_init(arch/arm/cpu/armv7/lowlevel_init.S)
    -> s_init(arch/arm/cpu/armv7/board/am33xx.c)

The failure appears to be in serial_init(), it tries to access gd->flags
which is not allocated yet and reads wrong value.

I was wondering whether entire UART initialization code in s_init() in
arch/arm/cpu/armv7/board/am33xx.c can be moved to the end of
board_init_f() where GD is accessible.

Regards
Vignesh