-The guest OS running inside the emulator uses a private IPv4 address, such -as 10.0.0.1, and the emulator acts as a NAT-like gateway/firewall at IPv4 -address 10.0.0.254. To the outside world it will seem like it is the host's -OS that connects to other machines on the internet, not the guest OS. -
-NOTE: This is still experimental! -As of 2004-07-21, ARP + ICMP + UDP + TCP are emulated well enough to let -NetBSD and OpenBSD install via ftp, and use the network for many normal -activities, but not everything works yet. + +
This is still experimental, hackish, and +rather buggy. With NetBSD running as guest operating system, it mostly +works. + +
When only one machine is being emulated, the following default values +apply:
+ IPv4 address: 10.0.0.1 + Netmask: 255.0.0.0 + Gateway / default route: 10.0.0.254 + Nameserver: 10.0.0.254 ++ +
The emulated machine must of course have a NIC which is emulated +correctly. At the moment, the following NICs should work: +
-
+
- ether, the "fake" experimental ethernet device + (documented here) +
- le, Turbochannel Lance Ethernet, as used in + DECstation 5000/200 ("3max") +
- mec, the SGI O2's ethernet controller +
- dec21143, Digital's 21143 NIC (known as dc + in OpenBSD, or tlp in NetBSD) +
The emulator acts as a NAT-like gateway/firewall; to the outside world +it will seem like it is the host's OS that connects to other machines on +the internet, not the guest OS. @@ -87,28 +108,57 @@
Porting operating systems to MIPS using GXemul:
+ +Writing operating system code, or developing firmware, using GXemul:
+ +Is this a good idea? The answer is yes and no, depending on the level of +detail you need in your simulations. If you are developing an operating +system or operating system kernel of your own, then the emulator can be a +complement to testing on real hardware. -Is this a good idea? The answer is yes and no, depending on what you are -trying to port to. If you are developing an operating system or operating -system kernel of your own, and wish to target MIPS-like systems in general, -then the answer might be yes, for experimental purposes. - --However, if you think that you can port an operating system -to, say, the Silicon Graphics machine mode of GXemul and hope that your -operating system will run on a real SGI machine, then you will most -likely fail. GXemul simply does not emulate things well enough for that to work. -Another example would be specific CPU details; if your code depends on, -say, R10000 specifics, chances are that GXemul will not be sufficient. - -
-In many cases, hardware devices in GXemul are only implemented well -enough to fool eg. NetBSD that they are working correctly, while in -fact they don't work very much at all. Please keep this in mind, if you plan -to use GXemul when porting your code to MIPS. +
Important things to keep in mind: +
-
+
- Porting code to a specific machine mode, e.g. a Silicon Graphics
+ machine, using GXemul, will not "magically" cause the code to
+ work on a real machine. Sometimes code works in GXemul which doesn't
+ work on real hardware, sometimes it's the other way around.
+
+
+
- GXemul contains bugs, and many things are not yet implemented.
+
+
+
- Very important! I have only implemented devices in GXemul
+ to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much.
+
+ If you are developing a driver for a device which is emulated by + GXemul, and your driver does not seem to be working, then the + probability of a bug in GXemul's implementation of the device is + very much higher than that of a bug in your driver. +
+ The device implementations in GXemul are based on the assumption + that the emulated OS is already developed and bug-free. They are + not primarily intended to be used for development of new device + driver code in operating systems, so if you do that, then be + prepared for bugs and inconsitencies. +
+
- CPU details in GXemul are usually wrong. If your code depends
+ on, say, R10000 or MIPS64 specifics, chances are that GXemul will
+ not be sufficient. One example is different revisions of ISAs;
+ 64-bit MIPS instructions which should trigger an exception on a
+ real 32-bit MIPS processor usually execute anyway in GXemul. Another
+ example is if userland code tries to access kernel memory; in some
+ cases there is protection against this, but not in all cases (to get
+ higher performance).
+
+
- Caches. There is no cache emulation in GXemul right now. Caches + for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc + in the DECstation emulation mode, but other than that, cache + operations are treated as nops. +
The bottom line is that GXemul can be useful as yet another way to test +your code during development, but it should not be fully relied on. @@ -120,8 +170,8 @@
Using GXemul in compiler contruction courses:
If you are learning how to write a compiler, and wish to target a -realistic target platform, then MIPS (as emulated by GXemul) -might be a suitable choice. +realistic target platform, then MIPS or ARM (as emulated by GXemul) +might be suitable choices.- (+) Your compiler needs to output real assembly
@@ -155,37 +205,37 @@
Here are some examples. If you want to run a NetBSD/pmax kernel on an
emulated DECstation machine, you would use a command line such as this:
- $ gxemul -E dec -e 3max -b -d pmax_diskimage.fs netbsd-pmax-INSTALL + $ gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL
--NOTE: For some emulation modes, such as the DECstation mode, you do -not have to specify the name of the kernel, if the disk image is -bootable! -
-It is possible to have more than one disk. For each -d argument, a disk + +
NOTE: For some emulation modes, such as the DECstation mode, you do +not actually have to specify the name of the kernel, if the disk +image is bootable! + +
It is possible to have more than one disk. For each -d argument, a disk image is added; the first will be SCSI target 0, the second will be target 1, and so on, unless you specify explicitly which ID number the devices should have.
- $ gxemul -E dec -e 3max -b -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL + $ gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL
Note: In the example above, disk2.raw will get scsi id 5. --If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be + +
If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk). For example, the following command would start the emulator with two CDROM images, and one harddisk image:
- $ gxemul -E dec -e 3max -b -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL + $ gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL
Usually, the device with the lowest id becomes the boot device. To override this, add a 'b' prefix to one of the devices:- $ gxemul -E dec -e 3max -b -d rootdisk.img -d bc:install-cd.iso name_of_kernel + $ gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel
If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can use it as a CD-ROM directly accessible from within the emulator:- $ gxemul -E dec -e 3max -b -d rootdisk.img -d bc:/dev/cd0c name_of_kernel + $ gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel
It is probably possible to use harddisks as well this way, but I would not recommend it. @@ -241,6 +291,53 @@ + + + +Transfering files to/from the guest OS:
+ +If the emulated machine supports networking (see +above), then transfering files via FTP is +probably easiest. + +There is another way of transfering files which works for any kind of +emulated machine which supports disks (either SCSI or IDE). Any file can +be supplied as a disk image. For example, consider the following:
+ $ gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC +
+This will start NetBSD/cats with nbsd_cats.img as IDE master on +controller 0 (wd0), and archive.tar.gz as IDE slave on controller +0 (wd1). From inside NetBSD, it is now possible to extract the files using +the following command:+ (inside emulated NetBSD/cats) + # tar zxvf /dev/wd1c +
+Don't worry if NetBSD complains about lack of disklabel; it doesn't +matter. On some machines, NetBSD uses wd1d instead of +wd1c for the entire disk. +There is also a minor problem: reading the end of the disk image. If you +experience problems untaring archives like this, then pad out the archive +first with some zeroes. + +Transfering files out from the emulated operating system to the +host can be done the same way. First, prepare an empty archive file:
+ $ dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000 +
This example created a 10 MB empty file. Then, start the emulator +like this:+ $ gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC +
+and transfer files by creating an archive directly onto the disk image:+ (inside emulated NetBSD/cats) + # tar cvf /dev/wd1c filenames +
+where filenames are the files or directories to transfer. + + + + +How to extract large gzipped disk images:
@@ -285,12 +382,13 @@Running userland binaries:
-You can run (some) userland programs as well. This will not emulate any -particular machine, but instead try to translate syscalls from for example -NetBSD/pmax into the host's OS' syscalls. Right now, this is just a -proof-of-concept, to show that it would work; there's lots of work left to -do to make it actually run useful programs (for example dynamically linked -programs). +Note: This does not really work yet. + +There is some skeleton code for running userland programs as well. This +will not emulate any particular machine, but instead try to translate +syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now, +this is just a proof-of-concept, to show that it could work; there's lots +of work left to do to make it actually run useful programs.
@@ -321,6 +419,7 @@ tab.csbnet.se +
- $ gxemul -E dec -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin + $ gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin KN02-BA V5.7e ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA] @@ -452,18 +552,20 @@ osconsole=3 >>-(Note: at the moment, this doesn't work. I must have broken something when -fixing something else, but this is what it looked like at the time.) -
-During bootup, the PROM complains a lot about hardware failures. + +
(Note: at the moment, this doesn't work. +I must have broken something when fixing something else, but this +is what it looked like at the time.) + +
During bootup, the PROM complains a lot about hardware failures. That's because the emulator doesn't emulate the hardware well enough yet. -
-The command line options used are: -E dec for DECstation, -e 3min for -"model 3" (5000/1xx), -Q to supress the emulator's own PROM -call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly + +
The command line options used are: -e 3min for +"DECstation 3min" (5000/1xx), -Q to supress the emulator's own PROM +call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly emulate memory detection well enough for the PROM to accept, so it will -always believe there is 128MB ram anyway), and -q to supress debug messages. -The 0xbfc00000 in front of the filename tells GXemul that it is a raw +always believe there is 128MB ram anyway), and -q to supress debug messages. +The 0xbfc00000 in front of the filename tells GXemul that it is a raw binary file which should be loaded at a specific virtual address. @@ -471,20 +573,53 @@
Dumping the PROM on a SGI O2:
The general ideas in this section applies to using ROM images from other -machines as well. Besides DECstation, I've also tried this on an SGI IP32 -("O2"). --For the O2, a suitable command to dump the prom memory range is +machines as well. I have also tried this on an SGI IP32 ("O2"), in addition +to the DECstation. + +
For the O2, a suitable command to dump the prom memory range is
>> dump -b 0xBFC00000:0xBFC80000Make sure you capture all the output (via serial console) into a file, -and then run experiments/sgiprom_to_bin on the captured file. -
-(2005-01-16: The emulator doesn't really emulate the IP32 well enough to -actually run the PROM image without using special hacks, but it might do -so some time in the future.) +and then run experiments/sgiprom_to_bin on the captured file. +
+
+
+
+
+
+
+
+
The photo on the left is from the real machine. The other two are +screenshots of the PROM running experimentally in GXemul, using -Y2 +framebuffer scaledown. + +
Normally during bootup, the IP32 PROM does a Power-On test which makes +sure that the caches and other things are working properly. GXemul doesn't +emulate all those things well enough for the tests to pass. The +experimental screenshots above were taken with cache detection skipped +manually. + +
+In other words: don't expect this to work out-of-the-box with GXemul right +now. It might work once I've added correct cache emulation. + +
The command line used to start the emulator, once correct cache +emulation has been implemented, would be something like gxemul -XQeo2 +0xbfc00000:prom.bin. + +
The same caution applies when dealing with SGI PROMs as with +DECstation PROMs: GXemul doesn't really emulate the hardware, it only +"fakes" devices well enough to fool some things, primarily NetBSD, that +it is emulating a real machine. ROM code is usually a lot more +picky about the details. + +
The graphics used in the O2 is (as far as I know) undocumented. Combining +some traces of info from how Linux/O2 draws to the screen with some +reverse-engineering of my own, I've implemented enough of the controller to +let the PROM draw rectangles and bitmaps, but not much more. The SCSI +controller is not implemented yet either.