On 4/4/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Blue Swirl blauwirbel@gmail.com:
On 4/3/10, Artyom Tarasenko atar4qemu@googlemail.com wrote:
2010/4/3 Mark Cave-Ayland mark.cave-ayland@siriusit.co.uk:
Mark Cave-Ayland wrote: (I wonder if some MMU/CPU emulation is broken somewhere?)
Actually a very good question. Does qemu emulate any sun4u machine good enough to have a chance running with OBP? It may be a good strategy for fixing the "hardware". At least it was fruitful on sun4m. Blue?
One problem with that strategy is that QEMU does not implement any real machines now. Typical Ultra machines had HME NICs, 53C875 SCSI controller but we have random PCI NICs and IDE (CMD646 exists but usually it's only used for CDROM). OSes probably don't care whether the machine matches any real one or not.
One solution would be to implement the first Ultra machines, which were partially SBUS based and had many common devices with Sun4m.
We could also implement some mid-class machine with HME and 53C875 (it may even be similar to lsi53c895a, which we have). PCI bridging does not work well in QEMU. The docs aren't very good I think. This is closest to what we have now. It could be interesting to see what OBP from a real machine would think of the QEMU machine.
How is SBUS connected to the IO-MMU? Directly or through a PCI bridge? Quick google search didn't help me to find it. I only found that in the Russian sparc32 PCI machine (Elbrus-90) SBUS is connected through a PCI-bridge. If that's the case in early Ultras too, OBP probably won't be able to tell us much via the serial port connected to the SBUS.
There's SYSIO bridge (U2S, STP2220ABGA-100). I couldn't find the user manual (U2S User Manual, Part Number: 805-0168-01) but arch/sparc64/kernel/sbus.c in Linux has some register information.
Third option would be to aim for T1/T2 class machines. The docs are good and there is even Verilog implementation to compare with because most of the devices are inside the CPU. The devices aren't very simple and there is very little commonality with old HW. There are also CPU features to be implemented (CMT). The boot ROM architecture is interesting, there is a hypervisor which OBP uses. Everything is open source, including the CPU. QEMU's Niagara machine can boot the hypervisor, which will output a few lines before crashing.
How about one more. The fourth option (or the second one for the OpenBIOS team) would be using Sun's legion T1/T2 emulator as the hardware for the OpenBIOS. It may be the shortest path to get OpenSolaris booting under OpenBIOS.
That's also possible. Also OpenBIOS could operate only as the hypervisor and use OBP, or vice versa.