10 |
|
|
11 |
<!-- |
<!-- |
12 |
|
|
13 |
$Id: misc.html,v 1.50 2005/08/16 05:15:24 debug Exp $ |
$Id: misc.html,v 1.58 2005/11/25 22:35:44 debug Exp $ |
14 |
|
|
15 |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
Copyright (C) 2003-2005 Anders Gavare. All rights reserved. |
16 |
|
|
52 |
developing firmware, using GXemul</a> |
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="#filexfer">Transfering files to/from the guest OS</a> |
56 |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
<li><a href="#largeimages">How to extract large gzipped disk images</a> |
57 |
<li><a href="#userland">Running userland binaries</a> |
<li><a href="#userland">Running userland binaries</a> |
58 |
<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> |
73 |
reasons why networking is implemented in the emulator the way it currently |
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"> |
is implemented, you might want to read the <a href="technical.html#net"> |
75 |
networking section in the technical documentation</a>. |
networking section in the technical documentation</a>. |
76 |
<p> |
|
77 |
The guest OS running inside the emulator uses a private IPv4 address, such |
<p><font color="#ff0000">This is still experimental, hackish, and |
78 |
as 10.0.0.1, and the emulator acts as a NAT-like gateway/firewall at IPv4 |
rather buggy. With NetBSD running as guest operating system, it mostly |
79 |
address 10.0.0.254. To the outside world it will seem like it is the host's |
works.</font> |
80 |
OS that connects to other machines on the internet, not the guest OS. |
|
81 |
<p> |
<p>When only one machine is being emulated, the following default values |
82 |
<font color="#ff0000">NOTE: This is still experimental! |
apply:<pre> |
83 |
As of 2004-07-21, ARP + ICMP + UDP + TCP are emulated well enough to let |
IPv4 address: 10.0.0.1 |
84 |
NetBSD and OpenBSD install via ftp, and use the network for many normal |
Netmask: 255.0.0.0 |
85 |
activities, but not everything works yet.</font> |
Gateway: 10.0.0.254 |
86 |
|
</pre> |
87 |
|
|
88 |
|
<p>The emulated machine must of course have a NIC which is emulated |
89 |
|
correctly. At the moment, the following NICs should work: |
90 |
|
<ul> |
91 |
|
<li><tt><b>ether</b></tt>, the "fake" experimental ethernet device |
92 |
|
(documented <a href="experiments.html#expdevices">here</a>) |
93 |
|
<li><tt><b>le</b></tt>, Turbochannel Lance Ethernet, as used in |
94 |
|
DECstation 5000/200 ("3max") |
95 |
|
<li><tt><b>mec</b></tt>, the SGI O2's ethernet controller |
96 |
|
<li><tt><b>dec21143</b></tt>, Digital's 21143 NIC (known as <tt>dc</tt> |
97 |
|
in OpenBSD, or <tt>tlp</tt> in NetBSD) |
98 |
|
</ul> |
99 |
|
|
100 |
|
<p>The emulator acts as a NAT-like gateway/firewall; to the outside world |
101 |
|
it will seem like it is the host's OS that connects to other machines on |
102 |
|
the internet, not the guest OS. |
103 |
|
|
104 |
|
|
105 |
|
|
112 |
|
|
113 |
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 |
114 |
detail you need in your simulations. If you are developing an operating |
detail you need in your simulations. If you are developing an operating |
115 |
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 |
116 |
MIPS-like systems in general, then the answer might be yes, for |
complement to testing on real hardware. |
|
experimental purposes. |
|
117 |
|
|
118 |
<p>Some examples of things that <i>don't</i> work, that you should keep in |
<p>Important things to keep in mind: |
|
mind: |
|
119 |
|
|
120 |
<ul> |
<ul> |
121 |
<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 |
122 |
machine, using GXemul, will not necessarily cause the code to |
machine, using GXemul, will not "magically" cause the code to |
123 |
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 |
124 |
work on real hardware, sometimes it's the other way around. |
work on real hardware, sometimes it's the other way around. |
125 |
|
|
127 |
<li>GXemul contains bugs, and many things are not yet implemented. |
<li>GXemul contains bugs, and many things are not yet implemented. |
128 |
|
|
129 |
<p> |
<p> |
130 |
<li>I have only implemented devices in GXemul to the degree that |
<li><b>Very important!</b> I have only implemented devices in GXemul |
131 |
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. |
132 |
is that the device implementations are "lazy hacks", based on the |
<p> |
133 |
assumption that the emulated OS is already developed and bug-free. |
If you are developing a driver for a device which is emulated by |
134 |
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 |
135 |
so if you do that, then be prepared for bugs and inconsitencies. |
probability of a bug in GXemul's implementation of the device is |
136 |
|
very much higher than that of a bug in your driver. |
137 |
|
<p> |
138 |
|
The device implementations in GXemul are based on the assumption |
139 |
|
that the emulated OS is already developed and bug-free. They are |
140 |
|
not primarily intended to be used for development of new device |
141 |
|
driver code in operating systems, so if you do that, then be |
142 |
|
prepared for bugs and inconsitencies. |
143 |
<p> |
<p> |
144 |
<li>CPU details in GXemul are usually wrong. If your code depends |
<li>CPU details in GXemul are usually wrong. If your code depends |
145 |
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
on, say, R10000 or MIPS64 specifics, chances are that GXemul will |
146 |
not be sufficient. Again, this was done as "lazy hacks", and pretty |
not be sufficient. One example is different revisions of ISAs; |
147 |
much assumes that the OS being emulated is already developed |
64-bit MIPS instructions which should trigger an exception on a |
148 |
and bug-free. |
real 32-bit MIPS processor usually execute anyway in GXemul. Another |
149 |
|
example is if userland code tries to access kernel memory; in some |
150 |
|
cases there is protection against this, but not in all cases (to get |
151 |
|
higher performance). |
152 |
<p> |
<p> |
153 |
<li>Caches. There is no cache emulation in GXemul right now. Caches |
<li>Caches. There is no cache emulation in GXemul right now. Caches |
154 |
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc |
169 |
<h3>Using GXemul in compiler contruction courses:</h3> |
<h3>Using GXemul in compiler contruction courses:</h3> |
170 |
|
|
171 |
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 |
172 |
realistic target platform, then MIPS (as emulated by GXemul) |
realistic target platform, then MIPS or ARM (as emulated by GXemul) |
173 |
might be a suitable choice. |
might be suitable choices. |
174 |
|
|
175 |
<ul> |
<ul> |
176 |
<li><b>(+)</b> Your compiler needs to output real assembly |
<li><b>(+)</b> Your compiler needs to output real assembly |
206 |
<pre> |
<pre> |
207 |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
$ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b> |
208 |
</pre> |
</pre> |
209 |
<p> |
|
210 |
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 |
211 |
<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 |
212 |
bootable! |
image is bootable! |
213 |
<p> |
|
214 |
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 |
215 |
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, |
216 |
unless you specify explicitly which ID number the devices should have. |
unless you specify explicitly which ID number the devices should have. |
217 |
<pre> |
<pre> |
218 |
$ <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> |
219 |
</pre> |
</pre> |
220 |
Note: In the example above, disk2.raw will get scsi id 5. |
Note: In the example above, disk2.raw will get scsi id 5. |
221 |
<p> |
|
222 |
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 |
223 |
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). |
224 |
For example, the following command would start the emulator with two |
For example, the following command would start the emulator with two |
225 |
CDROM images, and one harddisk image: |
CDROM images, and one harddisk image: |
290 |
|
|
291 |
|
|
292 |
|
|
293 |
|
|
294 |
|
|
295 |
|
|
296 |
|
<p><br> |
297 |
|
<a name="filexfer"></a> |
298 |
|
<h3>Transfering files to/from the guest OS:</h3> |
299 |
|
|
300 |
|
If the emulated machine supports networking (see |
301 |
|
<a href="#networking">above</a>), then transfering files via FTP is |
302 |
|
probably easiest. |
303 |
|
|
304 |
|
<p>There is another way of transfering files which works for any kind of |
305 |
|
emulated machine which supports disks (either SCSI or IDE). Any file can |
306 |
|
be supplied as a disk image. For example, consider the following:<pre> |
307 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b> |
308 |
|
</pre> |
309 |
|
This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on |
310 |
|
controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller |
311 |
|
0 (wd1). From inside NetBSD, it is now possible to extract the files using |
312 |
|
the following command:<pre> |
313 |
|
(inside emulated NetBSD/cats) |
314 |
|
# <b>tar zxvf /dev/wd1c</b> |
315 |
|
</pre> |
316 |
|
Don't worry if NetBSD complains about lack of disklabel; it doesn't |
317 |
|
matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of |
318 |
|
<tt>wd1c</tt> for the entire disk. |
319 |
|
There is also a minor problem: reading the end of the disk image. If you |
320 |
|
experience problems untaring archives like this, then pad out the archive |
321 |
|
first with some zeroes. |
322 |
|
|
323 |
|
<p>Transfering files <i>out</i> from the emulated operating system to the |
324 |
|
host can be done the same way. First, prepare an empty archive file:<pre> |
325 |
|
$ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b> |
326 |
|
</pre>This example created a 10 MB empty file. Then, start the emulator |
327 |
|
like this:<pre> |
328 |
|
$ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b> |
329 |
|
</pre> |
330 |
|
and transfer files by creating an archive directly onto the disk image:<pre> |
331 |
|
(inside emulated NetBSD/cats) |
332 |
|
# <b>tar cvf /dev/wd1c filenames</b> |
333 |
|
</pre> |
334 |
|
where filenames are the files or directories to transfer. |
335 |
|
|
336 |
|
|
337 |
|
|
338 |
|
|
339 |
|
|
340 |
<p><br> |
<p><br> |
341 |
<a name="largeimages"></a> |
<a name="largeimages"></a> |
342 |
<h3>How to extract large gzipped disk images:</h3> |
<h3>How to extract large gzipped disk images:</h3> |
551 |
osconsole=3 |
osconsole=3 |
552 |
>> |
>> |
553 |
</pre> |
</pre> |
554 |
<i>(Note: at the moment, this doesn't work. I must have broken something when |
|
555 |
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. |
556 |
<p> |
I must have broken something when fixing something else, but this |
557 |
During bootup, the PROM complains <i>a lot</i> about hardware failures. |
is what it looked like at the time.)</font> |
558 |
|
|
559 |
|
<p>During bootup, the PROM complains <i>a lot</i> about hardware failures. |
560 |
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. |
561 |
<p> |
|
562 |
The command line options used are: -e 3min for |
<p>The command line options used are: <tt>-e 3min</tt> for |
563 |
"DECstation 3min" (5000/1xx), -Q to supress the emulator's own PROM |
"DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM |
564 |
call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly |
call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly |
565 |
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 |
566 |
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. |
567 |
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 |
568 |
binary file which should be loaded at a specific virtual address. |
binary file which should be loaded at a specific virtual address. |
569 |
|
|
570 |
|
|
572 |
<h4>Dumping the PROM on a SGI O2:</h4> |
<h4>Dumping the PROM on a SGI O2:</h4> |
573 |
|
|
574 |
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 |
575 |
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 |
576 |
("O2"). |
to the DECstation. |
577 |
<p> |
|
578 |
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 |
579 |
<pre> |
<pre> |
580 |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
581 |
</pre> |
</pre> |
582 |
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, |
583 |
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.) |
|
584 |
|
|
585 |
|
<p> |
586 |
|
|
587 |
|
<a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a> |
588 |
|
|
589 |
|
<a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a> |
590 |
|
|
591 |
|
<a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a> |
592 |
|
|
593 |
|
<p>The photo on the left is from the real machine. The other two are |
594 |
|
screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt> |
595 |
|
framebuffer scaledown. |
596 |
|
|
597 |
|
<p>Normally during bootup, the IP32 PROM does a Power-On test which makes |
598 |
|
sure that the caches and other things are working properly. GXemul doesn't |
599 |
|
emulate all those things well enough for the tests to pass. The |
600 |
|
experimental screenshots above were taken with cache detection skipped |
601 |
|
manually. |
602 |
|
|
603 |
|
<p><font color="#ff0000"> |
604 |
|
In other words: don't expect this to work out-of-the-box with GXemul right |
605 |
|
now. It might work once I've added correct cache emulation.</font> |
606 |
|
|
607 |
|
<p>The command line used to start the emulator, once correct cache |
608 |
|
emulation has been implemented, would be something like <tt>gxemul -XQeo2 |
609 |
|
0xbfc00000:prom.bin</tt>. |
610 |
|
|
611 |
|
<p>The same caution applies when dealing with SGI PROMs as with |
612 |
|
DECstation PROMs: GXemul doesn't really emulate the hardware, it only |
613 |
|
"fakes" devices well enough to fool some things, primarily NetBSD, that |
614 |
|
it is emulating a real machine. ROM code is usually a <i>lot</i> more |
615 |
|
picky about the details. |
616 |
|
|
617 |
|
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
618 |
|
some traces of info from how Linux/O2 draws to the screen with some |
619 |
|
reverse-engineering of my own, I've implemented enough of the controller to |
620 |
|
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
621 |
|
controller is not implemented yet either. |
622 |
|
|
623 |
|
|
624 |
|
|