blob: 82134d278cfb95913e60f65d2c2ce8d9a225b0fc (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
|
device: 0.761
arm: 0.681
architecture: 0.680
graphic: 0.636
register: 0.619
vnc: 0.574
mistranslation: 0.541
performance: 0.532
ppc: 0.509
socket: 0.479
network: 0.468
kernel: 0.431
semantic: 0.402
risc-v: 0.360
boot: 0.344
peripherals: 0.332
permissions: 0.304
files: 0.292
user-level: 0.239
VMM: 0.233
debug: 0.229
virtual: 0.218
TCG: 0.166
hypervisor: 0.138
PID: 0.130
assembly: 0.118
x86: 0.116
i386: 0.098
KVM: 0.094
ARMv7-M software-triggered interrupts-- unexpected behaviour
The handling of the NVIC "Software Triggered Interrupt Register" in qemu-2.1.0/hw/intc/armv7m_nvic.c:375 isn't quite right. As things stand, writing a zero to the STIR ends up transferring control to vector table entry zero, which, on ARMv7-M, holds the reset value of the stack pointer. That's what I see with lm3s811evb emulation, and that's not what happens on my STM NUCLEO-F103RB board (Cortex-M3).
Seems like an oversight-- the handler probably wants armv7m_nvic_set_pending(), not gic_set_pending_private(), and the IRQ number needs 16 added onto it to get the exception number for the interrupt.
ARM DUI 0552A (Cortex-M3 Devices: Generic User's Guide), p. 134:
"Interrupt ID of the interrupt to trigger, in the range 0-239. For example, a value of 0x03 specifies interrupt IRQ3."
Cheers,
Boris
This bug was fixed in QEMU 2.9 as part of the rewrite of M profile exception handling.
|