1 |
<html> |
<html><head><title>Gavare's eXperimental Emulator: Miscellaneous</title> |
2 |
<head><title>GXemul documentation: Misc.</title> |
<meta name="robots" content="noarchive,nofollow,noindex"></head> |
3 |
</head> |
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
4 |
<body bgcolor="#ffffff" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
<table border=0 width=100% bgcolor="#d0d0d0"><tr> |
5 |
<p> |
<td width=100% align=center valign=center><table border=0 width=100%><tr> |
6 |
<table width="100%"> |
<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6"> |
7 |
<tr><td width="100%" bgcolor="#808070"><font color="#ffffe0" size="6"> |
<b>Gavare's eXperimental Emulator: </b></font> |
8 |
<b>GXemul documentation: Misc.</b></font></td></tr> |
<font color="#000000" size="6"><b>Miscellaneous</b> |
9 |
</table> |
</font></td></tr></table></td></tr></table><p> |
|
<p> |
|
|
<!-- The first 10 lines are cut away by the homepage updating script. --> |
|
|
|
|
10 |
|
|
11 |
<!-- |
<!-- |
12 |
|
|
13 |
$Id: misc.html,v 1.37 2005/04/07 15:50:38 debug Exp $ |
$Id: misc.html,v 1.50 2005/08/16 05:15:24 debug Exp $ |
14 |
|
|
15 |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
16 |
|
|
39 |
|
|
40 |
--> |
--> |
41 |
|
|
42 |
|
|
43 |
<a href="./">Back to the index</a> |
<a href="./">Back to the index</a> |
44 |
|
|
45 |
<p><br> |
<p><br> |
46 |
<h2>Misc.</h2> |
<h2>Miscellaneous</h2> |
47 |
|
|
48 |
<p> |
<p> |
49 |
<ul> |
<ul> |
50 |
<li><a href="#networking">Networking</a> |
<li><a href="#networking">Networking</a> |
51 |
<li><a href="#portmips">Porting operating systems to MIPS using GXemul</a> |
<li><a href="#devel">Writing operating system code, or |
52 |
|
developing firmware, using GXemul</a> |
53 |
<li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a> |
<li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a> |
54 |
<li><a href="#disk">How to start the emulator with a disk image</a> |
<li><a href="#disk">How to start the emulator with a disk image</a> |
55 |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
89 |
|
|
90 |
|
|
91 |
<p><br> |
<p><br> |
92 |
<a name="portmips"></a> |
<a name="devel"></a> |
93 |
<h3>Porting operating systems to MIPS using GXemul:</h3> |
<h3>Writing operating system code, or developing firmware, using GXemul:</h3> |
94 |
|
|
95 |
|
Is this a good idea? The answer is yes and no, depending on the level of |
96 |
|
detail you need in your simulations. If you are developing an operating |
97 |
|
system or operating system kernel of your own, and wish to target |
98 |
|
MIPS-like systems in general, then the answer might be yes, for |
99 |
|
experimental purposes. |
100 |
|
|
101 |
|
<p>Some examples of things that <i>don't</i> work, that you should keep in |
102 |
|
mind: |
103 |
|
|
104 |
Is this a good idea? The answer is yes and no, depending on what you are |
<ul> |
105 |
trying to port to. If you are developing an operating system or operating |
<li>Porting code to a specific machine mode, e.g. a Silicon Graphics |
106 |
system kernel of your own, and wish to target MIPS-like systems in general, |
machine, using GXemul, will not necessarily cause the code to |
107 |
then the answer might be yes, for experimental purposes. |
work on a real machine. Sometimes code works in GXemul which doesn't |
108 |
|
work on real hardware, sometimes it's the other way around. |
109 |
<p> |
|
110 |
However, if you think that you can port an operating system |
<p> |
111 |
to, say, the Silicon Graphics machine mode of GXemul and hope that your |
<li>GXemul contains bugs, and many things are not yet implemented. |
112 |
operating system will run on a real SGI machine, then you will most |
|
113 |
likely fail. GXemul simply does not emulate things well enough for that to work. |
<p> |
114 |
Another example would be specific CPU details; if your code depends on, |
<li>I have only implemented devices in GXemul to the degree that |
115 |
say, R10000 specifics, chances are that GXemul will not be sufficient. |
NetBSD, OpenBSD, etc, don't complain too much. One way to say it |
116 |
|
is that the device implementations are "lazy hacks", based on the |
117 |
<p> |
assumption that the emulated OS is already developed and bug-free. |
118 |
In many cases, hardware devices in GXemul are only implemented well |
They are not intended to be used for development of new OS code, |
119 |
enough to fool eg. NetBSD that they are working correctly, while in |
so if you do that, then be prepared for bugs and inconsitencies. |
120 |
fact they don't work very much at all. Please keep this in mind, if you plan |
|
121 |
to use GXemul when porting your code to MIPS. |
<p> |
122 |
|
<li>CPU details in GXemul are usually wrong. If your code depends |
123 |
|
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
124 |
|
not be sufficient. Again, this was done as "lazy hacks", and pretty |
125 |
|
much assumes that the OS being emulated is already developed |
126 |
|
and bug-free. |
127 |
|
|
128 |
|
<p> |
129 |
|
<li>Caches. There is no cache emulation in GXemul right now. Caches |
130 |
|
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
131 |
|
in the DECstation emulation mode, but other than that, cache |
132 |
|
operations are treated as nops. |
133 |
|
</ul> |
134 |
|
|
135 |
|
<p>The bottom line is that GXemul can be useful as yet another way to test |
136 |
|
your code during development, but it should not be fully relied on. |
137 |
|
|
138 |
|
|
139 |
|
|
180 |
Here are some examples. If you want to run a NetBSD/pmax kernel on an |
Here are some examples. If you want to run a NetBSD/pmax kernel on an |
181 |
emulated DECstation machine, you would use a command line such as this: |
emulated DECstation machine, you would use a command line such as this: |
182 |
<pre> |
<pre> |
183 |
$ <b>gxemul -E dec -e 3max -b -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
184 |
</pre> |
</pre> |
185 |
<p> |
<p> |
186 |
NOTE: For some emulation modes, such as the DECstation mode, you do |
NOTE: For some emulation modes, such as the DECstation mode, you do |
191 |
image is added; the first will be SCSI target 0, the second will be target 1, and so on, |
image is added; the first will be SCSI target 0, the second will be target 1, and so on, |
192 |
unless you specify explicitly which ID number the devices should have. |
unless you specify explicitly which ID number the devices should have. |
193 |
<pre> |
<pre> |
194 |
$ <b>gxemul -E dec -e 3max -b -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b> |
195 |
</pre> |
</pre> |
196 |
Note: In the example above, disk2.raw will get scsi id 5. |
Note: In the example above, disk2.raw will get scsi id 5. |
197 |
<p> |
<p> |
200 |
For example, the following command would start the emulator with two |
For example, the following command would start the emulator with two |
201 |
CDROM images, and one harddisk image: |
CDROM images, and one harddisk image: |
202 |
<pre> |
<pre> |
203 |
$ <b>gxemul -E dec -e 3max -b -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b> |
204 |
</pre> |
</pre> |
205 |
Usually, the device with the lowest id becomes the boot device. To override |
Usually, the device with the lowest id becomes the boot device. To override |
206 |
this, add a 'b' prefix to one of the devices: |
this, add a 'b' prefix to one of the devices: |
207 |
<pre> |
<pre> |
208 |
$ <b>gxemul -E dec -e 3max -b -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b> |
$ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b> |
209 |
</pre> |
</pre> |
210 |
If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can |
If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can |
211 |
use it as a CD-ROM directly accessible from within the emulator: |
use it as a CD-ROM directly accessible from within the emulator: |
212 |
<pre> |
<pre> |
213 |
$ <b>gxemul -E dec -e 3max -b -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b> |
$ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b> |
214 |
</pre> |
</pre> |
215 |
It is probably possible to use harddisks as well this way, but I would not |
It is probably possible to use harddisks as well this way, but I would not |
216 |
recommend it. |
recommend it. |
310 |
<a name="userland"></a> |
<a name="userland"></a> |
311 |
<h3>Running userland binaries:</h3> |
<h3>Running userland binaries:</h3> |
312 |
|
|
313 |
You can run (some) userland programs as well. This will not emulate any |
<font color="#ff0000">Note: This does not really work yet.</font> |
314 |
particular machine, but instead try to translate syscalls from for example |
|
315 |
NetBSD/pmax into the host's OS' syscalls. Right now, this is just a |
<p>There is some skeleton code for running userland programs as well. This |
316 |
proof-of-concept, to show that it would work; there's lots of work left to |
will not emulate any particular machine, but instead try to translate |
317 |
do to make it actually run useful programs (for example dynamically linked |
syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now, |
318 |
programs). |
this is just a proof-of-concept, to show that it could work; there's lots |
319 |
|
of work left to do to make it actually run useful programs. |
320 |
|
|
321 |
<p> |
<p> |
322 |
|
|
347 |
tab.csbnet.se |
tab.csbnet.se |
348 |
</pre> |
</pre> |
349 |
|
|
350 |
|
<!-- |
351 |
<p> |
<p> |
352 |
<li><b>NetBSD/powerpc:</b> |
<li><b>NetBSD/powerpc:</b> |
353 |
<br> |
<br> |
371 |
Hello, world! |
Hello, world! |
372 |
|
|
373 |
</pre> |
</pre> |
374 |
|
--> |
375 |
|
|
376 |
</ul> |
</ul> |
377 |
|
|
439 |
</pre> |
</pre> |
440 |
This binary image can now be used in the emulator: |
This binary image can now be used in the emulator: |
441 |
<pre> |
<pre> |
442 |
$ <b>gxemul -E dec -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b> |
$ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b> |
443 |
|
|
444 |
KN02-BA V5.7e |
KN02-BA V5.7e |
445 |
?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA] |
?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA] |
486 |
During bootup, the PROM complains <i>a lot</i> about hardware failures. |
During bootup, the PROM complains <i>a lot</i> about hardware failures. |
487 |
That's because the emulator doesn't emulate the hardware well enough yet. |
That's because the emulator doesn't emulate the hardware well enough yet. |
488 |
<p> |
<p> |
489 |
The command line options used are: |
The command line options used are: -e 3min for |
490 |
-D3 for DECstation model 3 (5000/1xx), -Q to supress the emulator's own PROM |
"DECstation 3min" (5000/1xx), -Q to supress the emulator's own PROM |
491 |
call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly |
call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly |
492 |
emulate memory detection well enough for the PROM to accept, so it will |
emulate memory detection well enough for the PROM to accept, so it will |
493 |
always believe there is 128MB ram anyway), and -q to supress debug messages. |
always believe there is 128MB ram anyway), and -q to supress debug messages. |