[U-Boot] QSPI XIP boot on am437x

[Albert ARIBAUD]

Hello Albert,

On Wed, 11 Nov 2015 08:15:31 +0100, Albert ARIBAUD
<albert.u.boot at aribaud.net> wrote:
> Hello Vignesh,
> 
> On Wed, 11 Nov 2015 11:42:55 +0530, R, Vignesh <vigneshr at 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 at 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.