/[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!
ViewVC logotype

Contents of /trunk/doc/misc.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 24 - (show annotations)
Mon Oct 8 16:19:56 2007 UTC (13 years, 1 month ago) by dpavlin
File MIME type: text/html
File size: 22582 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.1256 2006/06/23 20:43:44 debug Exp $
20060219	Various minor updates. Removing the old MIPS16 skeleton code,
		because it will need to be rewritten for dyntrans anyway.
20060220-22	Removing the non-working dyntrans backend support.
		Continuing on the 64-bit dyntrans virtual memory generalization.
20060223	More work on the 64-bit vm generalization.
20060225	Beginning on MIPS dyntrans load/store instructions.
		Minor PPC updates (64-bit load/store, etc).
		Fixes for the variable-instruction-length framework, some
		minor AVR updates (a simple Hello World program works!).
		Beginning on a skeleton for automatically generating documen-
		tation (for devices etc.).
20060226	PPC updates (adding some more 64-bit instructions, etc).
		AVR updates (more instructions).
		FINALLY found and fixed the zs bug, making NetBSD/macppc
		accept the serial console.
20060301	Adding more AVR instructions.
20060304	Continuing on AVR-related stuff. Beginning on a framework for
		cycle-accurate device emulation. Adding an experimental "PAL
		TV" device (just a dummy so far).
20060305	Adding more AVR instructions.
		Adding a dummy epcom serial controller (for TS7200 emulation).
20060310	Removing the emul() command from configuration files, so only
		net() and machine() are supported.
		Minor progress on the MIPS dyntrans rewrite.
20060311	Continuing on the MIPS dyntrans rewrite (adding more
		instructions, etc).
20060315	Adding more instructions (sllv, srav, srlv, bgtz[l], blez[l],
		beql, bnel, slti[u], various loads and stores).
20060316	Removing the ALWAYS_SIGNEXTEND_32 option, since it was rarely
		used.
		Adding more MIPS dyntrans instructions, and fixing bugs.
20060318	Implementing fast loads/stores for MIPS dyntrans (big/little
		endian, 32-bit and 64-bit modes).
20060320	Making MIPS dyntrans the default configure option; use
		"--enable-oldmips" to use the old bintrans system.
		Adding MIPS dyntrans dmult[u]; minor updates.
20060322	Continuing... adding some more instructions.
		Adding a simple skeleton for demangling C++ "_ZN" symbols.
20060323	Moving src/debugger.c into a new directory (src/debugger/).
20060324	Fixing the hack used to load PPC ELFs (useful for relocated
		Linux/ppc kernels), and adding a dummy G3 machine mode.
20060325-26	Beginning to experiment with GDB remote serial protocol
		connections; adding a -G command line option for selecting
		which TCP port to listen to.
20060330	Beginning a major cleanup to replace things like "0x%016llx"
		with more correct "0x%016"PRIx64, etc.
		Continuing on the GDB remote serial protocol support.
20060331	More cleanup, and some minor GDB remote progress.
20060402	Adding a hack to the configure script, to allow compilation
		on systems that lack PRIx64 etc.
20060406	Removing the temporary FreeBSD/arm hack in dev_ns16550.c and
		replacing it with a better fix from Olivier Houchard.
20060407	A remote debugger (gdb or ddd) can now start and stop the
		emulator using the GDB remote serial protocol, and registers
		and memory can be read. MIPS only for now.
20060408	More GDB progress: single-stepping also works, and also adding
		support for ARM, PowerPC, and Alpha targets.
		Continuing on the delay-slot-across-page-boundary issue.
20060412	Minor update: beginning to add support for the SPARC target
		to the remote GDB functionality.
20060414	Various MIPS updates: adding more instructions for dyntrans
		(eret, add), and making some exceptions work. Fixing a bug
		in dmult[u].
		Implementing the first SPARC instructions (sethi, or).
20060415	Adding "magic trap" instructions so that PROM calls can be
		software emulated in MIPS dyntrans.
		Adding more MIPS dyntrans instructions (ddiv, dadd) and
		fixing another bug in dmult.
20060416	More MIPS dyntrans progress: adding [d]addi, movn, movz, dsllv,
		rfi, an ugly hack for supporting R2000/R3000 style faked caches,
		preliminary interrupt support, and various other updates and
		bugfixes.
20060417	Adding more SPARC instructions (add, sub, sll[x], sra[x],
		srl[x]), and useful SPARC header definitions.
		Adding the first (trivial) x86/AMD64 dyntrans instructions (nop,
		cli/sti, stc/clc, std/cld, simple mov, inc ax). Various other
		x86 updates related to variable instruction length stuff.
		Adding unaligned loads/stores to the MIPS dyntrans mode (but
		still using the pre-dyntrans (slow) imlementation).
20060419	Fixing a MIPS dyntrans exception-in-delay-slot bug.
		Removing the old "show opcode statistics" functionality, since
		it wasn't really useful and isn't implemented for dyntrans.
		Single-stepping (or running with instruction trace) now looks
		ok with dyntrans with delay-slot architectures.
20060420	Minor hacks (removing the -B command line option when compiled
		for non-bintrans, and some other very minor updates).
		Adding (slow) MIPS dyntrans load-linked/store-conditional.
20060422	Applying fixes for bugs discovered by Nils Weller's nwcc
		(static DEC memmap => now per machine, and adding an extern
		keyword in cpu_arm_instr.c).
		Finally found one of the MIPS dyntrans bugs that I've been
		looking for (copy/paste spelling error BIG vs LITTLE endian in
		cpu_mips_instr_loadstore.c for 16-bit fast stores).
		FINALLY found the major MIPS dyntrans bug: slti vs sltiu
		signed/unsigned code in cpu_mips_instr.c. :-)
		Adding more MIPS dyntrans instructions (lwc1, swc1, bgezal[l],
		ctc1, tlt[u], tge[u], tne, beginning on rdhwr).
		NetBSD/hpcmips can now reach userland when using dyntrans :-)
		Adding some more x86 dyntrans instructions.
		Finally removed the old Alpha-specific virtual memory code,
		and replaced it with the generic 64-bit version.
		Beginning to add disassembly support for SPECIAL3 MIPS opcodes.
