On Wed, May 2, 2012 at 3:15 PM, Bob Breuer <breu...@mc.net> wrote: > 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.
Yes, currently all devices are fixed but for example display adapter should be pluggable and only on-board devices should be fixed. > 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. Nice work. > > Bob
