[Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Thomas Huth]

During Google Summer of Code 2011, Bryce Lanham added the possibility to
emulate the NeXTcube machine in QEMU, e.g. see this URL for some details:

https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation

But since the machine requires a 68040 CPU and this was not included in
upstream QEMU in 2011 yet, the patches have never been merged to upstream.
Now in 2018, Laurent completed the full 680x0 support in upstream QEMU, so
we could finally merge the NeXTcube support, too.

The QEMU interfaces changed a lot since 2011, so I had to modify the
sources quite a bit, but with the attached patches, it is now possible
to boot up to the firmware monitor again.

Note that boot device emulation is either still missing (network), or
not working correctly yet (SCSI), so you can not boot any operating
systems with this machine yet.

Please ignore the checkpatch warnings about C99 "//" comments. There
are many of those in the sources, used to comment out alternative code
lines. I did not want to remove those yet, since some of them could
still be helpful while improving the machine emulation in the future.

Thomas Huth (4):
  m68k: Add NeXTcube framebuffer device emulation
  m68k: Add NeXTcube keyboard device
  m68k: Add NeXTcube machine
  m68k: Add an entry for the NeXTcube machine to the MAINTAINERS file

 MAINTAINERS                      |    7 +
 default-configs/m68k-softmmu.mak |    4 +
 hw/display/Makefile.objs         |    1 +
 hw/display/next-fb.c             |  152 ++++
 hw/m68k/Makefile.objs            |    5 +-
 hw/m68k/next-cube.c              | 1103 ++++++++++++++++++++++++++++++
 hw/m68k/next-kbd.c               |  289 ++++++++
 include/hw/m68k/next-cube.h      |   49 ++
 8 files changed, 1608 insertions(+), 2 deletions(-)
 create mode 100644 hw/display/next-fb.c
 create mode 100644 hw/m68k/next-cube.c
 create mode 100644 hw/m68k/next-kbd.c
 create mode 100644 include/hw/m68k/next-cube.h

-- 
2.17.1

[Qemu-devel] [PATCH v1 1/4] m68k: Add NeXTcube framebuffer device emulation

[Thomas Huth]

The NeXTcube uses a linear framebuffer with 4 greyscale colors and
a fixed resolution of 1120 * 832.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at

 https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c

and altered to fit the latest interface of the current QEMU (e.g.
the device has been "qdev"-ified etc.).

Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
 default-configs/m68k-softmmu.mak |   2 +
 hw/display/Makefile.objs         |   1 +
 hw/display/next-fb.c             | 152 +++++++++++++++++++++++++++++++
 include/hw/m68k/next-cube.h      |   8 ++
 4 files changed, 163 insertions(+)
 create mode 100644 hw/display/next-fb.c
 create mode 100644 include/hw/m68k/next-cube.h

diff --git a/default-configs/m68k-softmmu.mak b/default-configs/m68k-softmmu.mak
index 60f7cdfbf2..d3248a6506 100644
--- a/default-configs/m68k-softmmu.mak
+++ b/default-configs/m68k-softmmu.mak
@@ -2,3 +2,5 @@
 
 CONFIG_COLDFIRE=y
 CONFIG_PTIMER=y
+CONFIG_NEXTCUBE=y
+CONFIG_FRAMEBUFFER=y
diff --git a/hw/display/Makefile.objs b/hw/display/Makefile.objs
index fb8408c6d0..c91a660ad2 100644
--- a/hw/display/Makefile.objs
+++ b/hw/display/Makefile.objs
@@ -34,6 +34,7 @@ obj-$(CONFIG_RASPI) += bcm2835_fb.o
 obj-$(CONFIG_SM501) += sm501.o
 obj-$(CONFIG_TCX) += tcx.o
 obj-$(CONFIG_CG3) += cg3.o
+obj-$(CONFIG_NEXTCUBE) += next-fb.o
 
 obj-$(CONFIG_VGA) += vga.o
 
