This series contains a number of tidy-ups and improvements to the NeXTCube machine
which include:

  - Bringing the code up-to-date with our latest coding standards/APIs, in particular
    related to the board configuration and IRQ wiring

  - Remove the remaining overlapping memory regions and consolidating multiple
    register implementations into a single place

  - Add a new next-scsi device containing the ESP device and its associated
    CSRs

  - Adding the empty_slot device to fill unimplemented devices and removing
    the "catch-all" next.scr memory region

  - QOMifying the next-rtc device and wiring it up with gpios as required

The next-cube machine looks in fairly good shape now, the main remaining work is to
create a separate device for the DMA controller and update the wiring of the IRQs
(including to the CPU) accordingly.

There is no change to the behaviour of the next-cube machine with this series in
that the next-cube machine with a suitable ROM image can now load the kernel from
a pre-installed NeXTStep image and start executing it.

Note that due to the device model changes this is a migration break, however since
the next-cube machine is currently unable to boot anything useful, I don't see
this as an issue.

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


Mark Cave-Ayland (36):
  next-cube: fix up compilation when DEBUG_NEXT is enabled
  next-cube: remove 0x14020 dummy value from next_mmio_read()
  next-cube: remove overlap between next.dma and next.mmio memory
    regions
  next-cube: remove cpu parameter from next_scsi_init()
  next-cube: create new next.scsi container memory region
  next-cube: move next_scsi_init() to next_pc_realize()
  next-cube: introduce next_pc_init() object init function
  next-cube: introduce next-scsi device
  next-cube: move SCSI CSRs from next-pc to the next-scsi device
  next-cube: move SCSI 4020 logic from next-pc device to next-scsi
    device
  next-cube: move floppy disk MMIO to separate memory region in next-pc
  next-cube: map ESCC registers as a subregion of the next.scr memory
    region
  next-cube: move ESCC to be QOM child of next-pc device
  next-cube: move timer MMIO to separate memory region on next-pc device
  next-cube: move en ethernet MMIO to separate memory region on next-pc
    device
  next-cube: add empty slots for unknown accesses to next.scr memory
    region
  next-cube: remove unused next.scr memory region
  next-cube: rearrange NeXTState declarations to improve readability
  next-cube: convert next-pc device to use Resettable interface
  next-cube: rename typedef struct NextRtc to NeXTRTC
  next-cube: use qemu_irq to drive int_status in next_scr2_rtc_update()
  next-cube: separate rtc read and write shift logic
  next-cube: always use retval to return rtc read values
  next-cube: use named gpio to set RTC data bit in scr2
  next-cube: use named gpio to read RTC data bit in scr2
  next-cube: don't use rtc phase value of -1
  next-cube: QOMify NeXTRTC
  next-cube: move reset of next-rtc fields from next-pc to next-rtc
  next-cube: move rtc-data-in gpio from next-pc to next-rtc device
  next-cube: use named gpio output for next-rtc data
  next-cube: add rtc-cmd-reset named gpio to reset the rtc state machine
  next-cube: add rtc-power-out named gpio to reset the rtc state machine
  next-cube: move next_rtc_cmd_is_write() and next_rtc_data_in_irq()
    functions
  next-cube: rename old_scr2 and scr2_2 in next_scr2_rtc_update()
  next-cube: add my copyright to the top of the file
  next-cube: replace boiler-plate GPL 2.0 or later license text with
    SPDX identifier

 hw/m68k/Kconfig     |    1 +
 hw/m68k/next-cube.c | 1025 +++++++++++++++++++++++++++----------------
 2 files changed, 655 insertions(+), 371 deletions(-)

-- 
2.39.5

On Wed, 23 Oct 2024 at 09:59, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> This series contains a number of tidy-ups and improvements to the NeXTCube machine
> which include:
>
>   - Bringing the code up-to-date with our latest coding standards/APIs, in particular
>     related to the board configuration and IRQ wiring
>
>   - Remove the remaining overlapping memory regions and consolidating multiple
>     register implementations into a single place
>
>   - Add a new next-scsi device containing the ESP device and its associated
>     CSRs
>
>   - Adding the empty_slot device to fill unimplemented devices and removing
>     the "catch-all" next.scr memory region
>
>   - QOMifying the next-rtc device and wiring it up with gpios as required
>
> The next-cube machine looks in fairly good shape now, the main remaining work is to
> create a separate device for the DMA controller and update the wiring of the IRQs
> (including to the CPU) accordingly.

Would you have time to consider updating hw/m68k/next-kbd.c
to stop using qemu_add_kbd_event_handler()? It's the only
user left in the codebase of that input-legacy.c API.
Generally using qemu_input_handler_register() should simplify
the code because it will no longer need to decode multi-byte
PS2 code sequences back into "what is the single key event
that this corresponds to?". Commit ff7888dcc6c701 is an
example of the conversion (though that input device
is somewhat simpler than a full real keyboard).

thanks
-- PMM

On 29/10/2024 11:22, Peter Maydell wrote:

> On Wed, 23 Oct 2024 at 09:59, Mark Cave-Ayland
> <mark.cave-ayland@ilande.co.uk> wrote:
>>
>> This series contains a number of tidy-ups and improvements to the NeXTCube machine
>> which include:
>>
>>    - Bringing the code up-to-date with our latest coding standards/APIs, in particular
>>      related to the board configuration and IRQ wiring
>>
>>    - Remove the remaining overlapping memory regions and consolidating multiple
>>      register implementations into a single place
>>
>>    - Add a new next-scsi device containing the ESP device and its associated
>>      CSRs
>>
>>    - Adding the empty_slot device to fill unimplemented devices and removing
>>      the "catch-all" next.scr memory region
>>
>>    - QOMifying the next-rtc device and wiring it up with gpios as required
>>
>> The next-cube machine looks in fairly good shape now, the main remaining work is to
>> create a separate device for the DMA controller and update the wiring of the IRQs
>> (including to the CPU) accordingly.
> 
> Would you have time to consider updating hw/m68k/next-kbd.c
> to stop using qemu_add_kbd_event_handler()? It's the only
> user left in the codebase of that input-legacy.c API.
> Generally using qemu_input_handler_register() should simplify
> the code because it will no longer need to decode multi-byte
> PS2 code sequences back into "what is the single key event
> that this corresponds to?". Commit ff7888dcc6c701 is an
> example of the conversion (though that input device
> is somewhat simpler than a full real keyboard).

Sure, I'll have a look and see if I can manage it - removing legacy APIs is always a 
good thing :)


ATB,

Mark.