/[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

Annotation of /trunk/doc/misc.html

Parent Directory Parent Directory | Revision Log Revision Log


Revision 12 - (hide 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 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 12 <b>Gavare's eXperimental Emulator:&nbsp;&nbsp;&nbsp;</b></font>
8     <font color="#000000" size="6"><b>Miscellaneous</b>
9 dpavlin 4 </font></td></tr></table></td></tr></table><p>
10 dpavlin 2
11     <!--
12    
13 dpavlin 12 $Id: misc.html,v 1.50 2005/08/16 05:15:24 debug Exp $
14 dpavlin 2
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 dpavlin 12
43 dpavlin 2 <a href="./">Back to the index</a>
44    
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     <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 dpavlin 12 <a name="devel"></a>
93     <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
94 dpavlin 2
95 dpavlin 12 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 dpavlin 2
101 dpavlin 12 <p>Some examples of things that <i>don't</i> work, that you should keep in
102     mind:
103 dpavlin 2
104 dpavlin 12 <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 dpavlin 2
110 dpavlin 12 <p>
111     <li>GXemul contains bugs, and many things are not yet implemented.
112 dpavlin 2
113 dpavlin 12 <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 dpavlin 2
121 dpavlin 12 <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 dpavlin 2
128 dpavlin 12 <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 dpavlin 2
135 dpavlin 12 <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 dpavlin 2
138    
139 dpavlin 12
140    
141    
142    
143 dpavlin 2 <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 dpavlin 12 $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
184 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
195 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
204 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
209 dpavlin 2 </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 dpavlin 12 $ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
214 dpavlin 2 </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 dpavlin 12 <font color="#ff0000">Note: This does not really work yet.</font>
314 dpavlin 2
315 dpavlin 12 <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 dpavlin 2 <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 dpavlin 12 <!--
351 dpavlin 2 <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 dpavlin 12 -->
375 dpavlin 2
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 dpavlin 12 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
443 dpavlin 2
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 dpavlin 12 The command line options used are: -e 3min for
490     "DECstation 3min" (5000/1xx), -Q to supress the emulator's own PROM
491 dpavlin 2 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