diff --git a/hw/display/next-fb.c b/hw/display/next-fb.c
new file mode 100644
index 0000000000..f4248405df
--- /dev/null
+++ b/hw/display/next-fb.c
@@ -0,0 +1,152 @@
+/*
+ * NeXT Cube/Station Framebuffer Emulation
+ *
+ * Copyright (c) 2011 Bryce Lanham
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "qemu/osdep.h"
+#include "hw/hw.h"
+#include "hw/boards.h"
+#include "hw/loader.h"
+#include "hw/display/framebuffer.h"
+#include "ui/console.h"
+#define BITS 8
+#include "ui/pixel_ops.h"
+#include "hw/m68k/next-cube.h"
+
+#define TYPE_NEXTFB "next-fb"
+#define NEXTFB(obj) OBJECT_CHECK(NeXTFbState, (obj), TYPE_NEXTFB)
+
+struct NeXTFbState {
+    SysBusDevice parent_obj;
+
+    MemoryRegion fb_mr;
+    MemoryRegionSection fbsection;
+    QemuConsole *con;
+
+    uint32_t pitch;
+    uint32_t cols;
+    uint32_t rows;
+    int invalidate;
+};
+typedef struct NeXTFbState NeXTFbState;
+
+static void nextfb_draw_line(void *opaque, uint8_t *d, const uint8_t *s,
+                             int width, int pitch)
+{
+    NeXTFbState *nfbstate = NEXTFB(opaque);
+    uint32_t pal[4] = { 0xFFFFFFFF, 0xFFAAAAAA, 0xFF555555, 0xFF000000 };
+    uint32_t *buf = (uint32_t *)d;
+    int i = 0;
+
+    for (i = 0; i < nfbstate->cols / 4; i++) {
+        int j = i * 4;
+        uint8_t src = s[i];
+        buf[j + 3] = pal[src & 0x3];
+        src >>= 2;
+        buf[j + 2] = pal[src & 0x3];
+        src >>= 2;
+        buf[j + 1] = pal[src & 0x3];
+        src >>= 2;
+        buf[j + 0] = pal[src & 0x3];
+    }
+}
+
+static void nextfb_update(void *opaque)
+{
+    NeXTFbState *s = NEXTFB(opaque);
+    int dest_width = 4;
+    int src_width;
+    int first = 0;
+    int last  = 0;
+    DisplaySurface *surface = qemu_console_surface(s->con);
+
+    src_width = s->cols / 4 + 8;
+    dest_width = s->cols * 4;
+
+    if (s->invalidate) {
+        framebuffer_update_memory_section(&s->fbsection, &s->fb_mr, 0,
+                                          s->cols, src_width);
+        s->invalidate = 0;
+    }
+
+    framebuffer_update_display(surface, &s->fbsection, 1120, 832,
+                               src_width, dest_width, 0, 1, nextfb_draw_line,
+                               s, &first, &last);
+
+    dpy_gfx_update(s->con, 0, 0, 1120, 832);
+}
+
+static void nextfb_invalidate(void *opaque)
+{
+    NeXTFbState *s = NEXTFB(opaque);
+    s->invalidate = 1;
+}
+
+static const GraphicHwOps nextfb_ops = {
+    .invalidate  = nextfb_invalidate,
+    .gfx_update  = nextfb_update,
+};
+
+static void nextfb_realize(DeviceState *dev, Error **errp)
+{
+    NeXTFbState *s = NEXTFB(dev);
+
+    memory_region_allocate_system_memory(&s->fb_mr, NULL, "next.video",
+                                         0x1CB100);
+    memory_region_add_subregion(get_system_memory(), 0xB000000, &s->fb_mr);
+
+    s->invalidate = 1;
+    s->cols = 1120;
+    s->rows = 832;
+
+    s->con = graphic_console_init(dev, 0, &nextfb_ops, s);
+    qemu_console_resize(s->con, s->cols, s->rows);
+}
+
+static void nextfb_class_init(ObjectClass *oc, void *data)
+{
+    DeviceClass *dc = DEVICE_CLASS(oc);
+
+    set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
+    dc->realize = nextfb_realize;
+}
+
+static const TypeInfo nextfb_info = {
+    .name          = TYPE_NEXTFB,
+    .parent        = TYPE_SYS_BUS_DEVICE,
+    .instance_size = sizeof(NeXTFbState),
+    .class_init    = nextfb_class_init,
+};
+
+static void nextfb_register_types(void)
+{
+    type_register_static(&nextfb_info);
+}
+
+type_init(nextfb_register_types)
+
+void nextfb_init(void)
+{
+    DeviceState *dev;
+
+    dev = qdev_create(NULL, TYPE_NEXTFB);
+    qdev_init_nofail(dev);
+}
diff --git a/include/hw/m68k/next-cube.h b/include/hw/m68k/next-cube.h
new file mode 100644
index 0000000000..cf07243bda
--- /dev/null
+++ b/include/hw/m68k/next-cube.h
@@ -0,0 +1,8 @@
+
+#ifndef NEXT_CUBE_H
+#define NEXT_CUBE_H
+
+/* next-fb.c */
+void nextfb_init(void);
+
+#endif /* NEXT_CUBE_H */
-- 
2.17.1

[Qemu-devel] [PATCH v1 2/4] m68k: Add NeXTcube keyboard device

[Thomas Huth]

It is likely still quite incomplete (e.g. mouse and interrupts are not
implemented yet), but it is good enough for keyboard input at the firmware
monitor.
This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at

 https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-kbd.c

and altered to fit the latest interface of the current QEMU (e.g. to use
memory_region_init_io() instead of cpu_register_physical_memory()).

Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
 hw/m68k/Makefile.objs       |   5 +-
 hw/m68k/next-kbd.c          | 289 ++++++++++++++++++++++++++++++++++++
 include/hw/m68k/next-cube.h |   3 +
 3 files changed, 295 insertions(+), 2 deletions(-)
 create mode 100644 hw/m68k/next-kbd.c

diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
index d1f089c08a..5852fd2500 100644
--- a/hw/m68k/Makefile.objs
+++ b/hw/m68k/Makefile.objs
@@ -1,2 +1,3 @@
-obj-y += an5206.o mcf5208.o
-obj-y += mcf5206.o mcf_intc.o
+obj-$(CONFIG_COLDFIRE) += an5206.o mcf5208.o
+obj-$(CONFIG_COLDFIRE) += mcf5206.o mcf_intc.o
+obj-$(CONFIG_NEXTCUBE) += next-kbd.o
diff --git a/hw/m68k/next-kbd.c b/hw/m68k/next-kbd.c
new file mode 100644
index 0000000000..0c4655f586
--- /dev/null
+++ b/hw/m68k/next-kbd.c
@@ -0,0 +1,289 @@
+/*
+ * QEMU NeXT Keyboard/Mouse emulation
+ *
+ * Copyright (c) 2011 Bryce Lanham
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/*
+ * This is admittedly hackish, but works well enough for basic input. Mouse
+ * support will be added once we can boot something that needs the mouse.
+ */
+
+#include "qemu/osdep.h"
+#include "exec/address-spaces.h"
+#include "hw/hw.h"
+#include "hw/m68k/next-cube.h"
+#include "ui/console.h"
+#include "sysemu/sysemu.h"
+
+/* debug NeXT keyboard */
+//#define DEBUG_KBD
+
+#ifdef DEBUG_KBD
+#define DPRINTF(fmt, ...) do { printf("KBD: " fmt , ## __VA_ARGS__); } while (0)
+#else
+#define DPRINTF(fmt, ...) do { } while (0)
+#endif
+
+/* following defintions from next68k netbsd */
+#define CSR_INT 0x00800000
+#define CSR_DATA 0x00400000
+
+#define KD_KEYMASK    0x007f
+#define KD_DIRECTION  0x0080 /* pressed or released */
+#define KD_CNTL       0x0100
+#define KD_LSHIFT     0x0200
+#define KD_RSHIFT     0x0400
+#define KD_LCOMM      0x0800
+#define KD_RCOMM      0x1000
+#define KD_LALT       0x2000
+#define KD_RALT       0x4000
+#define KD_VALID      0x8000 /* only set for scancode keys ? */
+#define KD_MODS       0x4f00
+
+#define KBD_QUEUE_SIZE 256
+
+typedef struct {
+    uint8_t data[KBD_QUEUE_SIZE];
+    int rptr, wptr, count;
+} KBDQueue;
+
+
+typedef struct KBDState {
+    KBDQueue queue;
+    uint8_t blank;
+    uint16_t shift;
+} KBDState;
+KBDState *kbd_env;
+
+static void queue_code(void *opaque, int code);
+
+/* lots of magic numbers here */
+static uint32_t kbd_read_byte(void *opaque, hwaddr addr)
+{
+    switch (addr & 0x3) {
+    case 0x0:   /* 0xe000 */
+        return 0x80 | 0x20;
+
+    case 0x1:   /* 0xe001 */
+        return 0x80 | 0x40 | 0x20 | 0x10;
+
+    case 0x2:   /* 0xe002 */
+        // return 0x40|0x10|0x2|0x1;
+        /* returning 0x40 caused mach to hang */
+        return 0x10 | 0x2 | 0x1;
+
+    default:
+        DPRINTF("RB ADDR %x\n", addr);
+    }
+
+    return 0;
+}
+
+static uint32_t kbd_read_word(void *opaque, hwaddr addr)
+{
+    DPRINTF("RW ADDR %x\n", addr);
+    return 0;
+}
+
+/* even more magic numbers */
+static uint32_t kbd_read_long(void *opaque, hwaddr addr)
+{
+    int key = 0;
+    KBDState *s = (KBDState *)opaque;
+    KBDQueue *q = &s->queue;
+
+    switch (addr & 0xf) {
+    case 0x0:   /* 0xe000 */
+        // DPRINTF("KB L Read: @ %X\n", pc);
+        return 0xA0F09300;
+
+    case 0x8:   /* 0xe008 */
+        /* get keycode from buffer */
+        if (q->count > 0) {
+            key = q->data[q->rptr];
+            if (++q->rptr == KBD_QUEUE_SIZE) {
+                q->rptr = 0;
+            }
+
+            q->count--;
+
+            if (s->shift) {
+                key |= s->shift;
+            }
+
+            if (key & 0x80) {
+                return 0;
+            } else {
+                return 0x10000000 | KD_VALID | key;
+            }
+        } else {
+            return 0;
+        }
+
+    default:
+        DPRINTF("RL ADDR %x\n", addr);
+        return 0;
+    }
+}
+
+static void kbd_write_byte(void *opaque, hwaddr addr, uint32_t val)
+{
+    DPRINTF("WB ADDR %x\n", addr);
+}
+static void kbd_write_word(void *opaque, hwaddr addr, uint32_t val)
+{
+    DPRINTF("WW ADDR %x\n", addr);
+}
+static void kbd_write_long(void *opaque, hwaddr addr, uint32_t val)
+{
+    DPRINTF("WL ADDR %x\n", addr);
+}
+
+static uint64_t kbd_readfn(void *opaque, hwaddr addr, unsigned size)
+{
+    switch (size) {
+    case 1:
+        return kbd_read_byte(opaque, addr);
+    case 2:
+        return kbd_read_word(opaque, addr);
+    case 4:
+        return kbd_read_long(opaque, addr);
+    default:
+        g_assert_not_reached();
+    }
+}
+
+static void kbd_writefn(void *opaque, hwaddr addr, uint64_t value,
+                        unsigned size)
+{
+    switch (size) {
+    case 1:
+        kbd_write_byte(opaque, addr, value);
+        break;
+    case 2:
+        kbd_write_word(opaque, addr, value);
+        break;
+    case 4:
+        kbd_write_long(opaque, addr, value);
+        break;
+    default:
+        g_assert_not_reached();
+    }
+}
+
+static const MemoryRegionOps kbd_ops = {
+    .read = kbd_readfn,
+    .write = kbd_writefn,
+    .valid.min_access_size = 1,
+    .valid.max_access_size = 4,
+    .endianness = DEVICE_NATIVE_ENDIAN,
+};
+
+static void nextkbd_event(void *opaque, int ch)
+{
+    /* Will want to set vars for caps/num lock */
+    /* if (ch & 0x80) -> key release */
+    /* there's also e0 escaped scancodes that might need to be handled */
+    DPRINTF("EVENT %X\n", ch);
+
+    queue_code(opaque, ch);
+}
+
+static const unsigned char next_keycodes[128] = {
+    0x00, 0x49, 0x4A, 0x4B, 0x4C, 0x4D, 0x50, 0x4F,
+    0x4E, 0x1E, 0x1F, 0x20, 0x1D, 0x1C, 0x1B, 0x00,
+    0x42, 0x43, 0x44, 0x45, 0x48, 0x47, 0x46, 0x06,
+    0x07, 0x08, 0x00, 0x00, 0x2A, 0x00, 0x39, 0x3A,
+    0x3B, 0x3C, 0x3D, 0x40, 0x3F, 0x3E, 0x2D, 0x2C,
+    0x2B, 0x26, 0x00, 0x00, 0x31, 0x32, 0x33, 0x34,
+    0x35, 0x37, 0x36, 0x2e, 0x2f, 0x30, 0x00, 0x00,
+    0x00, 0x38, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
+    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
+    0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+};
+
+static void queue_code(void *opaque, int code)
+{
+    KBDState *s = (KBDState *)opaque;
+    KBDQueue *q = &s->queue;
+    int key = code & 0x7F;
+    int release = code & 0x80;
+    static int ext;
+
+    if (code == 0xE0) {
+        ext = 1;
+    }
+
+    if (code == 0x2A || code == 0x1D || code == 0x36) {
+        if (code == 0x2A) {
+            s->shift = KD_LSHIFT;
+        } else if (code == 0x36) {
+            s->shift = KD_RSHIFT;
+            ext = 0;
+        } else if (code == 0x1D && !ext) {
+            s->shift = KD_LCOMM;
+        } else if (code == 0x1D && ext) {
+            ext = 0;
+            s->shift = KD_RCOMM;
+        }
+        return;
+    } else if (code == (0x2A | 0x80) || code == (0x1D | 0x80) ||
+               code == (0x36 | 0x80)) {
+        s->shift = 0;
+        return;
+    }
+
+    if (q->count >= KBD_QUEUE_SIZE) {
+        return;
+    }
+
+    q->data[q->wptr] = next_keycodes[key] | release;
+
+    if (++q->wptr == KBD_QUEUE_SIZE) {
+        q->wptr = 0;
+    }
+
+    q->count++;
+
+    /*
+     * might need to actually trigger the NeXT irq, but as the keyboard works
+     * at the moment, I'll worry about it later
+     */
+    // s->update_irq(s->update_arg, 1);
+
+    s->blank += 1;
+}
+
+void nextkbd_init(void)
+{
+    KBDState *s = g_new0(KBDState, 1);
+    MemoryRegion *kbdmem = g_new(MemoryRegion, 1);
+
+    s->shift = 0;
+
+    memory_region_init_io(kbdmem, NULL, &kbd_ops, s, "next.kbd", 0x1000);
+    memory_region_add_subregion(get_system_memory(), 0x200e000, kbdmem);
+
+    qemu_add_kbd_event_handler(nextkbd_event, s);
+}
diff --git a/include/hw/m68k/next-cube.h b/include/hw/m68k/next-cube.h
index cf07243bda..88e94f6595 100644
--- a/include/hw/m68k/next-cube.h
+++ b/include/hw/m68k/next-cube.h
@@ -5,4 +5,7 @@
 /* next-fb.c */
 void nextfb_init(void);
 
