On 12/09/2021 16:47, Philippe Mathieu-Daudé wrote:
On 9/12/21 9:48 AM, Mark Cave-Ayland wrote:
This patchset is the next set of changes required to boot MacOS on the q800
machine. The
main aim of these patches is to improve the Nubus support so that devices can
be plugged
into the Nubus from the command line i.e.
-device nubus-macfb[,romfile=decl.rom]
At the moment the only device that can be plugged into the Nubus is the macfb
framebuffer
however with these changes it is possible to take a ROM from a real Nubus card
and
attempt to use it in QEMU, and also allow for future interfaces such as virtio.
Patches 1 to 6 move the logic which manages bus addresses from the NubusDevice
into
the NubusBus itself, including the introduction of a bitmap to manage available
slots on the bus.
Patches 7 and 8 change the handling for unassigned (empty) slots to generate a
bus
fault and add trace events to allow logging of empty slot accesses during Nubus
enumeration.
Patches 9 to 11 remove the existing stubs for generating the format block (the
epilogue
of the Nubus device embedded ROM consisting of metadata and a checksum) and
replace them
with a romfile device property to allow the entire Nubus ROM to be loaded from
a file
into the ROM area, similar to a PCI option ROM.
Patch 12 moves the Nubus into its own separate address space whilst patches 13
to 17
update the NubusBridge (and MacNubusBridge) devices to allow machines to map the
required slots from the Nubus address space using sysbus_mmio_map().
Finally patches 18 to 20 add support for Nubus IRQs and wire them up
appropriately for
the q800 machine through VIA2, which is required for the next set of macfb
updates.
Thanks for the review so far :)
Some questions:
- TYPE_NUBUS_BRIDGE is not abstract. So far, beside
TYPE_MAC_NUBUS_BRIDGE, no other code use it. Could it
be use as it? If so, shouldn't the code in
mac_nubus_bridge_init() be moved to nubus_bridge_realize(),
creating the slot alias regions generically using the
slot range from slot_available_mask or using another
property?
Not yet, but Nubus was available on non-Apple machines. Given that TYPE_NUBUS_BRIDGE
and TYPE_MAC_NUBUS_BRIDGE are already there, it seems a shame to prevent anyone who
wanted to experiment with Nubus in other ways by hard-coding in the Macintosh
restrictions.
- Why is "slot-available-mask" a bridge device property and
not a bus one?
Architecturally a Nubus always has 16 slots with 1 IRQ per slot (you can compare this
with PCI always having 32 slots with 4 possible IRQs per slot). In the Macintosh
design Apple restricted the available address space by mapping a partial address
range onto the CPU bus, so I'd argue that this is an implementation property of the
bridge. And of course device properties already exist which helps make things easier
too :)
ATB,
Mark.
