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

Annotation of /trunk/doc/misc.html

Parent Directory Parent Directory | Revision Log Revision Log

Revision 22 - (hide annotations)
Mon Oct 8 16:19:37 2007 UTC (13 years, 3 months ago) by dpavlin
File MIME type: text/html
File size: 22503 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.1121 2006/02/18 21:03:08 debug Exp $
20051126	Cobalt and PReP now work with the 21143 NIC.
		Continuing on Alpha dyntrans things.
		Fixing some more left-shift-by-24 to unsigned.
20051127	Working on OpenFirmware emulation; major cleanup/redesign.
		Progress on MacPPC emulation: NetBSD detects two CPUs (when
		running with -n 2), framebuffer output (for text) works.
		Adding quick-hack Bandit PCI controller and "gc" interrupt
		controller for MacPPC.
20051128	Changing from a Bandit to a Uni-North controller for macppc.
		Continuing on OpenFirmware and MacPPC emulation in general
		(obio controller, and wdc attached to the obio seems to work).
20051129	More work on MacPPC emulation (adding a dummy ADB controller).
		Continuing the PCI bus cleanup (endianness and tag composition)
		and rewriting all PCI controllers' access functions.
20051130	Various minor PPC dyntrans optimizations.
		Manually inlining some parts of the framebuffer redraw routine.
		Slowly beginning the conversion of the old MIPS emulation into
		dyntrans (but this will take quite some time to get right).
		Generalizing quick_pc_to_pointers.
20051201	Documentation update (David Muse has made available a kernel
		which simplifies Debian/DECstation installation).
		Continuing on the ADB bus controller.
20051202	Beginning a rewrite of the Zilog serial controller (dev_zs).
20051203	Continuing on the zs rewrite (now called dev_z8530); conversion
		to devinit style.
		Reworking some of the input-only vs output-only vs input-output
		details of src/console.c, better warning messages, and adding
		a debug dump.
		Removing the concept of "device state"; it wasn't really used.
		Changing some debug output (-vv should now be used to show all
		details about devices and busses; not shown during normal
		startup anymore).
		Beginning on some SPARC instruction disassembly support.
20051204	Minor PPC updates (WALNUT skeleton stuff).
		Continuing on the MIPS dyntrans rewrite.
		More progress on the ADB controller (a keyboard is "detected"
		by NetBSD and OpenBSD).
		Downgrading OpenBSD/arc as a guest OS from "working" to
		"almost working" in the documentation.
		Progress on Algor emulation ("v3" PCI controller).
20051205	Minor updates.
20051207	Sorting devices according to address; this reduces complexity
		of device lookups from O(n) to O(log n) in memory_rw (but no
		real performance increase (yet) in experiments).
20051210	Beginning the work on native dyntrans backends (by making a
		simple skeleton; so far only for Alpha hosts).
20051211	Some very minor SPARC updates.
20051215	Fixing a bug in the MIPS mul (note: not mult) instruction,
		so it also works with non-64-bit emulation. (Thanks to Alec
		Voropay for noticing the problem.)
20051216	More work on the fake/empty/simple/skeleton/whatever backend;
		performance doesn't increase, so this isn't really worth it,
		but it was probably worth it to prepare for a real backend
20051219	More instr call statistics gathering and analysis stuff.
20051220	Another fix for MIPS 'mul'. Also converting mul and {d,}cl{o,z}
		to dyntrans.
		memory_ppc.c syntax error fix (noticed by Peter Valchev).
		Beginning to move out machines from src/machine.c into
		individual files in src/machines (in a way similar to the
		autodev system for devices).
20051222	Updating the documentation regarding NetBSD/pmax 3.0.
20051223	- " - NetBSD/cats 3.0.
20051225	- " - NetBSD/hpcmips 3.0.
20051226	Continuing on the machine registry redesign.
		Adding support for ARM rrx (33-bit rotate).
		Fixing some signed/unsigned issues (exposed by gcc -W).
