On 10/09/2015 02:18 PM, Peter Crosthwaite wrote: > On Fri, Oct 9, 2015 at 10:25 AM, Michael Davidsaver > <mdavidsa...@gmail.com> wrote: >> >> >> On 10/09/2015 12:59 PM, Peter Maydell wrote: >>> On 8 October 2015 at 16:40, Michael Davidsaver <mdavidsa...@gmail.com> >>> 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...)