[PATCH 0/5] m68k: Instantiate ESP and next-net in the next-cube machine

Thomas Huth posted 5 patches 7 months ago
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20230930132351.30282-1-huth@tuxfamily.org
Maintainers: Thomas Huth <huth@tuxfamily.org>, Jason Wang <jasowang@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <fam@euphon.net>
hw/m68k/next-cube.c         | 194 +++++++++----
hw/net/meson.build          |   1 +
hw/net/next-net.c           | 538 ++++++++++++++++++++++++++++++++++++
hw/scsi/esp.c               |   2 +-
include/hw/m68k/next-cube.h |  10 +
5 files changed, 692 insertions(+), 53 deletions(-)
create mode 100644 hw/net/next-net.c
[PATCH 0/5] m68k: Instantiate ESP and next-net in the next-cube machine
Posted by Thomas Huth 7 months ago
Mark Cave-Ayland recently asked me about the ESP patches for the
next-cube machine that I once posted a long time ago, but never
got it merged (since Mark is currently working on improving the
ESP device). With his help, I dusted off the ESP patch, but we
had to discover that the firmware also wants to see the NIC
device in the MMIO region, otherwise it often crashes or hangs.
So here's now the current set of patches for the next-cube machine.
Both, the ESP SCSI controller and the NIC do not properly work
yet, but at least the next-cube firmware gets much further now
during it selftest, so I think this is a good base for future
work and experiments.

Thomas Huth (5):
  hw/m68k/next-cube: Mirror BIOS to address 0
  hw/scsi/esp: Work around problem with PIO data read for the NeXT-Cube
    machine
  m68k: Instantiate the ESP SCSI controller for the NeXTcube machine
  hw/m68k/next-cube: Remove unused NEXTDMA_EN code
  m68k: Add NeXTcube network controller

 hw/m68k/next-cube.c         | 194 +++++++++----
 hw/net/meson.build          |   1 +
 hw/net/next-net.c           | 538 ++++++++++++++++++++++++++++++++++++
 hw/scsi/esp.c               |   2 +-
 include/hw/m68k/next-cube.h |  10 +
 5 files changed, 692 insertions(+), 53 deletions(-)
 create mode 100644 hw/net/next-net.c

-- 
2.41.0
Re: [PATCH 0/5] m68k: Instantiate ESP and next-net in the next-cube machine
Posted by Mark Cave-Ayland 7 months ago
On 30/09/2023 14:23, Thomas Huth wrote:

> Mark Cave-Ayland recently asked me about the ESP patches for the
> next-cube machine that I once posted a long time ago, but never
> got it merged (since Mark is currently working on improving the
> ESP device). With his help, I dusted off the ESP patch, but we
> had to discover that the firmware also wants to see the NIC
> device in the MMIO region, otherwise it often crashes or hangs.
> So here's now the current set of patches for the next-cube machine.
> Both, the ESP SCSI controller and the NIC do not properly work
> yet, but at least the next-cube firmware gets much further now
> during it selftest, so I think this is a good base for future
> work and experiments.
> 
> Thomas Huth (5):
>    hw/m68k/next-cube: Mirror BIOS to address 0
>    hw/scsi/esp: Work around problem with PIO data read for the NeXT-Cube
>      machine
>    m68k: Instantiate the ESP SCSI controller for the NeXTcube machine
>    hw/m68k/next-cube: Remove unused NEXTDMA_EN code
>    m68k: Add NeXTcube network controller
> 
>   hw/m68k/next-cube.c         | 194 +++++++++----
>   hw/net/meson.build          |   1 +
>   hw/net/next-net.c           | 538 ++++++++++++++++++++++++++++++++++++
>   hw/scsi/esp.c               |   2 +-
>   include/hw/m68k/next-cube.h |  10 +
>   5 files changed, 692 insertions(+), 53 deletions(-)
>   create mode 100644 hw/net/next-net.c

Thanks Thomas! So... just looking at this series (along with the existing NeXT 
files), it is obvious that the NeXT code hasn't been touched for some time. The 
problem I see with trying to bring the code in line with our current standards is 
that there are still quite a lot of experimental parts within it, so it's not always 
even clear what the correct behaviour should be without quite a bit of 
experimentation and testing.

If the plan is to keep the NeXT code and to work on it over time, then I'm inclined 
to say merge this series as-is so at least it provides test cases for hardware such 
as ESP, brings upstream up-to-date with Bryce's original work, and allow a future 
cleanup. So on this basis:

Acked-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>


ATB,

Mark.