20051227	Fixing the bug which prevented a NetBSD/prep 3.0 install kernel
		from starting (triggered when an mtmsr was the last instruction
		on a page). Unfortunately not enough to get the kernel to run
		as well as the 2.1 kernels did.
20051230	Some dyntrans refactoring.
20051231	Continuing on the machine registry redesign.
20060101-10	Continuing... moving more machines. Moving MD interrupt stuff
		from machine.c into a new src/machines/interrupts.c.
20060114	Adding various mvmeppc machine skeletons.
20060115	Continuing on mvme* stuff. NetBSD/mvmeppc prints boot messages
		(for MVME1600) and reaches the root device prompt, but no
		specific hardware devices are emulated yet.
20060116	Minor updates to the mvme1600 emulation mode; the Eagle PCI bus
		seems to work without much modification, and a 21143 can be
		detected, interrupts might work (but untested so far).
		Adding a fake MK48Txx (mkclock) device, for NetBSD/mvmeppc.
20060121	Adding an aux control register for ARM. (A BIG thank you to
		Olivier Houchard for tracking down this bug.)
20060122	Adding more ARM instructions (smulXY), and dev_iq80321_7seg.
20060124	Adding disassembly of more ARM instructions (mia*, mra/mar),
		and some semi-bogus XScale and i80321 registers.
20060201-02	Various minor updates. Moving the last machines out of
20060204	Adding a -c command line option, for running debugger commands
		before the simulation starts, but after all files have been
		Minor iq80321-related updates.
20060209	Minor hacks (DEVINIT macro, etc).
		Preparing for the generalization of the 64-bit dyntrans address
		translation subsystem.
20060216	Adding ARM ldrd (double-register load).
20060217	Continuing on various ARM-related stuff.
20060218	More progress on the ATA/wdc emulation for NetBSD/iq80321.
		NetBSD/evbarm can now be installed :-)  Updating the docs, etc.
		Continuing on Algor emulation.

==============  RELEASE 0.3.8  ==============

