All of lore.kernel.org
 help / color / mirror / Atom feed
* [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation
@ 2017-04-08  0:14 Adam Clark
  2017-04-08  0:17 ` [Qemu-devel] [Bug 1680991] " Adam Clark
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Adam Clark @ 2017-04-08  0:14 UTC (permalink / raw)
  To: qemu-devel

Public bug reported:

In a small hobby kernel for Raspberry Pi 2B, I am using the system timer
to control wait durations.  This timer is located at 0x3f003000 and the
timer counts are located at 0x3f003004 (CLO) and 0x3f004008 (CHI).
Reading these memory locations returns 0 for both.

The basic code for this function is:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@@ uint64_t ReadSysTimerCount() -- read the system time running count
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ReadSysTimerCount:
	ldr	r0,=ST_CLO                  @ load the base address of the system timer
	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
	mov	pc,lr			    @ return

Tracing back the definition of ST_CLO in my code:
#define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
#define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
#define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

I have tested a similar program that I know to work on real hardware
with qemu-system-arm reading the same mmio register and have the same
issue, so I'm pretty sure the issue is not with my code.

My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
[adam@os-dev ~]$ uname -a
Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
(git).

adam@os-dev ~]$ qemu-system-arm --version
QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

[adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

A remote debugger for my kernel shows the following:
(gdb) info reg
r0             0x0	0
r1             0x0	0
r2             0x96	150
r3             0x0	0
r4             0xa000	40960
r5             0x0	0
r6             0x0	0
r7             0x0	0
r8             0x0	0
r9             0xa000	40960
r10            0x0	0
r11            0x7fdc	32732
r12            0x0	0
sp             0x7fc8	0x7fc8
lr             0x8194	33172
pc             0x80a4	0x80a4
cpsr           0x800001d3	-2147483181
(gdb) stepi
0x000080a8 in ?? ()
(gdb) info reg
r0             0x3f003004	1056976900
r1             0x0	0
r2             0x96	150
r3             0x0	0
r4             0xa000	40960
r5             0x0	0
r6             0x0	0
r7             0x0	0
r8             0x0	0
r9             0xa000	40960
r10            0x0	0
r11            0x7fdc	32732
r12            0x0	0
sp             0x7fc8	0x7fc8
lr             0x8194	33172
pc             0x80a8	0x80a8
cpsr           0x800001d3	-2147483181
(gdb) stepi
0x000080ac in ?? ()
(gdb) info reg
r0             0x0	0
r1             0x0	0
r2             0x96	150
r3             0x0	0
r4             0xa000	40960
r5             0x0	0
r6             0x0	0
r7             0x0	0
r8             0x0	0
r9             0xa000	40960
r10            0x0	0
r11            0x7fdc	32732
r12            0x0	0
sp             0x7fc8	0x7fc8
lr             0x8194	33172
pc             0x80ac	0x80ac
cpsr           0x800001d3	-2147483181

Notice r0 is loaded with the address for CLO and then cleared with 0
when read.

I am writing my code against the documented specifications in "BCM2835
ARM Peripherals" (attached for convenience), section "12 System Timer".


Please let me know if you need anything else from me.

** Affects: qemu
     Importance: Undecided
         Status: New

** Attachment added: "BSM2835 ARM Peripherals"
   https://bugs.launchpad.net/bugs/1680991/+attachment/4857848/+files/SoC-Peripherals.pdf

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  System Timer returning 0 tick count for raspi2 emulation

Status in QEMU:
  New

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Qemu-devel] [Bug 1680991] Re: System Timer returning 0 tick count for raspi2 emulation
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
@ 2017-04-08  0:17 ` Adam Clark
  2017-11-07 15:07 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer not device implemented Peter Maydell
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Adam Clark @ 2017-04-08  0:17 UTC (permalink / raw)
  To: qemu-devel

The command lines are:

[adam@os-dev ~]$ qemu-system-aarch64 -m 256 -M raspi2 -serial stdio
-kernel bin/rpi2b/kernel.elf

[adam@os-dev workspace]$ ./qemu/bin/debug/native/arm-softmmu/qemu-
system-arm -m 256 -M raspi2 -serial stdio -kernel
century/bin/rpi2b/kernel.elf


A sample kernel is also attached for your convenience.

** Attachment added: "Sample kernel to reproduce the problem"
   https://bugs.launchpad.net/qemu/+bug/1680991/+attachment/4857850/+files/kernel.elf

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  System Timer returning 0 tick count for raspi2 emulation

Status in QEMU:
  New

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Qemu-devel] [Bug 1680991] Re: raspi2: system timer not device implemented
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
  2017-04-08  0:17 ` [Qemu-devel] [Bug 1680991] " Adam Clark
@ 2017-11-07 15:07 ` Peter Maydell
  2018-03-15 17:21 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer device not implemented Peter Maydell
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Peter Maydell @ 2017-11-07 15:07 UTC (permalink / raw)
  To: qemu-devel