+/* next-kbd.c  */
+void nextkbd_init(void);
+
 #endif /* NEXT_CUBE_H */
-- 
2.17.1

[Qemu-devel] [PATCH v1 4/4] m68k: Add an entry for the NeXTcube machine to the MAINTAINERS file

[Thomas Huth]

I don't have much clue about the NeXT hardware, but at least I know now
the source files a little bit, so I volunteer to pick up patches and send
PULL requests for them until someone else with more knowledge steps up
to do this job instead.

Signed-off-by: Thomas Huth <huth@tuxfamily.org>
---
 MAINTAINERS | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 42a1892d6a..7b8c0511a6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -693,6 +693,13 @@ F: hw/char/mcf_uart.c
 F: hw/net/mcf_fec.c
 F: include/hw/m68k/mcf*.h
 
+NeXTcube
+M: Thomas Huth <huth@tuxfamily.org>
+S: Odd Fixes
+F: hw/m68k/next-*.c
+F: hw/display/next-fb.c
+F: include/hw/m68k/next-cube.h
+
 MicroBlaze Machines
 -------------------
 petalogix_s3adsp1800
-- 
2.17.1

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Mark Cave-Ayland]

On 30/06/18 09:33, Thomas Huth wrote:

> During Google Summer of Code 2011, Bryce Lanham added the possibility to
> emulate the NeXTcube machine in QEMU, e.g. see this URL for some details:
> 
> https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation
> 
> But since the machine requires a 68040 CPU and this was not included in
> upstream QEMU in 2011 yet, the patches have never been merged to upstream.
> Now in 2018, Laurent completed the full 680x0 support in upstream QEMU, so
> we could finally merge the NeXTcube support, too.
> 
> The QEMU interfaces changed a lot since 2011, so I had to modify the
> sources quite a bit, but with the attached patches, it is now possible
> to boot up to the firmware monitor again.
> 
> Note that boot device emulation is either still missing (network), or
> not working correctly yet (SCSI), so you can not boot any operating
> systems with this machine yet.
> 
> Please ignore the checkpatch warnings about C99 "//" comments. There
> are many of those in the sources, used to comment out alternative code
> lines. I did not want to remove those yet, since some of them could
> still be helpful while improving the machine emulation in the future.
> 
> Thomas Huth (4):
>    m68k: Add NeXTcube framebuffer device emulation
>    m68k: Add NeXTcube keyboard device
>    m68k: Add NeXTcube machine
>    m68k: Add an entry for the NeXTcube machine to the MAINTAINERS file
> 
>   MAINTAINERS                      |    7 +
>   default-configs/m68k-softmmu.mak |    4 +
>   hw/display/Makefile.objs         |    1 +
>   hw/display/next-fb.c             |  152 ++++
>   hw/m68k/Makefile.objs            |    5 +-
>   hw/m68k/next-cube.c              | 1103 ++++++++++++++++++++++++++++++
>   hw/m68k/next-kbd.c               |  289 ++++++++
>   include/hw/m68k/next-cube.h      |   49 ++
>   8 files changed, 1608 insertions(+), 2 deletions(-)
>   create mode 100644 hw/display/next-fb.c
>   create mode 100644 hw/m68k/next-cube.c
>   create mode 100644 hw/m68k/next-kbd.c
>   create mode 100644 include/hw/m68k/next-cube.h