1 dpavlin 12 <html><head><title>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;Miscellaneous</title>
2 dpavlin 8 <meta name="robots" content="noarchive,nofollow,noindex"></head>
3 dpavlin 4 <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 dpavlin 22 <b>Gavare's eXperimental Emulator:</b></font><br>
8 dpavlin 12 <font color="#000000" size="6"><b>Miscellaneous</b>
9 dpavlin 4 </font></td></tr></table></td></tr></table><p>
10 dpavlin 2
11     <!--
13 dpavlin 22 $Id: misc.html,v 1.62 2006/02/18 13:15:21 debug Exp $
14 dpavlin 2
15 dpavlin 22 Copyright (C) 2003-2006 Anders Gavare. All rights reserved.
16 dpavlin 2
17     Redistribution and use in source and binary forms, with or without
18     modification, are permitted provided that the following conditions are met:
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.
40     -->
42 dpavlin 12
43 dpavlin 2 <a href="./">Back to the index</a>
45     <p><br>
46 dpavlin 12 <h2>Miscellaneous</h2>
47 dpavlin 2
48     <p>
49     <ul>
50     <li><a href="#networking">Networking</a>
51 dpavlin 12 <li><a href="#devel">Writing operating system code, or
52     developing firmware, using GXemul</a>
53 dpavlin 2 <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 dpavlin 20 <li><a href="#filexfer">Transfering files to/from the guest OS</a>
56 dpavlin 2 <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>
67     <p><br>
68     <a name="networking"></a>
69     <h3>Networking:</h3>
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>.
77 dpavlin 20 <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 dpavlin 2
81 dpavlin 20 <p>When only one machine is being emulated, the following default values
82     apply:<pre>
83     IPv4 address:
84     Netmask:
85 dpavlin 22 Gateway / default route:
86     Nameserver:
87 dpavlin 20 </pre>
88 dpavlin 2
89 dpavlin 20 <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 dpavlin 22 (documented <a href="experiments.html#expdevices_ether">here</a>)
94 dpavlin 20 <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 dpavlin 2
101 dpavlin 20 <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 dpavlin 2
106 dpavlin 20
110 dpavlin 2 <p><br>
111 dpavlin 12 <a name="devel"></a>
112     <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
113 dpavlin 2
114 dpavlin 12 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 dpavlin 20 system or operating system kernel of your own, then the emulator can be a
117     complement to testing on real hardware.
118 dpavlin 2
119 dpavlin 20 <p>Important things to keep in mind:
120 dpavlin 2
121 dpavlin 12 <ul>
122     <li>Porting code to a specific machine mode, e.g. a Silicon Graphics
123 dpavlin 20 machine, using GXemul, will not "magically" cause the code to
124 dpavlin 12 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 dpavlin 2
127 dpavlin 12 <p>
128     <li>GXemul contains bugs, and many things are not yet implemented.
129 dpavlin 2
130 dpavlin 12 <p>
131 dpavlin 20 <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 dpavlin 12 <p>
134 dpavlin 20 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 dpavlin 12 <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 dpavlin 20 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 dpavlin 12 <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 dpavlin 2
160 dpavlin 12 <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 dpavlin 2
164 dpavlin 12
168 dpavlin 2 <p><br>
169     <a name="compilercontruct"></a>
170     <h3>Using GXemul in compiler contruction courses:</h3>
172     If you are learning how to write a compiler, and wish to target a
173 dpavlin 20 realistic target platform, then MIPS or ARM (as emulated by GXemul)
174     might be suitable choices.
175 dpavlin 2
176     <ul>
177     <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
178     language code, which the assembler (eg 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     (eg 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>
196     <p><br>
197     <a name="disk"></a>
198     <h3>How to start the emulator with a disk image:</h3>
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.
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 dpavlin 12 $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
209 dpavlin 2 </pre>
210 dpavlin 20
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!
215     <p>It is possible to have more than one disk. For each -d argument, a disk
216 dpavlin 2 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 dpavlin 12 $ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
220 dpavlin 2 </pre>
221     Note: In the example above, disk2.raw will get scsi id 5.
222 dpavlin 20
223     <p>If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be
224 dpavlin 2 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 dpavlin 12 $ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
229 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
234 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
239 dpavlin 2 </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.
294 dpavlin 20
297 dpavlin 2 <p><br>
298 dpavlin 20 <a name="filexfer"></a>
299     <h3>Transfering files to/from the guest OS:</h3>
301     If the emulated machine supports networking (see
302     <a href="#networking">above</a>), then transfering files via FTP is
303     probably easiest.
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.
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.
341     <p><br>
342 dpavlin 2 <a name="largeimages"></a>
343     <h3>How to extract large gzipped disk images:</h3>
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.
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>
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.)
381     <p><br>
382     <a name="userland"></a>
383     <h3>Running userland binaries:</h3>
385 dpavlin 12 <font color="#ff0000">Note: This does not really work yet.</font>
386 dpavlin 2
387 dpavlin 12 <p>There is some skeleton code for running userland programs as well. This
388     will not emulate any particular machine, but instead try to translate
389     syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now,
390     this is just a proof-of-concept, to show that it could work; there's lots
391     of work left to do to make it actually run useful programs.
393 dpavlin 2 <p>
395     <ul>
396     <li><b>NetBSD/pmax:</b>
397     <br>
398     Running /bin/hostname or /bin/date and similarly trivial
399     programs from the NetBSD/pmax distribution works:<pre>
400     $ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b>
401     tab.csbnet.se
402     $ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b>
403     Sun Jan 25 02:26:14 GMT 2004
404     $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b>
405     usage: pmax_bin_sleep seconds
406     $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b>
407     $ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b>
408     </pre>
410     <p>
411     <li><b>Ultrix:</b>
412     <br>
413     At least /bin/date and /bin/hostname work:<pre>
414     $ <b>gxemul -q -u ultrix ultrix4_bin_date</b>
415     UNIMPLEMENTED ultrix syscall 54
416     UNIMPLEMENTED ultrix syscall 62
417     Mon Feb 9 12:50:59 WET 2004
418     $ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b>
419     tab.csbnet.se
420     </pre>
422 dpavlin 12 <!--
423 dpavlin 2 <p>
424     <li><b>NetBSD/powerpc:</b>
425     <br>
426     /bin/sync from NetBSD/macppc works, but probably not much else.<pre>
427     $ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b>
428     ...
429     [ sync() ]
430     [ exit(0) ]
431     cpu_run_deinit(): All CPUs halted.
433     </pre>
435     <p>
436     <li><b>Linux/PPC64:</b>
437     <br>
438     The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a>
439     on IBM's developerWorks pages runs:<pre>
440     $ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b>
441     $ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b>
442     $ <b>gxemul -q -u linux/ppc64 hello-ppc64</b>
443     Hello, world!
445     </pre>
446 dpavlin 12 -->
447 dpavlin 2
448     </ul>
454     <p><br>
455     <a name="promdump"></a>
456     <h3>Using a PROM dump from a real machine:</h3>
458     Raw PROM images from real machines can, in a few cases, be used in
459     the emulator. ROM code is usually much more sensitive to correctness
460     of the emulator than operating system kernels or userland programs
461     are, so don't expect any PROM image to just magically work.
464     <p>
465     <h4>Dumping the PROM on a DECstation 5000/125:</h4>
466     The image first needs to be extracted from the machine. There are
467     several ways to do this.
468     <ul>
469     <li>Use hardware to read the PROM chip(s) directly. Not easy if you
470     don't have such a hardware reader.
471     <li>Copy the PROM memory range into a file, from a running
472     operating system. You need a running OS, and it must
473     have access to the PROM memory range. NetBSD, for example,
474     doesn't allow that from userland.
475     <li>Hook up a serial console and dump using the PROM's own dump
476     command.
477     </ul>
478     <p>
479     The easiest way is to hook up a serial console. The terminal must be
480     able to capture output to a file.
481     <p>
482     These are approximately the commands that I used:
483     <pre>
484     >><b>cnfg</b> <i>Show machine configuration</i>
486     >><b>printenv</b> <i>Show environment variables</i>
488     >><b>setenv more 0</b> <i>This turns off the More messages</i>
490     >><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i>
491     </pre>
492     <p>
493     Remember that DECstations are little endian, so if the dump data
494     looks like this:
495     <pre>
496     bfc00000: 0x0bf0007e
497     </pre>
498     then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b.
499     <p>
500     At 9600 bps, about 10KB can be dumped per minute, so it takes a while.
501     Once enough of the PROM has been dumped, you can press CTRL-C to break out.
502     Then, restore the more environment variable:
503     <pre>
504     >><b>setenv more 24</b>
505     </pre>
506     <p>
507     Now, convert the data you just saved (little-endian words -> bytes),
508     and store in a file. Let's call this file DECstation5000_125_promdump.bin.
509     <pre>
510     $ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b>
511     </pre>
512     This binary image can now be used in the emulator:
513     <pre>
514 dpavlin 12 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
515 dpavlin 2
516     KN02-BA V5.7e
517     ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
518     ?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA]
519     ...
520     --More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C)
521     >><b>?</b>
522     ? [cmd]
523     boot [[-z #] [-n] #/path [ARG...]]
524     cat SCRPT
525     cnfg [#]
526     d [-bhw] [-S #] RNG VAL
527     e [-bhwcdoux] [-S #] RNG
528     erl [-c]
529     go [ADR]
530     init [#] [-m] [ARG...]
531     ls [#]
532     passwd [-c] [-s]
533     printenv [EVN]
534     restart
535     script SCRPT
536     setenv EVN STR
537     sh [-belvS] [SCRPT] [ARG..]
538     t [-l] #/STR [ARG..]
539     unsetenv EVN
540     >><b>cnfg</b>
541     3: KN02-BA DEC V5.7e TCF0 (128 MB)
542     (enet: 00-00-00-00-00-00)
543     (SCSI = 7)
544     0: PMAG-BA DEC V5.3a TCF0
545     >><b>printenv</b>
546     boot=
547     testaction=q
548     haltaction=h
549     more=24
550     #=3
551     console=*
552     osconsole=3
553     >>
554     </pre>
555 dpavlin 14
556     <p><font color="#ff0000">(Note: at the moment, this doesn't work.
557     I must have broken something when fixing something else, but this
558     is what it looked like at the time.)</font>
560     <p>During bootup, the PROM complains <i>a lot</i> about hardware failures.
561 dpavlin 2 That's because the emulator doesn't emulate the hardware well enough yet.
562 dpavlin 14
563     <p>The command line options used are: <tt>-e 3min</tt> for
564     "DECstation 3min" (5000/1xx), <tt>-Q</tt> to supress the emulator's own PROM
565     call emulation, <tt>-M128</tt> for 128MB RAM (because GXemul doesn't correctly
566 dpavlin 2 emulate memory detection well enough for the PROM to accept, so it will
567 dpavlin 14 always believe there is 128MB ram anyway), and <tt>-q</tt> to supress debug messages.
568     The <tt>0xbfc00000</tt> in front of the filename tells GXemul that it is a raw
569 dpavlin 2 binary file which should be loaded at a specific virtual address.
572     <p><br>
573     <h4>Dumping the PROM on a SGI O2:</h4>
575     The general ideas in this section applies to using ROM images from other
576 dpavlin 14 machines as well. I have also tried this on an SGI IP32 ("O2"), in addition
577     to the DECstation.
579     <p>For the O2, a suitable command to dump the prom memory range is
580 dpavlin 2 <pre>
581     &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
582     </pre>
583     Make sure you capture all the output (via serial console) into a file,
584 dpavlin 14 and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file.
586 dpavlin 2 <p>
587 dpavlin 14 &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
588     <a href="sgi-o2-real.jpg"><img src="sgi-o2-real_small.jpg"></a>
589     &nbsp;&nbsp;&nbsp;
590     <a href="20050817-sgi-o2-success-7.png"><img src="20050817-sgi-o2-success-7_small.png"></a>
591     &nbsp;&nbsp;&nbsp;
592     <a href="20050817-sgi-o2-success-8.png"><img src="20050817-sgi-o2-success-8_small.png"></a>
593 dpavlin 2
594 dpavlin 14 <p>The photo on the left is from the real machine. The other two are
595     screenshots of the PROM running experimentally in GXemul, using <tt>-Y2</tt>
596     framebuffer scaledown.
597 dpavlin 2
598 dpavlin 14 <p>Normally during bootup, the IP32 PROM does a Power-On test which makes
599     sure that the caches and other things are working properly. GXemul doesn't
600     emulate all those things well enough for the tests to pass. The
601     experimental screenshots above were taken with cache detection skipped
602     manually.
603 dpavlin 2
604 dpavlin 14 <p><font color="#ff0000">
605     In other words: don't expect this to work out-of-the-box with GXemul right
606     now. It might work once I've added correct cache emulation.</font>
607 dpavlin 2
608 dpavlin 14 <p>The command line used to start the emulator, once correct cache
609     emulation has been implemented, would be something like <tt>gxemul -XQeo2
610     0xbfc00000:prom.bin</tt>.
611 dpavlin 2
612 dpavlin 14 <p>The same caution applies when dealing with SGI PROMs as with
613     DECstation PROMs: GXemul doesn't really emulate the hardware, it only
614     "fakes" devices well enough to fool some things, primarily NetBSD, that
615     it is emulating a real machine. ROM code is usually a <i>lot</i> more
616     picky about the details.
618     <p>The graphics used in the O2 is (as far as I know) undocumented. Combining
619     some traces of info from how Linux/O2 draws to the screen with some
620 dpavlin 18 reverse-engineering of my own, I've implemented enough of the controller to
621 dpavlin 14 let the PROM draw rectangles and bitmaps, but not much more. The SCSI
622     controller is not implemented yet either.
627 dpavlin 2 </p>
629     </body>
630     </html>

  ViewVC Help
Powered by ViewVC 1.1.26