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 <vigne...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
