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