/[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 4 - (show annotations)
Mon Oct 8 16:18:00 2007 UTC (16 years, 5 months ago) by dpavlin
File MIME type: text/html
File size: 17138 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.707 2005/04/27 16:37:33 debug Exp $
20050408	Some minor updates to the wdc. Linux now doesn't complain
		anymore if a disk is non-present.
20050409	Various minor fixes (a bintrans bug, and some other things).
		The wdc seems to work with Playstation2 emulation, but there
		is a _long_ annoying delay when disks are detected.
		Fixing a really important bintrans bug (when devices and RAM
		are mixed within 4KB pages), which was triggered with
		NetBSD/playstation2 kernels.
20050410	Adding a dummy dev_ps2_ether (just so that NetBSD doesn't
		complain as much during bootup).
		Symbols starting with '$' are now ignored.
		Renaming dev_ps2_ohci.c to dev_ohci.c, etc.
20050411	Moving the bintrans-cache-isolation check from cpu_mips.c to
		cpu_mips_coproc.c. (I thought this would give a speedup, but
		it's not noticable.)
		Better playstation2 sbus interrupt code.
		Skip ahead many ticks if the count register is read manually.
		(This increases the speed of delay-loops that simply read
		the count register.)
20050412	Updates to the playstation2 timer/interrupt code.
		Some other minor updates.
20050413	NetBSD/cobalt runs from a disk image :-) including userland;
		updating the documentation on how to install NetBSD/cobalt
		using NetBSD/pmax (!).
		Some minor bintrans updates (no real speed improvement) and
		other minor updates (playstation2 now uses the -o options).
20050414	Adding a dummy x86 (and AMD64) mode.
20050415	Adding some (32-bit and 16-bit) x86 instructions.
		Adding some initial support for non-SCSI, non-IDE floppy
		images. (The x86 mode can boot from these, more or less.)
		Moving the devices/ and include/ directories to src/devices/
		and src/include/, respectively.
20050416	Continuing on the x86 stuff. (Adding pc_bios.c and some simple
		support for software interrupts in 16-bit mode.)
20050417	Ripping out most of the x86 instruction decoding stuff, trying
		to rewrite it in a cleaner way.
		Disabling some of the least working CPU families in the
		configure script (sparc, x86, alpha, hppa), so that they are
		not enabled by default.
20050418	Trying to fix the bug which caused problems when turning on
		and off bintrans interactively, by flushing the bintrans cache
		whenever bintrans is manually (re)enabled.
20050419	Adding the 'lswi' ppc instruction.
		Minor updates to the x86 instruction decoding.
20050420	Renaming x86 register name indices from R_xx to X86_R_xx (this
		makes building on Tru64 nicer).
20050422	Adding a check for duplicate MIPS TLB entries on tlbwr/tlbwi.
20050427	Adding screenshots to guestoses.html.
		Some minor fixes and testing for the next release.

==============  RELEASE 0.3.2  ==============


1 <html>
2 <head><title>GXemul documentation: Misc.</title>
3 </head>
4 <body bgcolor="#f8f8f8" text="#000000" link="#4040f0" vlink="#404040" alink="#ff0000">
5 <table border=0 width=100% bgcolor="#d0d0d0"><tr>
6 <td width=100% align=center valign=center><table border=0 width=100%><tr>
7 <td align="left" valign=center bgcolor="#d0efff"><font color="#6060e0" size="6">
8 <b>GXemul documentation:</b></font>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
9 <font color="#000000" size="6"><b>Misc.</b>
10 </font></td></tr></table></td></tr></table><p>
11 <!-- The first 10 lines are cut away by the homepage updating script. -->
12
13
14 <!--
15
16 $Id: misc.html,v 1.40 2005/04/16 00:29:45 debug Exp $
17
18 Copyright (C) 2003-2005 Anders Gavare. All rights reserved.
19
20 Redistribution and use in source and binary forms, with or without
21 modification, are permitted provided that the following conditions are met:
22
23 1. Redistributions of source code must retain the above copyright
24 notice, this list of conditions and the following disclaimer.
25 2. Redistributions in binary form must reproduce the above copyright
26 notice, this list of conditions and the following disclaimer in the
27 documentation and/or other materials provided with the distribution.
28 3. The name of the author may not be used to endorse or promote products
29 derived from this software without specific prior written permission.
30
31 THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
32 ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
33 IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
34 ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
35 FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
36 DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
37 OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
38 HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
39 LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
40 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
41 SUCH DAMAGE.
42
43 -->
44
45 <a href="./">Back to the index</a>
46
47 <p><br>
48 <h2>Misc.</h2>
49
50 <p>
51 <ul>
52 <li><a href="#networking">Networking</a>
53 <li><a href="#portmips">Porting operating systems to MIPS using GXemul</a>
54 <li><a href="#compilercontruct">Using GXemul in compiler contruction courses</a>
55 <li><a href="#disk">How to start the emulator with a disk image</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 <p>
77 The guest OS running inside the emulator uses a private IPv4 address, such
78 as 10.0.0.1, and the emulator acts as a NAT-like gateway/firewall at IPv4
79 address 10.0.0.254. To the outside world it will seem like it is the host's
80 OS that connects to other machines on the internet, not the guest OS.
81 <p>
82 <font color="#ff0000">NOTE: This is still experimental!
83 As of 2004-07-21, ARP + ICMP + UDP + TCP are emulated well enough to let
84 NetBSD and OpenBSD install via ftp, and use the network for many normal
85 activities, but not everything works yet.</font>
86
87
88
89
90
91
92 <p><br>
93 <a name="portmips"></a>
94 <h3>Porting operating systems to MIPS using GXemul:</h3>
95
96 Is this a good idea? The answer is yes and no, depending on what you are
97 trying to port to. If you are developing an operating system or operating
98 system kernel of your own, and wish to target MIPS-like systems in general,
99 then the answer might be yes, for experimental purposes.
100
101 <p>
102 However, if you think that you can port an operating system
103 to, say, the Silicon Graphics machine mode of GXemul and hope that your
104 operating system will run on a real SGI machine, then you will most
105 likely fail. GXemul simply does not emulate things well enough for that to work.
106 Another example would be specific CPU details; if your code depends on,
107 say, R10000 specifics, chances are that GXemul will not be sufficient.
108
109 <p>
110 In many cases, hardware devices in GXemul are only implemented well
111 enough to fool eg. NetBSD that they are working correctly, while in
112 fact they don't work very much at all. Please keep this in mind, if you plan
113 to use GXemul when porting your code to MIPS.
114
115
116
117
118
119
120
121 <p><br>
122 <a name="compilercontruct"></a>
123 <h3>Using GXemul in compiler contruction courses:</h3>
124
125 If you are learning how to write a compiler, and wish to target a
126 realistic target platform, then MIPS (as emulated by GXemul)
127 might be a suitable choice.
128
129 <ul>
130 <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
131 language code, which the assembler (eg gas, the GNU assembler) can
132 then compile into object format, and then you need to link this
133 into an executable image. This is much closer to how things work
134 in real life than running assembly language listings in a simulator
135 (eg SPIM).
136 <p>
137 <li><b>(-)</b>&nbsp;&nbsp;GXemul does not simulate out-of-order
138 execution, penalties related to instruction scheduling, or
139 load-delays, so it cannot be used to create optimizing compilers
140 that take advantage of such processor features. GXemul keeps
141 track of the number of instructions executed, but that's it.
142 </ul>
143
144
145
146
147
148
149 <p><br>
150 <a name="disk"></a>
151 <h3>How to start the emulator with a disk image:</h3>
152
153 Add <i>-d [prefixes:]diskimagefilename</i> to the command line, where prefixes
154 are one or more single-character options. Run <b>gxemul -h</b>
155 to get a list of possible options.
156
157 <p>
158 Here are some examples. If you want to run a NetBSD/pmax kernel on an
159 emulated DECstation machine, you would use a command line such as this:
160 <pre>
161 $ <b>gxemul -E dec -e 3max -b -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
162 </pre>
163 <p>
164 NOTE: For some emulation modes, such as the DECstation mode, you do
165 <i>not</i> have to specify the name of the kernel, if the disk image is
166 bootable!
167 <p>
168 It is possible to have more than one disk. For each -d argument, a disk
169 image is added; the first will be SCSI target 0, the second will be target 1, and so on,
170 unless you specify explicitly which ID number the devices should have.
171 <pre>
172 $ <b>gxemul -E dec -e 3max -b -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
173 </pre>
174 Note: In the example above, disk2.raw will get scsi id 5.
175 <p>
176 If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be
177 a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk).
178 For example, the following command would start the emulator with two
179 CDROM images, and one harddisk image:
180 <pre>
181 $ <b>gxemul -E dec -e 3max -b -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
182 </pre>
183 Usually, the device with the lowest id becomes the boot device. To override
184 this, add a 'b' prefix to one of the devices:
185 <pre>
186 $ <b>gxemul -E dec -e 3max -b -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
187 </pre>
188 If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can
189 use it as a CD-ROM directly accessible from within the emulator:
190 <pre>
191 $ <b>gxemul -E dec -e 3max -b -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
192 </pre>
193 It is probably possible to use harddisks as well this way, but I would not
194 recommend it.
195 <p>
196 Using emulated tape drives is a bit more complicated than disks, because a
197 tape can be made up of several "files" with space in between. The solution
198 I have choosen is to have one file in the host's file system space for each
199 tape file. The prefix for using tapes is 't', and the filename given is
200 for the <i>first</i> file on that tape (number zero, implicitly). For
201 files following file nr 0, a dot and the filenumber is appended to the
202 filename.
203 <p>
204 As an example, starting the emulator with
205 <pre>
206 <b>-d t4:mytape.img</b>
207 </pre>
208 will cause SCSI id 4 to be a tape device, using the following file number
209 to name translation scheme:
210 <p>
211 <center>
212 <table border="0">
213 <tr>
214 <td><b>File number:</b></td>
215 <td><b>File name in the host's filesystem:</b></td>
216 </tr>
217 <tr>
218 <td align="center">0</td>
219 <td align="left">mytape.img</td>
220 </tr>
221 <tr>
222 <td align="center">1</td>
223 <td align="left">mytape.img.1</td>
224 </tr>
225 <tr>
226 <td align="center">2</td>
227 <td align="left">mytape.img.2</td>
228 </tr>
229 <tr>
230 <td align="center">..</td>
231 <td align="left">..</td>
232 </tr>
233 </table>
234 </center>
235 <p>
236 If you already have a number of tape files, which should be placed on the
237 same emulated tape, then you might not want to rename all those files.
238 Use symbolic links instead (ln -s).
239 <p>
240 There is another advantage to using symbolic links for tape filenames:
241 every time a tape is rewound, it is reopened using the filename given
242 on the command line. By changing what the symbolic name points to,
243 you can "switch tapes" without quiting and restarting the emulator.
244
245
246
247 <p><br>
248 <a name="largeimages"></a>
249 <h3>How to extract large gzipped disk images:</h3>
250
251 Unix filesystems usually support large files with "holes". Holes are
252 zero-filled blocks that don't actually exist on disk. This is very
253 practical for emulated disk images, as it is possible to create a very
254 large disk image without using up much space at all.
255
256 <p>
257 Using gzip and gunzip on disk images can be <i>very</i> slow, as these
258 files can be multiple gigabytes large, but this is usually necessary for
259 transfering disk images over the internet. If you receive a gzipped disk
260 image, say disk.img.gz, and run a naive
261 <p>
262 <pre>
263 $ <b>gunzip disk.img.gz</b>
264 </pre>
265 <p>
266 on it, you will not end up with an optimized file unless
267 gunzip supports that. (In my experiments, it doesn't.) In plain English,
268 if you type <b>ls -l</b> and the filesize is 9 GB, it will actually occupy
269 9 GB of disk space! This is often unacceptable.
270 <p>
271 Using a simple tool which only writes blocks that are non-zero, a lot of
272 space can be saved. Compile the program cp_removeblocks in the
273 experiments/ directory, and type:
274 <p>
275 <pre>
276 $ <b>gunzip -c disk.img.gz | cp_removeblocks /dev/stdin disk.img</b>
277 </pre>
278
279 <p>
280 This will give you a disk.img which looks like it is 9 GB, and works like
281 the real file, but the holes are not written out to the disk. (You can see
282 this by running for example <b>du disk.img</b> to see the physical block
283 count.)
284
285
286
287 <p><br>
288 <a name="userland"></a>
289 <h3>Running userland binaries:</h3>
290
291 You can run (some) userland programs as well. This will not emulate any
292 particular machine, but instead try to translate syscalls from for example
293 NetBSD/pmax into the host's OS' syscalls. Right now, this is just a
294 proof-of-concept, to show that it would work; there's lots of work left to
295 do to make it actually run useful programs (for example dynamically linked
296 programs).
297
298 <p>
299
300 <ul>
301 <li><b>NetBSD/pmax:</b>
302 <br>
303 Running /bin/hostname or /bin/date and similarly trivial
304 programs from the NetBSD/pmax distribution works:<pre>
305 $ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b>
306 tab.csbnet.se
307 $ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b>
308 Sun Jan 25 02:26:14 GMT 2004
309 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b>
310 usage: pmax_bin_sleep seconds
311 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b>
312 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b>
313 </pre>
314
315 <p>
316 <li><b>Ultrix:</b>
317 <br>
318 At least /bin/date and /bin/hostname work:<pre>
319 $ <b>gxemul -q -u ultrix ultrix4_bin_date</b>
320 UNIMPLEMENTED ultrix syscall 54
321 UNIMPLEMENTED ultrix syscall 62
322 Mon Feb 9 12:50:59 WET 2004
323 $ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b>
324 tab.csbnet.se
325 </pre>
326
327 <p>
328 <li><b>NetBSD/powerpc:</b>
329 <br>
330 /bin/sync from NetBSD/macppc works, but probably not much else.<pre>
331 $ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b>
332 ...
333 [ sync() ]
334 [ exit(0) ]
335 cpu_run_deinit(): All CPUs halted.
336
337 </pre>
338
339 <p>
340 <li><b>Linux/PPC64:</b>
341 <br>
342 The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a>
343 on IBM's developerWorks pages runs:<pre>
344 $ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b>
345 $ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b>
346 $ <b>gxemul -q -u linux/ppc64 hello-ppc64</b>
347 Hello, world!
348
349 </pre>
350
351 </ul>
352
353
354
355
356
357 <p><br>
358 <a name="promdump"></a>
359 <h3>Using a PROM dump from a real machine:</h3>
360
361 Raw PROM images from real machines can, in a few cases, be used in
362 the emulator. ROM code is usually much more sensitive to correctness
363 of the emulator than operating system kernels or userland programs
364 are, so don't expect any PROM image to just magically work.
365
366
367 <p>
368 <h4>Dumping the PROM on a DECstation 5000/125:</h4>
369 The image first needs to be extracted from the machine. There are
370 several ways to do this.
371 <ul>
372 <li>Use hardware to read the PROM chip(s) directly. Not easy if you
373 don't have such a hardware reader.
374 <li>Copy the PROM memory range into a file, from a running
375 operating system. You need a running OS, and it must
376 have access to the PROM memory range. NetBSD, for example,
377 doesn't allow that from userland.
378 <li>Hook up a serial console and dump using the PROM's own dump
379 command.
380 </ul>
381 <p>
382 The easiest way is to hook up a serial console. The terminal must be
383 able to capture output to a file.
384 <p>
385 These are approximately the commands that I used:
386 <pre>
387 >><b>cnfg</b> <i>Show machine configuration</i>
388
389 >><b>printenv</b> <i>Show environment variables</i>
390
391 >><b>setenv more 0</b> <i>This turns off the More messages</i>
392
393 >><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i>
394 </pre>
395 <p>
396 Remember that DECstations are little endian, so if the dump data
397 looks like this:
398 <pre>
399 bfc00000: 0x0bf0007e
400 </pre>
401 then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b.
402 <p>
403 At 9600 bps, about 10KB can be dumped per minute, so it takes a while.
404 Once enough of the PROM has been dumped, you can press CTRL-C to break out.
405 Then, restore the more environment variable:
406 <pre>
407 >><b>setenv more 24</b>
408 </pre>
409 <p>
410 Now, convert the data you just saved (little-endian words -> bytes),
411 and store in a file. Let's call this file DECstation5000_125_promdump.bin.
412 <pre>
413 $ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b>
414 </pre>
415 This binary image can now be used in the emulator:
416 <pre>
417 $ <b>gxemul -E dec -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
418
419 KN02-BA V5.7e
420 ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
421 ?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA]
422 ...
423 --More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C)
424 >><b>?</b>
425 ? [cmd]
426 boot [[-z #] [-n] #/path [ARG...]]
427 cat SCRPT
428 cnfg [#]
429 d [-bhw] [-S #] RNG VAL
430 e [-bhwcdoux] [-S #] RNG
431 erl [-c]
432 go [ADR]
433 init [#] [-m] [ARG...]
434 ls [#]
435 passwd [-c] [-s]
436 printenv [EVN]
437 restart
438 script SCRPT
439 setenv EVN STR
440 sh [-belvS] [SCRPT] [ARG..]
441 t [-l] #/STR [ARG..]
442 unsetenv EVN
443 >><b>cnfg</b>
444 3: KN02-BA DEC V5.7e TCF0 (128 MB)
445 (enet: 00-00-00-00-00-00)
446 (SCSI = 7)
447 0: PMAG-BA DEC V5.3a TCF0
448 >><b>printenv</b>
449 boot=
450 testaction=q
451 haltaction=h
452 more=24
453 #=3
454 console=*
455 osconsole=3
456 >>
457 </pre>
458 <i>(Note: at the moment, this doesn't work. I must have broken something when
459 fixing something else, but this is what it looked like at the time.)</i>
460 <p>
461 During bootup, the PROM complains <i>a lot</i> about hardware failures.
462 That's because the emulator doesn't emulate the hardware well enough yet.
463 <p>
464 The command line options used are: -E dec for DECstation, -e 3min for
465 "model 3" (5000/1xx), -Q to supress the emulator's own PROM
466 call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly
467 emulate memory detection well enough for the PROM to accept, so it will
468 always believe there is 128MB ram anyway), and -q to supress debug messages.
469 The 0xbfc00000 in front of the filename tells GXemul that it is a raw
470 binary file which should be loaded at a specific virtual address.
471
472
473 <p><br>
474 <h4>Dumping the PROM on a SGI O2:</h4>
475
476 The general ideas in this section applies to using ROM images from other
477 machines as well. Besides DECstation, I've also tried this on an SGI IP32
478 ("O2").
479 <p>
480 For the O2, a suitable command to dump the prom memory range is
481 <pre>
482 &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
483 </pre>
484 Make sure you capture all the output (via serial console) into a file,
485 and then run experiments/sgiprom_to_bin on the captured file.
486 <p>
487 (2005-01-16: The emulator doesn't really emulate the IP32 well enough to
488 actually run the PROM image without using special hacks, but it might do
489 so some time in the future.)
490
491
492
493
494
495 </p>
496
497 </body>
498 </html>

  ViewVC Help
Powered by ViewVC 1.1.26