/[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 32 - (hide annotations)
Mon Oct 8 16:20:58 2007 UTC (12 years, 9 months ago) by dpavlin
File MIME type: text/html
File size: 21062 byte(s)
++ trunk/HISTORY	(local)
$Id: HISTORY,v 1.1421 2006/11/06 05:32:37 debug Exp $
20060816	Adding a framework for emulated/virtual timers (src/timer.c),
		using only setitimer().
		Rewriting the mc146818 to use the new timer framework.
20060817	Adding a call to gettimeofday() every now and then (once every
		second, at the moment) to resynch the timer if it drifts.
		Beginning to convert the ISA timer interrupt mechanism (8253
		and 8259) to use the new timer framework.
		Removing the -I command line option.
20060819	Adding the -I command line option again, with new semantics.
		Working on Footbridge timer interrupts; NetBSD/NetWinder and
		NetBSD/CATS now run at correct speed, but unfortunately with
		HUGE delays during bootup.
20060821	Some minor m68k updates. Adding the first instruction: nop. :)
		Minor Alpha emulation updates.
20060822	Adding a FreeBSD development specific YAMON environment
		variable ("khz") (as suggested by Bruce M. Simpson).
		Moving YAMON environment variable initialization from
		machine_evbmips.c into promemul/yamon.c, and adding some more
		variables.
		Continuing on the LCA PCI bus controller (for Alpha machines).
20060823	Continuing on the timer stuff: experimenting with MIPS count/
		compare interrupts connected to the timer framework.
20060825	Adding bogus SCSI commands 0x51 (SCSICDROM_READ_DISCINFO) and
		0x52 (SCSICDROM_READ_TRACKINFO) to the SCSI emulation layer,
		to allow NetBSD/pmax 4.0_BETA to be installed from CDROM.
		Minor updates to the LCA PCI controller.
20060827	Implementing a CHIP8 cpu mode, and a corresponding CHIP8
		machine, for fun. Disassembly support for all instructions,
		and most of the common instructions have been implemented: mvi,
		mov_imm, add_imm, jmp, rand, cls, sprite, skeq_imm, jsr,
		skne_imm, bcd, rts, ldr, str, mov, or, and, xor, add, sub,
		font, ssound, sdelay, gdelay, bogus skup/skpr, skeq, skne.
20060828	Beginning to convert the CHIP8 cpu in the CHIP8 machine to a
		(more correct) RCA 180x cpu. (Disassembly for all 1802
		instructions has been implemented, but no execution yet, and
		no 1805 extended instructions.)
20060829	Minor Alpha emulation updates.
20060830	Beginning to experiment a little with PCI IDE for SGI O2.
		Fixing the cursor key mappings for MobilePro 770 emulation.
		Fixing the LK201 warning caused by recent NetBSD/pmax.
		The MIPS R41xx standby, suspend, and hibernate instructions now
		behave like the RM52xx/MIPS32/MIPS64 wait instruction.
		Fixing dev_wdc so it calculates correct (64-bit) offsets before
		giving them to diskimage_access().
20060831	Continuing on Alpha emulation (OSF1 PALcode).
20060901	Minor Alpha updates; beginning on virtual memory pagetables.
		Removed the limit for max nr of devices (in preparation for
		allowing devices' base addresses to be changed during runtime).
		Adding a hack for MIPS [d]mfc0 select 0 (except the count
		register), so that the coproc register is simply copied.
		The MIPS suspend instruction now exits the emulator, instead
		of being treated as a wait instruction (this causes NetBSD/
		hpcmips to get correct 'halt' behavior).
		The VR41xx RTC now returns correct time.
		Connecting the VR41xx timer to the timer framework (fixed at
		128 Hz, for now).
		Continuing on SPARC emulation, adding more instructions:
		restore, ba_xcc, ble. The rectangle drawing demo works :)
		Removing the last traces of the old ENABLE_CACHE_EMULATION
		MIPS stuff (not usable with dyntrans anyway).
20060902	Splitting up src/net.c into several smaller files in its own
		subdirectory (src/net/).
20060903	Cleanup of the files in src/net/, to make them less ugly.
20060904	Continuing on the 'settings' subsystem.
		Minor progress on the SPARC emulation mode.