Looks like the most interesting patch (patch 3) has been blocked 
somewhere, presumably because it is quite large.

Is there a git repository for this patch series somewhere for the curious?


ATB,

Mark.

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Thomas Huth]

Am Sat, 30 Jun 2018 10:42:56 +0100
schrieb Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>:

> On 30/06/18 09:33, Thomas Huth wrote:
> 
> > During Google Summer of Code 2011, Bryce Lanham added the
> > possibility to emulate the NeXTcube machine in QEMU, e.g. see this
> > URL for some details:
> > 
> > https://wiki.qemu.org/Google_Summer_of_Code_2011#NeXT_machines_system_emulation
> > 
> > But since the machine requires a 68040 CPU and this was not
> > included in upstream QEMU in 2011 yet, the patches have never been
> > merged to upstream. Now in 2018, Laurent completed the full 680x0
> > support in upstream QEMU, so we could finally merge the NeXTcube
> > support, too.
> > 
> > The QEMU interfaces changed a lot since 2011, so I had to modify the
> > sources quite a bit, but with the attached patches, it is now
> > possible to boot up to the firmware monitor again.
> > 
> > Note that boot device emulation is either still missing (network),
> > or not working correctly yet (SCSI), so you can not boot any
> > operating systems with this machine yet.
> > 
> > Please ignore the checkpatch warnings about C99 "//" comments. There
> > are many of those in the sources, used to comment out alternative
> > code lines. I did not want to remove those yet, since some of them
> > could still be helpful while improving the machine emulation in the
> > future.
> > 
> > Thomas Huth (4):
> >    m68k: Add NeXTcube framebuffer device emulation
> >    m68k: Add NeXTcube keyboard device
> >    m68k: Add NeXTcube machine
> >    m68k: Add an entry for the NeXTcube machine to the MAINTAINERS
> > file
[...]
> Looks like the most interesting patch (patch 3) has been blocked 
> somewhere, presumably because it is quite large.

Weird... the mail was ca. 1200 lines ... that not small, but not so
big that I'd expect that it would get blocked somewhere. Let's wait
some more more hours, maybe the spam filter is just very slow today. If
it is then still not available on the list, I'll try to send it out
again.

> Is there a git repository for this patch series somewhere for the
> curious?

I just pushed it here:

https://gitlab.com/huth/qemu/tree/next-cube

 Thomas

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Peter Maydell]

On 30 June 2018 at 14:14, Thomas Huth <huth@tuxfamily.org> wrote:
> Weird... the mail was ca. 1200 lines ... that not small, but not so
> big that I'd expect that it would get blocked somewhere. Let's wait
> some more more hours, maybe the spam filter is just very slow today. If
> it is then still not available on the list, I'll try to send it out
> again.

The mailing list does just occasionally randomly eat patches,
as far as I can tell. It's not purely a size thing.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Thomas Huth]

Am Sat, 30 Jun 2018 14:17:32 +0100
schrieb Peter Maydell <peter.maydell@linaro.org>:

> On 30 June 2018 at 14:14, Thomas Huth <huth@tuxfamily.org> wrote:
> > Weird... the mail was ca. 1200 lines ... that not small, but not so
> > big that I'd expect that it would get blocked somewhere. Let's wait
> > some more more hours, maybe the spam filter is just very slow
> > today. If it is then still not available on the list, I'll try to
> > send it out again.  
> 
> The mailing list does just occasionally randomly eat patches,
> as far as I can tell. It's not purely a size thing.

Ok, good to know. I've just sent out patch 3/4 again, let's see how it
goes.

 Thomas

Re: [Qemu-devel] [PATCH v1 1/4] m68k: Add NeXTcube framebuffer device emulation

[Richard Henderson]

On 06/30/2018 01:33 AM, Thomas Huth wrote:
> +    uint32_t pal[4] = { 0xFFFFFFFF, 0xFFAAAAAA, 0xFF555555, 0xFF000000 };

static const.

Otherwise,
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>


r~

Re: [Qemu-devel] [PATCH v1 1/4] m68k: Add NeXTcube framebuffer device emulation

[Peter Maydell]

On 30 June 2018 at 09:33, Thomas Huth <huth@tuxfamily.org> wrote:
> The NeXTcube uses a linear framebuffer with 4 greyscale colors and
> a fixed resolution of 1120 * 832.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
>  https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
>
> and altered to fit the latest interface of the current QEMU (e.g.
> the device has been "qdev"-ified etc.).
>
> Signed-off-by: Thomas Huth <huth@tuxfamily.org>

