On 5/1/2012 1:48 PM, Mark Cave-Ayland wrote: > On 01/05/12 07:57, Blue Swirl wrote: > >>> Therefore I can't change it to my (modified) sbus_mmio_map() function >>> because it would break other non-SPARC platforms, and AIUI there is >>> nothing >>> in the memory API that allows me to move a subregion to a different >>> MemoryRegion parent, even if I can get a reference to it with >>> sysbus_mmio_get_region() after the sysbus_mmio_map() call - or have I >>> misunderstood something? >> >> Sysbus is used as a generic class for motherboard devices, there is an >> assumption that there is no higher level bus. What we need here is a >> full blown bus. The translations and mappigs between bus addresses and >> motherboard addresses should be done in a Sysbus to SBus bridge >> device, just like PCI host bridges do. > > Since SBus is mapped directly to physical addresses, is this mapping not > just 1:1? Or does it make sense to re-work all the offsets of the > various peripherals to be from the base address of the first slot?
It would be nice to have the device offsets be relative to the slot. User-pluggable sbus devices should be possible. I've just pushed an update of a dbri sbus device model to github ( https://github.com/breuerr/qemu/commits/dbri-pre2 ). This device was built-in to at least the SS-20, but also available as an sbus add-in card (SunLink ISDN). There's an fcode rom so it can be probed by OBP, and if we could get something like "-device SUNW,,DBRIe,slot=1" to work, then a user could add it to most of the sun4m machine models. Bob
