1 |
<html><head><title>Gavare's eXperimental Emulator: Miscellaneous</title> |
2 |
<meta name="robots" content="noarchive,nofollow,noindex"></head> |
3 |
<body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000"> |
4 |
<table border=0 width=100% bgcolor="#d0d0d0"><tr> |
5 |
<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"> |
7 |
<b>Gavare's eXperimental Emulator:</b></font><br> |
8 |
<font color="#000000" size="6"><b>Miscellaneous</b> |
9 |
</font></td></tr></table></td></tr></table><p> |
10 |
|
11 |
<!-- |
12 |
|
13 |
$Id: misc.html,v 1.62 2006/02/18 13:15:21 debug Exp $ |
14 |
|
15 |
Copyright (C) 2003-2006 Anders Gavare. All rights reserved. |
16 |
|
17 |
Redistribution and use in source and binary forms, with or without |
18 |
modification, are permitted provided that the following conditions are met: |
19 |
|
20 |
1. Redistributions of source code must retain the above copyright |
21 |
notice, this list of conditions and the following disclaimer. |
22 |
2. Redistributions in binary form must reproduce the above copyright |
23 |
notice, this list of conditions and the following disclaimer in the |
24 |
documentation and/or other materials provided with the distribution. |
25 |
3. The name of the author may not be used to endorse or promote products |
26 |
derived from this software without specific prior written permission. |
27 |
|
28 |
THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND |
29 |
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE |
30 |
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE |
31 |
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE |
32 |
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL |
33 |
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS |
34 |
OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) |
35 |
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT |
36 |
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY |
37 |
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF |
38 |
SUCH DAMAGE. |
39 |
|
40 |
--> |
41 |
|
42 |
|
43 |
<a href="./">Back to the index</a> |
44 |
|
45 |
<p><br> |
46 |
<h2>Miscellaneous</h2> |
47 |
|
48 |
<p> |
49 |
<ul> |
50 |
<li><a href="#networking">Networking</a> |
51 |
<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> |
54 |
<li><a href="#disk">How to start the emulator with a disk image</a> |
55 |
<li><a href="#filexfer">Transfering files to/from the guest OS</a> |
56 |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
57 |
<li><a href="#userland">Running userland binaries</a> |
58 |
<li><a href="#promdump">Using a PROM dump from a real machine</a> |
59 |
</ul> |
60 |
|
61 |
|
62 |
|
63 |
|
64 |
|
65 |
|
66 |
|
67 |
<p><br> |
68 |
<a name="networking"></a> |
69 |
<h3>Networking:</h3> |
70 |
|
71 |
It is possible to let the guest OS running inside the emulator get access to |
72 |
the Internet. If you are interested in the technical details, and the |
73 |
reasons why networking is implemented in the emulator the way it currently |
74 |
is implemented, you might want to read the <a href="technical.html#net"> |
75 |
networking section in the technical documentation</a>. |
76 |
|
77 |
<p><font color="#ff0000">This is still experimental, hackish, and |
78 |
rather buggy. With NetBSD running as guest operating system, it mostly |
79 |
works.</font> |
80 |
|
81 |
<p>When only one machine is being emulated, the following default values |
82 |
apply:<pre> |
83 |
IPv4 address: 10.0.0.1 |
84 |
Netmask: 255.0.0.0 |
85 |
Gateway / default route: 10.0.0.254 |
86 |
Nameserver: 10.0.0.254 |
87 |
</pre> |
88 |
|
89 |
<p>The emulated machine must of course have a NIC which is emulated |
90 |
correctly. At the moment, the following NICs should work: |
91 |
<ul> |
92 |
<li><tt><b>ether</b></tt>, the "fake" experimental ethernet device |
93 |
(documented <a href="experiments.html#expdevices_ether">here</a>) |
94 |
<li><tt><b>le</b></tt>, Turbochannel Lance Ethernet, as used in |
95 |
DECstation 5000/200 ("3max") |
96 |
<li><tt><b>mec</b></tt>, the SGI O2's ethernet controller |
97 |
<li><tt><b>dec21143</b></tt>, Digital's 21143 NIC (known as <tt>dc</tt> |
98 |
in OpenBSD, or <tt>tlp</tt> in NetBSD) |
99 |
</ul> |
100 |
|
101 |
<p>The emulator acts as a NAT-like gateway/firewall; to the outside world |
102 |
it will seem like it is the host's OS that connects to other machines on |
103 |
the internet, not the guest OS. |
104 |
|
105 |
|
106 |
|
107 |
|
108 |
|
109 |
|
110 |
<p><br> |
111 |
<a name="devel"></a> |
112 |
<h3>Writing operating system code, or developing firmware, using GXemul:</h3> |
113 |
|
114 |
Is this a good idea? The answer is yes and no, depending on the level of |
115 |
detail you need in your simulations. If you are developing an operating |
116 |
system or operating system kernel of your own, then the emulator can be a |
117 |
complement to testing on real hardware. |
118 |
|
119 |
<p>Important things to keep in mind: |
120 |
|
121 |
<ul> |
122 |
<li>Porting code to a specific machine mode, e.g. a Silicon Graphics |
123 |
machine, using GXemul, will not "magically" cause the code to |
124 |
work on a real machine. Sometimes code works in GXemul which doesn't |
125 |
work on real hardware, sometimes it's the other way around. |
126 |
|
127 |
<p> |
128 |
<li>GXemul contains bugs, and many things are not yet implemented. |
129 |
|
130 |
<p> |
131 |
<li><b>Very important!</b> I have only implemented devices in GXemul |
132 |
to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much. |
133 |
<p> |
134 |
If you are developing a driver for a device which is emulated by |
135 |
GXemul, and your driver does not seem to be working, then the |
136 |
probability of a bug in GXemul's implementation of the device is |
137 |
very much higher than that of a bug in your driver. |
138 |
<p> |
139 |
The device implementations in GXemul are based on the assumption |
140 |
that the emulated OS is already developed and bug-free. They are |
141 |
not primarily intended to be used for development of new device |
142 |
driver code in operating systems, so if you do that, then be |
143 |
prepared for bugs and inconsitencies. |
144 |
<p> |
145 |
<li>CPU details in GXemul are usually wrong. If your code depends |
146 |
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
147 |
not be sufficient. One example is different revisions of ISAs; |
148 |
64-bit MIPS instructions which should trigger an exception on a |
149 |
real 32-bit MIPS processor usually execute anyway in GXemul. Another |
150 |
example is if userland code tries to access kernel memory; in some |
151 |
cases there is protection against this, but not in all cases (to get |
152 |
higher performance). |
153 |
<p> |
154 |
<li>Caches. There is no cache emulation in GXemul right now. Caches |
155 |
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
156 |
in the DECstation emulation mode, but other than that, cache |
157 |
operations are treated as nops. |
158 |
</ul> |
159 |
|
160 |
<p>The bottom line is that GXemul can be useful as yet another way to test |
161 |
your code during development, but it should not be fully relied on. |
162 |
|
163 |
|
164 |
|
165 |
|
166 |
|
167 |
|
168 |
<p><br> |
169 |
<a name="compilercontruct"></a> |
170 |
<h3>Using GXemul in compiler contruction courses:</h3> |
171 |
|
172 |
If you are learning how to write a compiler, and wish to target a |
173 |
realistic target platform, then MIPS or ARM (as emulated by GXemul) |
174 |
might be suitable choices. |
175 |
|
176 |
<ul> |
177 |
<li><b>(+)</b> Your compiler needs to output real assembly |
178 |
language code, which the assembler (eg gas, the GNU assembler) can |
179 |
then compile into object format, and then you need to link this |
180 |
into an executable image. This is much closer to how things work |
181 |
in real life than running assembly language listings in a simulator |
182 |
(eg SPIM). |
183 |
<p> |
184 |
<li><b>(-)</b> GXemul does not simulate out-of-order |
185 |
execution, penalties related to instruction scheduling, or |
186 |
load-delays, so it cannot be used to create optimizing compilers |
187 |
that take advantage of such processor features. GXemul keeps |
188 |
track of the number of instructions executed, but that's it. |
189 |
</ul> |
190 |
|
191 |
|
192 |
|
193 |
|
194 |
|
195 |
|
196 |
<p><br> |
197 |
<a name="disk"></a> |
198 |
<h3>How to start the emulator with a disk image:</h3> |
199 |
|
200 |
Add <i>-d [prefixes:]diskimagefilename</i> to the command line, where prefixes |
201 |
are one or more single-character options. Run <b>gxemul -h</b> |
202 |
to get a list of possible options. |
203 |
|
204 |
<p> |
205 |
Here are some examples. If you want to run a NetBSD/pmax kernel on an |
206 |
emulated DECstation machine, you would use a command line such as this: |
207 |
<pre> |
208 |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
209 |
</pre> |
210 |
|
211 |
<p>NOTE: For some emulation modes, such as the DECstation mode, you do |
212 |
<i>not</i> actually have to specify the name of the kernel, if the disk |
213 |
image is bootable! |
214 |
|
215 |
<p>It is possible to have more than one disk. For each -d argument, a disk |
216 |
image is added; the first will be SCSI target 0, the second will be target 1, and so on, |
217 |
unless you specify explicitly which ID number the devices should have. |
218 |
<pre> |
219 |
$ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b> |
220 |
</pre> |
221 |
Note: In the example above, disk2.raw will get scsi id 5. |
222 |
|
223 |
<p>If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be |
224 |
a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk). |
225 |
For example, the following command would start the emulator with two |
226 |
CDROM images, and one harddisk image: |
227 |
<pre> |
228 |
$ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b> |
229 |
</pre> |
230 |
Usually, the device with the lowest id becomes the boot device. To override |
231 |
this, add a 'b' prefix to one of the devices: |
232 |
<pre> |
233 |
$ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b> |
234 |
</pre> |
235 |
If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can |
236 |
use it as a CD-ROM directly accessible from within the emulator: |
237 |
<pre> |
238 |
$ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b> |
239 |
</pre> |
240 |
It is probably possible to use harddisks as well this way, but I would not |
241 |
recommend it. |
242 |
<p> |
243 |
Using emulated tape drives is a bit more complicated than disks, because a |
244 |
tape can be made up of several "files" with space in between. The solution |
245 |
I have choosen is to have one file in the host's file system space for each |
246 |
tape file. The prefix for using tapes is 't', and the filename given is |
247 |
for the <i>first</i> file on that tape (number zero, implicitly). For |
248 |
files following file nr 0, a dot and the filenumber is appended to the |
249 |
filename. |
250 |
<p> |
251 |
As an example, starting the emulator with |
252 |
<pre> |
253 |
<b>-d t4:mytape.img</b> |
254 |
</pre> |
255 |
will cause SCSI id 4 to be a tape device, using the following file number |
256 |
to name translation scheme: |
257 |
<p> |
258 |
<center> |
259 |
<table border="0"> |
260 |
<tr> |
261 |
<td><b>File number:</b></td> |
262 |
<td><b>File name in the host's filesystem:</b></td> |
263 |
</tr> |
264 |
<tr> |
265 |
<td align="center">0</td> |
266 |
<td align="left">mytape.img</td> |
267 |
</tr> |
268 |
<tr> |
269 |
<td align="center">1</td> |
270 |
<td align="left">mytape.img.1</td> |
271 |
</tr> |
272 |
<tr> |
273 |
<td align="center">2</td> |
274 |
<td align="left">mytape.img.2</td> |
275 |
</tr> |
276 |
<tr> |
277 |
<td align="center">..</td> |
278 |
<td align="left">..</td> |
279 |
</tr> |
280 |
</table> |
281 |
</center> |
282 |
<p> |
283 |
If you already have a number of tape files, which should be placed on the |
284 |
same emulated tape, then you might not want to rename all those files. |
285 |
Use symbolic links instead (ln -s). |
286 |
<p> |
287 |
There is another advantage to using symbolic links for tape filenames: |
288 |
every time a tape is rewound, it is reopened using the filename given |
289 |
on the command line. By changing what the symbolic name points to, |
290 |
you can "switch tapes" without quiting and restarting the emulator. |
291 |
|
292 |
|
293 |
|
294 |
|
295 |
|
296 |
|
297 |
<p><br> |
298 |
<a name="filexfer"></a> |
299 |
<h3>Transfering files to/from the guest OS:</h3> |
300 |
|
301 |
If the emulated machine supports networking (see |
302 |
<a href="#networking">above</a>), then transfering files via FTP is |
303 |
probably easiest. |
304 |
|
305 |
<p>There is another way of transfering files which works for any kind of |
306 |
emulated machine which supports disks (either SCSI or IDE). Any file can |
307 |
be supplied as a disk image. For example, consider the following:<pre> |
308 |
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b> |
309 |
</pre> |
310 |
This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on |
311 |
controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller |
312 |
0 (wd1). From inside NetBSD, it is now possible to extract the files using |
313 |
the following command:<pre> |
314 |
(inside emulated NetBSD/cats) |
315 |
# <b>tar zxvf /dev/wd1c</b> |
316 |
</pre> |
317 |
Don't worry if NetBSD complains about lack of disklabel; it doesn't |
318 |
matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of |
319 |
<tt>wd1c</tt> for the entire disk. |
320 |
There is also a minor problem: reading the end of the disk image. If you |
321 |
experience problems untaring archives like this, then pad out the archive |
322 |
first with some zeroes. |
323 |
|
324 |
<p>Transfering files <i>out</i> from the emulated operating system to the |
325 |
host can be done the same way. First, prepare an empty archive file:<pre> |
326 |
$ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b> |
327 |
</pre>This example created a 10 MB empty file. Then, start the emulator |
328 |
like this:<pre> |
329 |
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b> |
330 |
</pre> |
331 |
and transfer files by creating an archive directly onto the disk image:<pre> |
332 |
(inside emulated NetBSD/cats) |
333 |
# <b>tar cvf /dev/wd1c filenames</b> |
334 |
</pre> |
335 |
where filenames are the files or directories to transfer. |
336 |
|
337 |
|
338 |
|
339 |
|
340 |
|
341 |
<p><br> |
342 |
<a name="largeimages"></a> |
343 |
<h3>How to extract large gzipped disk images:</h3> |
344 |
|
345 |
Unix filesystems usually support large files with "holes". Holes are |
346 |
zero-filled blocks that don't actually exist on disk. This is very |
347 |
practical for emulated disk images, as it is possible to create a very |
348 |
large disk image without using up much space at all. |
349 |
|
350 |
<p> |
351 |
Using gzip and gunzip on disk images can be <i>very</i> slow, as these |
352 |
files can be multiple gigabytes large, but this is usually necessary for |
353 |
transfering disk images over the internet. If you receive a gzipped disk |
354 |
image, say disk.img.gz, and run a naive |
355 |
<p> |
356 |
<pre> |
357 |
$ <b>gunzip disk.img.gz</b> |
358 |
</pre> |
359 |
<p> |
360 |
on it, you will not end up with an optimized file unless |
361 |
gunzip supports that. (In my experiments, it doesn't.) In plain English, |
362 |
if you type <b>ls -l</b> and the filesize is 9 GB, it will actually occupy |
363 |
9 GB of disk space! This is often unacceptable. |
364 |
<p> |
365 |
Using a simple tool which only writes blocks that are non-zero, a lot of |
366 |
space can be saved. Compile the program cp_removeblocks in the |
367 |
experiments/ directory, and type: |
368 |
<p> |
369 |
<pre> |
370 |
$ <b>gunzip -c disk.img.gz | cp_removeblocks /dev/stdin disk.img</b> |
371 |
</pre> |
372 |
|
373 |
<p> |
374 |
This will give you a disk.img which looks like it is 9 GB, and works like |
375 |
the real file, but the holes are not written out to the disk. (You can see |
376 |
this by running for example <b>du disk.img</b> to see the physical block |
377 |
count.) |
378 |
|
379 |
|
380 |
|
381 |
<p><br> |
382 |
<a name="userland"></a> |
383 |
<h3>Running userland binaries:</h3> |
384 |
|
385 |
<font color="#ff0000">Note: This does not really work yet.</font> |
386 |
|
387 |
<p>There is some skeleton code for running userland programs as well. This |
388 |
will not emulate any particular machine, but instead try to translate |
389 |
syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now, |
390 |
this is just a proof-of-concept, to show that it could work; there's lots |
391 |
of work left to do to make it actually run useful programs. |
392 |
|
393 |
<p> |
394 |
|
395 |
<ul> |
396 |
<li><b>NetBSD/pmax:</b> |
397 |
<br> |
398 |
Running /bin/hostname or /bin/date and similarly trivial |
399 |
programs from the NetBSD/pmax distribution works:<pre> |
400 |
$ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b> |
401 |
tab.csbnet.se |
402 |
$ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b> |
403 |
Sun Jan 25 02:26:14 GMT 2004 |
404 |
$ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b> |
405 |
usage: pmax_bin_sleep seconds |
406 |
$ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b> |
407 |
$ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b> |
408 |
</pre> |
409 |
|
410 |
<p> |
411 |
<li><b>Ultrix:</b> |
412 |
<br> |
413 |
At least /bin/date and /bin/hostname work:<pre> |
414 |
$ <b>gxemul -q -u ultrix ultrix4_bin_date</b> |
415 |
UNIMPLEMENTED ultrix syscall 54 |
416 |
UNIMPLEMENTED ultrix syscall 62 |
417 |
Mon Feb 9 12:50:59 WET 2004 |
418 |
$ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b> |
419 |
tab.csbnet.se |
420 |
</pre> |
421 |
|
422 |
<!-- |
423 |
<p> |
424 |
<li><b>NetBSD/powerpc:</b> |
425 |
<br> |
426 |
/bin/sync from NetBSD/macppc works, but probably not much else.<pre> |
427 |
$ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b> |
428 |
... |
429 |
[ sync() ] |
430 |
[ exit(0) ] |
431 |
cpu_run_deinit(): All CPUs halted. |
432 |
|
433 |
</pre> |
434 |
|
435 |
<p> |
436 |
<li><b>Linux/PPC64:</b> |
437 |
<br> |
438 |
The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a> |
439 |
on IBM's developerWorks pages runs:<pre> |
440 |
$ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b> |
441 |
$ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b> |
442 |
$ <b>gxemul -q -u linux/ppc64 hello-ppc64</b> |
443 |
Hello, world! |
444 |
|
445 |
</pre> |
446 |
--> |
447 |
|
448 |
</ul> |
449 |
|
450 |
|
451 |
|
452 |
|
453 |
|
454 |
<p><br> |
455 |
<a name="promdump"></a> |
456 |
<h3>Using a PROM dump from a real machine:</h3> |
457 |
|
458 |
Raw PROM images from real machines can, in a few cases, be used in |
459 |
the emulator. ROM code is usually much more sensitive to correctness |
460 |
of the emulator than operating system kernels or userland programs |
461 |
are, so don't expect any PROM image to just magically work. |
462 |
|
463 |
|
464 |
<p> |
465 |
<h4>Dumping the PROM on a DECstation 5000/125:</h4> |
466 |
The image first needs to be extracted from the machine. There are |
467 |
several ways to do this. |
468 |
<ul> |
469 |
<li>Use hardware to read the PROM chip(s) directly. Not easy if you |
470 |
don't have such a hardware reader. |
471 |
<li>Copy the PROM memory range into a file, from a running |
472 |
operating system. You need a running OS, and it must |
473 |
have access to the PROM memory range. NetBSD, for example, |
474 |
doesn't allow that from userland. |
475 |
<li>Hook up a serial console and dump using the PROM's own dump |
476 |
command. |
477 |
</ul> |
478 |
<p> |
479 |
The easiest way is to hook up a serial console. The terminal must be |
480 |
able to capture output to a file. |
481 |
<p> |
482 |
These are approximately the commands that I used: |
483 |
<pre> |
484 |
>><b>cnfg</b> <i>Show machine configuration</i> |
485 |
|
486 |
>><b>printenv</b> <i>Show environment variables</i> |
487 |
|
488 |
>><b>setenv more 0</b> <i>This turns off the More messages</i> |
489 |
|
490 |
>><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i> |
491 |
</pre> |
492 |
<p> |
493 |
Remember that DECstations are little endian, so if the dump data |
494 |
looks like this: |
495 |
<pre> |
496 |
bfc00000: 0x0bf0007e |
497 |
</pre> |
498 |
then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b. |
499 |
<p> |
500 |
At 9600 bps, about 10KB can be dumped per minute, so it takes a while. |
501 |
Once enough of the PROM has been dumped, you can press CTRL-C to break out. |
502 |
Then, restore the more environment variable: |
503 |
<pre> |
504 |
>><b>setenv more 24</b> |
505 |
</pre> |
506 |
<p> |
507 |
Now, convert the data you just saved (little-endian words -> bytes), |
508 |
and store in a file. Let's call this file DECstation5000_125_promdump.bin. |
509 |
<pre> |
510 |
$ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b> |
511 |
</pre> |
512 |
This binary image can now be used in the emulator: |
513 |
<pre> |
514 |
$ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b> |
515 |
|
516 |
KN02-BA V5.7e |
517 |
?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA] |
518 |
?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA] |
519 |
... |
520 |
--More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C) |
521 |
>><b>?</b> |
522 |
? [cmd] |
523 |
boot [[-z #] [-n] #/path [ARG...]] |
524 |
cat SCRPT |
525 |
cnfg [#] |
526 |
d [-bhw] [-S #] RNG VAL |
527 |
e [-bhwcdoux] [-S #] RNG |
528 |
erl [-c] |
529 |
go [ADR] |
530 |
init [#] [-m] [ARG...] |
531 |
ls [#] |
532 |
passwd [-c] [-s] |
533 |
printenv [EVN] |
534 |
restart |
535 |
script SCRPT |
536 |
setenv EVN STR |
537 |
sh [-belvS] [SCRPT] [ARG..] |
538 |
t [-l] #/STR [ARG..] |
539 |
unsetenv EVN |
540 |
>><b>cnfg</b> |
541 |
3: KN02-BA DEC V5.7e TCF0 (128 MB) |
542 |
(enet: 00-00-00-00-00-00) |
543 |
(SCSI = 7) |
544 |
0: PMAG-BA DEC V5.3a TCF0 |
545 |
>><b>printenv</b> |
546 |
boot= |
547 |
testaction=q |
548 |
haltaction=h |
549 |
more=24 |
550 |
#=3 |
551 |
console=* |
552 |
osconsole=3 |
553 |
>> |
554 |
</pre> |
555 |
|
556 |
<p><font color="#ff0000">(Note: at the moment, this doesn't work. |
557 |
I must have broken something when fixing something else, but this |
558 |
is what it looked like at the time.)</font> |
559 |
|
560 |
<p>During bootup, the PROM complains <i>a lot</i> about hardware failures. |
561 |
That's because the emulator doesn't emulate the hardware well enough yet. |
562 |
|
563 |
<p>The command line options used are: <tt>-e 3min</tt> for |
564 |
"DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM |
565 |
call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly |
566 |
emulate memory detection well enough for the PROM to accept, so it will |
567 |
always believe there is 128MB ram anyway), and <tt>-q</tt> to supress debug messages. |
568 |
The <tt>0xbfc00000</tt> in front of the filename tells GXemul that it is a raw |
569 |
binary file which should be loaded at a specific virtual address. |
570 |
|
571 |
|
572 |
<p><br> |
573 |
<h4>Dumping the PROM on a SGI O2:</h4> |
574 |
|
575 |
The general ideas in this section applies to using ROM images from other |
576 |
machines as well. I have also tried this on an SGI IP32 ("O2"), in addition |
577 |
to the DECstation. |
578 |
|
579 |
<p>For the O2, a suitable command to dump the prom memory range is |
580 |
<pre> |
581 |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
582 |
</pre> |
583 |
Make sure you capture all the output (via serial console) into a file, |
584 |
and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file. |
585 |
|
586 |
<p> |
587 |
|
588 |
<a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a> |
589 |
|
590 |
<a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a> |
591 |
|
592 |
<a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a> |
593 |
|
594 |
<p>The photo on the left is from the real machine. The other two are |
595 |
screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt> |
596 |
framebuffer scaledown. |
597 |
|
598 |
<p>Normally during bootup, the IP32 PROM does a Power-On test which makes |
599 |
sure that the caches and other things are working properly. GXemul doesn't |
600 |
emulate all those things well enough for the tests to pass. The |
601 |
experimental screenshots above were taken with cache detection skipped |
602 |
manually. |
603 |
|
604 |
<p><font color="#ff0000"> |
605 |
In other words: don't expect this to work out-of-the-box with GXemul right |
606 |
now. It might work once I've added correct cache emulation.</font> |
607 |
|
608 |
<p>The command line used to start the emulator, once correct cache |
609 |
emulation has been implemented, would be something like <tt>gxemul -XQeo2 |
610 |
0xbfc00000:prom.bin</tt>. |
611 |
|
612 |
<p>The same caution applies when dealing with SGI PROMs as with |
613 |
DECstation PROMs: GXemul doesn't really emulate the hardware, it only |
614 |
"fakes" devices well enough to fool some things, primarily NetBSD, that |
615 |
it is emulating a real machine. ROM code is usually a <i>lot</i> more |
616 |
picky about the details. |
617 |
|
618 |
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
619 |
some traces of info from how Linux/O2 draws to the screen with some |
620 |
reverse-engineering of my own, I've implemented enough of the controller to |
621 |
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
622 |
controller is not implemented yet either. |
623 |
|
624 |
|
625 |
|
626 |
|
627 |
</p> |
628 |
|
629 |
</body> |
630 |
</html> |