/[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 20 - (show annotations)
Mon Oct 8 16:19:23 2007 UTC (13 years, 3 months ago) by dpavlin
File MIME type: text/html
File size: 22471 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.1055 2005/11/25 22:48:36 debug Exp $
20051031	Adding disassembly support for more ARM instructions (clz,
		smul* etc), and adding a hack to support "new tiny" pages
		for StrongARM.
20051101	Minor documentation updates (NetBSD 2.0.2 -> 2.1, and OpenBSD
		3.7 -> 3.8, and lots of testing).
		Changing from 1-sector PIO mode 0 transfers to 128-sector PIO
		mode 3 (in dev_wdc).
		Various minor ARM dyntrans updates (pc-relative loads from
		within the same page as the instruction are now treated as
		constant "mov").
20051102	Re-enabling instruction combinations (they were accidentally
		disabled).
		Dyntrans TLB entries are now overwritten using a round-robin
		scheme instead of randomly. This increases performance.
		Fixing a typo in file.c (thanks to Chuan-Hua Chang for
		noticing it).
		Experimenting with adding ATAPI support to dev_wdc (to make
		emulated *BSD detect cdroms as cdroms, not harddisks).
20051104	Various minor updates.
20051105	Continuing on the ATAPI emulation. Seems to work well enough
		for a NetBSD/cats installation, but not OpenBSD/cats.
		Various other updates.
20051106	Modifying the -Y command line option to allow scaleup with
		certain graphic controllers (only dev_vga so far), not just
		scaledown.
		Some minor dyntrans cleanups.
20051107	Beginning a cleanup up the PCI subsystem (removing the
		read_register hack, etc).
20051108	Continuing the cleanup; splitting up some pci devices into a
		normal autodev device and some separate pci glue code.
20051109	Continuing on the PCI bus stuff; all old pci_*.c have been
		incorporated into normal devices and/or rewritten as glue code
		only, adding a dummy Intel 82371AB PIIX4 for Malta (not really
		tested yet).
		Minor pckbc fix so that Linux doesn't complain.
		Working on the DEC 21143 NIC (ethernet mac rom stuff mostly).
		Various other minor fixes.
20051110	Some more ARM dyntrans fine-tuning (e.g. some instruction
		combinations (cmps followed by conditional branch within the
		same page) and special cases for DPIs with regform when the
		shifter isn't used).
20051111	ARM dyntrans updates: O(n)->O(1) for just-mark-as-non-
		writable in the generic pc_to_pointers function, and some other
		minor hacks.
		Merging Cobalt and evbmips (Malta) ISA interrupt handling,
		and some minor fixes to allow Linux to accept harddisk irqs.
20051112	Minor device updates (pckbc, dec21143, lpt, ...), most
		importantly fixing the ALI M1543/M5229 so that harddisk irqs
		work with Linux/CATS.
20051113	Some more generalizations of the PCI subsystem.
		Finally took the time to add a hack for SCSI CDROM TOCs; this
		enables OpenBSD to use partition 'a' (as needed by the OpenBSD
		installer), and Windows NT's installer to get a bit further.
		Also fixing dev_wdc to allow Linux to detect ATAPI CDROMs.
		Continuing on the DEC 21143.
20051114	Minor ARM dyntrans tweaks; ARM cmps+branch optimization when
		comparing with 0, and generalizing the xchg instr. comb.
		Adding disassembly of ARM mrrc/mcrr and q{,d}{add,sub}.
20051115	Continuing on various PPC things (BATs, other address trans-
		lation things, various loads/stores, BeBox emulation, etc.).
		Beginning to work on PPC interrupt/exception support.
20051116	Factoring out some code which initializes legacy ISA devices
		from those machines that use them (bus_isa).
		Continuing on PPC interrupt/exception support.
20051117	Minor Malta fixes: RTC year offset = 80, disabling a speed hack
		which caused NetBSD to detect a too fast cpu, and adding a new
		hack to make Linux detect a faster cpu.
		Continuing on the Artesyn PM/PPC emulation mode.
		Adding an Algor emulation skeleton (P4032 and P5064);
		implementing some of the basics.
		Continuing on PPC emulation in general; usage of unimplemented
		SPRs is now easier to track, continuing on memory/exception
		related issues, etc.
20051118	More work on PPC emulation (tgpr0..3, exception handling,
		memory stuff, syscalls, etc.).
20051119	Changing the ARM dyntrans code to mostly use cpu->pc, and not
		necessarily use arm reg 15. Seems to work.
		Various PPC updates; continuing on the PReP emulation mode.
20051120	Adding a workaround/hack to dev_mc146818 to allow NetBSD/prep
		to detect the clock.
20051121	More cleanup of the PCI bus (memory and I/O bases, etc).
		Continuing on various PPC things (decrementer and timebase,
		WDCs on obio (on PReP) use irq 13, not 14/15).
20051122	Continuing on the CPC700 controller (interrupts etc) for PMPPC,
		and on PPC stuff in general.
		Finally! After some bug fixes to the virtual to physical addr
		translation, NetBSD/{prep,pmppc} 2.1 reach userland and are
		stable enough to be interacted with.
		More PCI updates; reverse-endian device access for PowerPC etc.
20051123	Generalizing the IEEE floating point subsystem (moving it out
		from src/cpus/cpu_mips_coproc.c into a new src/float_emul.c).
		Input via slave xterms was sometimes not really working; fixing
		this for ns16550, and a warning message is now displayed if
		multiple non-xterm consoles are active.
		Adding some PPC floating point support, etc.
		Various interrupt related updates (dev_wdc, _ns16550, _8259,
		and the isa32 common code in machine.c).
		NetBSD/prep can now be installed! :-) (Well, with some manual
		commands necessary before running sysinst.) Updating the
		documentation and various other things to reflect this.
20051124	Various minor documentation updates.
		Continuing the work on the DEC 21143 NIC.
20051125	LOTS of work on the 21143. Both OpenBSD and NetBSD work fine
		with it now, except that OpenBSD sometimes gives a time-out
		warning.
		Minor documentation updates.

==============  RELEASE 0.3.7  ==============


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:&nbsp;&nbsp;&nbsp;</b></font>
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.58 2005/11/25 22:35:44 debug Exp $
14
15 Copyright (C) 2003-2005 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: 10.0.0.254
86 </pre>
87
88 <p>The emulated machine must of course have a NIC which is emulated
89 correctly. At the moment, the following NICs should work:
90 <ul>
91 <li><tt><b>ether</b></tt>, the "fake" experimental ethernet device
92 (documented <a href="experiments.html#expdevices">here</a>)
93 <li><tt><b>le</b></tt>, Turbochannel Lance Ethernet, as used in
94 DECstation 5000/200 ("3max")
95 <li><tt><b>mec</b></tt>, the SGI O2's ethernet controller
96 <li><tt><b>dec21143</b></tt>, Digital's 21143 NIC (known as <tt>dc</tt>
97 in OpenBSD, or <tt>tlp</tt> in NetBSD)
98 </ul>
99
100 <p>The emulator acts as a NAT-like gateway/firewall; to the outside world
101 it will seem like it is the host's OS that connects to other machines on
102 the internet, not the guest OS.
103
104
105
106
107
108
109 <p><br>
110 <a name="devel"></a>
111 <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
112
113 Is this a good idea? The answer is yes and no, depending on the level of
114 detail you need in your simulations. If you are developing an operating
115 system or operating system kernel of your own, then the emulator can be a
116 complement to testing on real hardware.
117
118 <p>Important things to keep in mind:
119
120 <ul>
121 <li>Porting code to a specific machine mode, e.g. a Silicon Graphics
122 machine, using GXemul, will not "magically" cause the code to
123 work on a real machine. Sometimes code works in GXemul which doesn't
124 work on real hardware, sometimes it's the other way around.
125
126 <p>
127 <li>GXemul contains bugs, and many things are not yet implemented.
128
129 <p>
130 <li><b>Very important!</b> I have only implemented devices in GXemul
131 to the degree that NetBSD, OpenBSD, Linux, etc don't complain too much.
132 <p>
133 If you are developing a driver for a device which is emulated by
134 GXemul, and your driver does not seem to be working, then the
135 probability of a bug in GXemul's implementation of the device is
136 very much higher than that of a bug in your driver.
137 <p>
138 The device implementations in GXemul are based on the assumption
139 that the emulated OS is already developed and bug-free. They are
140 not primarily intended to be used for development of new device
141 driver code in operating systems, so if you do that, then be
142 prepared for bugs and inconsitencies.
143 <p>
144 <li>CPU details in GXemul are usually wrong. If your code depends
145 on, say, R10000 or MIPS64 specifics, chances are that GXemul will
146 not be sufficient. One example is different revisions of ISAs;
147 64-bit MIPS instructions which should trigger an exception on a
148 real 32-bit MIPS processor usually execute anyway in GXemul. Another
149 example is if userland code tries to access kernel memory; in some
150 cases there is protection against this, but not in all cases (to get
151 higher performance).
152 <p>
153 <li>Caches. There is no cache emulation in GXemul right now. Caches
154 for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc
155 in the DECstation emulation mode, but other than that, cache
156 operations are treated as nops.
157 </ul>
158
159 <p>The bottom line is that GXemul can be useful as yet another way to test
160 your code during development, but it should not be fully relied on.
161
162
163
164
165
166
167 <p><br>
168 <a name="compilercontruct"></a>
169 <h3>Using GXemul in compiler contruction courses:</h3>
170
171 If you are learning how to write a compiler, and wish to target a
172 realistic target platform, then MIPS or ARM (as emulated by GXemul)
173 might be suitable choices.
174
175 <ul>
176 <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
177 language code, which the assembler (eg gas, the GNU assembler) can
178 then compile into object format, and then you need to link this
179 into an executable image. This is much closer to how things work
180 in real life than running assembly language listings in a simulator
181 (eg SPIM).
182 <p>
183 <li><b>(-)</b>&nbsp;&nbsp;GXemul does not simulate out-of-order
184 execution, penalties related to instruction scheduling, or
185 load-delays, so it cannot be used to create optimizing compilers
186 that take advantage of such processor features. GXemul keeps
187 track of the number of instructions executed, but that's it.
188 </ul>
189
190
191
192
193
194
195 <p><br>
196 <a name="disk"></a>
197 <h3>How to start the emulator with a disk image:</h3>
198
199 Add <i>-d [prefixes:]diskimagefilename</i> to the command line, where prefixes
200 are one or more single-character options. Run <b>gxemul -h</b>
201 to get a list of possible options.
202
203 <p>
204 Here are some examples. If you want to run a NetBSD/pmax kernel on an
205 emulated DECstation machine, you would use a command line such as this:
206 <pre>
207 $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
208 </pre>
209
210 <p>NOTE: For some emulation modes, such as the DECstation mode, you do
211 <i>not</i> actually have to specify the name of the kernel, if the disk
212 image is bootable!
213
214 <p>It is possible to have more than one disk. For each -d argument, a disk
215 image is added; the first will be SCSI target 0, the second will be target 1, and so on,
216 unless you specify explicitly which ID number the devices should have.
217 <pre>
218 $ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
219 </pre>
220 Note: In the example above, disk2.raw will get scsi id 5.
221
222 <p>If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be
223 a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk).
224 For example, the following command would start the emulator with two
225 CDROM images, and one harddisk image:
226 <pre>
227 $ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
228 </pre>
229 Usually, the device with the lowest id becomes the boot device. To override
230 this, add a 'b' prefix to one of the devices:
231 <pre>
232 $ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
233 </pre>
234 If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can
235 use it as a CD-ROM directly accessible from within the emulator:
236 <pre>
237 $ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
238 </pre>
239 It is probably possible to use harddisks as well this way, but I would not
240 recommend it.
241 <p>
242 Using emulated tape drives is a bit more complicated than disks, because a
243 tape can be made up of several "files" with space in between. The solution
244 I have choosen is to have one file in the host's file system space for each
245 tape file. The prefix for using tapes is 't', and the filename given is
246 for the <i>first</i> file on that tape (number zero, implicitly). For
247 files following file nr 0, a dot and the filenumber is appended to the
248 filename.
249 <p>
250 As an example, starting the emulator with
251 <pre>
252 <b>-d t4:mytape.img</b>
253 </pre>
254 will cause SCSI id 4 to be a tape device, using the following file number
255 to name translation scheme:
256 <p>
257 <center>
258 <table border="0">
259 <tr>
260 <td><b>File number:</b></td>
261 <td><b>File name in the host's filesystem:</b></td>
262 </tr>
263 <tr>
264 <td align="center">0</td>
265 <td align="left">mytape.img</td>
266 </tr>
267 <tr>
268 <td align="center">1</td>
269 <td align="left">mytape.img.1</td>
270 </tr>
271 <tr>
272 <td align="center">2</td>
273 <td align="left">mytape.img.2</td>
274 </tr>
275 <tr>
276 <td align="center">..</td>
277 <td align="left">..</td>
278 </tr>
279 </table>
280 </center>
281 <p>
282 If you already have a number of tape files, which should be placed on the
283 same emulated tape, then you might not want to rename all those files.
284 Use symbolic links instead (ln -s).
285 <p>
286 There is another advantage to using symbolic links for tape filenames:
287 every time a tape is rewound, it is reopened using the filename given
288 on the command line. By changing what the symbolic name points to,
289 you can "switch tapes" without quiting and restarting the emulator.
290
291
292
293
294
295
296 <p><br>
297 <a name="filexfer"></a>
298 <h3>Transfering files to/from the guest OS:</h3>
299
300 If the emulated machine supports networking (see
301 <a href="#networking">above</a>), then transfering files via FTP is
302 probably easiest.
303
304 <p>There is another way of transfering files which works for any kind of
305 emulated machine which supports disks (either SCSI or IDE). Any file can
306 be supplied as a disk image. For example, consider the following:<pre>
307 $ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar.gz netbsd-GENERIC</b>
308 </pre>
309 This will start NetBSD/cats with <tt>nbsd_cats.img</tt> as IDE master on
310 controller 0 (wd0), and <tt>archive.tar.gz</tt> as IDE slave on controller
311 0 (wd1). From inside NetBSD, it is now possible to extract the files using
312 the following command:<pre>
313 (inside emulated NetBSD/cats)
314 # <b>tar zxvf /dev/wd1c</b>
315 </pre>
316 Don't worry if NetBSD complains about lack of disklabel; it doesn't
317 matter. On some machines, NetBSD uses <tt>wd1d</tt> instead of
318 <tt>wd1c</tt> for the entire disk.
319 There is also a minor problem: reading the end of the disk image. If you
320 experience problems untaring archives like this, then pad out the archive
321 first with some zeroes.
322
323 <p>Transfering files <i>out</i> from the emulated operating system to the
324 host can be done the same way. First, prepare an empty archive file:<pre>
325 $ <b>dd if=/dev/zero of=newarchive.tar bs=1024 count=1 seek=10000</b>
326 </pre>This example created a 10 MB empty file. Then, start the emulator
327 like this:<pre>
328 $ <b>gxemul -XEcats -d nbsd_cats.img -d archive.tar netbsd-GENERIC</b>
329 </pre>
330 and transfer files by creating an archive directly onto the disk image:<pre>
331 (inside emulated NetBSD/cats)
332 # <b>tar cvf /dev/wd1c filenames</b>
333 </pre>
334 where filenames are the files or directories to transfer.
335
336
337
338
339
340 <p><br>
341 <a name="largeimages"></a>
342 <h3>How to extract large gzipped disk images:</h3>
343
344 Unix filesystems usually support large files with "holes". Holes are
345 zero-filled blocks that don't actually exist on disk. This is very
346 practical for emulated disk images, as it is possible to create a very
347 large disk image without using up much space at all.
348
349 <p>
350 Using gzip and gunzip on disk images can be <i>very</i> slow, as these
351 files can be multiple gigabytes large, but this is usually necessary for
352 transfering disk images over the internet. If you receive a gzipped disk
353 image, say disk.img.gz, and run a naive
354 <p>
355 <pre>
356 $ <b>gunzip disk.img.gz</b>
357 </pre>
358 <p>
359 on it, you will not end up with an optimized file unless
360 gunzip supports that. (In my experiments, it doesn't.) In plain English,
361 if you type <b>ls -l</b> and the filesize is 9 GB, it will actually occupy
362 9 GB of disk space! This is often unacceptable.
363 <p>
364 Using a simple tool which only writes blocks that are non-zero, a lot of
365 space can be saved. Compile the program cp_removeblocks in the
366 experiments/ directory, and type:
367 <p>
368 <pre>
369 $ <b>gunzip -c disk.img.gz | cp_removeblocks /dev/stdin disk.img</b>
370 </pre>
371
372 <p>
373 This will give you a disk.img which looks like it is 9 GB, and works like
374 the real file, but the holes are not written out to the disk. (You can see
375 this by running for example <b>du disk.img</b> to see the physical block
376 count.)
377
378
379
380 <p><br>
381 <a name="userland"></a>
382 <h3>Running userland binaries:</h3>
383
384 <font color="#ff0000">Note: This does not really work yet.</font>
385
386 <p>There is some skeleton code for running userland programs as well. This
387 will not emulate any particular machine, but instead try to translate
388 syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now,
389 this is just a proof-of-concept, to show that it could work; there's lots
390 of work left to do to make it actually run useful programs.
391
392 <p>
393
394 <ul>
395 <li><b>NetBSD/pmax:</b>
396 <br>
397 Running /bin/hostname or /bin/date and similarly trivial
398 programs from the NetBSD/pmax distribution works:<pre>
399 $ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b>
400 tab.csbnet.se
401 $ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b>
402 Sun Jan 25 02:26:14 GMT 2004
403 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b>
404 usage: pmax_bin_sleep seconds
405 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b>
406 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b>
407 </pre>
408
409 <p>
410 <li><b>Ultrix:</b>
411 <br>
412 At least /bin/date and /bin/hostname work:<pre>
413 $ <b>gxemul -q -u ultrix ultrix4_bin_date</b>
414 UNIMPLEMENTED ultrix syscall 54
415 UNIMPLEMENTED ultrix syscall 62
416 Mon Feb 9 12:50:59 WET 2004
417 $ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b>
418 tab.csbnet.se
419 </pre>
420
421 <!--
422 <p>
423 <li><b>NetBSD/powerpc:</b>
424 <br>
425 /bin/sync from NetBSD/macppc works, but probably not much else.<pre>
426 $ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b>
427 ...
428 [ sync() ]
429 [ exit(0) ]
430 cpu_run_deinit(): All CPUs halted.
431
432 </pre>
433
434 <p>
435 <li><b>Linux/PPC64:</b>
436 <br>
437 The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a>
438 on IBM's developerWorks pages runs:<pre>
439 $ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b>
440 $ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b>
441 $ <b>gxemul -q -u linux/ppc64 hello-ppc64</b>
442 Hello, world!
443
444 </pre>
445 -->
446
447 </ul>
448
449
450
451
452
453 <p><br>
454 <a name="promdump"></a>
455 <h3>Using a PROM dump from a real machine:</h3>
456
457 Raw PROM images from real machines can, in a few cases, be used in
458 the emulator. ROM code is usually much more sensitive to correctness
459 of the emulator than operating system kernels or userland programs
460 are, so don't expect any PROM image to just magically work.
461
462
463 <p>
464 <h4>Dumping the PROM on a DECstation 5000/125:</h4>
465 The image first needs to be extracted from the machine. There are
466 several ways to do this.
467 <ul>
468 <li>Use hardware to read the PROM chip(s) directly. Not easy if you
469 don't have such a hardware reader.
470 <li>Copy the PROM memory range into a file, from a running
471 operating system. You need a running OS, and it must
472 have access to the PROM memory range. NetBSD, for example,
473 doesn't allow that from userland.
474 <li>Hook up a serial console and dump using the PROM's own dump
475 command.
476 </ul>
477 <p>
478 The easiest way is to hook up a serial console. The terminal must be
479 able to capture output to a file.
480 <p>
481 These are approximately the commands that I used:
482 <pre>
483 >><b>cnfg</b> <i>Show machine configuration</i>
484
485 >><b>printenv</b> <i>Show environment variables</i>
486
487 >><b>setenv more 0</b> <i>This turns off the More messages</i>
488
489 >><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i>
490 </pre>
491 <p>
492 Remember that DECstations are little endian, so if the dump data
493 looks like this:
494 <pre>
495 bfc00000: 0x0bf0007e
496 </pre>
497 then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b.
498 <p>
499 At 9600 bps, about 10KB can be dumped per minute, so it takes a while.
500 Once enough of the PROM has been dumped, you can press CTRL-C to break out.
501 Then, restore the more environment variable:
502 <pre>
503 >><b>setenv more 24</b>
504 </pre>
505 <p>
506 Now, convert the data you just saved (little-endian words -> bytes),
507 and store in a file. Let's call this file DECstation5000_125_promdump.bin.
508 <pre>
509 $ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b>
510 </pre>
511 This binary image can now be used in the emulator:
512 <pre>
513 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
514
515 KN02-BA V5.7e
516 ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
517 ?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA]
518 ...
519 --More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C)
520 >><b>?</b>
521 ? [cmd]
522 boot [[-z #] [-n] #/path [ARG...]]
523 cat SCRPT
524 cnfg [#]
525 d [-bhw] [-S #] RNG VAL
526 e [-bhwcdoux] [-S #] RNG
527 erl [-c]
528 go [ADR]
529 init [#] [-m] [ARG...]
530 ls [#]
531 passwd [-c] [-s]
532 printenv [EVN]
533 restart
534 script SCRPT
535 setenv EVN STR
536 sh [-belvS] [SCRPT] [ARG..]
537 t [-l] #/STR [ARG..]
538 unsetenv EVN
539 >><b>cnfg</b>
540 3: KN02-BA DEC V5.7e TCF0 (128 MB)
541 (enet: 00-00-00-00-00-00)
542 (SCSI = 7)
543 0: PMAG-BA DEC V5.3a TCF0
544 >><b>printenv</b>
545 boot=
546 testaction=q
547 haltaction=h
548 more=24
549 #=3
550 console=*
551 osconsole=3
552 >>
553 </pre>
554
555 <p><font color="#ff0000">(Note: at the moment, this doesn't work.
556 I must have broken something when fixing something else, but this
557 is what it looked like at the time.)</font>
558
559 <p>During bootup, the PROM complains <i>a lot</i> about hardware failures.
560 That's because the emulator doesn't emulate the hardware well enough yet.
561
562 <p>The command line options used are: <tt>-e 3min</tt> for
563 "DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM
564 call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly
565 emulate memory detection well enough for the PROM to accept, so it will
566 always believe there is 128MB ram anyway), and <tt>-q</tt> to supress debug messages.
567 The <tt>0xbfc00000</tt> in front of the filename tells GXemul that it is a raw
568 binary file which should be loaded at a specific virtual address.
569
570
571 <p><br>
572 <h4>Dumping the PROM on a SGI O2:</h4>
573
574 The general ideas in this section applies to using ROM images from other
575 machines as well. I have also tried this on an SGI IP32 ("O2"), in addition
576 to the DECstation.
577
578 <p>For the O2, a suitable command to dump the prom memory range is
579 <pre>
580 &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
581 </pre>
582 Make sure you capture all the output (via serial console) into a file,
583 and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file.
584
585 <p>
586 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
587 <a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a>
588 &nbsp;&nbsp;&nbsp;
589 <a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a>
590 &nbsp;&nbsp;&nbsp;
591 <a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a>
592
593 <p>The photo on the left is from the real machine. The other two are
594 screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt>
595 framebuffer scaledown.
596
597 <p>Normally during bootup, the IP32 PROM does a Power-On test which makes
598 sure that the caches and other things are working properly. GXemul doesn't
599 emulate all those things well enough for the tests to pass. The
600 experimental screenshots above were taken with cache detection skipped
601 manually.
602
603 <p><font color="#ff0000">
604 In other words: don't expect this to work out-of-the-box with GXemul right
605 now. It might work once I've added correct cache emulation.</font>
606
607 <p>The command line used to start the emulator, once correct cache
608 emulation has been implemented, would be something like <tt>gxemul -XQeo2
609 0xbfc00000:prom.bin</tt>.
610
611 <p>The same caution applies when dealing with SGI PROMs as with
612 DECstation PROMs: GXemul doesn't really emulate the hardware, it only
613 "fakes" devices well enough to fool some things, primarily NetBSD, that
614 it is emulating a real machine. ROM code is usually a <i>lot</i> more
615 picky about the details.
616
617 <p>The graphics used in the O2 is (as far as I know) undocumented. Combining
618 some traces of info from how Linux/O2 draws to the screen with some
619 reverse-engineering of my own, I've implemented enough of the controller to
620 let the PROM draw rectangles and bitmaps, but not much more. The SCSI
621 controller is not implemented yet either.
622
623
624
625
626 </p>
627
628 </body>
629 </html>

  ViewVC Help
Powered by ViewVC 1.1.26