/[gxemul]/trunk/doc/misc.html

This is repository of my old source code which isn't updated any more. Go to git.rot13.org for current projects!

Diff of /trunk/doc/misc.html

Parent Directory | Revision Log | View Patch Patch

-revision 8 by dpavlin,
Mon Oct  8 16:18:19 2007 UTC
+revision 20 by dpavlin,
Mon Oct  8 16:19:23 2007 UTC
 Line 1
- <html><head><title>GXemul documentation: Misc.</title>
+ <html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;Miscellaneous</title>
  <meta name="robots" content="noarchive,nofollow,noindex"></head>
  <body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
  <table border=0 width=100% bgcolor="#d0d0d0"><tr>
  <td width=100% align=center valign=center><table border=0 width=100%><tr>
  <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
- <b>GXemul documentation:</b></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+ <b>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;</b></font>
- <font color="#000000" size="6"><b>Misc.</b>
+ <font color="#000000" size="6"><b>Miscellaneous</b>
  </font></td></tr></table></td></tr></table><p>
  <!--
- $Id: misc.html,v 1.41 2005/06/04 22:47:49 debug Exp $
+ $Id: misc.html,v 1.58 2005/11/25 22:35:44 debug Exp $
  Copyright (C) 2003-2005  Anders Gavare.  All rights reserved.
 Line 39 
 SUCH DAMAGE.
  -->
  <a href="./">Back to the index</a>
  <p><br>
- <h2>Misc.</h2>
+ <h2>Miscellaneous</h2>
  <p>
  <ul>
    <li><a href="#networking">Networking</a>
-   <li><a href="#portmips">Porting operating systems to MIPS using GXemul</a>
+   <li><a href="#devel">Writing operating system code, or
+         developing firmware, using GXemul</a>
    <li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a>
    <li><a href="#disk">How to start the emulator with a disk image</a>
+   <li><a href="#filexfer">Transfering files to/from the guest OS</a>
    <li><a href="#largeimages">How to extract large gzipped disk images</a>
    <li><a href="#userland">Running userland binaries</a>
    <li><a href="#promdump">Using a PROM dump from a real machine</a>
-Line 70 
 the Internet. If you are interested in t
+Line 73 
 the Internet. If you are interested in t
  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
+ <p><font color="#ff0000">This is still experimental, hackish, and
- 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
- address 10.0.0.254. To the outside world it will seem like it is the host's
+ works.</font>
- OS that connects to other machines on the internet, not the guest OS.
- <p>
+ <p>When only one machine is being emulated, the following default values
- <font color="#ff0000">NOTE: This is still experimental!
+ apply:<pre>
- As of 2004-07-21, ARP + ICMP + UDP + TCP are emulated well enough to let
+         IPv4 address:                   10.0.0.1
- NetBSD and OpenBSD install via ftp, and use the network for many normal
+         Netmask:                        255.0.0.0
- activities, but not everything works yet.</font>
+         Gateway:                        10.0.0.254
+ </pre>
+ <p>The emulated machine must of course have a NIC which is emulated
+ correctly. At the moment, the following NICs should work:
+ <ul>
+   <li><tt><b>ether</b></tt>, the "fake" experimental ethernet device
+         (documented <a href="experiments.html#expdevices">here</a>)
+   <li><tt><b>le</b></tt>, Turbochannel Lance Ethernet, as used in
+         DECstation 5000/200 ("3max")
+   <li><tt><b>mec</b></tt>, the SGI O2's ethernet controller
+   <li><tt><b>dec21143</b></tt>, Digital's 21143 NIC (known as <tt>dc</tt>
+         in OpenBSD, or <tt>tlp</tt> in NetBSD)
+ </ul>
+ <p>The emulator acts as a NAT-like gateway/firewall; 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.
-Line 87 
 activities, but not everything works yet
+Line 107 
 activities, but not everything works yet
  <p><br>
