From patchwork Thu Jan 24 09:21:53 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Joakim Tjernlund X-Patchwork-Id: 215280 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from theia.denx.de (theia.denx.de [85.214.87.163]) by ozlabs.org (Postfix) with ESMTP id 4CE682C0086 for ; Thu, 24 Jan 2013 20:22:05 +1100 (EST) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 52CB54A099; Thu, 24 Jan 2013 10:22:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rOUCYC+-N+3; Thu, 24 Jan 2013 10:22:02 +0100 (CET) Received: from theia.denx.de (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id C58D94A054; Thu, 24 Jan 2013 10:22:00 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by theia.denx.de (Postfix) with ESMTP id 1D2084A054 for ; Thu, 24 Jan 2013 10:21:58 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at theia.denx.de Received: from theia.denx.de ([127.0.0.1]) by localhost (theia.denx.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wI1N6pPnD1yG for ; Thu, 24 Jan 2013 10:21:57 +0100 (CET) X-policyd-weight: NOT_IN_SBL_XBL_SPAMHAUS=-1.5 NOT_IN_SPAMCOP=-1.5 NOT_IN_BL_NJABL=-1.5 (only DNSBL check requested) Received: from gw1.transmode.se (gw1.transmode.se [195.58.98.146]) by theia.denx.de (Postfix) with ESMTPS id 13B634A052 for ; Thu, 24 Jan 2013 10:21:55 +0100 (CET) Received: from mail1.transmode.se (mail1.transmode.se [192.168.201.18]) by gw1.transmode.se (Postfix) with ESMTP id 49020258155; Thu, 24 Jan 2013 10:21:54 +0100 (CET) In-Reply-To: References: , <20130123212559.309ED2454A1@gemini.denx.de> MIME-Version: 1.0 X-KeepSent: 78771BBB:E9A12F58-C1257AFD:0031DD1A; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 From: Joakim Tjernlund Message-ID: Date: Thu, 24 Jan 2013 10:21:53 +0100 X-MIMETrack: Serialize by Router on mail1/Transmode(Release 8.5.3FP1|March 07, 2012) at 24/01/2013 10:21:53, Serialize complete at 24/01/2013 10:21:53 Cc: "u-boot@lists.denx.de" , =?ISO-8859-15?Q?Mats_K=E4rrman?= Subject: Re: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01 X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.11 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: u-boot-bounces@lists.denx.de Errors-To: u-boot-bounces@lists.denx.de Joakim Tjernlund/Transmode wrote on 2013/01/24 09:58:35: > > Joakim Tjernlund/Transmode wrote on 2013/01/24 09:40:45: > > > From: Joakim Tjernlund/Transmode > > To: Mats Kärrman , > > Cc: "u-boot@lists.denx.de" , Wolfgang Denk > > Date: 2013/01/24 09:40 > > Subject: RE: [U-Boot] mpc512x: Trouble migrating from 2012.07 to 2013.01 > > > > Mats Kärrman wrote on 2013/01/23 22:58:56: > > > > > > Dear Wolfgang Denk, > > > > > > >> Found that it was looping endlessly in arch/powerpc/lib/ticks.S::wait_ticks > > > (). Reverting commit "ppc: Create a stack frame for wait_ticks()" made > > > everything work again. > > > > > > > > This makes no sense to me - especially as it works on all other > > > > systems. > > > > > > > Me neither, there is not a lot details. I do recall having other problems with > > wait_ticks from time to time, sometimes the TB counter(mtfbu, mftb in get_ticks) > > would not increment so one would just loop forever in wait_ticks. This problem > > had nothing to do with my patch though. > > Never got around to finding out what caused it, we ended up blaming unstable HW. > > > > Some ideas though: > > - Perhaps you have some alignment problem, try adding nop's here and there. > > - My patch uses r0(which is what one should use to make gdb happy) instead of r8 > > to stash the LR. Possibly you have some odd dependency on r0, try using r8 again. > > Try getting LR from stack instead of trusting r0 to be valid: > - mtlr r0 /* restore link register */ > + lwz r0, 20(r1) /* restore link register */ > + mtlr r0 > This is what one should do but as we have complete control of r0 here we don't need to. > > hmm, do you have WATCHDOG_RESET defined? does it use r0? > I guess the above patch would make wait_ticks safer from accidental use by > WATCHDOG_RESET, > if it works for you, please send a proper patch to u-boot. Looking at the watchdog impl. I see it can be normal C code. This makes wait_ticks unsafe (even before my patch) as wait_ticks relies on r6 and r7 (and with my patch r0 too) to be unmodified. This MIGHT be the fix: Not sure about the 4 and 8 offsets though Jocke --- a/arch/powerpc/lib/ticks.S +++ b/arch/powerpc/lib/ticks.S @@ -56,13 +56,17 @@ wait_ticks: /* Calculate end time */ addc r7, r4, r7 /* Compute end time lower */ addze r6, r3 /* and end time upper */ - + stw r7, 4(r1) /* Stash r6 and r7 */ + stw r6, 8(r1) WATCHDOG_RESET /* Trigger watchdog, if needed */ + lwz r7, 4(r1) + lwz r6, 8(r1) 1: bl get_ticks /* Get current time */ subfc r4, r4, r7 /* Subtract current time from end time */ subfe. r3, r3, r6 bge 1b /* Loop until time expired */ - mtlr r0 /* restore link register */ + lwz r0, 20(r1) /* restore link register */ + mtlr r0 addi r1,r1,16 blr