From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Wed, 11 Nov 2015 10:03:35 +0100 Subject: [U-Boot] QSPI XIP boot on am437x In-Reply-To: <20151111081531.65a53e88@lilith> References: <5641B20A.4080207@ti.com> <20151110131431.73cd022d@lilith> <5642DC67.6080908@ti.com> <20151111081531.65a53e88@lilith> Message-ID: <20151111100335.5d303fe2@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Albert, On Wed, 11 Nov 2015 08:15:31 +0100, Albert ARIBAUD wrote: > Hello Vignesh, > > On Wed, 11 Nov 2015 11:42:55 +0530, R, Vignesh 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 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.