20060423	Continuing on the delay-slot-across-page-boundary issue;
		adding an end_of_page2 ic slot (like I had planned before, but
		had removed for some reason).
		Adding a quick-and-dirty fallback to legacy coprocessor 1
		code (i.e. skipping dyntrans implementation for now).
		NetBSD/hpcmips and NetBSD/pmax (when running on an emulated
		R4400) can now be installed and run. :-)  (Many bugs left
		to fix, though.)
		Adding more MIPS dyntrans instructions: madd[u], msub[u].
		Cleaning up the SPECIAL2 vs R5900/TX79/C790 "MMI" opcode
		maps somewhat (disassembly and dyntrans instruction decoding).
20060424	Adding an isa_revision field to mips_cpu_types.h, and making
		sure that SPECIAL3 opcodes cause Reserved Instruction
		exceptions on MIPS32/64 revisions lower than 2.
		Adding the SPARC 'ba', 'call', 'jmpl/retl', 'and', and 'xor'
		instructions.
20060425	Removing the -m command line option ("run at most x 
		instructions") and -T ("single_step_on_bad_addr"), because
		they never worked correctly with dyntrans anyway.
		Freshening up the man page.
20060428	Adding more MIPS dyntrans instructions: bltzal[l], idle.
		Enabling MIPS dyntrans compare interrupts.
20060429	FINALLY found the weird dyntrans bug, causing NetBSD etc. to
		behave strangely: some floating point code (conditional
		coprocessor branches) could not be reused from the old
		non-dyntrans code. The "quick-and-dirty fallback" only appeared
		to work. Fixing by implementing bc1* for MIPS dyntrans.
		More MIPS instructions: [d]sub, sdc1, ldc1, dmtc1, dmfc1, cfc0.
		Freshening up MIPS floating point disassembly appearance.
20060430	Continuing on C790/R5900/TX79 disassembly; implementing 128-bit
		"por" and "pextlw".
20060504	Disabling -u (userland emulation) unless compiled as unstable
		development version.
		Beginning on freshening up the testmachine include files,
		to make it easier to reuse those files (placing them in
		src/include/testmachine/), and beginning on a set of "demos"
		or "tutorials" for the testmachine functionality.
		Minor updates to the MIPS GDB remote protocol stub.
		Refreshing doc/experiments.html and gdb_remote.html.
		Enabling Alpha emulation in the stable release configuration,
		even though no guest OSes for Alpha can run yet.
20060505	Adding a generic 'settings' object, which will contain
		references to settable variables (which will later be possible
		to access using the debugger).
20060506	Updating dev_disk and corresponding demo/documentation (and
		switching from SCSI to IDE disk types, so it actually works
		with current test machines :-).
20060510	Adding a -D_LARGEFILE_SOURCE hack for 64-bit Linux hosts,
		so that fseeko() doesn't give a warning.
		Updating the section about how dyntrans works (the "runnable
		IR") in doc/intro.html.
		Instruction updates (some x64=1 checks, some more R5900
		dyntrans stuff: better mul/mult separation from MIPS32/64,
		adding ei and di).
		Updating MIPS cpuregs.h to a newer one (from NetBSD).
		Adding more MIPS dyntrans instructions: deret, ehb.
20060514	Adding disassembly and beginning implementation of SPARC wr
		and wrpr instructions.
20060515	Adding a SUN SPARC machine mode, with dummy SS20 and Ultra1
		machines. Adding the 32-bit "rd psr" instruction.
20060517	Disassembly support for the general SPARC rd instruction.
		Partial implementation of the cmp (subcc) instruction.
		Some other minor updates (making sure that R5900 processors
		start up with the EIE bit enabled, otherwise Linux/playstation2
		receives no interrupts).
20060519	Minor MIPS updates/cleanups.
20060521	Moving the MeshCube machine into evbmips; this seems to work
		reasonably well with a snapshot of a NetBSD MeshCube kernel.
		Cleanup/fix of MIPS config0 register initialization.
20060529	Minor MIPS fixes, including a sign-extension fix to the
		unaligned load/store code, which makes NetBSD/pmax on R3000
		work better with dyntrans. (Ultrix and Linux/DECstation still
		don't work, though.)
20060530	Minor updates to the Alpha machine mode: adding an AlphaBook
		mode, an LCA bus (forwarding accesses to an ISA bus), etc.
20060531	Applying a bugfix for the MIPS dyntrans sc[d] instruction from
		Ondrej Palkovsky. (Many thanks.)
20060601	Minifix to allow ARM immediate msr instruction to not give
		an error for some valid values.
		More Alpha updates.
20060602	Some minor Alpha updates.
20060603	Adding the Alpha cmpbge instruction. NetBSD/alpha prints its
		first boot messages :-) on an emulated Alphabook 1.
20060612	Minor updates; adding a dev_ether.h include file for the
		testmachine ether device. Continuing the hunt for the dyntrans
		bug which makes Linux and Ultrix on DECstation behave
		strangely... FINALLY found it! It seems to be related to
		invalidation of the translation cache, on tlbw{r,i}. There
		also seems to be some remaining interrupt-related problems.
20060614	Correcting the implementation of ldc1/sdc1 for MIPS dyntrans
		(so that it uses 16 32-bit registers if the FR bit in the
		status register is not set).
20060616	REMOVING BINTRANS COMPLETELY!
		Removing the old MIPS interpretation mode.
		Removing the MFHILO_DELAY and instruction delay stuff, because
		they wouldn't work with dyntrans anyway.
20060617	Some documentation updates (adding "NetBSD-archive" to some
		URLs, and new Debian/DECstation installation screenshots).
		Removing the "tracenull" and "enable-caches" configure options.
		Improving MIPS dyntrans performance somewhat (only invalidate
		translations if necessary, on writes to the entryhi register,
		instead of doing it for all cop0 writes).
20060618	More cleanup after the removal of the old MIPS emulation.
		Trying to fix the MIPS dyntrans performance bugs/bottlenecks;
		only semi-successful so far (for R3000).
20060620	Minor update to allow clean compilation again on Tru64/Alpha.
20060622	MIPS cleanup and fixes (removing the pc_last stuff, which
		doesn't make sense with dyntrans anyway, and fixing a cross-
		page-delay-slot-with-exception case in end_of_page).
		Removing the old max_random_cycles_per_chunk stuff, and the
		concept of cycles vs instructions for MIPS emulation.
		FINALLY found and fixed the bug which caused NetBSD/pmax
		clocks to behave strangely (it was a load to the zero register,
		which was treated as a NOP; now it is treated as a load to a
		dummy scratch register).
20060623	Increasing the dyntrans chunk size back to
		N_SAFE_DYNTRANS_LIMIT, instead of N_SAFE_DYNTRANS_LIMIT/2.
		Preparing for a quick release, even though there are known
		bugs, and performance for non-R3000 MIPS emulation is very
		poor. :-/
		Reverting to half the dyntrans chunk size again, because
		NetBSD/cats seemed less stable with full size chunks. :(
		NetBSD/sgimips 3.0 can now run :-)  (With release 0.3.8, only
		NetBSD/sgimips 2.1 worked, not 3.0.)

==============  RELEASE 0.4.0  ==============


1 <html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;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.63 2006/05/22 04:53:52 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>&nbsp;&nbsp;Your compiler needs to output real assembly
178 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
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 (e.g. SPIM).
183 <p>
184 <li><b>(-)</b>&nbsp;&nbsp;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 feature does not really work yet.
386 It is currently disabled in stable release builds of the emulator.</font>
387
388 <p>There is some skeleton code for running userland programs as well. This
389 will not emulate any particular machine, but instead try to translate
390 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>
395
396 <ul>
397 <li><b>NetBSD/pmax:</b>
398 <br>
399 Running /bin/hostname or /bin/date and similarly trivial
400 programs from the NetBSD/pmax distribution works:<pre>
401 $ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b>
402 tab.csbnet.se
403 $ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b>
404 Sun Jan 25 02:26:14 GMT 2004
405 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b>
406 usage: pmax_bin_sleep seconds
407 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b>
408 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b>
409 </pre>
410
411 <p>
412 <li><b>Ultrix:</b>
413 <br>
414 At least /bin/date and /bin/hostname work:<pre>
415 $ <b>gxemul -q -u ultrix ultrix4_bin_date</b>
416 UNIMPLEMENTED ultrix syscall 54
417 UNIMPLEMENTED ultrix syscall 62
418 Mon Feb 9 12:50:59 WET 2004
419 $ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b>
420 tab.csbnet.se
421 </pre>
422
423 <!--
424 <p>
425 <li><b>NetBSD/powerpc:</b>
426 <br>
427 /bin/sync from NetBSD/macppc works, but probably not much else.<pre>
428 $ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b>
429 ...
430 [ sync() ]
431 [ exit(0) ]
432 cpu_run_deinit(): All CPUs halted.
433
434 </pre>
435
436 <p>
437 <li><b>Linux/PPC64:</b>
438 <br>
439 The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a>
440 on IBM's developerWorks pages runs:<pre>
441 $ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b>
442 $ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b>
443 $ <b>gxemul -q -u linux/ppc64 hello-ppc64</b>
444 Hello, world!
445
446 </pre>
447 -->
448
449 </ul>
450
451
452
453
454
455 <p><br>
456 <a name="promdump"></a>
457 <h3>Using a PROM dump from a real machine:</h3>
458
459 Raw PROM images from real machines can, in a few cases, be used in
460 the emulator. ROM code is usually much more sensitive to correctness
461 of the emulator than operating system kernels or userland programs
462 are, so don't expect any PROM image to just magically work.
463
464
465 <p>
466 <h4>Dumping the PROM on a DECstation 5000/125:</h4>
467 The image first needs to be extracted from the machine. There are
468 several ways to do this.
469 <ul>
470 <li>Use hardware to read the PROM chip(s) directly. Not easy if you
471 don't have such a hardware reader.
472 <li>Copy the PROM memory range into a file, from a running
473 operating system. You need a running OS, and it must
474 have access to the PROM memory range. NetBSD, for example,
475 doesn't allow that from userland.
476 <li>Hook up a serial console and dump using the PROM's own dump
477 command.
478 </ul>
479 <p>
480 The easiest way is to hook up a serial console. The terminal must be
481 able to capture output to a file.
482 <p>
483 These are approximately the commands that I used:
484 <pre>
485 >><b>cnfg</b> <i>Show machine configuration</i>
486
487 >><b>printenv</b> <i>Show environment variables</i>
488
489 >><b>setenv more 0</b> <i>This turns off the More messages</i>
490
491 >><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i>
492 </pre>
493 <p>
494 Remember that DECstations are little endian, so if the dump data
495 looks like this:
496 <pre>
497 bfc00000: 0x0bf0007e
498 </pre>
499 then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b.
500 <p>
501 At 9600 bps, about 10KB can be dumped per minute, so it takes a while.
502 Once enough of the PROM has been dumped, you can press CTRL-C to break out.
503 Then, restore the more environment variable:
504 <pre>
505 >><b>setenv more 24</b>
506 </pre>
507 <p>
508 Now, convert the data you just saved (little-endian words -> bytes),
509 and store in a file. Let's call this file DECstation5000_125_promdump.bin.
510 <pre>
511 $ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b>
512 </pre>
513 This binary image can now be used in the emulator:
514 <pre>
515 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
516
517 KN02-BA V5.7e
518 ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
519 ?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA]
520 ...
521 --More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C)
522 >><b>?</b>
523 ? [cmd]
524 boot [[-z #] [-n] #/path [ARG...]]
525 cat SCRPT
526 cnfg [#]
527 d [-bhw] [-S #] RNG VAL
528 e [-bhwcdoux] [-S #] RNG
529 erl [-c]
530 go [ADR]
531 init [#] [-m] [ARG...]
532 ls [#]
533 passwd [-c] [-s]
534 printenv [EVN]
535 restart
536 script SCRPT
537 setenv EVN STR
538 sh [-belvS] [SCRPT] [ARG..]
539 t [-l] #/STR [ARG..]
540 unsetenv EVN
541 >><b>cnfg</b>
542 3: KN02-BA DEC V5.7e TCF0 (128 MB)
543 (enet: 00-00-00-00-00-00)
544 (SCSI = 7)
545 0: PMAG-BA DEC V5.3a TCF0
546 >><b>printenv</b>
547 boot=
548 testaction=q
549 haltaction=h
550 more=24
551 #=3
552 console=*
553 osconsole=3
554 >>
555 </pre>
556
557 <p><font color="#ff0000">(Note: at the moment, this doesn't work.
558 I must have broken something when fixing something else, but this
559 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.
563
564 <p>The command line options used are: <tt>-e 3min</tt> for
565 "DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM
566 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
568 always believe there is 128MB ram anyway), and <tt>-q</tt> to supress debug messages.
569 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.
571
572
573 <p><br>
574 <h4>Dumping the PROM on a SGI O2:</h4>
575
576 The general ideas in this section applies to using ROM images from other
577 machines as well. I have also tried this on an SGI IP32 ("O2"), in addition
578 to the DECstation.
579
580 <p>For the O2, a suitable command to dump the prom memory range is
581 <pre>
582 &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
583 </pre>
584 Make sure you capture all the output (via serial console) into a file,
585 and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file.
586
587 <p>
588 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
589 <a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a>
590 &nbsp;&nbsp;&nbsp;
591 <a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a>
592 &nbsp;&nbsp;&nbsp;
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
627
628 </p>
629
630 </body>
631 </html>

  ViewVC Help
Powered by ViewVC 1.1.26