20060905	Cleanup of various things, and connecting the settings
		infrastructure to various subsystems (emul, machine, cpu, etc).
		Changing the lk201 mouse update routine to not rely on any
		emulated hardware framebuffer cursor coordinates, but instead
		always do (semi-usable) relative movements.
20060906	Continuing on the lk201 mouse stuff. Mouse behaviour with
		multiple framebuffers (which was working in Ultrix) is now
		semi-broken (but it still works, in a way).
		Moving the documentation about networking into its own file
		(networking.html), and refreshing it a bit. Adding an example
		of how to use ethernet frame direct-access (udp_snoop).
20060907	Continuing on the settings infrastructure.
20060908	Minor updates to SH emulation: for 32-bit emulation: delay
		slots and the 'jsr @Rn' instruction. I'm putting 64-bit SH5 on
		ice, for now.
20060909-10	Implementing some more 32-bit SH instructions. Removing the
		64-bit mode completely. Enough has now been implemented to run
		the rectangle drawing demo. :-)
20060912	Adding more SH instructions.
20060916	Continuing on SH emulation (some more instructions: div0u,
		div1, rotcl/rotcr, more mov instructions, dt, braf, sets, sett,
		tst_imm, dmuls.l, subc, ldc_rm_vbr, movt, clrt, clrs, clrmac).
		Continuing on the settings subsystem (beginning on reading/
		writing settings, removing bugs, and connecting more cpus to
		the framework).
20060919	More work on SH emulation; adding an ldc banked instruction,
		and attaching a 640x480 framebuffer to the Dreamcast machine
		mode (NetBSD/dreamcast prints the NetBSD copyright banner :-),
		and then panics).
20060920	Continuing on the settings subsystem.
20060921	Fixing the Footbridge timer stuff so that NetBSD/cats and
		NetBSD/netwinder boot up without the delays.
20060922	Temporarily hardcoding MIPS timer interrupt to 100 Hz. With
		'wait' support disabled, NetBSD/malta and Linux/malta run at
		correct speed.
20060923	Connecting dev_gt to the timer framework, so that NetBSD/cobalt
		runs at correct speed.
		Moving SH4-specific memory mapped registers into its own
		device (dev_sh4.c).
		Running with -N now prints "idling" instead of bogus nr of
		instrs/second (which isn't valid anyway) while idling.
20060924	Algor emulation should now run at correct speed.
		Adding disassembly support for some MIPS64 revision 2
		instructions: ext, dext, dextm, dextu.
20060926	The timer framework now works also when the MIPS wait
		instruction is used.
20060928	Re-implementing checks for coprocessor availability for MIPS
		cop0 instructions. (Thanks to Carl van Schaik for noticing the
		lack of cop0 availability checks.)
20060929	Implementing an instruction combination hack which treats
		NetBSD/pmax' idle loop as a wait-like instruction.
20060930	The ENTRYHI_R_MASK was missing in (at least) memory_mips_v2p.c,
		causing TLB lookups to sometimes succeed when they should have
		failed. (A big thank you to Juli Mallett for noticing the
		problem.)
		Adding disassembly support for more MIPS64 revision 2 opcodes
		(seb, seh, wsbh, jalr.hb, jr.hb, synci, ins, dins, dinsu,
		dinsm, dsbh, dshd, ror, dror, rorv, drorv, dror32). Also
		implementing seb, seh, dsbh, dshd, and wsbh.
		Implementing an instruction combination hack for Linux/pmax'
		idle loop, similar to the NetBSD/pmax case.
20061001	Changing the NetBSD/sgimips install instructions to extract
		files from an iso image, instead of downloading them via ftp.
20061002	More-than-31-bit userland addresses in memory_mips_v2p.c were
		not actually working; applying a fix from Carl van Schaik to
		enable them to work + making some other updates (adding kuseg
		support).
		Fixing hpcmips (vr41xx) timer initialization.
		Experimenting with O(n)->O(1) reduction in the MIPS TLB lookup
		loop. Seems to work both for R3000 and non-R3000.
20061003	Continuing a little on SH emulation (adding more control
		registers; mini-cleanup of memory_sh.c).
20061004	Beginning on a dev_rtc, a clock/timer device for the test
		machines; also adding a demo, and some documentation.
		Fixing a bug in SH "mov.w @(disp,pc),Rn" (the result wasn't
		sign-extended), and adding the addc and ldtlb instructions.
20061005	Contining on SH emulation: virtual to physical address
		translation, and a skeleton exception mechanism.
20061006	Adding more SH instructions (various loads and stores, rte,
		negc, muls.w, various privileged register-move instructions).
20061007	More SH instructions: various move instructions, trapa, div0s,
		float, fdiv, ftrc.
		Continuing on dev_rtc; removing the rtc demo.
20061008	Adding a dummy Dreamcast PROM module. (Homebrew Dreamcast
		programs using KOS libs need this.)
		Adding more SH instructions: "stc vbr,rn", rotl, rotr, fsca,
		fmul, fadd, various floating-point moves, etc. A 256-byte
		demo for Dreamcast runs :-)
