Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752872AbcCIKtz (ORCPT ); Wed, 9 Mar 2016 05:49:55 -0500 Received: from navarro.puc.rediris.es ([130.206.18.139]:37695 "EHLO navarro.puc.rediris.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751427AbcCIKts (ORCPT ); Wed, 9 Mar 2016 05:49:48 -0500 X-Greylist: delayed 1235 seconds by postgrey-1.27 at vger.kernel.org; Wed, 09 Mar 2016 05:49:48 EST X-Envelope-From: paubert@iram.es Date: Wed, 9 Mar 2016 11:28:55 +0100 From: Gabriel Paubert To: Scott Wood Cc: Alessio Igor Bogani , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [1/1] powerpc/embedded6xx: Make reboot works on MVME5100 Message-ID: <20160309102855.GA12303@visitor2.iram.es> References: <1457423952-13014-1-git-send-email-alessio.bogani@elettra.eu> <20160309063818.GA10069@home.buserror.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160309063818.GA10069@home.buserror.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spamina-Bogosity: Unsure X-Spamina-Spam-Score: -0.2 (/) X-Spamina-Spam-Report: Content analysis details: (-0.2 points) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4906] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1923 Lines: 44 On Wed, Mar 09, 2016 at 12:38:18AM -0600, Scott Wood wrote: > On Tue, Mar 08, 2016 at 08:59:12AM +0100, Alessio Igor Bogani wrote: > > The mtmsr() function hangs during restart. Make reboot works on > > MVME5100 removing that function call. > > --- > > arch/powerpc/platforms/embedded6xx/mvme5100.c | 2 -- > > 1 file changed, 2 deletions(-) > > Missing signoff > > Do you know why MSR_IP was there to begin with? Huh? The patch sets MSR_IP for reset but it is cleared while running Linux. I don't have any MVME5100, however I do have MVME2400/2700 with the same bridge (Hawk), so I can say that the address space layout is quite standard: memory at 0, ROM at the high end of the 32-bit address space. However the reset method is quite different (no external register set on the Hawk). > Does this board have a switch that determines whether boot vectors > are high or low (I remember some 83xx boards that did), in which > case is this fixing one config by breaking another? For the switch, no AFAICT. And the code is MVME5100 specific so I suspect that it is very unlikely to break other boards. Very likely the source of the problem is that the restart address is remapped (ioremap) but never accessed while the kernel is running (the only access to *restart is in the reboot routine) so we take a DSI exception to fill the hash table when attempting to reboot. It would be enough to move the setting of MSR_IP until after triggering the restart, but this performs a hard reset of the CPU, which will set MSR_IP anyway (granted that the CPU will probably set MSR_IP way before the reset signal comes in). One way to check this hypothesis would be to introduce a write of 0 to the restart address before setting MSR_IP. This said restart is declared as u_char *, so the cast in the out_8 register access is useless and ugly. Gabriel P.S.: my MVME24xx/26x/27xx do not run such a modern kernel.