/[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 12 - (show annotations)
Mon Oct 8 16:18:38 2007 UTC (16 years, 6 months ago) by dpavlin
File MIME type: text/html
File size: 17997 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.905 2005/08/16 09:16:24 debug Exp $
20050628	Continuing the work on the ARM translation engine. end_of_page
		works. Experimenting with load/store translation caches
		(virtual -> physical -> host).
20050629	More ARM stuff (memory access translation cache, mostly). This
		might break a lot of stuff elsewhere, probably some MIPS-
		related translation things.
20050630	Many load/stores are now automatically generated and included
		into cpu_arm_instr.c; 1024 functions in total (!).
		Fixes based on feedback from Alec Voropay: only print 8 hex
		digits instead of 16 in some cases when emulating 32-bit
		machines; similar 8 vs 16 digit fix for breakpoint addresses;
		4Kc has 16 TLB entries, not 48; the MIPS config select1
		register is now printed with "reg ,0".
		Also changing many other occurances of 16 vs 8 digit output.
		Adding cache associativity fields to mips_cpu_types.h; updating
		some other cache fields; making the output of
		mips_cpu_dumpinfo() look nicer.
		Generalizing the bintrans stuff for device accesses to also
		work with the new translation system. (This might also break
		some MIPS things.)
		Adding multi-load/store instructions to the ARM disassembler
		and the translator, and some optimizations of various kinds.
20050701	Adding a simple dev_disk (it can read/write sectors from
		disk images).
20050712	Adding dev_ether (a simple ethernet send/receive device).
		Debugger command "ninstrs" for toggling show_nr_of_instructions
		during runtime.
		Removing the framebuffer logo.
20050713	Continuing on dev_ether.
		Adding a dummy cpu_alpha (again).
20050714	More work on cpu_alpha.
20050715	More work on cpu_alpha. Many instructions work, enough to run
		a simple framebuffer fill test (similar to the ARM test).
20050716	More Alpha stuff.
20050717	Minor updates (Alpha stuff).
20050718	Minor updates (Alpha stuff).
20050719	Generalizing some Alpha instructions.
20050720	More Alpha-related updates.
20050721	Continuing on cpu_alpha. Importing rpb.h from NetBSD/alpha.
20050722	Alpha-related updates: userland stuff (Hello World using
		write() compiled statically for FreeBSD/Alpha runs fine), and
		more instructions are now implemented.
20050723	Fixing ldq_u and stq_u.
		Adding more instructions (conditional moves, masks, extracts,
		shifts).
20050724	More FreeBSD/Alpha userland stuff, and adding some more
		instructions (inserts).
20050725	Continuing on the Alpha stuff. (Adding dummy ldt/stt.)
		Adding a -A command line option to turn off alignment checks
		in some cases (for translated code).
		Trying to remove the old bintrans code which updated the pc
		and nr_of_executed_instructions for every instruction.
20050726	Making another attempt att removing the pc/nr of instructions
		code. This time it worked, huge performance increase for
		artificial test code, but performance loss for real-world
		code :-( so I'm scrapping that code for now.
		Tiny performance increase on Alpha (by using ret instead of
		jmp, to play nice with the Alpha's branch prediction) for the
		old MIPS bintrans backend.
20050727	Various minor fixes and cleanups.
20050728	Switching from a 2-level virtual to host/physical translation
		system for ARM emulation, to a 1-level translation.
		Trying to switch from 2-level to 1-level for the MIPS bintrans
		system as well (Alpha only, so far), but there is at least one
		problem: caches and/or how they work with device mappings.
20050730	Doing the 2-level to 1-level conversion for the i386 backend.
		The cache/device bug is still there for R2K/3K :(
		Various other minor updates (Malta etc).
		The mc146818 clock now updates the UIP bit in a way which works
		better with Linux for at least sgimips and Malta emulation.
		Beginning the work on refactoring the dyntrans system.
20050731	Continuing the dyntrans refactoring.
		Fixing a small but serious host alignment bug in memory_rw.
		Adding support for big-endian load/stores to the i386 bintrans
		backend.
		Another minor i386 bintrans backend update: stores from the
		zero register are now one (or two) loads shorter.
		The slt and sltu instructions were incorrectly implemented for
		the i386 backend; only using them for 32-bit mode for now.
20050801	Continuing the dyntrans refactoring.
		Cleanup of the ns16550 serial controller (removing unnecessary
		code).
		Bugfix (memory corruption bug) in dev_gt, and a patch/hack from
		Alec Voropay for Linux/Malta.
20050802	More cleanup/refactoring of the dyntrans subsystem: adding
		phys_page pointers to the lookup tables, for quick jumps
		between translated pages.
		Better fix for the ns16550 device (but still no real FIFO
		functionality).
		Converting cpu_ppc to the new dyntrans system. This means that
		I will have to start from scratch with implementing each
		instruction, and figure out how to implement dual 64/32-bit
		modes etc.
		Removing the URISC CPU family, because it was useless.
20050803	When selecting a machine type, the main type can now be omitted
		if the subtype name is unique. (I.e. -E can be omitted.)
		Fixing a dyntrans/device update bug. (Writes to offset 0 of
		a device could sometimes go unnoticed.)
		Adding an experimental "instruction combination" hack for
		ARM for memset-like byte fill loops.
20050804	Minor progress on cpu_alpha and related things.
		Finally fixing the MIPS dmult/dmultu bugs.
		Fixing some minor TODOs.
20050805	Generalizing the 8259 PIC. It now also works with Cobalt
		and evbmips emulation, in addition to the x86 hack.
		Finally converting the ns16550 device to use devinit.
		Continuing the work on the dyntrans system. Thinking about
		how to add breakpoints.
20050806	More dyntrans updates. Breakpoints seem to work now.
20050807	Minor updates: cpu_alpha and related things; removing
		dev_malta (as it isn't used any more).
		Dyntrans: working on general "show trace tree" support.
		The trace tree stuff now works with both the old MIPS code and
		with newer dyntrans modes. :)
		Continuing on Alpha-related stuff (trying to get *BSD to boot
		a bit further, adding more instructions, etc).
20050808	Adding a dummy IA64 cpu family, and continuing the refactoring
		of the dyntrans system.
		Removing the regression test stuff, because it was more or
		less useless.
		Adding loadlinked/storeconditional type instructions to the
		Alpha emulation. (Needed for Linux/alpha. Not very well tested
		yet.)
20050809	The function call trace tree now prints a per-function nr of
		arguments. (Semi-meaningless, since that data isn't read yet
		from the ELFs; some hardcoded symbols such as memcpy() and
		strlen() work fine, though.)
		More dyntrans refactoring; taking out more of the things that
		are common to all cpu families.
20050810	Working on adding support for "dual mode" for PPC dyntrans
		(i.e. both 64-bit and 32-bit modes).
		(Re)adding some simple PPC instructions.
20050811	Adding a dummy M68K cpu family. The dyntrans system isn't ready
		for variable-length ISAs yet, so it's completely bogus so far.
		Re-adding more PPC instructions.
		Adding a hack to src/file.c which allows OpenBSD/mac68k a.out
		kernels to be loaded.
		Beginning to add PPC loads/stores. So far they only work in
		32-bit mode.
20050812	The configure file option "add_remote" now accepts symbolic
		host names, in addition to numeric IPv4 addresses.
		Re-adding more PPC instructions.
20050814	Continuing to port back more PPC instructions.
		Found and fixed the cache/device write-update bug for 32-bit
		MIPS bintrans. :-)
		Triggered a really weird and annoying bug in Compaq's C
		compiler; ccc sometimes outputs code which loads from an
		address _before_ checking whether the pointer was NULL or not.
		(I'm not sure how to handle this problem.)
20050815	Removing all of the old x86 instruction execution code; adding
		a new (dummy) dyntrans module for x86.
		Taking the first steps to extend the dyntrans system to support
		variable-length instructions.
		Slowly preparing for the next release.
20050816	Adding a dummy SPARC cpu module.
		Minor updates (documentation etc) for the release.

==============  RELEASE 0.3.5  ==============


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.50 2005/08/16 05:15:24 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="#largeimages">How to extract large gzipped disk images</a>
56 <li><a href="#userland">Running userland binaries</a>
57 <li><a href="#promdump">Using a PROM dump from a real machine</a>
58 </ul>
59
60
61
62
63
64
65
66 <p><br>
67 <a name="networking"></a>
68 <h3>Networking:</h3>
69
70 It is possible to let the guest OS running inside the emulator get access to
71 the Internet. If you are interested in the technical details, and the
72 reasons why networking is implemented in the emulator the way it currently
73 is implemented, you might want to read the <a href="technical.html#net">
74 networking section in the technical documentation</a>.
75 <p>
76 The guest OS running inside the emulator uses a private IPv4 address, such
77 as 10.0.0.1, and the emulator acts as a NAT-like gateway/firewall at IPv4
78 address 10.0.0.254. To the outside world it will seem like it is the host's
79 OS that connects to other machines on the internet, not the guest OS.
80 <p>
81 <font color="#ff0000">NOTE: This is still experimental!
82 As of 2004-07-21, ARP + ICMP + UDP + TCP are emulated well enough to let
83 NetBSD and OpenBSD install via ftp, and use the network for many normal
84 activities, but not everything works yet.</font>
85
86
87
88
89
90
91 <p><br>
92 <a name="devel"></a>
93 <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
94
95 Is this a good idea? The answer is yes and no, depending on the level of
96 detail you need in your simulations. If you are developing an operating
97 system or operating system kernel of your own, and wish to target
98 MIPS-like systems in general, then the answer might be yes, for
99 experimental purposes.
100
101 <p>Some examples of things that <i>don't</i> work, that you should keep in
102 mind:
103
104 <ul>
105 <li>Porting code to a specific machine mode, e.g. a Silicon Graphics
106 machine, using GXemul, will not necessarily cause the code to
107 work on a real machine. Sometimes code works in GXemul which doesn't
108 work on real hardware, sometimes it's the other way around.
109
110 <p>
111 <li>GXemul contains bugs, and many things are not yet implemented.
112
113 <p>
114 <li>I have only implemented devices in GXemul to the degree that
115 NetBSD, OpenBSD, etc, don't complain too much. One way to say it
116 is that the device implementations are "lazy hacks", based on the
117 assumption that the emulated OS is already developed and bug-free.
118 They are not intended to be used for development of new OS code,
119 so if you do that, then be prepared for bugs and inconsitencies.
120
121 <p>
122 <li>CPU details in GXemul are usually wrong. If your code depends
123 on, say, R10000 or MIPS64 specifics, chances are that GXemul will
124 not be sufficient. Again, this was done as "lazy hacks", and pretty
125 much assumes that the OS being emulated is already developed
126 and bug-free.
127
128 <p>
129 <li>Caches. There is no cache emulation in GXemul right now. Caches
130 for R2000/R3000 are faked well enough to run NetBSD, Ultrix, etc
131 in the DECstation emulation mode, but other than that, cache
132 operations are treated as nops.
133 </ul>
134
135 <p>The bottom line is that GXemul can be useful as yet another way to test
136 your code during development, but it should not be fully relied on.
137
138
139
140
141
142
143 <p><br>
144 <a name="compilercontruct"></a>
145 <h3>Using GXemul in compiler contruction courses:</h3>
146
147 If you are learning how to write a compiler, and wish to target a
148 realistic target platform, then MIPS (as emulated by GXemul)
149 might be a suitable choice.
150
151 <ul>
152 <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
153 language code, which the assembler (eg gas, the GNU assembler) can
154 then compile into object format, and then you need to link this
155 into an executable image. This is much closer to how things work
156 in real life than running assembly language listings in a simulator
157 (eg SPIM).
158 <p>
159 <li><b>(-)</b>&nbsp;&nbsp;GXemul does not simulate out-of-order
160 execution, penalties related to instruction scheduling, or
161 load-delays, so it cannot be used to create optimizing compilers
162 that take advantage of such processor features. GXemul keeps
163 track of the number of instructions executed, but that's it.
164 </ul>
165
166
167
168
169
170
171 <p><br>
172 <a name="disk"></a>
173 <h3>How to start the emulator with a disk image:</h3>
174
175 Add <i>-d [prefixes:]diskimagefilename</i> to the command line, where prefixes
176 are one or more single-character options. Run <b>gxemul -h</b>
177 to get a list of possible options.
178
179 <p>
180 Here are some examples. If you want to run a NetBSD/pmax kernel on an
181 emulated DECstation machine, you would use a command line such as this:
182 <pre>
183 $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
184 </pre>
185 <p>
186 NOTE: For some emulation modes, such as the DECstation mode, you do
187 <i>not</i> have to specify the name of the kernel, if the disk image is
188 bootable!
189 <p>
190 It is possible to have more than one disk. For each -d argument, a disk
191 image is added; the first will be SCSI target 0, the second will be target 1, and so on,
192 unless you specify explicitly which ID number the devices should have.
193 <pre>
194 $ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
195 </pre>
196 Note: In the example above, disk2.raw will get scsi id 5.
197 <p>
198 If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be
199 a CDROM device (this can be overridden with a 'd' prefix, to force a read/write disk).
200 For example, the following command would start the emulator with two
201 CDROM images, and one harddisk image:
202 <pre>
203 $ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
204 </pre>
205 Usually, the device with the lowest id becomes the boot device. To override
206 this, add a 'b' prefix to one of the devices:
207 <pre>
208 $ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
209 </pre>
210 If you have a physical CD-ROM drive on the host machine, say /dev/cd0c, you can
211 use it as a CD-ROM directly accessible from within the emulator:
212 <pre>
213 $ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
214 </pre>
215 It is probably possible to use harddisks as well this way, but I would not
216 recommend it.
217 <p>
218 Using emulated tape drives is a bit more complicated than disks, because a
219 tape can be made up of several "files" with space in between. The solution
220 I have choosen is to have one file in the host's file system space for each
221 tape file. The prefix for using tapes is 't', and the filename given is
222 for the <i>first</i> file on that tape (number zero, implicitly). For
223 files following file nr 0, a dot and the filenumber is appended to the
224 filename.
225 <p>
226 As an example, starting the emulator with
227 <pre>
228 <b>-d t4:mytape.img</b>
229 </pre>
230 will cause SCSI id 4 to be a tape device, using the following file number
231 to name translation scheme:
232 <p>
233 <center>
234 <table border="0">
235 <tr>
236 <td><b>File number:</b></td>
237 <td><b>File name in the host's filesystem:</b></td>
238 </tr>
239 <tr>
240 <td align="center">0</td>
241 <td align="left">mytape.img</td>
242 </tr>
243 <tr>
244 <td align="center">1</td>
245 <td align="left">mytape.img.1</td>
246 </tr>
247 <tr>
248 <td align="center">2</td>
249 <td align="left">mytape.img.2</td>
250 </tr>
251 <tr>
252 <td align="center">..</td>
253 <td align="left">..</td>
254 </tr>
255 </table>
256 </center>
257 <p>
258 If you already have a number of tape files, which should be placed on the
259 same emulated tape, then you might not want to rename all those files.
260 Use symbolic links instead (ln -s).
261 <p>
262 There is another advantage to using symbolic links for tape filenames:
263 every time a tape is rewound, it is reopened using the filename given
264 on the command line. By changing what the symbolic name points to,
265 you can "switch tapes" without quiting and restarting the emulator.
266
267
268
269 <p><br>
270 <a name="largeimages"></a>
271 <h3>How to extract large gzipped disk images:</h3>
272
273 Unix filesystems usually support large files with "holes". Holes are
274 zero-filled blocks that don't actually exist on disk. This is very
275 practical for emulated disk images, as it is possible to create a very
276 large disk image without using up much space at all.
277
278 <p>
279 Using gzip and gunzip on disk images can be <i>very</i> slow, as these
280 files can be multiple gigabytes large, but this is usually necessary for
281 transfering disk images over the internet. If you receive a gzipped disk
282 image, say disk.img.gz, and run a naive
283 <p>
284 <pre>
285 $ <b>gunzip disk.img.gz</b>
286 </pre>
287 <p>
288 on it, you will not end up with an optimized file unless
289 gunzip supports that. (In my experiments, it doesn't.) In plain English,
290 if you type <b>ls -l</b> and the filesize is 9 GB, it will actually occupy
291 9 GB of disk space! This is often unacceptable.
292 <p>
293 Using a simple tool which only writes blocks that are non-zero, a lot of
294 space can be saved. Compile the program cp_removeblocks in the
295 experiments/ directory, and type:
296 <p>
297 <pre>
298 $ <b>gunzip -c disk.img.gz | cp_removeblocks /dev/stdin disk.img</b>
299 </pre>
300
301 <p>
302 This will give you a disk.img which looks like it is 9 GB, and works like
303 the real file, but the holes are not written out to the disk. (You can see
304 this by running for example <b>du disk.img</b> to see the physical block
305 count.)
306
307
308
309 <p><br>
310 <a name="userland"></a>
311 <h3>Running userland binaries:</h3>
312
313 <font color="#ff0000">Note: This does not really work yet.</font>
314
315 <p>There is some skeleton code for running userland programs as well. This
316 will not emulate any particular machine, but instead try to translate
317 syscalls from e.g. NetBSD/pmax into the host's OS' syscalls. Right now,
318 this is just a proof-of-concept, to show that it could work; there's lots
319 of work left to do to make it actually run useful programs.
320
321 <p>
322
323 <ul>
324 <li><b>NetBSD/pmax:</b>
325 <br>
326 Running /bin/hostname or /bin/date and similarly trivial
327 programs from the NetBSD/pmax distribution works:<pre>
328 $ <b>gxemul -q -u netbsd/pmax pmax_bin_hostname</b>
329 tab.csbnet.se
330 $ <b>gxemul -q -u netbsd/pmax pmax_bin_date</b>
331 Sun Jan 25 02:26:14 GMT 2004
332 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep</b>
333 usage: pmax_bin_sleep seconds
334 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sleep 5</b>
335 $ <b>gxemul -q -u netbsd/pmax pmax_bin_sync</b>
336 </pre>
337
338 <p>
339 <li><b>Ultrix:</b>
340 <br>
341 At least /bin/date and /bin/hostname work:<pre>
342 $ <b>gxemul -q -u ultrix ultrix4_bin_date</b>
343 UNIMPLEMENTED ultrix syscall 54
344 UNIMPLEMENTED ultrix syscall 62
345 Mon Feb 9 12:50:59 WET 2004
346 $ <b>gxemul -q -u ultrix ultrix4_bin_hostname</b>
347 tab.csbnet.se
348 </pre>
349
350 <!--
351 <p>
352 <li><b>NetBSD/powerpc:</b>
353 <br>
354 /bin/sync from NetBSD/macppc works, but probably not much else.<pre>
355 $ <b>gxemul -v -u netbsd/powerpc netbsd-1.6.2-macppc-bin-sync</b>
356 ...
357 [ sync() ]
358 [ exit(0) ]
359 cpu_run_deinit(): All CPUs halted.
360
361 </pre>
362
363 <p>
364 <li><b>Linux/PPC64:</b>
365 <br>
366 The <a href="http://www-106.ibm.com/developerworks/library/l-ppc/#h13">64-bit Hello World assembly language example</a>
367 on IBM's developerWorks pages runs:<pre>
368 $ <b>ppc64-unknown-linux-as hello-ppc64.s -o hello-ppc64.o</b>
369 $ <b>ppc64-unknown-linux-ld hello-ppc64.o -o hello-ppc64</b>
370 $ <b>gxemul -q -u linux/ppc64 hello-ppc64</b>
371 Hello, world!
372
373 </pre>
374 -->
375
376 </ul>
377
378
379
380
381
382 <p><br>
383 <a name="promdump"></a>
384 <h3>Using a PROM dump from a real machine:</h3>
385
386 Raw PROM images from real machines can, in a few cases, be used in
387 the emulator. ROM code is usually much more sensitive to correctness
388 of the emulator than operating system kernels or userland programs
389 are, so don't expect any PROM image to just magically work.
390
391
392 <p>
393 <h4>Dumping the PROM on a DECstation 5000/125:</h4>
394 The image first needs to be extracted from the machine. There are
395 several ways to do this.
396 <ul>
397 <li>Use hardware to read the PROM chip(s) directly. Not easy if you
398 don't have such a hardware reader.
399 <li>Copy the PROM memory range into a file, from a running
400 operating system. You need a running OS, and it must
401 have access to the PROM memory range. NetBSD, for example,
402 doesn't allow that from userland.
403 <li>Hook up a serial console and dump using the PROM's own dump
404 command.
405 </ul>
406 <p>
407 The easiest way is to hook up a serial console. The terminal must be
408 able to capture output to a file.
409 <p>
410 These are approximately the commands that I used:
411 <pre>
412 >><b>cnfg</b> <i>Show machine configuration</i>
413
414 >><b>printenv</b> <i>Show environment variables</i>
415
416 >><b>setenv more 0</b> <i>This turns off the More messages</i>
417
418 >><b>e -x 0xbfc00000:0xbfffffff</b> <i>Dump the PROM data</i>
419 </pre>
420 <p>
421 Remember that DECstations are little endian, so if the dump data
422 looks like this:
423 <pre>
424 bfc00000: 0x0bf0007e
425 </pre>
426 then the bytes in memory are actually 0x7e, 0x00, 0xf0, and 0x0b.
427 <p>
428 At 9600 bps, about 10KB can be dumped per minute, so it takes a while.
429 Once enough of the PROM has been dumped, you can press CTRL-C to break out.
430 Then, restore the more environment variable:
431 <pre>
432 >><b>setenv more 24</b>
433 </pre>
434 <p>
435 Now, convert the data you just saved (little-endian words -> bytes),
436 and store in a file. Let's call this file DECstation5000_125_promdump.bin.
437 <pre>
438 $ <b>decprom_dump_txt_to_bin DECstation5000_125_promdump.txt DECstation5000_125_promdump.bin</b>
439 </pre>
440 This binary image can now be used in the emulator:
441 <pre>
442 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
443
444 KN02-BA V5.7e
445 ?TFL: 3/scc/access (1:Ln1 reg-12: actual=0x00 xpctd=0x01) [KN02-BA]
446 ?TFL: 3/scc/io (1:Ln0 tx bfr not empty. status=0X 0) [KN02-BA]
447 ...
448 --More--?TFL: 3/scsi/cntl (CUX, cause= 1000002C)
449 >><b>?</b>
450 ? [cmd]
451 boot [[-z #] [-n] #/path [ARG...]]
452 cat SCRPT
453 cnfg [#]
454 d [-bhw] [-S #] RNG VAL
455 e [-bhwcdoux] [-S #] RNG
456 erl [-c]
457 go [ADR]
458 init [#] [-m] [ARG...]
459 ls [#]
460 passwd [-c] [-s]
461 printenv [EVN]
462 restart
463 script SCRPT
464 setenv EVN STR
465 sh [-belvS] [SCRPT] [ARG..]
466 t [-l] #/STR [ARG..]
467 unsetenv EVN
468 >><b>cnfg</b>
469 3: KN02-BA DEC V5.7e TCF0 (128 MB)
470 (enet: 00-00-00-00-00-00)
471 (SCSI = 7)
472 0: PMAG-BA DEC V5.3a TCF0
473 >><b>printenv</b>
474 boot=
475 testaction=q
476 haltaction=h
477 more=24
478 #=3
479 console=*
480 osconsole=3
481 >>
482 </pre>
483 <i>(Note: at the moment, this doesn't work. I must have broken something when
484 fixing something else, but this is what it looked like at the time.)</i>
485 <p>
486 During bootup, the PROM complains <i>a lot</i> about hardware failures.
487 That's because the emulator doesn't emulate the hardware well enough yet.
488 <p>
489 The command line options used are: -e 3min for
490 "DECstation 3min" (5000/1xx), -Q to supress the emulator's own PROM
491 call emulation, -M128 for 128MB RAM (because GXemul doesn't correctly
492 emulate memory detection well enough for the PROM to accept, so it will
493 always believe there is 128MB ram anyway), and -q to supress debug messages.
494 The 0xbfc00000 in front of the filename tells GXemul that it is a raw
495 binary file which should be loaded at a specific virtual address.
496
497
498 <p><br>
499 <h4>Dumping the PROM on a SGI O2:</h4>
500
501 The general ideas in this section applies to using ROM images from other
502 machines as well. Besides DECstation, I've also tried this on an SGI IP32
503 ("O2").
504 <p>
505 For the O2, a suitable command to dump the prom memory range is
506 <pre>
507 &gt;&gt; <b>dump -b 0xBFC00000:0xBFC80000</b>
508 </pre>
509 Make sure you capture all the output (via serial console) into a file,
510 and then run experiments/sgiprom_to_bin on the captured file.
511 <p>
512 (2005-01-16: The emulator doesn't really emulate the IP32 well enough to
513 actually run the PROM image without using special hacks, but it might do
514 so some time in the future.)
515
516
517
518
519
520 </p>
521
522 </body>
523 </html>

  ViewVC Help
Powered by ViewVC 1.1.26