- <a name="portmips"></a>
+ <a name="devel"></a>
- <h3>Porting operating systems to MIPS using GXemul:</h3>
+ <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
+ Is this a good idea?  The answer is yes and no, depending on the level of
+ detail you need in your simulations. If you are developing an operating
+ system or operating system kernel of your own, then the emulator can be a
+ complement to testing on real hardware.
- 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.
+ <ul>
+         <li>Porting code to a specific machine mode, e.g. a Silicon Graphics
+         machine, using GXemul, will not "magically" cause the code to
+         work on a real machine. Sometimes code works in GXemul which doesn't
+         work on real hardware, sometimes it's the other way around.
+         <p>
+         <li>GXemul contains bugs, and many things are not yet implemented.
+         <p>
+         <li><b>Very important!</b> I have only implemented devices in GXemul
+         to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much.
+         <p>
+         If you are developing a driver for a device which is emulated by
+         GXemul, and your driver does not seem to be working, then the
+         probability of a bug in GXemul's implementation of the device is
+         very much higher than that of a bug in your driver.
+         <p>
+         The device implementations in GXemul are based on the assumption
+         that the emulated OS is already developed and bug-free. They are
+         not primarily intended to be used for development of new device
+         driver code in operating systems, so if you do that, then be
+         prepared for bugs and inconsitencies.
+         <p>
+         <li>CPU details in GXemul are usually wrong. If your code depends
+         on, say, R10000 or MIPS64 specifics, chances are that GXemul will
+         not be sufficient. One example is different revisions of ISAs;
+-bit MIPS instructions which should trigger an exception on a
+         real 32-bit MIPS processor usually execute anyway in GXemul. Another
+         example is if userland code tries to access kernel memory; in some
+         cases there is protection against this, but not in all cases (to get
+         higher performance).
+         <p>
+         <li>Caches. There is no cache emulation in GXemul right now. Caches
+         for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc
+         in the DECstation emulation mode, but other than that, cache
+         operations are treated as nops.
+ </ul>
+ <p>The bottom line is that GXemul can be useful as yet another way to test
+ your code during development, but it should not be fully relied on.
-Line 120 
 to use GXemul when porting your code to
+Line 169 
 to use GXemul when porting your code to
  <h3>Using GXemul in compiler contruction courses:</h3>
  If you are learning how to write a compiler, and wish to target a
- realistic target platform, then MIPS (as emulated by GXemul)
+ realistic target platform, then MIPS or ARM (as emulated by GXemul)
- might be a suitable choice.
+ might be suitable choices.
  <ul>
    <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
-Line 155 
 to get a list of possible options.
+Line 204 
 to get a list of possible options.
  Here are some examples. If you want to run a NetBSD/pmax kernel on an
  emulated DECstation machine, you would use a command line such as this:
  <pre>
-         $ <b>gxemul -E dec -e 3max -b -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
+         $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
  </pre>
- <p>
- 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
- <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
- bootable!
+ image is bootable!
- <p>
- 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
  image is added; the first will be SCSI target 0, the second will be target 1, and so on,
  unless you specify explicitly which ID number the devices should have.
  <pre>
-         $ <b>gxemul -E dec -e 3max -b -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>
  </pre>
  Note: In the example above, disk2.raw will get scsi id 5.
- <p>
- 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
  a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk).
  For example, the following command would start the emulator with two
  CDROM images, and one harddisk image:
  <pre>
-         $ <b>gxemul -E dec -e 3max -b -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>
  </pre>
  Usually, the device with the lowest id becomes the boot device. To override
  this, add a 'b' prefix to one of the devices:
  <pre>
-         $ <b>gxemul -E dec -e 3max -b -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>
  </pre>
  If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can
  use it as a CD-ROM directly accessible from within the emulator:
  <pre>
-         $ <b>gxemul -E dec -e 3max -b -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>
  </pre>
  It is probably possible to use harddisks as well this way, but I would not
  recommend it.
-Line 241 
 you can "switch tapes" without quiting a
+Line 290 
 you can "switch tapes" without quiting a
+ <p><br>
+ <a name="filexfer"></a>
+ <h3>Transfering files to/from the guest OS:</h3>
+ If the emulated machine supports networking (see
+ <a href="#networking">above</a>), then transfering files via FTP is
+ probably easiest.
+ <p>There is another way of transfering files which works for any kind of
+ emulated machine which supports disks (either SCSI or IDE). Any file can
+ be supplied as a disk image. For example, consider the following:<pre>
+         $ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b>
+ </pre>
+ This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on
+ controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller
+(wd1). From inside NetBSD, it is now possible to extract the files using
+ the following command:<pre>
+         (inside emulated NetBSD/cats)
+         # <b>tar zxvf /dev/wd1c</b>
+ </pre>
+ Don't worry if NetBSD complains about lack of disklabel; it doesn't
+ matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of
+ <tt>wd1c</tt> for the entire disk.
+ There is also a minor problem: reading the end of the disk image. If you
+ experience problems untaring archives like this, then pad out the archive
+ first with some zeroes.
+ <p>Transfering files <i>out</i> from the emulated operating system to the
+ host can be done the same way. First, prepare an empty archive file:<pre>
+         $ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b>
+ </pre>This example created a 10 MB empty file. Then, start the emulator
+ like this:<pre>
+         $ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b>
+ </pre>
+ and transfer files by creating an archive directly onto the disk image:<pre>
+         (inside emulated NetBSD/cats)
+         # <b>tar cvf /dev/wd1c filenames</b>
+ </pre>
+ where filenames are the files or directories to transfer.
  <p><br>
  <a name="largeimages"></a>
  <h3>How to extract large gzipped disk images:</h3>
