On 14/12/2024 13:29, Philippe Mathieu-Daudé wrote:
On 12/12/24 12:45, Mark Cave-Ayland wrote:
Move the timer MMIO accesses to a separate memory region on the next-pc device
instead of being part of the next.scr MMIO memory region.
Signed-off-by: Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk>
Reviewed-by: Thomas Huth <h...@tuxfamily.org>
---
hw/m68k/next-cube.c | 63 +++++++++++++++++++++++++++++++++++----------
1 file changed, 50 insertions(+), 13 deletions(-)
+static uint64_t next_timer_read(void *opaque, hwaddr addr, unsigned size)
+{
+ uint64_t val;
+
+ switch (addr) {
+ case 0 ... 3:
+ /*
+ * These 4 registers are the hardware timer, not sure which register
+ * is the latch instead of data, but no problems so far.
+ *
+ * Hack: We need to have the LSB change consistently to make it work
+ */
+ val = extract32(clock(), (4 - addr - size) << 3,
+ size << 3);
Does this mean ...
+ break;
+
+ default:
+ g_assert_not_reached();
+ }
+
+ return val;
+}
+
+static const MemoryRegionOps next_timer_ops = {
+ .read = next_timer_read,
+ .write = next_timer_write,
+ .valid.min_access_size = 1,
+ .valid.max_access_size = 4,
+ .endianness = DEVICE_BIG_ENDIAN,
... this should be in little endianness?
Anyhow,
Reviewed-by: Philippe Mathieu-Daudé <phi...@linaro.org>
+};
That's a good point re: endian. I don't have any documentation for the timer device,
so the patch is focused to moving its registers to a separate memory region. It's
definitely something to consider in the future though.
ATB,
Mark.
