4 |
<table border=0 width=100% bgcolor="#d0d0d0"><tr> |
<table border=0 width=100% bgcolor="#d0d0d0"><tr> |
5 |
<td width=100% align=center valign=center><table border=0 width=100%><tr> |
<td width=100% align=center valign=center><table border=0 width=100%><tr> |
6 |
<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6"> |
<td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6"> |
7 |
<b>Gavare's eXperimental Emulator: </b></font> |
<b>Gavare's eXperimental Emulator:</b></font><br> |
8 |
<font color="#000000" size="6"><b>Miscellaneous</b> |
<font color="#000000" size="6"><b>Miscellaneous</b> |
9 |
</font></td></tr></table></td></tr></table><p> |
</font></td></tr></table></td></tr></table><p> |
10 |
|
|
11 |
<!-- |
<!-- |
12 |
|
|
13 |
$Id: misc.html,v 1.53 2005/09/04 14:00:25 debug Exp $ |
$Id: misc.html,v 1.65 2006/10/19 10:15:23 debug Exp $ |
14 |
|
|
15 |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
Copyright (C) 2003-2006 Anders Gavare. All rights reserved. |
16 |
|
|
17 |
Redistribution and use in source and binary forms, with or without |
Redistribution and use in source and binary forms, with or without |
18 |
modification, are permitted provided that the following conditions are met: |
modification, are permitted provided that the following conditions are met: |
47 |
|
|
48 |
<p> |
<p> |
49 |
<ul> |
<ul> |
|
<li><a href="#networking">Networking</a> |
|
50 |
<li><a href="#devel">Writing operating system code, or |
<li><a href="#devel">Writing operating system code, or |
51 |
developing firmware, using GXemul</a> |
developing firmware, using GXemul</a> |
52 |
<li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a> |
<li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a> |
53 |
<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> |
54 |
|
<li><a href="#filexfer">Transfering files to/from the guest OS</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> |
56 |
<li><a href="#userland">Running userland binaries</a> |
<li><a href="#userland">Running userland binaries</a> |
57 |
<li><a href="#promdump">Using a PROM dump from a real machine</a> |
<li><a href="#promdump">Using a PROM dump from a real machine</a> |
63 |
|
|
64 |
|
|
65 |
|
|
|
<p><br> |
|
|
<a name="networking"></a> |
|
|
<h3>Networking:</h3> |
|
|
|
|
|
It is possible to let the guest OS running inside the emulator get access to |
|
|
the Internet. If you are interested in the technical details, and the |
|
|
reasons why networking is implemented in the emulator the way it currently |
|
|
is implemented, you might want to read the <a href="technical.html#net"> |
|
|
networking section in the technical documentation</a>. |
|
|
<p> |
|
|
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. |
|
|
<p> |
|
|
<font color="#ff0000">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.</font> |
|
|
|
|
|
|
|
|
|
|
|
|
|
66 |
|
|
67 |
|
|
68 |
<p><br> |
<p><br> |
71 |
|
|
72 |
Is this a good idea? The answer is yes and no, depending on the level of |
Is this a good idea? The answer is yes and no, depending on the level of |
73 |
detail you need in your simulations. If you are developing an operating |
detail you need in your simulations. If you are developing an operating |
74 |
system or operating system kernel of your own, and wish to target |
system or operating system kernel of your own, then the emulator can be a |
75 |
MIPS-like systems in general, then the answer might be yes, for |
complement to testing on real hardware. |
|
experimental purposes. |
|
76 |
|
|
77 |
<p>Some examples of things that <i>don't</i> work, that you should keep in |
<p>Important things to keep in mind: |
|
mind: |
|
78 |
|
|
79 |
<ul> |
<ul> |
80 |
<li>Porting code to a specific machine mode, e.g. a Silicon Graphics |
<li>Porting code to a specific machine mode, e.g. a Silicon Graphics |
81 |
machine, using GXemul, will not necessarily cause the code to |
machine, using GXemul, will not "magically" cause the code to |
82 |
work on a real machine. Sometimes code works in GXemul which doesn't |
work on a real machine. Sometimes code works in GXemul which doesn't |
83 |
work on real hardware, sometimes it's the other way around. |
work on real hardware, sometimes it's the other way around. |
84 |
|
|
86 |
<li>GXemul contains bugs, and many things are not yet implemented. |
<li>GXemul contains bugs, and many things are not yet implemented. |
87 |
|
|
88 |
<p> |
<p> |
89 |
<li>I have only implemented devices in GXemul to the degree that |
<li><b>Very important!</b> I have only implemented devices in GXemul |
90 |
NetBSD, OpenBSD, etc, don't complain too much. One way to say it |
to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much. |
91 |
is that the device implementations are "lazy hacks", based on the |
<p> |
92 |
assumption that the emulated OS is already developed and bug-free. |
If you are developing a driver for a device which is emulated by |
93 |
They are not intended to be used for development of new OS code, |
GXemul, and your driver does not seem to be working, then the |
94 |
so if you do that, then be prepared for bugs and inconsitencies. |
probability of a bug in GXemul's implementation of the device is |
95 |
|
very much higher than that of a bug in your driver. |
96 |
|
<p> |
97 |
|
The device implementations in GXemul are based on the assumption |
98 |
|
that the emulated OS is already developed and bug-free. They are |
99 |
|
not primarily intended to be used for development of new device |
100 |
|
driver code in operating systems, so if you do that, then be |
101 |
|
prepared for bugs and inconsitencies. |
102 |
<p> |
<p> |
103 |
<li>CPU details in GXemul are usually wrong. If your code depends |
<li>CPU details in GXemul are usually wrong. If your code depends |
104 |
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
105 |
not be sufficient. Again, this was done as "lazy hacks", and pretty |
not be sufficient. One example is different revisions of ISAs; |
106 |
much assumes that the OS being emulated is already developed |
some instructions which should trigger an exception on a |
107 |
and bug-free. |
real MIPS processor usually execute anyway in GXemul. Another |
108 |
|
example is if userland code tries to access kernel memory; in some |
109 |
|
cases there is protection against this, but not in all cases (to get |
110 |
|
higher performance). |
111 |
<p> |
<p> |
112 |
<li>Caches. There is no cache emulation in GXemul right now. Caches |
<li>Caches. There is no cache emulation in GXemul right now. Caches |
113 |
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
128 |
<h3>Using GXemul in compiler contruction courses:</h3> |
<h3>Using GXemul in compiler contruction courses:</h3> |
129 |
|
|
130 |
If you are learning how to write a compiler, and wish to target a |
If you are learning how to write a compiler, and wish to target a |
131 |
realistic target platform, then MIPS (as emulated by GXemul) |
realistic target platform, then MIPS or ARM (as emulated by GXemul) |
132 |
might be a suitable choice. |
might be suitable choices. |
133 |
|
|
134 |
<ul> |
<ul> |
135 |
<li><b>(+)</b> Your compiler needs to output real assembly |
<li><b>(+)</b> Your compiler needs to output real assembly |
136 |
language code, which the assembler (eg gas, the GNU assembler) can |
language code, which the assembler (e.g. gas, the GNU assembler) can |
137 |
then compile into object format, and then you need to link this |
then compile into object format, and then you need to link this |
138 |
into an executable image. This is much closer to how things work |
into an executable image. This is much closer to how things work |
139 |
in real life than running assembly language listings in a simulator |
in real life than running assembly language listings in a simulator |
140 |
(eg SPIM). |
(e.g. SPIM). |
141 |
<p> |
<p> |
142 |
<li><b>(-)</b> GXemul does not simulate out-of-order |
<li><b>(-)</b> GXemul does not simulate out-of-order |
143 |
execution, penalties related to instruction scheduling, or |
execution, penalties related to instruction scheduling, or |
165 |
<pre> |
<pre> |
166 |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
167 |
</pre> |
</pre> |
168 |
<p> |
|
169 |
NOTE: For some emulation modes, such as the DECstation mode, you do |
<p>NOTE: For some emulation modes, such as the DECstation mode, you do |
170 |
<i>not</i> have to specify the name of the kernel, if the disk image is |
<i>not</i> actually have to specify the name of the kernel, if the disk |
171 |
bootable! |
image is bootable! |
172 |
<p> |
|
173 |
It is possible to have more than one disk. For each -d argument, a disk |
<p>It is possible to have more than one disk. For each -d argument, a disk |
174 |
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, |
175 |
unless you specify explicitly which ID number the devices should have. |
unless you specify explicitly which ID number the devices should have. |
176 |
<pre> |
<pre> |
177 |
$ <b>gxemul -e 3max -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> |
178 |
</pre> |
</pre> |
179 |
Note: In the example above, disk2.raw will get scsi id 5. |
Note: In the example above, disk2.raw will get scsi id 5. |
180 |
<p> |
|
181 |
If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be |
<p>If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be |
182 |
a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk). |
a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk). |
183 |
For example, the following command would start the emulator with two |
For example, the following command would start the emulator with two |
184 |
CDROM images, and one harddisk image: |
CDROM images, and one harddisk image: |
249 |
|
|
250 |
|
|
251 |
|
|
252 |
|
|
253 |
|
|
254 |
|
|
255 |
|
<p><br> |
256 |
|
<a name="filexfer"></a> |
257 |
|
<h3>Transfering files to/from the guest OS:</h3> |
258 |
|
|
259 |
|
If the emulated machine supports networking (see <a |
260 |
|
href="networking.html#intro">this section</a> for more info), then |
261 |
|
transfering files via FTP is probably easiest. |
262 |
|
|
263 |
|
<p>There is another way of transfering files which works for any kind of |
264 |
|
emulated machine which supports disks (either SCSI or IDE). Any file can |
265 |
|
be supplied as a disk image. For example, consider the following:<pre> |
266 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b> |
267 |
|
</pre> |
268 |
|
This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on |
269 |
|
controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller |
270 |
|
0 (wd1). From inside NetBSD, it is now possible to extract the files using |
271 |
|
the following command:<pre> |
272 |
|
(inside emulated NetBSD/cats) |
273 |
|
# <b>tar zxvf /dev/wd1c</b> |
274 |
|
</pre> |
275 |
|
Don't worry if NetBSD complains about lack of disklabel; it doesn't |
276 |
|
matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of |
277 |
|
<tt>wd1c</tt> for the entire disk. |
278 |
|
There is also a minor problem: reading the end of the disk image. If you |
279 |
|
experience problems untaring archives like this, then pad out the archive |
280 |
|
first with some zeroes. |
281 |
|
|
282 |
|
<p>Transfering files <i>out</i> from the emulated operating system to the |
283 |
|
host can be done the same way. First, prepare an empty archive file:<pre> |
284 |
|
$ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b> |
285 |
|
</pre>This example created a 10 MB empty file. Then, start the emulator |
286 |
|
like this:<pre> |
287 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b> |
288 |
|
</pre> |
289 |
|
and transfer files by creating an archive directly onto the disk image:<pre> |
290 |
|
(inside emulated NetBSD/cats) |
291 |
|
# <b>tar cvf /dev/wd1c filenames</b> |
292 |
|
</pre> |
293 |
|
where filenames are the files or directories to transfer. |
294 |
|
|
295 |
|
|
296 |
|
|
297 |
|
|
298 |
|
|
299 |
<p><br> |
<p><br> |
300 |
<a name="largeimages"></a> |
<a name="largeimages"></a> |
301 |
<h3>How to extract large gzipped disk images:</h3> |
<h3>How to extract large gzipped disk images:</h3> |
340 |
<a name="userland"></a> |
<a name="userland"></a> |
341 |
<h3>Running userland binaries:</h3> |
<h3>Running userland binaries:</h3> |
342 |
|
|
343 |
<font color="#ff0000">Note: This does not really work yet.</font> |
<font color="#ff0000">Note: This feature does not really work yet. |
344 |
|
It is currently disabled in stable release builds of the emulator.</font> |
345 |
|
|
346 |
<p>There is some skeleton code for running userland programs as well. This |
<p>There is some skeleton code for running userland programs as well. This |
347 |
will not emulate any particular machine, but instead try to translate |
will not emulate any particular machine, but instead try to translate |
576 |
|
|
577 |
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
578 |
some traces of info from how Linux/O2 draws to the screen with some |
some traces of info from how Linux/O2 draws to the screen with some |
579 |
reverse-engineering of my own, I've implemeneted enough of the controller to |
reverse-engineering of my own, I've implemented enough of the controller to |
580 |
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
581 |
controller is not implemented yet either. |
controller is not implemented yet either. |
582 |
|
|