-Line 285 
 count.)
+Line 381 
 count.)
  <a name="userland"></a>
  <h3>Running userland binaries:</h3>
- You can run (some) userland programs as well. This will not emulate any
+ <font color="#ff0000">Note: This does not really work yet.</font>
- particular machine, but instead try to translate syscalls from for example
- NetBSD/pmax into the host's OS' syscalls. Right now, this is just a
+ <p>There is some skeleton code for running userland programs as well. This
- proof-of-concept, to show that it would work; there's lots of work left to
+ will not emulate any particular machine, but instead try to translate
- do to make it actually run useful programs (for example dynamically linked
+ syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now,
- programs).
+ this is just a proof-of-concept, to show that it could work; there's lots
+ of work left to do to make it actually run useful programs.
  <p>
-Line 321 
 programs).
+Line 418 
 programs).
          tab.csbnet.se
  </pre>
+ <!--
    <p>
    <li><b>NetBSD/powerpc:</b>
          <br>
-Line 344 
 programs).
+Line 442 
 programs).
          Hello, world!
  </pre>
+ -->
  </ul>
-Line 411 
 and store in a file. Let's call this fil
+Line 510 
 and store in a file. Let's call this fil
  </pre>
  This binary image can now be used in the emulator:
  <pre>
-         $ <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>
          KN02-BA V5.7e
          ?TFL:  3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
-Line 452 
 This binary image can now be used in the
+Line 551 
 This binary image can now be used in the
           osconsole=3
          >>
  </pre>
- <i>(Note: at the moment, this doesn't work. I must have broken something when
- 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.
- <p>
+ I must have broken something when fixing something else, but this
- During bootup, the PROM complains <i>a lot</i> about hardware failures.
+ is what it looked like at the time.)</font>
+ <p>During bootup, the PROM complains <i>a lot</i> about hardware failures.
  That's because the emulator doesn't emulate the hardware well enough yet.
- <p>
- 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
- "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
- call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly
+ call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly
  emulate memory detection well enough for the PROM to accept, so it will
- 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.
- 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
  binary file which should be loaded at a specific virtual address.
-Line 471 
 binary file which should be loaded at a
+Line 572 
 binary file which should be loaded at a
  <h4>Dumping the PROM on a SGI O2:</h4>
  The general ideas in this section applies to using ROM images from other
- 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
- ("O2").
+ to the DECstation.
- <p>
- 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
  <pre>
          &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
  </pre>
  Make sure you capture all the output (via serial console) into a file,
- 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.)
+ <p>
+ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+ <a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a>
+ &nbsp;&nbsp;&nbsp;
+ <a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a>
+ &nbsp;&nbsp;&nbsp;
+ <a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a>
+ <p>The photo on the left is from the real machine. The other two are
+ screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt>
+ framebuffer scaledown.
+ <p>Normally during bootup, the IP32 PROM does a Power-On test which makes
+ sure that the caches and other things are working properly. GXemul doesn't
+ emulate all those things well enough for the tests to pass. The
+ experimental screenshots above were taken with cache detection skipped
+ manually.
+ <p><font color="#ff0000">
+ In other words: don't expect this to work out-of-the-box with GXemul right
+ now. It might work once I've added correct cache emulation.</font>
+ <p>The command line used to start the emulator, once correct cache
+ emulation has been implemented, would be something like <tt>gxemul -XQeo2
+xbfc00000:prom.bin</tt>.
+ <p>The same caution applies when dealing with SGI PROMs as with
+ DECstation PROMs: GXemul doesn't really emulate the hardware, it only
+ "fakes" devices well enough to fool some things, primarily NetBSD, that
+ it is emulating a real machine. ROM code is usually a <i>lot</i> more
+ picky about the details.
+ <p>The graphics used in the O2 is (as far as I know) undocumented. Combining
+ some traces of info from how Linux/O2 draws to the screen with some
+ reverse-engineering of my own, I've implemented enough of the controller to
+ let the PROM draw rectangles and bitmaps, but not much more. The SCSI
+ controller is not implemented yet either.

 Legend:



Removed from v.8
 


changed lines


 
Added in v.20
 Legend:



Removed from v.8
 


changed lines


 
Added in v.20
-Removed from v.8
+Added in v.20

	ViewVC Help
Powered by ViewVC 1.1.26