> +static void nextfb_realize(DeviceState *dev, Error **errp)
> +{
> +    NeXTFbState *s = NEXTFB(dev);
> +
> +    memory_region_allocate_system_memory(&s->fb_mr, NULL, "next.video",
> +                                         0x1CB100);

memory_region_allocate_system_memory() is for allocating
a machine model's main memory, not for things like video
framebuffer RAM. (See the doc comment in memory.h.)

> +    memory_region_add_subregion(get_system_memory(), 0xB000000, &s->fb_mr);

Devices shouldn't directly add memory regions into
system memory. Instead they should expose sysbus
memory regions which the board model then maps into
the right place.

> +
> +    s->invalidate = 1;
> +    s->cols = 1120;
> +    s->rows = 832;
> +
> +    s->con = graphic_console_init(dev, 0, &nextfb_ops, s);
> +    qemu_console_resize(s->con, s->cols, s->rows);
> +}
> +
> +static void nextfb_class_init(ObjectClass *oc, void *data)
> +{
> +    DeviceClass *dc = DEVICE_CLASS(oc);
> +
> +    set_bit(DEVICE_CATEGORY_DISPLAY, dc->categories);
> +    dc->realize = nextfb_realize;

Worth having at least a comment to say this device has
no mutable state and so needs no reset function or
vmstate.

> +}
> +
> +static const TypeInfo nextfb_info = {
> +    .name          = TYPE_NEXTFB,
> +    .parent        = TYPE_SYS_BUS_DEVICE,
> +    .instance_size = sizeof(NeXTFbState),
> +    .class_init    = nextfb_class_init,
> +};
> +
> +static void nextfb_register_types(void)
> +{
> +    type_register_static(&nextfb_info);
> +}
> +
> +type_init(nextfb_register_types)
> +
> +void nextfb_init(void)
> +{
> +    DeviceState *dev;
> +
> +    dev = qdev_create(NULL, TYPE_NEXTFB);
> +    qdev_init_nofail(dev);
> +}

This is so simple it's not really worth having, I think.
Just have the board model code create the device...

> diff --git a/include/hw/m68k/next-cube.h b/include/hw/m68k/next-cube.h
> new file mode 100644
> index 0000000000..cf07243bda
> --- /dev/null
> +++ b/include/hw/m68k/next-cube.h
> @@ -0,0 +1,8 @@
> +
> +#ifndef NEXT_CUBE_H
> +#define NEXT_CUBE_H
> +
> +/* next-fb.c */
> +void nextfb_init(void);
> +
> +#endif /* NEXT_CUBE_H */

New header files should have copyright and license comment headers
too, though in this case if you drop the nextfb_init() function
then the header isn't needed any more.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 2/4] m68k: Add NeXTcube keyboard device

[Peter Maydell]

On 30 June 2018 at 09:33, Thomas Huth <huth@tuxfamily.org> wrote:
> It is likely still quite incomplete (e.g. mouse and interrupts are not
> implemented yet), but it is good enough for keyboard input at the firmware
> monitor.
> This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch at
>
>  https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-kbd.c
>
> and altered to fit the latest interface of the current QEMU (e.g. to use
> memory_region_init_io() instead of cpu_register_physical_memory()).
>
> Signed-off-by: Thomas Huth <huth@tuxfamily.org>
> ---
>  hw/m68k/Makefile.objs       |   5 +-
>  hw/m68k/next-kbd.c          | 289 ++++++++++++++++++++++++++++++++++++
>  include/hw/m68k/next-cube.h |   3 +
>  3 files changed, 295 insertions(+), 2 deletions(-)
>  create mode 100644 hw/m68k/next-kbd.c
>
> diff --git a/hw/m68k/Makefile.objs b/hw/m68k/Makefile.objs
> index d1f089c08a..5852fd2500 100644
> --- a/hw/m68k/Makefile.objs
> +++ b/hw/m68k/Makefile.objs
> @@ -1,2 +1,3 @@
> -obj-y += an5206.o mcf5208.o
> -obj-y += mcf5206.o mcf_intc.o
> +obj-$(CONFIG_COLDFIRE) += an5206.o mcf5208.o
> +obj-$(CONFIG_COLDFIRE) += mcf5206.o mcf_intc.o
> +obj-$(CONFIG_NEXTCUBE) += next-kbd.o
> diff --git a/hw/m68k/next-kbd.c b/hw/m68k/next-kbd.c
> new file mode 100644
> index 0000000000..0c4655f586
> --- /dev/null
> +++ b/hw/m68k/next-kbd.c
> @@ -0,0 +1,289 @@
> +/*
> + * QEMU NeXT Keyboard/Mouse emulation
> + *
> + * Copyright (c) 2011 Bryce Lanham
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a copy
> + * of this software and associated documentation files (the "Software"), to deal
> + * in the Software without restriction, including without limitation the rights
> + * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
> + * copies of the Software, and to permit persons to whom the Software is
> + * furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice shall be included in
> + * all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
> + * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
> + * THE SOFTWARE.
> + */
> +
> +/*
> + * This is admittedly hackish, but works well enough for basic input. Mouse
> + * support will be added once we can boot something that needs the mouse.
> + */
> +
> +#include "qemu/osdep.h"
> +#include "exec/address-spaces.h"
> +#include "hw/hw.h"
> +#include "hw/m68k/next-cube.h"
> +#include "ui/console.h"
> +#include "sysemu/sysemu.h"
> +
> +/* debug NeXT keyboard */
> +//#define DEBUG_KBD
> +
> +#ifdef DEBUG_KBD
> +#define DPRINTF(fmt, ...) do { printf("KBD: " fmt , ## __VA_ARGS__); } while (0)
> +#else
> +#define DPRINTF(fmt, ...) do { } while (0)
> +#endif
> +
> +/* following defintions from next68k netbsd */
> +#define CSR_INT 0x00800000
> +#define CSR_DATA 0x00400000
> +
> +#define KD_KEYMASK    0x007f
> +#define KD_DIRECTION  0x0080 /* pressed or released */
> +#define KD_CNTL       0x0100
> +#define KD_LSHIFT     0x0200
> +#define KD_RSHIFT     0x0400
> +#define KD_LCOMM      0x0800
> +#define KD_RCOMM      0x1000
> +#define KD_LALT       0x2000
> +#define KD_RALT       0x4000
> +#define KD_VALID      0x8000 /* only set for scancode keys ? */
> +#define KD_MODS       0x4f00
> +
> +#define KBD_QUEUE_SIZE 256
> +
> +typedef struct {
> +    uint8_t data[KBD_QUEUE_SIZE];
> +    int rptr, wptr, count;
> +} KBDQueue;
> +
> +
> +typedef struct KBDState {
> +    KBDQueue queue;
> +    uint8_t blank;
> +    uint16_t shift;
> +} KBDState;