20061012	Adding the SH "lds Rm,pr" and bsr instructions.
20061013	More SH instructions: "sts fpscr,rn", tas.b, and some more
		floating point instructions, cmp/str, and more moves.
		Adding a dummy dev_pvr (Dreamcast graphics controller).
20061014	Generalizing the expression evaluator (used in the built-in
		debugger) to support parentheses and +-*/%^&|.
20061015	Removing the experimental tlb index hint code in
		mips_memory_v2p.c, since it didn't really have any effect.
20061017	Minor SH updates; adding the "sts pr,Rn", fcmp/gt, fneg,
		frchg, and some other instructions. Fixing missing sign-
		extension in an 8-bit load instruction.
20061019	Adding a simple dev_dreamcast_rtc.
		Implementing memory-mapped access to the SH ITLB/UTLB arrays.
20061021	Continuing on various SH and Dreamcast things: sh4 timers,
		debug messages for dev_pvr, fixing some virtual address
		translation bugs, adding the bsrf instruction.
		The NetBSD/dreamcast GENERIC_MD kernel now reaches userland :)
		Adding a dummy dev_dreamcast_asic.c (not really useful yet).
		Implementing simple support for Store Queues.
		Beginning on the PVR Tile Accelerator.
20061022	Generalizing the PVR framebuffer to support off-screen drawing,
		multiple bit-depths, etc. (A small speed penalty, but most
		likely worth it.)
		Adding more SH instructions (mulu.w, fcmp/eq, fsub, fmac,
		fschg, and some more); correcting bugs in "fsca" and "float".
20061024	Adding the SH ftrv (matrix * vector) instruction. Marcus
		Comstedt's "tatest" example runs :) (wireframe only).
		Correcting disassembly for SH floating point instructions that
		use the xd* registers.
		Adding the SH fsts instruction.
		In memory_device_dyntrans_access(), only the currently used
		range is now invalidated, and not the entire device range.
20061025	Adding a dummy AVR32 cpu mode skeleton.
20061026	Various Dreamcast updates; beginning on a Maple bus controller.
20061027	Continuing on the Maple bus. A bogus Controller, Keyboard, and
		Mouse can now be detected by NetBSD and KOS homebrew programs.
		Cleaning up the SH4 Timer Management Unit, and beginning on
		SH4 interrupts.
		Implementing the Dreamcast SYSASIC.
20061028	Continuing on the SYSASIC.
		Adding the SH fsqrt instruction.
		memory_sh.c now actually scans the ITLB.
		Fixing a bug in dev_sh4.c, related to associative writes into
		the memory-mapped UTLB array. NetBSD/dreamcast now reaches
		userland stably, and prints the "Terminal type?" message :-]
		Implementing enough of the Dreamcast keyboard to make NetBSD
		accept it for input.
		Enabling SuperH for stable (non-development) builds.
		Adding NetBSD/dreamcast to the documentation, although it
		doesn't support root-on-nfs yet.
20061029	Changing usleep(1) calls in the debugger to to usleep(10000)
		(according to Brian Foley, this makes GXemul run better on
		MacOS X).
		Making the Maple "Controller" do something (enough to barely
		interact with dcircus.elf).
20061030-31	Some progress on the PVR. More test programs start running (but
		with strange output).
		Various other SH4-related updates.
20061102	Various Dreamcast and SH4 updates; more KOS demos run now.
20061104	Adding a skeleton dev_mb8696x.c (the Dreamcast's LAN adapter).
20061105	Continuing on the MB8696x; NetBSD/dreamcast detects it as mbe0.
		Testing for the release.

==============  RELEASE 0.4.3  ==============


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

  ViewVC Help
Powered by ViewVC 1.1.26