From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:57675) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zkcli-00012w-3c for qemu-devel@nongnu.org; Fri, 09 Oct 2015 14:52:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkclL-0000fq-G4 for qemu-devel@nongnu.org; Fri, 09 Oct 2015 14:51:49 -0400 Received: from mail-qg0-x231.google.com ([2607:f8b0:400d:c04::231]:35017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkclL-0000fL-9Z for qemu-devel@nongnu.org; Fri, 09 Oct 2015 14:51:27 -0400 Received: by qgt47 with SMTP id 47so76358393qgt.2 for ; Fri, 09 Oct 2015 11:51:27 -0700 (PDT) Message-ID: <56180CAD.50901@gmail.com> Date: Fri, 09 Oct 2015 14:51:25 -0400 From: Michael Davidsaver MIME-Version: 1.0 References: <1b09df0b1659aefda410242d9976db61eb099b32.1444318183.git.mdavidsaver@gmail.com> <5617F8A0.2050300@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] armv7-m: exit on external reset request List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Crosthwaite Cc: Peter Maydell , QEMU Developers On 10/09/2015 02:18 PM, Peter Crosthwaite wrote: > On Fri, Oct 9, 2015 at 10:25 AM, Michael Davidsaver > wrote: >> >> >> On 10/09/2015 12:59 PM, Peter Maydell wrote: >>> On 8 October 2015 at 16:40, Michael Davidsaver wrote: >>>> ... >>>> case 0xd0c: /* Application Interrupt/Reset Control. */ >>>> if ((value >> 16) == 0x05fa) { >>>> + if (value & 4) { >>>> + qemu_system_reset_request(); >>>> + } >> ... >>> >>> Strictly speaking what this bit does is assert a signal out of >>> the CPU to some external power management or similar device >>> in the SoC, which then is responsible for doing the reset. >>> So just calling qemu_system_reset_request() here is a bit of >>> a shortcut. But maybe it's a pragmatic shortcut? >> >> I'm not sure what you mean by shortcut? Most targets have some way to trigger qemu to exit. I actually compiled a list recently (see below). I couldn't find one for the lm3s6965evb machine, thus this patch. >> > ... > I think it would be better for SoC (or board) level to > install the GPIO handler to do the reset. As far as target-arm is > concerned this is then just a GPIO. I don't think I'm well versed enough in qemu lingo to parse this sentence :) Are you concerned about adding this function to AIRCR (which would effect every armv7-m board), or about directly calling qemu_system_reset_request() in armv7m_nvic.c? > We should check the lm3s docs to see what the implementation of this > signal is. To quote page 129 of http://www.ti.com/lit/ds/symlink/lm3s6965.pdf > System Reset Request > Value Description > 0 > No effect. > 1 > Resets the core and all on-chip peripherals except the Debug > interface. > This bit is automatically cleared during the reset of the core and reads > as 0. There is also mention of a board specific watchdog timer. I also looked at the TI MSP432P4xx (I have one), which give a similar definition for this bit (along with a dozen board specific ways to do different reset levels...)