On Thu, Oct 27, 2016 at 03:34:29PM +0100, Peter Maydell wrote: > On 25 October 2016 at 19:21, Guenter Roeck <li...@roeck-us.net> wrote: > > Problem though is that the kernel doesn't really set GPIO01. > > It sets SPITZ_GPIO_ON_RESET (for spitz), which is 89. > > This is mapped to the reset function in spitz.c. > > /* Handle reset */ > > qdev_connect_gpio_out(cpu->gpio, SPITZ_GPIO_ON_RESET, cpu->reset); > > > > This doesn't seem correct; with that override, the reset is supposed > > to happen unconditionally, not only if bit 4 of PCFR is set (and that > > bit isn't set for spitz). > > Yes, that code looks dodgy (among other things it shouldn't > be reaching into the PXA2xxState's structure members directly > like that; par for the course on an unmaintained elderly bit > of QEMU code like this though). > > > How should I correctly handle that situation ? Allocate a second irq > > for non-GPIO01 reset requests ? > > What does the hardware actually do here? It seems unlikely that > the board really wires up the GPIO 89 pin back into the CPU/SoC to > ask the CPU to do a full reset, rather than just handling reset itself.
Yes, I am quite sure that is what it does. > If it's handled at board level then the right thing would be > for the spitz.c code to have its own GPIO handler that does > a power-on-reset. > Makes sense. I'll fix spitz.c (and tosa.c, which does the same) along that line. Thanks, Guenter
