Hello Vignesh,
On Wed, 11 Nov 2015 11:42:55 +0530, R, Vignesh vigneshr@ti.com wrote:
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 feel a great disturbance in the Force...
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.
I suggest you watch the list for other issues where access to gd->xxxx is broken -- it seems like several targets are experiencing this kind of problem. See for instance the thread with theis subject:
Revert "arm: Switch 32-bit ARM to using generic global_data setup"
Regards Vignesh
Amicalement,