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? > Thanks! NP. > Regards > Vignesh Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot