From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49578) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkvEq-0007Jl-G6 for qemu-devel@nongnu.org; Sat, 10 Oct 2015 10:35:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZkvEm-0003Vu-FM for qemu-devel@nongnu.org; Sat, 10 Oct 2015 10:35:08 -0400 Received: from mail-qg0-x231.google.com ([2607:f8b0:400d:c04::231]:36664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZkvEm-0003Vq-BQ for qemu-devel@nongnu.org; Sat, 10 Oct 2015 10:35:04 -0400 Received: by qgx61 with SMTP id 61so91087635qgx.3 for ; Sat, 10 Oct 2015 07:35:04 -0700 (PDT) Message-ID: <56192216.5060006@gmail.com> Date: Sat, 10 Oct 2015 10:35:02 -0400 From: Michael Davidsaver MIME-Version: 1.0 References: <1b09df0b1659aefda410242d9976db61eb099b32.1444318183.git.mdavidsaver@gmail.com> <5617F8A0.2050300@gmail.com> <56180CAD.50901@gmail.com> In-Reply-To: <56180CAD.50901@gmail.com> 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:51 PM, Michael Davidsaver wrote: > 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? I think I've answered my own question. You mean to replace the call to qemu_system_reset_request() with something like qemu_irq_pulse()? I think I see how to do this. The simplest (adding another named GPIO to the NVIC devices) is complicated by the fact that the armv7m_init() doesn't return the nvic object, but rather an array of qemu_irq. Is it reasonable to change armv7m_init() to return DeviceState*?