Got back to SunOS 4.1.4 (aka Solaris 1.1.2). Thanks to Carey Sсhug, I had a chance to test in on a hard drive image. While serial port driver still has problems, the system is alive in the background and using qemu port forwarding I was able to login via telnet:
SunOS UNIX (sol112)
login: root
SunOS Release 4.1.4 (GENERIC) #2: Fri Oct 14 11:09:47 PDT 1994
sol112#
Subscribe to:
Post Comments (Atom)
19 comments:
Artyom,
I havent tried yet, but is 4.1.4 installable if following the HOW To?
Given 4.1.4 previously did not work, are the recent FPU patches required to make it function?
As an aside, can X be used in any Solaris version yet, or is it that the video card is un-emulated
Keep up the good work!
Thanks
Jason
No 4.1.4 can not be installed using qemu yet. Can use only a hdd image pre-installed on a real machine.
X can not be started, but you can run graphical programs using X-forwarding.
I don't really see the need for a video card. Unless you have some applications which directly use the framebuffer.
Where did you get an image? I've been trying to track down SunOS 4.1.x media for a while and having no luck.
Is there a /usr/include/a.out.h file on your 4.1.4 system?
I got the image from Carey who had it on a real hw.
sol112# head /usr/include/a.out.h
/* @(#)a.out.h 1.25 89/02/22 SMI; from UCB 4.1 83/05/03 */
#ifndef _a_out_h
#define _a_out_h
#if !defined(_CROSS_TARGET_ARCH)
/* The usual, native case. Usage:
* #include
*/
Nice. I was hoping 4.1 serial had a.out, but it's been so long I wasn't sure. A friend of mine has a 4.1 install cd, so I'm hoping to get that working. You said in a previous message that the installer wouldn't work--how come?
Gack! I meant still, not serial! Sorry about that. Spell checkers ftw!
Two problems: it tries to access something in iommu which qemu doesn't have and a serial console is broken.
The installer doesn't go past "Wh". I wrote about it some time ago.
I think I may have solved serial problem (currently reading the ~300 pages Zilog serial port documentation).
But IOMMU problem is a show stopper. Currently investigating it.
Oof. I tried to get through that document once in order to do a NetBSD driver for it. That's a surprisingly complicated chip, considering that it's "just" a serial port controller.
Thanks for working on this. Some CS archaeologist a hundred years from now is going to light incense for you out of gratitude.
You wrote the NetBSD driver for zs? Hats off! Actually it is NetBSD 1.3.3 which makes me doubt that I fixed zs emulation properly. Do you know which assumptions does the driver make concerning "Reset IUS"?
I don't think some future CS archaeologists would care about such stuff. But I'm feeling myself being an archaeologist and it is fun.
No, I just hacked on it. Somebody a lot smarter than me wrote it. Probably Charles Hannum or Jason Thorpe. It's been so long since I hacked on it that you might as well be talking to a fresh CS graduate. If you want, I can take a look at the source code and see what changed between 1.3.3 and whatever version works, though.
Hm, there are a few changes with how it does DCD between 1.3.3 and 1.4, and the interface with the prom appears to have been largely rewritten. I don't see anything about IUS, but I don't know what that is. It also sets a different interrupt level when it's resetting the chip, but I don't grok the SPARC interrupt scheme well enough to know what the difference is.
It was weird poking through the CVS logs--I'd forgotten, but Perry Metzger and I did the release engineering for 1.3.3, and so my name is all over the commit logs not because of changes I made, but because of pullups I did.
I'm not sure that newer NetBSD behave differently in this respect. I tried 1.3.3 cause it's the most fragile one. Will check the newer versions.
Different interrupt level on reset? Sounds interesting. (not because of this problem but because there are some versions between 1.3.3 and 4.x which do not boot at all) In which version was it changed?
This particular change is between 1.3.3 and 1.4. There are a few more interrupt changes between 1.3.3 and 4.0, but most of the changes have to do with the bus_space code, and so I doubt they're relevant. I can give you the 1.3.3 and 4.0 versions to compare if that would be useful.
BTW, it wouldn't surprise me at all if someone used your work 100 years from now. A _lot_ of work was done on Suns, and it's still lying around. Being able to emulate a sun CPU could be really helpful. That's why I'm doing it--there's some code that I want to port to modern architectures that most recently ran on the Sun, and in order to port it I need to run it on its current machine--it's a compiler, and I have to use it to compile the new version of itself.
What compiler is it?
In my picture of the World every proprietary product which existed >15 years ago has an open source equivalent now. The quality may vary of course. This is just a rule of thumb. That's why I doubt that emulating old stuff is interesting for a wide audience. Of course there are some special cases in companies with a special internal rules.
BTW, have you tried "The Machine Emulator" (tme)? It emulates just sun4c, but must be pretty good for SunOS 4.x and NetBSD 1.x.
Needs gtk1 though, so I never found the time to actually look at it.
It's T. It is open source, but it's ancient, and needs a sparc to bootstrap. The goal is to convert it to run on something more recent.
The reason I think people will want the emulator is not because they'll need to run the old software in production, bit because they'll need it to decode ancient data.
I have thought about hacking qemu to emulate the cpu without emulating the machine (that is, just forward the sys calls to the MacOS kernel), but I think that would be more work.
If I can't get 4.1 working, the binary does run on more recent versions, but it'll require more work to make it self-host there because of the ELF object file format, so I'd prefer to avoid that.
Oh, TME looked like too much work to me too. :) I'm a geek--I'm lazy.
Never heard of T. (Just have read that it is a scheme dialect). In my daily work I have to do with q and k (the a+ successors). According to the naming schema, T must be more advanced than these two. :)
There is already a mode in qemu where sys calls are forwarded to the host os (afaik it's not cross-os though: for a Linux guest the host must be linux and for guest *BSD the host must be *BSD). Try qemu-user* instead of qemu-system*. Don I expect problems for multi-threaded applications though: some cpu ops which must be atomic are not. It's not a problem while emulating machine cause the whole machine is using just one thread. But may be a problem in the user mode.
Hm, I might be able to make that work--thanks for the pointer! T is not multithreaded as far as I know, so it should be okay as long as I can get it to run. I suspect the compiler only uses a few syscalls anyway, and it ran on a lot of different operating systems, so the shim should be pretty simple.
As for advanced, I don't know. It supposedly does type inferencing and some other cool compiler things, and produces really good code, but I've never used it for real work--this'll be the first time, if I can get it working.
Post a Comment