From mboxrd@z Thu Jan 1 00:00:00 1970 From: Allen Martin Date: Tue, 7 Aug 2012 16:34:34 -0700 Subject: [U-Boot] [PATCH] tegra20: add back USE_PRIVATE_LIBGCC In-Reply-To: <1344379365.1477.34.camel@tellur> References: <1344298788-7059-1-git-send-email-dev@lynxeye.de> <502149B0.8020904@wwwdotorg.org> <1344359340.1477.12.camel@tellur> <20120807174329.GI7791@nvidia.com> <1344361980.1477.18.camel@tellur> <20120807222841.GK7791@nvidia.com> <1344379365.1477.34.camel@tellur> Message-ID: <20120807233434.GL7791@nvidia.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Aug 07, 2012 at 03:42:45PM -0700, Lucas Stach wrote: > Am Dienstag, den 07.08.2012, 15:28 -0700 schrieb Allen Martin: > > On Tue, Aug 07, 2012 at 10:53:00AM -0700, Lucas Stach wrote: > > > Hi Allen, > > > > > > And to answer Tom's question: the failure was that the real U-Boot would > > > not come up after the SPL. All I could see was the one line printed by > > > the SPL and nothing more. > > > > I think I found the problem. It's the following code from start.S: > > > > ENTRY(cpu_init_crit) > > /* > > * Jump to board specific initialization... > > * The Mask ROM will have already initialized > > * basic memory. Go here to bump up clock rate and handle > > * wake up conditions. > > */ > > mov ip, lr @ persevere link reg across > > call > > bl lowlevel_init @ go setup pll,mux,memory > > mov lr, ip @ restore link > > mov pc, lr @ back to my caller > > ENDPROC(cpu_init_crit) > > > > > > The "ip" register is not preserved across function calls, and the > > CodeSourcery compiler is using it in lowlevel_init or one of the > > functions it calls. This code was there before the SPL changes, but > > wasn't being called because CONFIG_SKIP_LOWLEVEL_INIT was set, but now > > it isn't. > > > > Lucas, can you try the following change? I tested it on seaboard with > > CodeSourcery arm-2011.09-70-arm-none-linux-gnueabi and I'm able to > > boot a kernel. > > Yes I can confirm this fixes the issue without further workarounds. > Thanks, and: > > Tested-by: Lucas Stach Digging a little deeper into this, cpu_init_crit() and lowlevel_init() are called before the stack is setup, so the fact that we call into C code on tegra here is probably the bigger issue. I think the correct fix here is for me to move the code from lowlevel_init() to board_init_f(). -Allen -- nvpublic