The raspi2 board model is only partial, and is missing various devices that weren't used by the test images that it was tested with (mostly Windows-for-Arm, I think). The "system timer" is one of the devices that hasn't been implemented, which is why the memory locations where it should be just read-as-zero.
 

** Summary changed:

- System Timer returning 0 tick count for raspi2 emulation
+ raspi2: system timer not device implemented

** Changed in: qemu
       Status: New => Confirmed

** Tags added: arm

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer not device implemented

Status in QEMU:
  Confirmed

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Qemu-devel] [Bug 1680991] Re: raspi2: system timer device not implemented
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
  2017-04-08  0:17 ` [Qemu-devel] [Bug 1680991] " Adam Clark
  2017-11-07 15:07 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer not device implemented Peter Maydell
@ 2018-03-15 17:21 ` Peter Maydell
  2020-11-18 10:51 ` Thomas Huth
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Peter Maydell @ 2018-03-15 17:21 UTC (permalink / raw)
  To: qemu-devel

** Summary changed:

- raspi2: system timer not device implemented
+ raspi2: system timer device not implemented

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer device not implemented

Status in QEMU:
  Confirmed

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions

^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1680991] Re: raspi2: system timer device not implemented
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
                   ` (2 preceding siblings ...)
  2018-03-15 17:21 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer device not implemented Peter Maydell
@ 2020-11-18 10:51 ` Thomas Huth
  2020-11-18 11:14 ` Philippe Mathieu-Daudé
  2020-12-10  9:16 ` Thomas Huth
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Huth @ 2020-11-18 10:51 UTC (permalink / raw)
  To: qemu-devel

Is anybody still working on the raspi2 model? If not, shall we close
this as WontFix?

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer device not implemented

Status in QEMU:
  Confirmed

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1680991] Re: raspi2: system timer device not implemented
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
                   ` (3 preceding siblings ...)
  2020-11-18 10:51 ` Thomas Huth
@ 2020-11-18 11:14 ` Philippe Mathieu-Daudé
  2020-12-10  9:16 ` Thomas Huth
  5 siblings, 0 replies; 7+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-11-18 11:14 UTC (permalink / raw)
  To: qemu-devel

The timer has been implemented, see commits:
d05be883fc9 ("hw/timer/bcm2835: Add the BCM2835 SYS_timer")
0e5bbd74064 ("hw/arm/bcm2835_peripherals: Use the SYS_timer")
722bde6789c ("hw/arm/bcm2835_peripherals: Correctly wire the SYS_timer IRQs")

Running the attached test with "-trace bcm2835_systmr_read" produces:
1634226@1605697958.837194:bcm2835_systmr_read timer read: offset 0x4 data 0x7cfc
1634226@1605697958.837229:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837313:bcm2835_systmr_read timer read: offset 0x4 data 0x7d73
1634226@1605697958.837323:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837439:bcm2835_systmr_read timer read: offset 0x4 data 0x7df1
1634226@1605697958.837454:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837553:bcm2835_systmr_read timer read: offset 0x4 data 0x7e64
1634226@1605697958.837561:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837568:bcm2835_systmr_read timer read: offset 0x4 data 0x7e73
1634226@1605697958.837574:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837578:bcm2835_systmr_read timer read: offset 0x4 data 0x7e7d
1634226@1605697958.837582:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837586:bcm2835_systmr_read timer read: offset 0x4 data 0x7e85
1634226@1605697958.837590:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837594:bcm2835_systmr_read timer read: offset 0x4 data 0x7e8d
1634226@1605697958.837598:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837602:bcm2835_systmr_read timer read: offset 0x4 data 0x7e95
1634226@1605697958.837606:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837611:bcm2835_systmr_read timer read: offset 0x4 data 0x7e9e
1634226@1605697958.837616:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837621:bcm2835_systmr_read timer read: offset 0x4 data 0x7ea7
1634226@1605697958.837625:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837629:bcm2835_systmr_read timer read: offset 0x4 data 0x7eaf
1634226@1605697958.837634:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837640:bcm2835_systmr_read timer read: offset 0x4 data 0x7ebb
1634226@1605697958.837646:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837653:bcm2835_systmr_read timer read: offset 0x4 data 0x7ec8
1634226@1605697958.837666:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837673:bcm2835_systmr_read timer read: offset 0x4 data 0x7edc
1634226@1605697958.837679:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837685:bcm2835_systmr_read timer read: offset 0x4 data 0x7ee7
1634226@1605697958.837690:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837696:bcm2835_systmr_read timer read: offset 0x4 data 0x7ef2
1634226@1605697958.837707:bcm2835_systmr_read timer read: offset 0x8 data 0x0
1634226@1605697958.837713:bcm2835_systmr_read timer read: offset 0x4 data 0x7f03
1634226@1605697958.837717:bcm2835_systmr_read timer read: offset 0x8 data 0x0


** Changed in: qemu
       Status: Confirmed => Fix Committed

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer device not implemented

Status in QEMU:
  Fix Committed

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

* [Bug 1680991] Re: raspi2: system timer device not implemented
  2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
                   ` (4 preceding siblings ...)
  2020-11-18 11:14 ` Philippe Mathieu-Daudé
@ 2020-12-10  9:16 ` Thomas Huth
  5 siblings, 0 replies; 7+ messages in thread
