Hello Albert, On Wed, 11 Nov 2015 08:15:31 +0100, Albert ARIBAUD <albert.u.b...@aribaud.net> wrote: > Hello Vignesh, > > On Wed, 11 Nov 2015 11:42:55 +0530, R, Vignesh <vigne...@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 <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 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"
Alternatively, you could test the patch at http://patchwork.ozlabs.org/patch/542558/ Let us know if this solves your issue. If it does, then it will confirm the issue is with arch_setup_gd not being able to set up your GD for some reason. IMPORTANT: patch 542558 is *not* a final patch (there will be at least a v3), and may even never land in u-boot/master; but some equivalent will eventually do. Right now, patch 542558 is only a way to test if your issue is a GD one. > > Regards > > Vignesh Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot