Message ID | 20241023085852.1061031-1-mark.cave-ayland@ilande.co.uk (mailing list archive) |
---|---|
Headers | show |
Series | next-cube: more tidy-ups and improvements | expand |
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.
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(-)