| 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.63 2006/05/22 04:53:52 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: |
| 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="#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 / 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 |
|
|
| 108 |
|
|
| 109 |
|
|
| 110 |
<p><br> |
<p><br> |
| 111 |
<a name="portmips"></a> |
<a name="devel"></a> |
| 112 |
<h3>Porting operating systems to MIPS using GXemul:</h3> |
<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 |
Is this a good idea? The answer is yes and no, depending on what you are |
<p>Important things to keep in mind: |
|
trying to port to. If you are developing an operating system or operating |
|
|
system kernel of your own, and wish to target MIPS-like systems in general, |
|
|
then the answer might be yes, for experimental purposes. |
|
|
|
|
|
<p> |
|
|
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. |
|
|
|
|
|
<p> |
|
|
In many cases, hardware devices in GXemul are only implemented well |
|
|
enough to fool eg. NetBSD that they are working correctly, while in |
|
|
fact they don't work very much at all. Please keep this in mind, if you plan |
|
|
to use GXemul when porting your code to MIPS. |
|
| 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 |
|
|
| 170 |
<h3>Using GXemul in compiler contruction courses:</h3> |
<h3>Using GXemul in compiler contruction courses:</h3> |
| 171 |
|
|
| 172 |
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 |
| 173 |
realistic target platform, then MIPS (as emulated by GXemul) |
realistic target platform, then MIPS or ARM (as emulated by GXemul) |
| 174 |
might be a suitable choice. |
might be suitable choices. |
| 175 |
|
|
| 176 |
<ul> |
<ul> |
| 177 |
<li><b>(+)</b> Your compiler needs to output real assembly |
<li><b>(+)</b> Your compiler needs to output real assembly |
| 178 |
language code, which the assembler (eg gas, the GNU assembler) can |
language code, which the assembler (e.g. gas, the GNU assembler) can |
| 179 |
then compile into object format, and then you need to link this |
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 |
into an executable image. This is much closer to how things work |
| 181 |
in real life than running assembly language listings in a simulator |
in real life than running assembly language listings in a simulator |
| 182 |
(eg SPIM). |
(e.g. SPIM). |
| 183 |
<p> |
<p> |
| 184 |
<li><b>(-)</b> GXemul does not simulate out-of-order |
<li><b>(-)</b> GXemul does not simulate out-of-order |
| 185 |
execution, penalties related to instruction scheduling, or |
execution, penalties related to instruction scheduling, or |
| 205 |
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 |
| 206 |
emulated DECstation machine, you would use a command line such as this: |
emulated DECstation machine, you would use a command line such as this: |
| 207 |
<pre> |
<pre> |
| 208 |
$ <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> |
| 209 |
</pre> |
</pre> |
| 210 |
<p> |
|
| 211 |
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 |
| 212 |
<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 |
| 213 |
bootable! |
image is bootable! |
| 214 |
<p> |
|
| 215 |
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 |
| 216 |
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, |
| 217 |
unless you specify explicitly which ID number the devices should have. |
unless you specify explicitly which ID number the devices should have. |
| 218 |
<pre> |
<pre> |
| 219 |
$ <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> |
| 220 |
</pre> |
</pre> |
| 221 |
Note: In the example above, disk2.raw will get scsi id 5. |
Note: In the example above, disk2.raw will get scsi id 5. |
| 222 |
<p> |
|
| 223 |
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 |
| 224 |
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). |
| 225 |
For example, the following command would start the emulator with two |
For example, the following command would start the emulator with two |
| 226 |
CDROM images, and one harddisk image: |
CDROM images, and one harddisk image: |
| 227 |
<pre> |
<pre> |
| 228 |
$ <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> |
| 229 |
</pre> |
</pre> |
| 230 |
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 |
| 231 |
this, add a 'b' prefix to one of the devices: |
this, add a 'b' prefix to one of the devices: |
| 232 |
<pre> |
<pre> |
| 233 |
$ <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> |
| 234 |
</pre> |
</pre> |
| 235 |
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 |
| 236 |
use it as a CD-ROM directly accessible from within the emulator: |
use it as a CD-ROM directly accessible from within the emulator: |
| 237 |
<pre> |
<pre> |
| 238 |
$ <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> |
| 239 |
</pre> |
</pre> |
| 240 |
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 |
| 241 |
recommend it. |
recommend it. |
| 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> |
<p><br> |
| 342 |
<a name="largeimages"></a> |
<a name="largeimages"></a> |
| 343 |
<h3>How to extract large gzipped disk images:</h3> |
<h3>How to extract large gzipped disk images:</h3> |
| 382 |
<a name="userland"></a> |
<a name="userland"></a> |
| 383 |
<h3>Running userland binaries:</h3> |
<h3>Running userland binaries:</h3> |
| 384 |
|
|
| 385 |
You can run (some) userland programs as well. This will not emulate any |
<font color="#ff0000">Note: This feature does not really work yet. |
| 386 |
particular machine, but instead try to translate syscalls from for example |
It is currently disabled in stable release builds of the emulator.</font> |
| 387 |
NetBSD/pmax into the host's OS' syscalls. Right now, this is just a |
|
| 388 |
proof-of-concept, to show that it would work; there's lots of work left to |
<p>There is some skeleton code for running userland programs as well. This |
| 389 |
do to make it actually run useful programs (for example dynamically linked |
will not emulate any particular machine, but instead try to translate |
| 390 |
programs). |
syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now, |
| 391 |
|
this is just a proof-of-concept, to show that it could work; there's lots |
| 392 |
|
of work left to do to make it actually run useful programs. |
| 393 |
|
|
| 394 |
<p> |
<p> |
| 395 |
|
|
| 420 |
tab.csbnet.se |
tab.csbnet.se |
| 421 |
</pre> |
</pre> |
| 422 |
|
|
| 423 |
|
<!-- |
| 424 |
<p> |
<p> |
| 425 |
<li><b>NetBSD/powerpc:</b> |
<li><b>NetBSD/powerpc:</b> |
| 426 |
<br> |
<br> |
| 444 |
Hello, world! |
Hello, world! |
| 445 |
|
|
| 446 |
</pre> |
</pre> |
| 447 |
|
--> |
| 448 |
|
|
| 449 |
</ul> |
</ul> |
| 450 |
|
|
| 512 |
</pre> |
</pre> |
| 513 |
This binary image can now be used in the emulator: |
This binary image can now be used in the emulator: |
| 514 |
<pre> |
<pre> |
| 515 |
$ <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> |
| 516 |
|
|
| 517 |
KN02-BA V5.7e |
KN02-BA V5.7e |
| 518 |
?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] |
| 553 |
osconsole=3 |
osconsole=3 |
| 554 |
>> |
>> |
| 555 |
</pre> |
</pre> |
| 556 |
<i>(Note: at the moment, this doesn't work. I must have broken something when |
|
| 557 |
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. |
| 558 |
<p> |
I must have broken something when fixing something else, but this |
| 559 |
During bootup, the PROM complains <i>a lot</i> about hardware failures. |
is what it looked like at the time.)</font> |
| 560 |
|
|
| 561 |
|
<p>During bootup, the PROM complains <i>a lot</i> about hardware failures. |
| 562 |
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. |
| 563 |
<p> |
|
| 564 |
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 |
| 565 |
"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 |
| 566 |
call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly |
call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly |
| 567 |
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 |
| 568 |
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. |
| 569 |
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 |
| 570 |
binary file which should be loaded at a specific virtual address. |
binary file which should be loaded at a specific virtual address. |
| 571 |
|
|
| 572 |
|
|
| 574 |
<h4>Dumping the PROM on a SGI O2:</h4> |
<h4>Dumping the PROM on a SGI O2:</h4> |
| 575 |
|
|
| 576 |
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 |
| 577 |
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 |
| 578 |
("O2"). |
to the DECstation. |
| 579 |
<p> |
|
| 580 |
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 |
| 581 |
<pre> |
<pre> |
| 582 |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
>> <b>dump -b 0xBFC00000:0xBFC80000</b> |
| 583 |
</pre> |
</pre> |
| 584 |
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, |
| 585 |
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.) |
|
| 586 |
|
|
| 587 |
|
<p> |
| 588 |
|
|
| 589 |
|
<a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a> |
| 590 |
|
|
| 591 |
|
<a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a> |
| 592 |
|
|
| 593 |
|
<a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a> |
| 594 |
|
|
| 595 |
|
<p>The photo on the left is from the real machine. The other two are |
| 596 |
|
screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt> |
| 597 |
|
framebuffer scaledown. |
| 598 |
|
|
| 599 |
|
<p>Normally during bootup, the IP32 PROM does a Power-On test which makes |
| 600 |
|
sure that the caches and other things are working properly. GXemul doesn't |
| 601 |
|
emulate all those things well enough for the tests to pass. The |
| 602 |
|
experimental screenshots above were taken with cache detection skipped |
| 603 |
|
manually. |
| 604 |
|
|
| 605 |
|
<p><font color="#ff0000"> |
| 606 |
|
In other words: don't expect this to work out-of-the-box with GXemul right |
| 607 |
|
now. It might work once I've added correct cache emulation.</font> |
| 608 |
|
|
| 609 |
|
<p>The command line used to start the emulator, once correct cache |
| 610 |
|
emulation has been implemented, would be something like <tt>gxemul -XQeo2 |
| 611 |
|
0xbfc00000:prom.bin</tt>. |
| 612 |
|
|
| 613 |
|
<p>The same caution applies when dealing with SGI PROMs as with |
| 614 |
|
DECstation PROMs: GXemul doesn't really emulate the hardware, it only |
| 615 |
|
"fakes" devices well enough to fool some things, primarily NetBSD, that |
| 616 |
|
it is emulating a real machine. ROM code is usually a <i>lot</i> more |
| 617 |
|
picky about the details. |
| 618 |
|
|
| 619 |
|
<p>The graphics used in the O2 is (as far as I know) undocumented. Combining |
| 620 |
|
some traces of info from how Linux/O2 draws to the screen with some |
| 621 |
|
reverse-engineering of my own, I've implemented enough of the controller to |
| 622 |
|
let the PROM draw rectangles and bitmaps, but not much more. The SCSI |
| 623 |
|
controller is not implemented yet either. |
| 624 |
|
|
| 625 |
|
|
| 626 |
|
|
Parent Directory
| 
Revision Log
| 
Patch