1 |
<html><head><title>GXemul documentation: Misc.</title> |
<html><head><title>Gavare's eXperimental Emulator: Miscellaneous</title> |
2 |
<meta name="robots" content="noarchive,nofollow,noindex"></head> |
<meta name="robots" content="noarchive,nofollow,noindex"></head> |
3 |
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
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>GXemul documentation:</b></font> |
<b>Gavare's eXperimental Emulator:</b></font><br> |
8 |
<font color="#000000" size="6"><b>Misc.</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.42 2005/06/26 08:42:26 debug Exp $ |
$Id: misc.html,v 1.70 2007/06/15 06:26:20 debug Exp $ |
14 |
|
|
15 |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
Copyright (C) 2003-2007 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: |
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="#devel">Writing operating system code, or |
51 |
<li><a href="#portmips">Porting operating systems to MIPS 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="#tape_images">How to start the emulator with tape images</a> |
55 |
|
<li><a href="#disk_overlays">How to use disk image overlays</a> |
56 |
|
<li><a href="#filexfer">Transfering files to/from the guest OS</a> |
57 |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
58 |
<li><a href="#userland">Running userland binaries</a> |
<li><a href="#userland">Running userland binaries</a> |
59 |
<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> |
65 |
|
|
66 |
|
|
67 |
|
|
|
<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> |
|
|
|
|
|
|
|
|
|
|
|
|
|
68 |
|
|
69 |
|
|
70 |
<p><br> |
<p><br> |
71 |
<a name="portmips"></a> |
<a name="devel"></a> |
72 |
<h3>Porting operating systems to MIPS using GXemul:</h3> |
<h3>Writing operating system code, or developing firmware, using GXemul:</h3> |
73 |
|
|
74 |
Is this a good idea? The answer is yes and no, depending on what you are |
Is this a good idea? The answer is yes and no, depending on the level of |
75 |
trying to port to. If you are developing an operating system or operating |
detail you need in your simulations. If you are developing an operating |
76 |
system kernel of your own, and wish to target MIPS-like systems in general, |
system or operating system kernel of your own, then the emulator can be a |
77 |
then the answer might be yes, for experimental purposes. |
complement to testing on real hardware. |
78 |
|
|
79 |
<p> |
<p>Important things to keep in mind: |
|
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. |
|
80 |
|
|
81 |
<p> |
<ul> |
82 |
In many cases, hardware devices in GXemul are only implemented well |
<li>Porting code to a specific machine mode, e.g. a Silicon Graphics |
83 |
enough to fool eg. NetBSD that they are working correctly, while in |
machine, using GXemul, will not "magically" cause the code to |
84 |
fact they don't work very much at all. Please keep this in mind, if you plan |
work on a real machine. Sometimes code works in GXemul which doesn't |
85 |
to use GXemul when porting your code to MIPS. |
work on real hardware, sometimes it's the other way around. |
86 |
|
|
87 |
|
<p> |
88 |
|
<li>GXemul contains bugs, and many things are not yet implemented. |
89 |
|
|
90 |
|
<p> |
91 |
|
<li><b>Very important!</b> I have only implemented devices in GXemul |
92 |
|
to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much. |
93 |
|
<p> |
94 |
|
If you are developing a driver for a device which is emulated by |
95 |
|
GXemul, and your driver does not seem to be working, then the |
96 |
|
probability of a bug in GXemul's implementation of the device is |
97 |
|
very much higher than that of a bug in your driver. |
98 |
|
<p> |
99 |
|
The device implementations in GXemul are based on the assumption |
100 |
|
that the emulated OS is already developed and bug-free. They are |
101 |
|
not primarily intended to be used for development of new device |
102 |
|
driver code in operating systems, so if you do that, then be |
103 |
|
prepared for bugs and inconsitencies. |
104 |
|
<p> |
105 |
|
<li>CPU details in GXemul are usually wrong. If your code depends |
106 |
|
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
107 |
|
not be sufficient. One example is different revisions of ISAs; |
108 |
|
some instructions which should trigger an exception on a |
109 |
|
real MIPS processor usually execute anyway in GXemul. Another |
110 |
|
example is if userland code tries to access kernel memory; in some |
111 |
|
cases there is protection against this, but not in all cases (to get |
112 |
|
higher performance). |
113 |
|
<p> |
114 |
|
<li>Caches. There is no cache emulation in GXemul right now. Caches |
115 |
|
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
116 |
|
in the DECstation emulation mode, but other than that, cache |
117 |
|
operations are treated as nops. |
118 |
|
</ul> |
119 |
|
|
120 |
|
<p>The bottom line is that GXemul can be useful as yet another way to test |
121 |
|
your code during development, but it should not be fully relied on. |
122 |
|
|
123 |
|
|
124 |
|
|
130 |
<h3>Using GXemul in compiler contruction courses:</h3> |
<h3>Using GXemul in compiler contruction courses:</h3> |
131 |
|
|
132 |
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 |
133 |
realistic target platform, then MIPS (as emulated by GXemul) |
realistic target platform, then MIPS or ARM (as emulated by GXemul) |
134 |
might be a suitable choice. |
might be suitable choices. |
135 |
|
|
136 |
<ul> |
<ul> |
137 |
<li><b>(+)</b> Your compiler needs to output real assembly |
<li><b>(+)</b> Your compiler needs to output real assembly |
138 |
language code, which the assembler (eg gas, the GNU assembler) can |
language code, which the assembler (e.g. gas, the GNU assembler) can |
139 |
then compile into object format, and then you need to link this |
then compile into object format, and then you need to link this |
140 |
into an executable image. This is much closer to how things work |
into an executable image. This is much closer to how things work |
141 |
in real life than running assembly language listings in a simulator |
in real life than running assembly language listings in a simulator |
142 |
(eg SPIM). |
(e.g. SPIM). |
143 |
<p> |
<p> |
144 |
<li><b>(-)</b> GXemul does not simulate out-of-order |
<li><b>(-)</b> GXemul does not simulate out-of-order |
145 |
execution, penalties related to instruction scheduling, or |
execution, penalties related to instruction scheduling, or |
165 |
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 |
166 |
emulated DECstation machine, you would use a command line such as this: |
emulated DECstation machine, you would use a command line such as this: |
167 |
<pre> |
<pre> |
168 |
$ <b>gxemul -E dec -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
169 |
</pre> |
</pre> |
170 |
<p> |
|
171 |
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 |
172 |
<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 |
173 |
bootable! |
image is bootable! |
174 |
<p> |
|
175 |
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 |
176 |
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, |
177 |
unless you specify explicitly which ID number the devices should have. |
unless you specify explicitly which ID number the devices should have. |
178 |
<pre> |
<pre> |
179 |
$ <b>gxemul -E dec -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> |
180 |
</pre> |
</pre> |
181 |
Note: In the example above, disk2.raw will get scsi id 5. |
Note: In the example above, disk2.raw will get scsi id 5. |
182 |
<p> |
|
183 |
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 |
184 |
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). |
185 |
For example, the following command would start the emulator with two |
For example, the following command would start the emulator with two |
186 |
CDROM images, and one harddisk image: |
CDROM images, and one harddisk image: |
187 |
<pre> |
<pre> |
188 |
$ <b>gxemul -E dec -e 3max -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> |
189 |
</pre> |
</pre> |
190 |
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 |
191 |
this, add a 'b' prefix to one of the devices: |
this, add a 'b' prefix to one of the devices: |
192 |
<pre> |
<pre> |
193 |
$ <b>gxemul -E dec -e 3max -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> |
194 |
</pre> |
</pre> |
195 |
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 |
196 |
use it as a CD-ROM directly accessible from within the emulator: |
use it as a CD-ROM directly accessible from within the emulator: |
197 |
<pre> |
<pre> |
198 |
$ <b>gxemul -E dec -e 3max -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> |
199 |
</pre> |
</pre> |
200 |
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 |
201 |
recommend it. |
recommend it. |
202 |
<p> |
|
203 |
|
|
204 |
|
|
205 |
|
|
206 |
|
|
207 |
|
|
208 |
|
<p><br> |
209 |
|
<a name="tape_images"></a> |
210 |
|
<h3>How to start the emulator with tape images:</h3> |
211 |
|
|
212 |
Using emulated tape drives is a bit more complicated than disks, because a |
Using emulated tape drives is a bit more complicated than disks, because a |
213 |
tape can be made up of several "files" with space in between. The solution |
tape can be made up of several "files" with space in between. The solution |
214 |
I have choosen is to have one file in the host's file system space for each |
I have choosen is to have one file in the host's file system space for each |
258 |
on the command line. By changing what the symbolic name points to, |
on the command line. By changing what the symbolic name points to, |
259 |
you can "switch tapes" without quiting and restarting the emulator. |
you can "switch tapes" without quiting and restarting the emulator. |
260 |
|
|
261 |
|
<p> |
262 |
|
<font color="#ff0000">Note: Tape support is most likely very buggy, |
263 |
|
because it has not been tested much, and has probably also suffered |
264 |
|
from bit-rot by now.</font> |
265 |
|
|
266 |
|
|
267 |
|
|
268 |
|
|
269 |
|
|
270 |
|
|
271 |
|
<p><br> |
272 |
|
<a name="disk_overlays"></a> |
273 |
|
<h3>How to use disk image overlays:</h3> |
274 |
|
|
275 |
|
This is most likely best understood by an example: |
276 |
|
|
277 |
|
<p><ul> |
278 |
|
<li>Install e.g. <a href="guestoses.html#netbsdcatsinstall">NetBSD/cats</a>. |
279 |
|
You will end up with a disk image called |
280 |
|
<tt>nbsd_cats.img</tt>. |
281 |
|
<p> |
282 |
|
<li>Running the following command will boot straight from the disk |
283 |
|
image, with no overlay images:<pre> |
284 |
|
<b>gxemul -XEcats -d nbsd_cats.img netbsd.aout-GENERIC.gz</b> |
285 |
|
|
286 |
|
</pre> |
287 |
|
<li>You may now create an overlay file, a corresponding map file, |
288 |
|
and start the emulator with the overlay image connected to |
289 |
|
the same (explicit) ID as the base disk image:<pre> |
290 |
|
<b>touch overlay.img overlay.img.map |
291 |
|
gxemul -XEcats -d 0:nbsd_cats.img -d V0:overlay.img netbsd.aout-GENERIC.gz</b> |
292 |
|
|
293 |
|
</pre> |
294 |
|
<li>Any changes to the filesystem you perform when using the overlay |
295 |
|
will only be written to that overlay. For example, to perform |
296 |
|
a "roll back", you can do the following:<pre> |
297 |
|
<b>rm -f overlay.img overlay.img.map |
298 |
|
touch overlay.img overlay.img.map</b> |
299 |
|
|
300 |
|
</pre> |
301 |
|
and then simply start the emulator again, with the newly created |
302 |
|
overlay image. |
303 |
|
</ul> |
304 |
|
|
305 |
|
<p>It is also possible to add multiple overlays. In that case, writes |
306 |
|
always go the the <i>last</i> added overlay. |
307 |
|
|
308 |
|
<p>GXemul uses Unix' way of supporting files with "holes", |
309 |
|
so even if <tt>ls -l overlay.img</tt> says that the overlay is several |
310 |
|
gigabytes large, <tt>du overlay.img</tt> should reveal that only the |
311 |
|
blocks that have actually been written to have been stored in the |
312 |
|
overlay, e.g.:<pre> |
313 |
|
<b>$ ls -l |
314 |
|
.. |
315 |
|
-rw-r--r-- 1 debug wheel 3072319488 Mar 24 11:59 nbsd_cats.img |
316 |
|
-rw-r--r-- 1 debug wheel 2465354 Mar 24 11:44 netbsd.aout-GENERIC.gz |
317 |
|
-rw-r--r-- 1 debug wheel 2930841600 Mar 24 14:02 overlay.img |
318 |
|
-rw-r--r-- 1 debug wheel 715538 Mar 24 14:02 overlay.img.map |
319 |
|
$ du overlay.img |
320 |
|
864 overlay.img |
321 |
|
</b> |
322 |
|
</pre> |
323 |
|
|
324 |
|
<p>The .map file is simply a raw bitmap telling which blocks of the |
325 |
|
overlay file that are in use. |
326 |
|
|
327 |
|
|
328 |
|
|
329 |
|
|
330 |
|
|
331 |
|
<p><br> |
332 |
|
<a name="filexfer"></a> |
333 |
|
<h3>Transfering files to/from the guest OS:</h3> |
334 |
|
|
335 |
|
If the emulated machine supports networking (see <a |
336 |
|
href="networking.html#intro">this section</a> for more info), then the easiest |
337 |
|
way to transfer files is probably to use FTP or similar methods. |
338 |
|
|
339 |
|
<p>There is another way of transfering files which works for any kind of |
340 |
|
emulated machine which supports disks (either SCSI or IDE). Any file can |
341 |
|
be supplied as a disk image. For example, consider the following:<pre> |
342 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b> |
343 |
|
</pre> |
344 |
|
This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on |
345 |
|
controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller |
346 |
|
0 (wd1). From inside NetBSD, it is now possible to extract the files using |
347 |
|
the following command:<pre> |
348 |
|
(inside emulated NetBSD/cats) |
349 |
|
# <b>tar zxvf /dev/wd1c</b> |
350 |
|
</pre> |
351 |
|
Don't worry if NetBSD complains about lack of disklabel; it doesn't |
352 |
|
matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of |
353 |
|
<tt>wd1c</tt> for the entire disk. |
354 |
|
There is also a minor problem: reading the end of the disk image. If you |
355 |
|
experience problems untaring archives like this, then pad out the archive |
356 |
|
first with some zeroes. |
357 |
|
|
358 |
|
<p>Transfering files <i>out</i> from the emulated operating system to the |
359 |
|
host can be done the same way. First, prepare an empty archive file:<pre> |
360 |
|
$ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b> |
361 |
|
</pre>This example created a 10 MB empty file. Then, start the emulator |
362 |
|
like this:<pre> |
363 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b> |
364 |
|
</pre> |
365 |
|
and transfer files by creating an archive directly onto the disk image:<pre> |
366 |
|
(inside emulated NetBSD/cats) |
367 |
|
# <b>tar cvf /dev/wd1c filenames</b> |
368 |
|
</pre> |
369 |
|
where filenames are the files or directories to transfer. |
370 |
|
|
371 |
|
|
372 |
|
|
373 |
|
|
374 |
|
|
375 |
<p><br> |
<p><br> |
416 |
<a name="userland"></a> |
<a name="userland"></a> |
417 |
<h3>Running userland binaries:</h3> |
<h3>Running userland binaries:</h3> |
418 |
|
|
419 |
You can run (some) userland programs as well. This will not emulate any |
<font color="#ff0000"><b>NOTE 2007-06-15:</b> I just removed most of the |
420 |
particular machine, but instead try to translate syscalls from for example |
userland (syscall) emulation support, and started a rewrite from scratch. |
421 |
NetBSD/pmax into the host's OS' syscalls. Right now, this is just a |
The rest of this section in the documentation is not currently valid.</font> |
422 |
proof-of-concept, to show that it would work; there's lots of work left to |
|
423 |
do to make it actually run useful programs (for example dynamically linked |
<p>There is some skeleton code for running userland programs as well. This |
424 |
programs). |
will not emulate any particular machine, but instead try to translate |
425 |
|
syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now, |
426 |
|
this is just a proof-of-concept, to show that it could work; there's lots |
427 |
|
of work left to do to make it actually run useful programs. |
428 |
|
|
429 |
<p> |
<p> |
430 |
|
|
455 |
tab.csbnet.se |
tab.csbnet.se |
456 |
</pre> |
</pre> |
457 |
|
|
458 |
|
<!-- |
459 |
<p> |
<p> |
460 |
<li><b>NetBSD/powerpc:</b> |
<li><b>NetBSD/powerpc:</b> |
461 |
<br> |
<br> |
479 |
Hello, world! |
Hello, world! |
480 |
|
|
481 |
</pre> |
</pre> |
482 |
|
--> |
483 |
|
|
484 |
</ul> |
</ul> |
485 |
|
|
547 |
</pre> |
</pre> |
548 |
This binary image can now be used in the emulator: |
This binary image can now be used in the emulator: |
549 |
<pre> |
<pre> |
550 |
$ <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> |
551 |
|
|
552 |
KN02-BA V5.7e |
KN02-BA V5.7e |
553 |
?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] |
588 |
osconsole=3 |
osconsole=3 |
589 |
>> |
>> |
590 |
</pre> |
</pre> |
591 |
<i>(Note: at the moment, this doesn't work. I must have broken something when |
|
592 |
fixing something else, but this is what it looked like at the time.)</i> |
<p><font color="#ff0000">(Note: at the moment, this doesn't work. |
593 |
<p> |
I must have broken something when fixing something else, but this |
594 |
During bootup, the PROM complains <i>a lot</i> about hardware failures. |
is what it looked like at the time.)</font> |
595 |
|
|
596 |
|
<p>During bootup, the PROM complains <i>a lot</i> about hardware failures. |
597 |
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. |
598 |
<p> |
|
599 |
The command line options used are: -E dec for DECstation, -e 3min for |
<p>The command line options used are: <tt>-e 3min</tt> for |
600 |
"model 3" (5000/1xx), -Q to supress the emulator's own PROM |
"DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM |
601 |
call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly |
call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly |
602 |
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 |
603 |
always believe there is 128MB ram anyway), and -q to supress debug messages. |
always believe there is 128MB ram anyway), and <tt>-q</tt> to supress debug messages. |
604 |
The 0xbfc00000 in front of the filename tells GXemul that it is a raw |
The <tt>0xbfc00000</tt> in front of the filename tells GXemul that it is a raw |
605 |
binary file which should be loaded at a specific virtual address. |
binary file which should be loaded at a specific virtual address. |
606 |
|
|
607 |
|
|
608 |
<p><br> |
<p><br> |
609 |
<h4>Dumping the PROM on a SGI O2:</h4> |
<a name="promdump_o2"><h4>Dumping the PROM on a SGI O2:</h4></a> |
610 |
|
|
611 |
The general ideas in this section applies to using ROM images from other |
The general ideas in this section applies to using ROM images from other |
612 |
machines as well. Besides DECstation, I've also tried this on an SGI IP32 |
machines as well. I have also tried this on an SGI IP32 ("O2"), in addition |
613 |
("O2"). |
to the DECstation. |
614 |
<p> |
|
615 |
For the O2, a suitable command to dump the prom memory range is |
<p>For the O2, a suitable command to dump the prom memory range is |
616 |
<pre> |
<pre> |
617 |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
618 |
</pre> |
</pre> |
619 |
Make sure you capture all the output (via serial console) into a file, |
Make sure you capture all the output (via serial console) into a file, |
620 |
and then run experiments/sgiprom_to_bin on the captured file. |
and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file. |
|
<p> |
|
|
(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.) |
|
621 |
|
|
622 |
|
<p> |
623 |
|
|
624 |
|
<a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a> |
625 |
|
|
626 |
|
<a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a> |
627 |
|
|
628 |
|
<a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a> |
629 |
|
|
630 |
|
<p>The photo on the left is from the real machine. The other two are |
631 |
|
screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt> |
632 |
|
framebuffer scaledown. |
633 |
|
|
634 |
|
<p>Normally during bootup, the IP32 PROM does a Power-On test which makes |
635 |
|
sure that the caches and other things are working properly. GXemul doesn't |
636 |
|
emulate all those things well enough for the tests to pass. The |
637 |
|
experimental screenshots above were taken with cache detection skipped |
638 |
|
manually. |
639 |
|
|
640 |
|
<p><font color="#ff0000"> |
641 |
|
In other words: don't expect this to work out-of-the-box with GXemul right |
642 |
|
now. It might work once I've added correct cache emulation.</font> |
643 |
|
|
644 |
|
<p>The command line used to start the emulator, once correct cache |
645 |
|
emulation has been implemented, would be something like <tt>gxemul -XQeo2 |
646 |
|
0xbfc00000:prom.bin</tt>. |
647 |
|
|
648 |
|
<p>The same caution applies when dealing with SGI PROMs as with |
649 |
|
DECstation PROMs: GXemul doesn't really emulate the hardware, it only |
650 |
|
"fakes" devices well enough to fool some things, primarily NetBSD, that |
651 |
|
it is emulating a real machine. ROM code is usually a <i>lot</i> more |
652 |
|
picky about the details. |
653 |
|
|
654 |
|
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
655 |
|
some traces of info from how Linux/O2 draws to the screen with some |
656 |
|
reverse-engineering of my own, I've implemented enough of the controller to |
657 |
|
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
658 |
|
controller is not implemented yet either. |
659 |
|
|
660 |
|
|
661 |
|
|