Meanwhile qemu-system-sparc is good enough to boot most Solaris versions with OBP. ( http://tyom.blogspot.com/2009/12/solaris-under-qemu-how-to.html )
Great to have you working on OpenBIOS - the story on your blog of getting Solaris to boot with OBP has been really fascinating.
Thanks. But I think my success was partly a pure luck, and partly a lack of interest in launching Solaris from more experienced people and then again a luck of getting these experienced people on board. Anyone who had debugged Solaris kernel on a real hardware would have probably achieved in hours the things for which I needed months. Basically Mitch Bradley proved this by going all the chain from what looked like a scsi-disk bug to finding a cpu math bug within just one day.
But overall the idea of using OBP to find bugs in qemu was good. After we fixed qemu-sparc, you guys have more solid base to improve OpenBIOS. Having two suspects for bugs is always worse than one.
I'm trying to find out what is missing in OpenBIOS to do the same. Currently the boot just hangs. I did a wild guess: $ strings sun4m/ufsboot ... ['] find-device catch if 2drop true else current-device device-end then swap l! ...
It looks like all the keywords are known to the OpenBIOS, but I can't input the test string: " /options" ['] find-device catch if 2drop true else current-device device-end then swap l!
it is longer than 80 characters, and OpenBIOS lets me enter only the part of the string up to "device-end t".
You should be able to split the above test string at any whitespace character, since the Forth engine handles the switch between word interpreting/compiling automatically. All whitespace, including CRs/LFs is generally ignored.
The questions are: - is it just an interactive command line limitation, or an api limitation?
I suspect just an interactive command limitation.
Doesn't look like this: I patched ufsboot by replacing space character with 0x0a and now it gets a bit further!