/[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 32 - (show annotations)
Mon Oct 8 16:20:58 2007 UTC (16 years, 5 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 <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:</b></font><br>
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.65 2006/10/19 10:15:23 debug Exp $
14
15 Copyright (C) 2003-2006 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="#devel">Writing operating system code, or
51 developing firmware, using GXemul</a>
52 <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 <li><a href="#filexfer">Transfering files to/from the guest OS</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
67
68 <p><br>
69 <a name="devel"></a>
70 <h3>Writing operating system code, or developing firmware, using GXemul:</h3>
71
72 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 system or operating system kernel of your own, then the emulator can be a
75 complement to testing on real hardware.
76
77 <p>Important things to keep in mind:
78
79 <ul>
80 <li>Porting code to a specific machine mode, e.g. a Silicon Graphics
81 machine, using GXemul, will not "magically" cause the code to
82 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
85 <p>
86 <li>GXemul contains bugs, and many things are not yet implemented.
87
88 <p>
89 <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 <p>
92 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 <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 not be sufficient. One example is different revisions of ISAs;
106 some instructions which should trigger an exception on a
107 real MIPS processor usually execute anyway in GXemul. Another
108 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 <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
118 <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
121
122
123
124
125
126 <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 realistic target platform, then MIPS or ARM (as emulated by GXemul)
132 might be suitable choices.
133
134 <ul>
135 <li><b>(+)</b>&nbsp;&nbsp;Your compiler needs to output real assembly
136 language code, which the assembler (e.g. gas, the GNU assembler) can
137 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 (e.g. SPIM).
141 <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 $ <b>gxemul -e 3max -d pmax_diskimage.fs netbsd-pmax-INSTALL</b>
167 </pre>
168
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 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 $ <b>gxemul -e 3max -d disk0.raw -d disk1.raw -d 5:disk2.raw netbsd-pmax-INSTALL</b>
178 </pre>
179 Note: In the example above, disk2.raw will get scsi id 5.
180
181 <p>If a filename has a 'c' prefix, or ends with ".iso", then it is assumed to be
182 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 $ <b>gxemul -e 3max -d image.iso -d disk0.img -d c:second_cdrom.img netbsd-pmax-INSTALL</b>
187 </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 $ <b>gxemul -e 3max -d rootdisk.img -d bc:install-cd.iso name_of_kernel</b>
192 </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 $ <b>gxemul -e 3max -d rootdisk.img -d bc:/dev/cd0c name_of_kernel</b>
197 </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
253
254
255 <p><br>
256 <a name="filexfer"></a>
257 <h3>Transfering files to/from the guest OS:</h3>
258
259 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
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 <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 <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
346 <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 <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 <!--
382 <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 -->
406
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 $ <b>gxemul -e 3min -Q -M128 -q 0xbfc00000:DECstation5000_125_promdump.bin</b>
474
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
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 That's because the emulator doesn't emulate the hardware well enough yet.
521
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 emulate memory detection well enough for the PROM to accept, so it will
526 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 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 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 <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 and then run <tt>experiments/sgiprom_to_bin</tt> on the captured file.
544
545 <p>
546 &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
553 <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
557 <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
563 <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
567 <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
571 <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 reverse-engineering of my own, I've implemented enough of the controller to
580 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 </p>
587
588 </body>
589 </html>

  ViewVC Help
Powered by ViewVC 1.1.26