From: Thomas Huth @ 2020-12-10  9:16 UTC (permalink / raw)
  To: qemu-devel

Released with QEMU v5.2.0.

** Changed in: qemu
       Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1680991

Title:
  raspi2: system timer device not implemented

Status in QEMU:
  Fix Released

Bug description:
  In a small hobby kernel for Raspberry Pi 2B, I am using the system
  timer to control wait durations.  This timer is located at 0x3f003000
  and the timer counts are located at 0x3f003004 (CLO) and 0x3f004008
  (CHI).  Reading these memory locations returns 0 for both.

  The basic code for this function is:
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  @@ uint64_t ReadSysTimerCount() -- read the system time running count
  @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
  ReadSysTimerCount:
  	ldr	r0,=ST_CLO                  @ load the base address of the system timer
  	ldrd	r0,r1,[r0]                  @ Get the 64-bit timer "count" into r1:r0
  	mov	pc,lr			    @ return

  Tracing back the definition of ST_CLO in my code:
  #define ST_CLO              (ST_BASE+4)                 // Counter Lower 32 bits
  #define ST_BASE             (HW_BASE+0x3000)            // System Timer base address
  #define HW_BASE             (0x3f000000)                // this is the base address for all hardware I/O addresses

  I have tested a similar program that I know to work on real hardware
  with qemu-system-arm reading the same mmio register and have the same
  issue, so I'm pretty sure the issue is not with my code.

  My Host PC is a VM on vmWare esxi running FC25 (8 cores, 8GB RAM): 
  [adam@os-dev ~]$ uname -a
  Linux os-dev.jammin 4.10.8-200.fc25.x86_64 #1 SMP Fri Mar 31 13:20:22 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

  I have confirmed this issue on QEMU 2.7.1 (fc25 Distro) and 2.9.0-rc3
  (git).

  adam@os-dev ~]$ qemu-system-arm --version
  QEMU emulator version 2.7.1(qemu-2.7.1-4.fc25), Copyright (c) 2003-2016 Fabrice Bellard and the QEMU Project developers

  [adam@os-dev ~]$ ./workspace/qemu/bin/debug/native/arm-softmmu/qemu-system-arm --version
  QEMU emulator version 2.8.93 (v2.9.0-rc3-15-g5daf9b3)
  Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers

  A remote debugger for my kernel shows the following:
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a4	0x80a4
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080a8 in ?? ()
  (gdb) info reg
  r0             0x3f003004	1056976900
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80a8	0x80a8
  cpsr           0x800001d3	-2147483181
  (gdb) stepi
  0x000080ac in ?? ()
  (gdb) info reg
  r0             0x0	0
  r1             0x0	0
  r2             0x96	150
  r3             0x0	0
  r4             0xa000	40960
  r5             0x0	0
  r6             0x0	0
  r7             0x0	0
  r8             0x0	0
  r9             0xa000	40960
  r10            0x0	0
  r11            0x7fdc	32732
  r12            0x0	0
  sp             0x7fc8	0x7fc8
  lr             0x8194	33172
  pc             0x80ac	0x80ac
  cpsr           0x800001d3	-2147483181

  Notice r0 is loaded with the address for CLO and then cleared with 0
  when read.

  I am writing my code against the documented specifications in "BCM2835
  ARM Peripherals" (attached for convenience), section "12 System
  Timer".

  
  Please let me know if you need anything else from me.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1680991/+subscriptions


^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2020-12-10  9:57 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-08  0:14 [Qemu-devel] [Bug 1680991] [NEW] System Timer returning 0 tick count for raspi2 emulation Adam Clark
2017-04-08  0:17 ` [Qemu-devel] [Bug 1680991] " Adam Clark
2017-11-07 15:07 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer not device implemented Peter Maydell
2018-03-15 17:21 ` [Qemu-devel] [Bug 1680991] Re: raspi2: system timer device not implemented Peter Maydell
2020-11-18 10:51 ` Thomas Huth
2020-11-18 11:14 ` Philippe Mathieu-Daudé
2020-12-10  9:16 ` Thomas Huth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.