bochsrc.5

来自「bochs : one pc simulator.」· 5 代码 · 共 834 行 · 第 1/2 页

.I "error:"
Bochs produces an error message when it  finds
a condition that really shouldn't happen,  but
doesn't endanger the simulation. An example of
an error  might be  if the  emulated  software
produces an illegal disk command.

The "error" setting tells Bochs how to respond
to an error condition.   You can set  this  to
fatal  (terminate the session),  report (print
information to the  console),  or  ignore  (do
nothing).

Example:
  error: action=report

.TP
.I "info:"
This setting tells Bochs what to  do  when  an
event  occurs   that  generates  informational
messages.  You can  set this  to  fatal  (that
would not be very smart though), report (print
information to the  console),  or  ignore  (do
nothing).   For  general  usage,  the "report"
option is probably a good choice.

Example:
  info: action=report

.TP
.I "debug:"
This  setting  tells  Bochs what  to  do  with
messages intended to assist in debugging.  You
can set  this  to  fatal  (but you shouldn't),
report (print information to the  console), or
ignore (do nothing). You should generally  set
this  to  ignore,  unless  you are  trying  to
diagnose a particular problem.

.B NOTE: 
When  action=report,   Bochs   may  spit  out
thousands of debug messages per second, which
can impact performance and fill up your disk.

Example:
  debug: action=ignore

.TP
.I "debugger_log:"
Give the path of the log file you'd like Bochs to log debugger output.
If you really don't want it, make it '/dev/null', or '-'.

Example:
  log: debugger.out
  log: /dev/null              (unix only)
  log: -

.TP
.I "sb16:"
This  defines the SB16 sound emulation. It can
have several of the  following properties. All
properties are in this format:
  sb16: property=value


.B PROPERTIES FOR sb16:

midi:

The  filename is where the midi data is  sent.
This can  be  a device  or just a file if  you
want to record the midi data.

midimode:

 0 = No data should be output.
 1 = output to device (system dependent - midi
 denotes the device driver).
 2 = SMF file output, including headers.
 3 = Output  the midi  data stream to the file
 (no  midi headers  and  no delta  times, just
 command and data bytes).

wave:

This  is the device/file where wave  output is
stored.

wavemode:

 0 = no data
 1 = output to device (system dependent - wave
 denotes the device driver).
 2 = VOC file output, including headers.
 3 = Output the raw wave stream to the file.

log:

The file to write the sb16 emulator messages to.

loglevel:

 0 = No log.
 1 = Resource changes, midi program and bank changes.
 2 = Severe errors.
 3 = All errors.
 4 = All errors plus all port accesses.
 5 = All  errors and port  accesses plus a lot
 of extra information.

It is possible to change the loglevel at runtime.

dmatimer:

Microseconds per second for a DMA cycle.  Make it smaller
to fix non-continuous sound.  750000 is  usually  a  good
value.  This  needs  a reasonably  correct   setting  for
the  IPS  parameter of the CPU option.  It is possible to
adjust the dmatimer at runtime.

Example:
  sb16: midimode=1, midi=/dev/midi00,
  wavemode=1, wave=/dev/dsp, loglevel=2,
  log=sb16.log, dmatimer=600000

.B NOTE:
The  example is  wrapped onto three  lines for
formatting  reasons, but  it should all be  on
one line in the actual bochsrc file.

.TP
.I "vga_update_interval:"
Video memory is scanned for updates and screen updated
every so many virtual seconds. The default value is
40000, about 25Hz. Keep in mind that you  must tweak
the 'cpu: ips=N' directive to be as close  to the number of
emulated instructions-per-second your  workstation can
do, for this to be accurate.

Example:
  vga_update_interval: 250000


.TP
.I "keyboard_serial_delay:"
Approximate time in microseconds that it takes
one  character  to   be  transfered  from  the
keyboard to controller over the serial path.

Example:
  keyboard_serial_delay: 200

.TP
.I "keyboard_paste_delay:"
Approximate time in microseconds between attempts to paste
characters to the keyboard controller. This leaves time for the
guest os to deal with the flow of characters.  The ideal setting
depends on how your operating system processes characters.  The
default of 100000 usec (.1 seconds) was chosen because it works 
consistently in Windows.

If your OS is losing characters during a paste, increase the paste
delay until it stops losing characters.

Example:
  keyboard_paste_delay: 100000

.TP
.I "ips:"
Emulated Instructions Per Second.  This option is deprecated.
Use the CPU paramter IPS instead (cpu: ips=N).

.TP
.I "clock:"
This defines the parameters of the clock inside Bochs.

sync

TO BE COMPLETED (see Greg explanation in feature request #536329)

time0

Specifies the start (boot) time of the virtual machine. Use a time 
value as returned by the time(2) system call. If no time0 value is 
set or if time0 equal to 1 (special case) or if time0 equal 'local', 
the simulation will be started at the current local host time.
If time0 equal to 2 (special case) or if time0 equal 'utc',
the simulation will be started at the current utc time.

Syntax:
  clock: sync=[none|slowdown|realtime|both], time0=[timeValue|local|utc]

Default value are sync=none, time0=local

Example:
  clock: sync=realtime, time0=938581955   # Wed Sep 29 07:12:35 1999

.TP
.I "mouse:"
This option prevents Bochs from creating mouse "events"
unless a mouse is enabled. The hardware emulation itself
is not disabled  by this. You can turn the mouse on by
setting enabled to  1, or turn it off by setting enabled
to 0. Unless you have a particular reason  for enabling
the mouse by default, it is recommended that you leave
it off. You can also toggle the mouse usage at runtime
(control key + middle mouse button).
With the mouse type option you can select the type of mouse to emulate.
The default value is 'ps2'. The other choices are 'imps2' (wheel mouse
on PS/2), 'serial', 'serial_wheel' (one com port requires setting 'mode=mouse')
and 'usb' (3-button mouse - one of the USB ports must be connected with
the 'mouse' device - requires PCI and USB support).

Examples:
  mouse: enabled=0
  mouse: enabled=1, type=imps2

.TP
.I "private_colormap:"
Requests that the GUI create and use it's  own
non-shared colormap.  This  colormap  will  be
used when in the bochs window. If not enabled,
a shared  colormap  scheme  may be used.  Once
again, enabled=1  turns on this feature  and 0
turns it off.

Example:
  private_colormap: enabled=1

.TP
.I "i440fxsupport:"
This option controls the presence of the i440FX PCI chipset. You can
also specify the devices connected to PCI slots. Up to 5 slots are
available now. These devices are currently supported: ne2k, pcivga,
pcidev and pcipnic. If Bochs is compiled with Cirrus SVGA support
you'll have the additional choice 'cirrus'.

Example:
  i440fxsupport: enabled=1, slot1=pcivga, slot2=ne2k

.TP
.I "pcidev:"
Enables the mapping of a host PCI hardware device within the PCI subsystem of
the Bochs x86 emulator. This feature requires Linux as a host OS.

Example:
  pcidev: vendor=0x1234, device=0x5678

The vendor and device arguments should contain the vendor ID respectively the
device ID of the PCI device you want to map within Bochs.
.B The PCI mapping is still very experimental.

.TP
.I "ne2k:"
Defines the characteristics of an attached ne2000 isa card :
   ioaddr=IOADDR,
   irq=IRQ, 
   mac=MACADDR, 
   ethmod=MODULE, 
   ethdev=DEVICE, 
   script=SCRIPT

.B PROPERTIES FOR ne2k:

ioaddr, irq:
You probably won't need to change ioaddr and irq, unless there are IRQ conflicts.
These parameters are ignored if the NE2000 is assigned to a PCI slot.

mac:
The MAC address MUST NOT match the address of any machine on the net.
Also, the first byte must be an even number (bit 0 set means a multicast
address), and you cannot use ff:ff:ff:ff:ff:ff because that's the broadcast
address.  For the ethertap module, you must use fe:fd:00:00:00:01.  There may
be other restrictions too.  To be safe, just use the b0:c4... address.

ethmod:
The ethmod value defines which low level OS specific module to be used
to access physical ethernet interface. Current implemented values include
 - fbsd   : ethernet on freebsd and openbsd
 - linux  : ethernet on linux
 - win32  : ethernet on win32
 - tap    : ethernet through a linux tap interface
 - tuntap : ethernet through a linux tuntap interface

If you don't want to make connections to any physical networks,
you can use the following 'ethmod's to simulate a virtual network.
 - null   : All packets are discarded, but logged to a few files
 - arpback: ARP is simulated (disabled by default)
 - vde    : Virtual Distributed Ethernet
 - vnet   : ARP, ICMP-echo(ping), DHCP and TFTP are simulated
            The virtual host uses 192.168.10.1
            DHCP assigns 192.168.10.2 to the guest
            The TFTP server use ethdev for the root directory and doesn't
            overwrite files

ethdev:
The ethdev value is the name of the network interface on your host
platform.  On UNIX machines, you can get the name by running ifconfig.  On
Windows machines, you must run niclist to get the name of the ethdev.
Niclist source code is in misc/niclist.c and it is included in Windows
binary releases.

script:
The script value is optional, and is the name of a script that
is executed after bochs initialize the network interface. You can use
this script to configure this network interface, or enable masquerading.
This is mainly useful for the tun/tap devices that only exist during
Bochs execution. The network interface name is supplied to the script
as first parameter

Examples:
  ne2k: ioaddr=0x240, irq=9, mac=b0:c4:20:00:00:00, ethmod=fbsd, ethdev=xlo
  ne2k: ioaddr=0x240, irq=9, mac=b0:c4:20:00:00:00, ethmod=linux, ethdev=eth0
  ne2k: ioaddr=0x240, irq=9, mac=b0:c4:20:00:00:01, ethmod=win32, ethdev=MYCARD
  ne2k: ioaddr=0x240, irq=9, mac=fe:fd:00:00:00:01, ethmod=tap, ethdev=tap0
  ne2k: ioaddr=0x240, irq=9, mac=fe:fd:00:00:00:01, ethmod=tuntap, ethdev=/dev/net/tun0, script=./tunconfig
  ne2k: ioaddr=0x240, irq=9, mac=b0:c4:20:00:00:01, ethmod=vde, ethdev="/tmp/vde.ctl"
  ne2k: ioaddr=0x240, irq=9, mac=b0:c4:20:00:00:01, ethmod=vnet, ethdev="c:/temp"

.TP
.I "keyboard_mapping:"
This enables a remap of a physical localized keyboard to a
virtualized us keyboard, as the PC architecture expects.
If enabled, the keymap file must be specified.

 Examples:
   keyboard_mapping: enabled=1, map=gui/keymaps/x11-pc-de.map

.TP
.I "keyboard_type:"
Type of emulated keyboard sent back  to the OS
to a "keyboard identify"  command.  It must be 
one of "xt", "at" or "mf". 

Example:
  keyboard_type: mf

.TP
.I "user_shortcut:"
This defines the keyboard shortcut to be sent when you press the "user"
button in the headerbar. The shortcut string is a combination of maximum
3 key names (listed below) separated with a '-' character. The old-style
syntax (without the '-') still works for the key combinations supported
in Bochs 2.2.1.

Valid key names:

"alt", "bksl", "bksp", "ctrl", "del", "down", "end", "enter", "esc",
"f1", ... "f12", "home", "ins", "left", "menu", "minus", "pgdwn", "pgup", "plus",
"right", "shift", "space", "tab", "up", and "win".

Example:
  user_shortcut: keys=ctrl-alt-del

.TP
.I "cmosimage:"
This defines image file that can be loaded into the CMOS RAM at startup.
The rtc_init parameter controls whether initialize the RTC with values stored
in the image. By default the time0 argument given to the clock option is used.
With 'rtc_init=image' the image is the source for the initial time.

Example:
  cmosimage: file=cmos.img, rtc_init=time0

.TP
.I "usb1:"
This option controls the presence of the USB root hub which is a part
of the i440FX PCI chipset. With the portX option you can connect devices
to the hub (currently supported: 'mouse' and 'keypad'). If you connect
the mouse to one of the ports and use the mouse option 'type=usb' you'll
have a 3-button USB mouse.

Example:
  usb1: enabled=1, port1=mouse, port2=keypad

.\"SKIP_SECTION"
.SH LICENSE
This program  is distributed  under the terms of the  GNU
Lesser General Public License as published  by  the  Free
Software  Foundation.  See  the  COPYING file located  in
/usr/local/share/doc/bochs/ for details on the license and
the lack of warranty.
.\"SKIP_SECTION"
.SH AVAILABILITY
The latest version of this program can be found at:
  http://bochs.sourceforge.net/getcurrent.html
.\"SKIP_SECTION"
.SH SEE ALSO
bochs(1), bochs-dlx(1), bximage(1), bxcommit(1)
.PP
.nf
The Bochs IA-32 Emulator site on the World Wide Web:
        http://bochs.sourceforge.net

Online Bochs Documentation
	http://bochs.sourceforge.net/doc/docbook
.fi
.\"SKIP_SECTION"
.SH AUTHORS
The   Bochs  emulator  was   created   by  Kevin   Lawton
([e-mail]),  and  is  currently  maintained
by the  members of  the  Bochs x86 Emulator Project.  You
can see a current roster of members at:
  http://bochs.sourceforge.net/getinvolved.html
.\"SKIP_SECTION"
.SH BUGS
Please  report all  bugs to the bug tracker  on  our  web
site. Just go to http://bochs.sourceforge.net, and click
"Bug Reports" on the sidebar under "Feedback".
.PP
Provide a detailed description of the bug, the version of
the program you are running, the operating system you are
running the program on  and  the  operating   system  you
are running in the emulator.