I'm sceptical that the real hardware has a 256 byte queue
like this...

> +KBDState *kbd_env;

What is this global for?

> +void nextkbd_init(void)
> +{
> +    KBDState *s = g_new0(KBDState, 1);
> +    MemoryRegion *kbdmem = g_new(MemoryRegion, 1);
> +
> +    s->shift = 0;
> +
> +    memory_region_init_io(kbdmem, NULL, &kbd_ops, s, "next.kbd", 0x1000);
> +    memory_region_add_subregion(get_system_memory(), 0x200e000, kbdmem);
> +
> +    qemu_add_kbd_event_handler(nextkbd_event, s);
> +}

This needs to be a proper QOM device (and this one does have
internal state so needs reset and vmstate).

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Bryce Lanham]

Oh hi!

Luckily gmail brought this to the top since I don’t pay attention to the
list. I’m away from my computer at the moment, but I had more than this
working, including interrupts, Ethernet, and SCSI for sure. (
https://i.imgur.com/Py0FO.png) I’d love to dive back into this now that
68040 support is complete and merged.


On Sat, Jun 30, 2018 at 8:34 AM, Thomas Huth <huth@tuxfamily.org> wrote:

> Am Sat, 30 Jun 2018 14:17:32 +0100
> schrieb Peter Maydell <peter.maydell@linaro.org>:
>
> > On 30 June 2018 at 14:14, Thomas Huth <huth@tuxfamily.org> wrote:
> > > Weird... the mail was ca. 1200 lines ... that not small, but not so
> > > big that I'd expect that it would get blocked somewhere. Let's wait
> > > some more more hours, maybe the spam filter is just very slow
> > > today. If it is then still not available on the list, I'll try to
> > > send it out again.
> >
> > The mailing list does just occasionally randomly eat patches,
> > as far as I can tell. It's not purely a size thing.
>
> Ok, good to know. I've just sent out patch 3/4 again, let's see how it
> goes.
>
>  Thomas
>

Re: [Qemu-devel] [PATCH v1 1/4] m68k: Add NeXTcube framebuffer device emulation

[Thomas Huth]

Am Sat, 30 Jun 2018 17:12:01 +0100
schrieb Peter Maydell <peter.maydell@linaro.org>:

> On 30 June 2018 at 09:33, Thomas Huth <huth@tuxfamily.org> wrote:
> > The NeXTcube uses a linear framebuffer with 4 greyscale colors and
> > a fixed resolution of 1120 * 832.
> > This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch
> > at
> >
> >  https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
> >
> > and altered to fit the latest interface of the current QEMU (e.g.
> > the device has been "qdev"-ified etc.).
> >
> > Signed-off-by: Thomas Huth <huth@tuxfamily.org>  
> 
> > +static void nextfb_realize(DeviceState *dev, Error **errp)
> > +{
> > +    NeXTFbState *s = NEXTFB(dev);
> > +
> > +    memory_region_allocate_system_memory(&s->fb_mr, NULL,
> > "next.video",
> > +                                         0x1CB100);  
> 
> memory_region_allocate_system_memory() is for allocating
> a machine model's main memory, not for things like video
> framebuffer RAM. (See the doc comment in memory.h.)

That comment recommends memory_region_allocate_aux_memory(), but
that function does not exist (anymore)?

> > +    memory_region_add_subregion(get_system_memory(), 0xB000000,
> > &s->fb_mr);  
> 
> Devices shouldn't directly add memory regions into
> system memory. Instead they should expose sysbus
> memory regions which the board model then maps into
> the right place.

Ok, ... so just to make sure that I've got you right: The device
should call memory_region_init_ram() in it's realize function and the
board code should then call sysbus_mmio_map() with that region, right?

 Thomas

Re: [Qemu-devel] [PATCH v1 1/4] m68k: Add NeXTcube framebuffer device emulation

[Peter Maydell]

On 30 June 2018 at 20:47, Thomas Huth <huth@tuxfamily.org> wrote:
> Am Sat, 30 Jun 2018 17:12:01 +0100
> schrieb Peter Maydell <peter.maydell@linaro.org>:
>
>> On 30 June 2018 at 09:33, Thomas Huth <huth@tuxfamily.org> wrote:
>> > The NeXTcube uses a linear framebuffer with 4 greyscale colors and
>> > a fixed resolution of 1120 * 832.
>> > This code has been taken from Bryce Lanham's GSoC 2011 NeXT branch
>> > at
>> >
>> >  https://github.com/blanham/qemu-NeXT/blob/next-cube/hw/next-fb.c
>> >
>> > and altered to fit the latest interface of the current QEMU (e.g.
>> > the device has been "qdev"-ified etc.).
>> >
>> > Signed-off-by: Thomas Huth <huth@tuxfamily.org>
>>
>> > +static void nextfb_realize(DeviceState *dev, Error **errp)
>> > +{
>> > +    NeXTFbState *s = NEXTFB(dev);
>> > +
>> > +    memory_region_allocate_system_memory(&s->fb_mr, NULL,
>> > "next.video",
>> > +                                         0x1CB100);
>>
>> memory_region_allocate_system_memory() is for allocating
>> a machine model's main memory, not for things like video
>> framebuffer RAM. (See the doc comment in memory.h.)
>
> That comment recommends memory_region_allocate_aux_memory(), but
> that function does not exist (anymore)?

Oops, good catch. That's a leftover comment that should have
been updated -- we changed the function name during discussion
of the patchset, I think, but I forgot to fix the comment.
I'll send a patch to fix that next week.

You want memory_region_init_ram() (which does both the MR
init and the mark-this-ram-for-migration).

>> > +    memory_region_add_subregion(get_system_memory(), 0xB000000,
>> > &s->fb_mr);
>>
>> Devices shouldn't directly add memory regions into
>> system memory. Instead they should expose sysbus
>> memory regions which the board model then maps into
>> the right place.
>
> Ok, ... so just to make sure that I've got you right: The device
> should call memory_region_init_ram() in it's realize function and the
> board code should then call sysbus_mmio_map() with that region, right?

The device should call memory_region_init_ram() and then
sysbus_init_mmio(); then the board code can call
sysbus_mmio_map().

I have a feeling that for framebuffer devices you should
also do something involving DIRTY_MEMORY_VGA, but I'm
not really familiar enough with the display code to say
for sure.

thanks
-- PMM

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Thomas Huth]

Am Sat, 30 Jun 2018 12:07:01 -0500
schrieb Bryce Lanham <blanham@gmail.com>:

> Oh hi!
> 
> Luckily gmail brought this to the top since I don’t pay attention to
> the list. I’m away from my computer at the moment, but I had more
> than this working, including interrupts, Ethernet, and SCSI for sure.
> ( https://i.imgur.com/Py0FO.png) I’d love to dive back into this now
> that 68040 support is complete and merged.

 Hi Bryce,

great to hear that you are still around! If you like to take care of
this again, that would be very welcome! So I'll keep my hands off these
patches for now, and let you handle this again :-)

For what it's worth, I've pushed my final state of the patches here:

 https://gitlab.com/huth/qemu/tree/next-cube

I've also managed to get the next-nic.c code compilable again, but as I
mentioned earlier, it's currently not working anymore. Not sure, but I
think there is some wrong overlap in the memory mapping of the 0x110 and
0x150 DMA registers between next-nic.c and next-cube.c in there.

Anyway, feel free to use my patches as a base for your new work, or
simply ignore them if you prefer to start with your old codebase again.
Either way I'm just glad if we finally get an additional 68k machine in
QEMU :-)

 Cheers,
  Thomas

Re: [Qemu-devel] [PATCH v1 0/4] m68k: Add basic support for the NeXTcube machine

[Natalia Portillo]

[-- Attachment #1: Type: text/plain, Size: 1423 bytes --]

Now you've made me subscribe again to qemu-devel ;)

On 30/06/18 18:07, Bryce Lanham wrote:
> Oh hi! 
> 
> Luckily gmail brought this to the top since I don’t pay attention to the
> list. I’m away from my computer at the moment, but I had more than this
> working, including interrupts, Ethernet, and SCSI for sure.
> (https://i.imgur.com/Py0FO.png) I’d love to dive back into this now that
> 68040 support is complete and merged.
> 
> 
> On Sat, Jun 30, 2018 at 8:34 AM, Thomas Huth <huth@tuxfamily.org
> <mailto:huth@tuxfamily.org>> wrote:
> 
>     Am Sat, 30 Jun 2018 14:17:32 +0100
>     schrieb Peter Maydell <peter.maydell@linaro.org
>     <mailto:peter.maydell@linaro.org>>:
> 
>     > On 30 June 2018 at 14:14, Thomas Huth <huth@tuxfamily.org <mailto:huth@tuxfamily.org>> wrote:
>     > > Weird... the mail was ca. 1200 lines ... that not small, but not so
>     > > big that I'd expect that it would get blocked somewhere. Let's wait
>     > > some more more hours, maybe the spam filter is just very slow
>     > > today. If it is then still not available on the list, I'll try to
>     > > send it out again.  
>     > 
>     > The mailing list does just occasionally randomly eat patches,
>     > as far as I can tell. It's not purely a size thing.
> 
>     Ok, good to know. I've just sent out patch 3/4 again, let's see how it
>     goes.
> 
>      Thomas
> 
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]