Overview

The hardware of the emulated system is defined in the emulator configuration file. Charon-PAR comes with a number of template files that are stored in /opt/charon/cfg. Each template file contains the settings for a particular Charon-PAR/PA3 or Charon-PAR/PA9 hardware model or model family. The files also contain important descriptions for all parameters listed.

The name of the Charon-PAR/PA3 template file is pa3.cfg. The names of the Charon-PAR/PA9-64 templates are rp*.cfg, for Charon-PAR/PA9-32 pa9-32.cfg.

Before starting an emulator instance,

copy the appropriate template file to the directory where you store the configuration data of your emulator instance, and
modify the template file according to your requirements.

Comments in the file are preceded by the # character.

Please note that some entries require an equal-sign (=) and for other parameters an equal-sign is not allowed. The emulator will not start if a required equal-sign is missing or an equal-sign is placed where it is not permitted.

If a parameter value is a string, it must be enclosed in double quotes.

The configuration file is structured in several sections that are described below.

Please note the following if running the emulator in a cloud enviroment: some emulated hardware can be linked to physical host hardware. For example, serial lines, tape drives, optical drives. These options are not available in a cloud environment as the physical devices do not exist there.

License Configuration

This section defines the license specific parameters.

Parameter license_key_id

Optional parameter for HASP licenses, mandatory for VE licenses.

Please note: when configuring the emulator, VE licenses and HASP licenses are mutually exclusive. If a configuration file contains the definition of a VE license, any HASP license definition is ignored (that is, the VE configuration takes precedence).

Parameter Use for HASP Licenses

There can be several license_key_id parameters in this section. They define a prioritized list of license keys. The first entry has the highest priority. If no key with this ID is available, the next key in the list will be tried. If a higher priority key becomes available, the emulator will switch to this license at the next periodic license check.

Syntax:

license_key_id "key-id-prio1"

license_key_id "key-id-prio2"

(...)

Parameters:

The key-id-prioX parameter is a numerical value that can be determined using the hasp_srm_view -all command and identifying the value of the License KeyId parameter in the output. As long as the ID is a numerical value, the quotes are optional.

Parameter Use for VE Licenses

The configuration of primary and (optionally) backup license server must be entered into the emulator configuration file using a text editor.

Relevant parameter:

license_key_id "VE://<license-server-IP>[:<port>]/<passphrase>/"

Where the following parameters are used:

license-server-IP: the IP address of the VE license server (127.0.0.1 if the VE license server is on the same host).
port: the TCP port on which the license is served (if not specified, the default port 8083 will be used).
passphrase: the passphrase of the correct product section on the license. This is required for the emulator to identify the correct section.

To configure a backup license server, repeat the line, but with the address and passphrase of the backup license server. The first line is treated as the primary server, the second as the backup server.

Parameter license_use_any_key

Please note: this parameter is not supported by the VE license server. If it is in the configuration file, comment it out.

Optional parameter for HASP licensing. This parameter is closely related to the license_key_id parameter. If the license_key_id parameter is used, it determines what happens if none of the defined license keys are available.

Syntax:

license_use_any_key false | true

Parameters:

Default value: false

If this parameter is set to true, the emulator will try to find any other suitable licenses should none of the licenses specified by the license_key_id parameter(s) be available. By default, if the license_key_id parameter is used, only the license keys specified there will be considered.

Parameter license_id

Please note: this parameter is not supported by the VE license server. If it is in the configuration file, comment it out.

Optional parameter for HASP licensing. There can be several license_id parameters in this section. They define a prioritized list of product license IDs. The first entry has the highest priority. If no key with this product license ID is available, the next product license ID in the list will be attempted. If a higher priority license becomes available, the emulator will switch to this license at the next periodic license check.

Syntax:

license_id "lic-id-prio1"

license_id "lic-id-prio2"

(...)

Parameters:

The lic-id-prioX parameter is a string value that must be enclosed in quotes. It can be determined using the hasp_srm_view -all command and identifying the value of the Product License Number parameter in the output. If none of the specified product licenses is available, the emulator will not start, or a running emulator will stop.

Problem Handler Parameters

The Charon-PAR configuration file supports the following parameters that can be used to alert the user to potential license problems:

Parameter	Description
hasp_lost_usr_cmd (this parameter will be renamed to license_lost_usr_cmd to reflect the VE licensing option)	Runs a user-defined script or a executable if Charon disconnects from current valid license and no other valid license is found. This action is called every hour during the 12 hours grace period (at the end of which Charon-PAR stops unless a license has been found). The script or command started receives three parameters from Charon-PAR: key-id, product-license-id, and termination time. Usage example: `hasp_lost_usr_cmd=“./my-license_connection_lost.sh"`
license_changed_usr_cmd	Runs a user-defined script or an executable when Charon-PAR disconnects from one license and connects to another for any reason. The script or command started receives four parameters from Charon-PAR: old-key-id, old-product-license-id,new-key-id, and new-product-license-id. Usage example: `license_changed_usr_cmd="./my-license_changed.sh"`
license_expiration_warning_usr_cmd	Runs a user-defined script or an executable when the license expiration time is within few hours. The default setup is: starting 24 hours before expiration this script is invoked each hour. The script or command started receives three parameters from Charon-PAR: key-id, product-license-id, expiration time. Usage example: `license_expiration_warning_usr_cmd=“./my-license_expiration_warning.sh”`

Parameter

Description

hasp_lost_usr_cmd

(this parameter will be renamed to
license_lost_usr_cmd to reflect the VE licensing option)

Runs a user-defined script or a executable if Charon disconnects from current valid license and no other valid license is found. This action is called every hour during the 12 hours grace period (at the end of which Charon-PAR stops unless a license has been found).

The script or command started receives three parameters from Charon-PAR: key-id, product-license-id, and termination time.

Usage example:
hasp_lost_usr_cmd=“./my-license_connection_lost.sh"

license_changed_usr_cmd

Runs a user-defined script or an executable when Charon-PAR disconnects from one license and connects to another for any reason.

The script or command started receives four parameters from Charon-PAR: old-key-id, old-product-license-id,new-key-id, and new-product-license-id.

Usage example:
license_changed_usr_cmd="./my-license_changed.sh"

license_expiration_warning_usr_cmd

Runs a user-defined script or an executable when the license expiration time is within few hours. The default setup is: starting 24 hours before expiration this script is invoked each hour.

The script or command started receives three parameters from Charon-PAR: key-id, product-license-id, expiration time.

Usage example:
license_expiration_warning_usr_cmd=“./my-license_expiration_warning.sh”

Machine State Parameters

Optional parameter: allows a non-default path to store the machine state.

Syntax:

machine_state_path "path"

Parameters:

The value of path is a Unix file system path. It must be enclosed in double quotes.

System Model Configuration

The system model configuration section contains one parameter defining the emulated historic PA-RISC model.

Syntax:

model "model-name"

The configured model must be covered by your license.

Charon-PAR Model Names

Model Name Rules

Charon-PAR/PA9-64 model name details

The model names of Charon-PAR emulated historic PA-RISC systems for HP-UX consist of three parts:

<family-name>-<number-of-cpus>-<clock-speed>

Parameters:

family-name describes the model family, e.g., rp2400,
number-of-cpus describes the number of emulated CPUs, and
clock-speed describes the CPU clock frequency in MHz.

Example: rp2470-2-750 stands for an rp2470 model with two 750-MHz CPUs.

Abbreviations are possible, e.g,, rp2470-1 stands for an rp2470-1-750 model. See configuration file templates for permitted abbreviations.

Charon-PAR/PA9-32 model name details

Currently, there are the following 32-bit models:

The PA9-32/720 (PA-RISC v1.1a) with single CPU at 50MHz, model string: "720"
The PA9-32/B132L with 1 CPU at 132MHz (oversized models with up to 16 CPUs may be available), model string: B132L-<nr-of-cpus>.
Supported starting with Charon-PAR 3.0.7.

Charon-PAR/PA3 model name details

The model names of Charon-PAR emulated historic PA-RISC systems for MPE/iX consist of three parts:

<family-name>-<number-of-cpus>-<clock-speed>

Parameters:

family-name describes the model family, e.g., A400,
number-of-cpus describes the number of emulated CPUs multiplied by 100, and
clock-speed describes the CPU clock frequency in MHz.

Example: A400-100-110 is a single-CPU A400 system running at 110 MHz.

Model Name Examples

Each configuration file template is preconfigured for a certain family of models. The following table shows a sample model-name for each of the configuration file templates:

Template	Sample model names model-name (example for one CPU)	Description
pa3.cfg	A400-100-110, A500-100-200, N4000-100-750
rp2400.cfg	rp2400-1-360	1 CPU, 360MHz, model string: 9000/800/A400-36
	rp2400-1-440	1 CPU, 440MHz, model string: 9000/800/A400-44
rp2430.cfg	rp2430-1-550	1 CPU, 550MHz, model string: 9000/800/A400-5X
	rp2430-1-650	1 CPU, 650MHz, model string: 9000/800/A400-6X
rp2450.cfg	rp2450-1-360	1 CPU, 360MHz, model string: 9000/800/A500-36
	rp2450-1-440	1 CPU, 440MHz, model string: 9000/800/A500-44
	rp2450-1-550	1 CPU, 550MHz, model string: 9000/800/A500-5X
rp2470.cfg	rp2470-1-650	1 CPU, 650MHz, model string: 9000/800/A500-6X
	rp2470-1-750	1 CPU, 750MHz, model string: 9000/800/A500-7X
rp3410[+].cfg	rp3410[+]-1-800	1 CPU at 800MHz, model string:"9000/800/rp3410"
	rp3410[+]-1-1000	1 CPU at 1000MHz, model string:"9000/800/rp3410"
rp3440[+].cfg ⁽¹⁾	rp3440[+]-1-800	1 CPU at 800MHz, model string:"9000/800/rp3440"
	rp3440[+]-1-1000	1 CPU at 1000MHz, model string:"9000/800/rp3440"
rp4410[+].cfg	rp4410[+]+-1-800	1 CPU at 800MHz, model string:"9000/800/rp4410"
	rp4410[+]-1-1000	1 CPU at 1000MHz, model string:"9000/800/rp4410"
rp4440[+].cfg ⁽¹⁾	rp4440[+]-1-800	1 CPU at 800MHz, model string:"9000/800/rp4440"
	rp4440[+]-1-1000	1 CPU at 1000MHz, model string:"9000/800/rp4440"
rp5400.cfg	rp5400-1-360	1 CPU, 360MHz, model string: 9000/800/L1000-36
	rp5400-1-440	1 CPU, 440MHz, model string: 9000/800/L1000-44
	rp5400-1-550	1 CPU, 550MHz, model string: 9000/800/L1000-5X
rp5430.cfg	rp5430-1-360	1 CPU, 360MHz, model string: 9000/800/L1500-36
	rp5430-1-440	1 CPU, 440MHz, model string: 9000/800/L1500-44
	rp5430-1-550	1 CPU, 550MHz, model string: 9000/800/L1500-5X
	rp5430-1-650	1 CPU, 650MHz, model string: 9000/800/L1500-6X
	rp5430-1-750	1 CPU, 750MHz, model string: 9000/800/L1500-7X
	rp5430-1-875	1 CPU, 875MHz, model string: 9000/800/L1500-8X
rp5450.cfg	rp5450-1-360	1 CPU, 360MHz, model string: 9000/800/L2000-36
	rp5450-1-440	1 CPU, 440MHz, model string: 9000/800/L2000-44
	rp5450-1-550	1 CPU, 550MHz, model string: 9000/800/L2000-5X
rp5470.cfg	rp5470-1-550	1 CPU, 550MHz, model string: 9000/800/L3000-5X
	rp5470-1-650	1 CPU, 650MHz, model string: 9000/800/L3000-6X
	rp5470-1-750	1 CPU, 750MHz, model string: 9000/800/L3000-7X
	rp5470-1-875	1 CPU, 875MHz, model string: 9000/800/L3000-8X
rp7400.cfg ⁽²⁾	rp7400-1-360	1 CPU, 360MHz, model string:"9000/800/N4000-36
	rp7400-1-440	1 CPU, 440MHz, model string:"9000/800/N4000-44
	rp7400-1-550	1 CPU, 550MHz, model string:"9000/800/N4000-55
	rp7400-1-650	1 CPU, 650MHz, model string:"9000/800/N4000-65
	rp7400-1-750	1 CPU, 750MHz, model string:"9000/800/N4000-75
pa9-32.cfg	720	1 CPU, 50MHz, model string: "720"
To be added in v3.0.8. Contact Stromasys.	B132L-<nr-of-cpus>	1 CPU (up to 16 for oversized models), model string "9000/778"

⁽¹⁾ The rp3440 and rp4440 models may also be available in “oversized” versions up to 128 CPUs and 512GB RAM. Please check the availability for your model with your Sales representative. The +-versions of the rp34xx and rp44xx models emulate PA-8800 CPUs, the non-plus versions PA-8900 CPUs.

⁽²⁾ Starting with version 3.0.5, the models above may also be available in “oversized” versions up to 64 CPUs and 512GB RAM. Please check the availability for your model with your Sales representative.

Memory Configuration

This section defines the RAM size for the emulated system. It only contains one parameter.

Syntax:

memory memsizeG or memory memsize

Memory size can be specified in gigabytes (denoted by the letter G) or megabytes.

Parameters:

Default memsize: 2 gigabytes

Maximum memsize: maximum allowed RAM size for the emulated system. See section Emulated Models Supported by Charon-PAR for the maximum allowed values.

The configurable memory also depends on the amount of memory available on the host system.

I/O Slot Configuration

This section is used to load additional controllers for the emulated system.

The available expansion PCI slots depend on the configured hardware model (see configuration template files and chapter Emulated Model Hardware Configuration Details). The Emulated Model Hardware Configuration chapter also lists the device paths for all expansion slots of a model.

Supported controller types: SCSI controllers and Ethernet cards.

Syntax for Ethernet cards:

load ETH tulip PCI slot-number

Parameters for Ethernet cards:

The parameter slot-number identifies the number of PCI slot (see configuration file template and Emulated Model Hardware Configuration Details). All other parameters are fixed in the current version of the software.

Syntax for SCSI controllers:

load SCSI controller-model PCI slot-number

Parameters for SCSI controllers:

slot-number identifies the number of PCI slot (see configuration file template and Emulated Model Hardware Configuration Details).
controller-model can be
53C875 for single-chip boards (assigned to PCI device function 0), or
53C896 for a dual 53C895 controller (assigned to PCI device function 0 and 1)

System Console and Serial Line Configuration

Built-in Serial Lines

Most of the emulated systems have 2 serial lines. Please refer to Emulated Model Hardware Configuration Details for the device path associated with the built-in serial lines.

Configuration path for built-in serial lines on Charon-PAR/PA3 and Charon-PAR/PA9-64	Comment
serial.uart0.device	Console
serial.uart2.device
Configuration path for built-in serial lines on Charon-PAR/PA9-32 (720)
asp.uart0.device	Console
asp.uart1.device
Configuration path for built-in serial lines on Charon-PAR/PA9-32 (B132L)
gsc.lasi.uart.device	Console
gsc.wax.uart.device

The configuration path string is used in the configuration file to specify parameters for the virtual serial line.

Super/IO Module

If the Super/IO module has been loaded, there are two additional serial lines. In the configuration, they are identified by superio_001.uart0 and
superio_001.uart1. The basic configuration options are the same as for the default serial lines.

Configuration Syntax

Syntax:

serial.uartX.device.<option>="<value>"

or

superio_001.uartX.device.<option>="<value>"

The options available for configuration are described below.

Serial port options

type

The type option specifies the serial line connection type.

Possible values:

DUMMY

Default value
The serial line is not connected to a port.
The line has no input.
The output will be discarded but can be logged to a file.

telnet

Port is a network socket with telnet protocol support.
Data is transmitted as a character stream encapsulated in the telnet protocol.
UART baud rate and parity modes are ignored.
If no client is connected, the output will be discarded.
Only one client connection is allowed.

socket

Raw network socket port mode.
Data is transmitted as a character stream without UART signals.
UART baud rate and parity modes are ignored.
If no client is connected, the output will be discarded.
Only one client connection is allowed.

pty

Linux pseudo terminal device.
UART baud rate and parity modes are ignored.
Ignores serial port control signals changes.

tty

Linux serial interface device.
This port type implements all serial port control signals, baud rate changes, parity modes. Actual capabilities depend on the capabilities of the host hardware.

RFC2217

Port is a network telnet client with RFC2217 support.
The RFC2217 COM Port Control (a telnet protocol extension) allows sharing modems and other serial devices over a TCP/IP network.
The emulated serial interface connects to a serial port server.
This port type implements all serial port control signals, baud rate changes, parity modes. Actual capabilities depend on the capabilities of the host hardware.

port

The format and values of the port option, depend on the type of the port.

Type	Port settings
DUMMY	Any existing port settings are ignored.
socket, telnet	The port is mapped to a TCP socket on the emulator host. A TCP port number must be unique on the host system. The TCP port number is specified in the following format: `<where-to-listen>:<portnumber>` Possible values for where-to-listen: Empty: If the port number is specified without a colon (:), the interface process will only be accessible on the localhost address. Equivalent `lo:<portnumber>`. If the port number is specified with a colon, the interface process will listen on all host interfaces. Interface name: the interface process will only listen on the specified host IP interface. IP address: the interface process will only listen on the specified host IP address. Default values: ":30000" for line 1 ":30002" for line 2
pty, tty	The port is mapped to a serial host interface (e.g., /dev/ttyS0, /dev/ttyUSB0). For type pty, a pseudoterminal device is created automatically if no device is specified. The format is `<device-path>` (as shown in the examples above). Please note: physical serial lines are not available in cloud environments.
RFC2217	The port is mapped to a serial port server on the network. The format is `<ip-address>`:`<tcp-port>`

command

This parameter is optional. It can be used to specify a terminal emulation program that is started automatically when the emulated system is started. Charon-PAR provides preconfigured profiles for PuTTY (PAR-Socket, PAR-Telnet, PAR-Telnet-VT100) that can be used to connect to the emulated system via a serial line.

stop_command

Boolean flag. If true, the command started on the serial line (parameter command) will be stopped when exiting from the emulator.

out_log

File name for logging the output character stream from the CPU to the device. Does not depend on the port being operational (the actual transmission is not logged). Depending on the data sent, the file may best be viewed using a tool such as hexdump or od.

in_log

File name for logging the input character stream from the port to the device. Best be viewed using a tool such as hexdump or od.

keep_on_reset

New in version 3.0.6. For physical serial ports. If set to 1, the emulator will keep the port speed, parity, stop bits, data bits on reset.

port_defaults

New in version 3.0.6. For physical serial ports: string defining the port default settings after a reset.

The format of the string is <speed> <bits><parity><stop> with the following possible values:

speed: 300, 600, 1200, 2400, 4800, 9600, 19200, 38400, 57600, or 115200
bits: 5, 6, 7, or 8
parity values and the corresponding stty parameters:
- N: -parenb (none)
- E: parenb -parodd -cmspar (even)
- O: parenb parodd -cmspar (odd)
- M: parenb -parodd cmspar (mark)
- S: parenb parodd cmspar (space)
stop values and the corresponding stty parameters:
- 1: -cstopb (one stop bit)
- 2 : cstopb (two stop bits)

Example: system.uart0.device.port_defaults = "115200 8N1"

Console Communication

Charon-PAR provides preconfigured PuTTY session templates for connecting to a serial emulator console port. The templates must be copied to /root/.putty/sessions or /root/.config/putty/sessions because the emulator must be started as the root user.

Method 1: TCP port 30000, raw data mode

serial.uart0.device.type="socket"
serial.uart0.device.port=":30000"
serial.uart0.device.command="putty -load PAR-Socket"

Method 2: TCP port 30000, Telnet protocol

serial.uart0.device.type="telnet"
serial.uart0.device.port=":30000"
serial.uart0.device.command="putty -load PAR-Telnet-VT100"

To connect to the console port without loading a PuTTY template, the command parameter can be set to

serial.uart0.device.command="putty"

To start the xhpterm emulator (Charon-PAR/PA3), the following setting should be used:

serial.uart0.device.command="./xhpterm -port 30000 -clean -font 10x20"

Please note::

If no command is specified, a connection to the TCP port is possible by starting another terminal emulator manually.
For device naming on Charon-PAR/PA9-32 refer to the serial line configuration section above.
By default, pressing Ctrl+C in the Charon-PAR console is passed to the emulator's child processes and kills the PuTTY console process. If this is not desired, you can modify the command line to include the setsid command to start the telnet command in a new session.
For example: serial.uart0.device.command="setsid putty -telnet -P 30000 localhost"

SCSI Controllers and Devices

Every Charon-PAR emulated model has preconfigured SCSI controllers that can be used to configure emulated disks for the guest system. All models also have the option to load additional controllers. Please refer to the section I/O Slot Configuration in this chapter.

Please note:

The description below shows how to work with preloaded SCSI controllers. Once an additional SCSI controller has been loaded, the steps below also apply to such a controller.
It is not recommended to place emulator storage devices (in particular vdisks) on NFS as this will have a significant impact on performance. However, if any of the storage (e.g., ISO files or vdisks) is on an NFS share, NFS locking must be enabled and all intermediate firewalls between client and server must allow the port used by the lockd and statd. Failure to do so will cause the emulator to hang at startup.

Preloaded SCSI Device Controllers

Charon-PAR implements I/O using controllers. Each controller

supports up to 15 SCSI devices,
is identified by a character code,
is assigned a path corresponding to the leading for elements of the device path.

The tables below show the preconfigured SCSI controllers of an rp2400 model as an example.

Please note: Other models may have more or less preconfigured controllers with different device paths and code mappings. For details regarding your model refer to the configuration file template or the chapter Emulated Model Hardware Configuration Details.

Code	Module path (rp2400)	Controller model
A	0/0/1/0	53C875
B	0/0/1/1	53C875
C	0/0/2/0	53C896
D	0/0/2/1	53C896

Load Device Command for SCSI Devices

The load command is used to define SCSI devices.

Syntax:

load DDXnnn

DDXnnn represents the device name. It has the following components:

Component	Value	Description
DD	SCSI device type
	DK	Disk device mapped to file or physical device
	MK	Tape device mapped to file or physical device
	GK	Generic SCSI device mapped to physical SCSI target
X	Controller Code The rp2400 model is used as an example below; refer to the template configuration file of your model and to Emulated Model Hardware Configuration Details for model specific details.
	A	rp2400 controller device path: 0/0/1/0
	B	rp2400 controller device path: 0/0/1/1
	C	rp2400 controller device path: 0/0/2/0
	D	rp2400 controller device path: 0/0/2/1
nnn	SCSI target ID and LUN
	(SCSI ID * 100) + LUN	Identifies the SCSI device connected to a SCSI controller

Examples:

To load a disk on device path 0/0/1/0.1.2 (SCSI target ID 1, LUN 2), add the command

load DKA102

To load a tape on device path 0/0/1/1.12.0 (SCSI target ID 12, LUN 0), add the command

load MKB1200

The image Subcommand

After a SCSI device has been loaded, the associated container file or device must be specified. Please note: physical tape or CD-ROM drives are not available in cloud environments.

Please note: the image subcommand is for MK and DK devices only.

Format:

device.image="<path-to-device-or-file>"

Parameters:

device: the virtual SCSI device created by the load command. See the load command for details about the device name syntax.
path-to-device-or-file: the path to the Linux device (a physical disk device or disk partition) or container file. For physical devices it is strongly recommended to use a persistent device name from
- /dev/disk/by-id, or
- /dev/disk/by-uuid
  instead of a non-persistent /dev/sdX device name.

Example:

To associate a disk device on 0/0/1/0.0.0 (controller code A, SCSI target ID 0, LUN 0) with a container file called ldev1.dsk, add the command

DKA0.image="ldev1.dsk"

The devname Subcommand

Use the devname subcommand to specify the device to be used for a generic SCSI device (GK device). Please note: physical tape or CD-ROM drives are not available in cloud environments.

Please note: A generic SCSI device can be a tape or disk device. Guest system SCSI commands are passed through to the device directly and not handled by the Linux disk or tape driver. The functionality depends on the device understanding the guest system SCSI commands.

Format:

GKXnnn.devname="<path-to-device>"

Parameters:

GKXnnn: the generic virtual SCSI device created by the load command. See the load command for details about the device name syntax.
path-to-device: special filename of the generic SCSI device (/dev/sgX) on Linux, for example: /dev/sg0.

Tape autoload Subcommand

To enable tape container files to be automatically loaded as tapes into a virtual tape device, the autoload command can be added for a specific tape device in the configuration file. Not applicable to physical tape devices.

Format:

MKXnnn.autoload=yes|no

Parameters:

MKXnnn: the emulated tape device. Possible values for X and nnn see above.

Default: autoload is off by default.

Please note:

The autoload command works well in many situations but can cause problems in some cases, for example with multi-volume backups. Any applications using tape devices should be tested thoroughly to verify if the autoload option is working as expected.
MPE/iX can load a tape using operating system utilities. HP-UX cannot. Hence, the autoload command may be more often useful in an HP-UX environment.

Tape size Subcommand

The size command limits the maximum size of a tape container file. Not applicable to physical tape devices.

Format:

MKXnnn.size=<size-in-bytes>

Parameters:

MKXnnn: the virtual SCSI tape device created by the load command. See the load command for details about the device name syntax.
size-in-bytes: maximum size of the tape container file.

Default: tape container file size is not limited.

Tape Subcommands for Physical Tape Devices

The following two commands can only be used for physical tape devices:

Subcommand	Description
`MKXnnn.fast=true\|false`	Optimization for writing EOF marks. Do not use for old tape drives. Default is off.
`MKXnnn.nounload=true\|false`	Set to true for DDS tapes. Set to false for DLT tapes. Default is on.

Typical System Disk Configuration

The system disk is usually configured on device path 0/0/1/0.0.0. To load this device and to map it to a disk image file, add the following commands:

load DKA0

DKA0.image="/data/virtual-disks/ldev1.dsk"

Network Card Configuration

General information

The emulated Ethernet interfaces of Charon-PAR can be linked either to a

physical host interface,
a TAP interface connected to a virtual bridge on the host, or
(since Charon-PAR 3.0.9) a MACVTAP interface linked to a physical NIC on the host.

Notes for physical interfaces:

If used directly as a guest interface, offloading parameters must be turned off using the initialization command parameter in the configuration file.
In cloud environments, the necessary interface settings are not always reflected correctly on the cloud-provided NICs. For such installation settings a MACVTAP interface can be used to provide a dedicated connection without connecting the emulator directly to the physical interface.

Notes for TAP interfaces:

A TAP interface can either be created by the user or will be created automatically by the emulator if it does not already exist.
For automatically created TAP interfaces, the user can specify a name or let the emulator select a name.
A automatically created TAP interface is not automatically added to a bridge, this must be configured via the initialize_command (see the Ethernet Configuration Parameter table below).
An automatically created TAP interface is deleted automatically upon emulator stop.
If used in a cloud environment, only internal virtual bridges (no connection to the cloud LAN) are supported.

Notes for MACVTAP interfaces:

Introduces a transparent bridge interface associated with on physical NIC on the host, and provides a dedicated interface to the emulator.
Provides an abstraction layer between physical NIC and emulator.
Physical interface requires no changes in the offloading configuration.
Fragmentation is performed by Linux on the MACVTAP interface. Jumbo frames on the physical interface will not cause problems.
Uses same MAC address as the physical interface.
Suited for associating a dedicated host Ethernet interface to the emulator in cloud environments.

Notes for network configurations on VMware:

ESXi has configuration parameters that improve security but may block certain emulator NIC configurations.
One configuration option allows or blocks promiscuous mode (the default mode of operation for Charon-PAR guest NICs).
Other configuration options allow or block the change of a MAC address or the use of a different, additional MAC address on the same NIC (MAC address changes, Forged transmits).

By default, emulated models have one Ethernet device. Depending on the model, more Ethernet devices can be added.

A guest HP-UX system will perceive the network card as a 10/100 Mbit/s controller running at 10 Mbit/s half-duplex. If the user tries to change this setting using SAM or the lanadmin command, the command will be accepted but the displayed interface settings will not change. However, the throughput of the emulated network card depends on the combination of network performance, physical network card characteristics, host system and guest system performance - it is not tied to the displayed interface settings. So the actual throughput will be what can be achieved depending on the conditions listed above.

The emulated network devices

DE 500 PCI based cards (for 64-bit systems), and
LASI-82596 cards (for the 32-bit system)

do not support Jumbo frames. For physical interfaces, this feature must be disabled in the emulator configuration (together with any other offloading parameters) using the initialize_command parameter.

Ethernet Card Device Names

Names on 64-bit systems:

The name of the Ethernet interface in the emulator configuration file has the format EWxn with the following definitions:

x is an uppercase letter starting with A for the first interface and then continues with B, C, etc. for additional interfaces. The possible number of network cards depends on the features of the original physical system. The absolute maximum number is 16.
n is the device number of the card starting with 0 for each value of x.

Names on 32-bit systems:

The currently supported 32-bit system supports only one Ethernet card:

Model 720: system.lan0.card
Model B132L: gsc.lasi.lan.card

Ethernet Configuration Parameters

This section lists the available Ethernet interface configuration parameters.

Basic syntax:

<device-name>.<parameter>="<value>"

The device-name specifies the name of the Ethernet card as described above in the Ethernet Card Device Names section.

The parameters and their values are described in the following table:

Parameter	Values
mapping_mode	Possible values: RAW: the emulated Ethernet card is mapped to a physical interface on the Charon host that is dedicated to the Charon guest system. This setting is the default value. TAP: the emulated Ethernet card is mapped to a TAP device on the Charon host. If the parameter iface is not set or the specified interface does not exist, it is created by the emulator. MACVTAP: links the emulated NIC to a physical NIC on the host via an automatically configured TAP interface. Different from a bridge, it allows using the same MAC as the host NIC when used in passthrough mode. This makes it suitable for cloud environments. MACVTAP mode requires at least Charon-PAR version 3.0.9. DUMMY: presents a network interface without any actual network connectivity to the guest system. All other Ethernet parameters are ignored if this parameter is set. It will be set automatically, if iface="dummy", or iface="" and mapping_mode="RAW".
iface	Specifies the name of the host interface mapped to the emulated interface. For mapping_mode="RAW" or "MACVTAP": this parameter must be set to an interface dedicated to the emulator. For mapping_mode="TAP": the parameter can be empty: the emulator will choose a name for the TAP interface and create it automatically at startup (and delete it when stopped). name of non-existing TAP interface: the emulator will create the interface automatically at startup (and delete it when stopped). name of an existing TAP interface: the emulator will use this interface. For any mapping_mode: the value dummy will cause the emulator to present a dummy NIC to the guest system. Upon emulator start, Charon-PAR will set a variable IFACE to contain the interface name. This variable can then be used in the initialization command to refer to the interface name.
macaddr	Can be set to override the default (same as host interface) MAC address of the interface. By default, if this parameter is used together with mapping_mode RAW, the interface is put into promiscuous mode, and the original MAC address of the interface is not overwritten. If the legacy_mode is configured for the interface, the interface is not set into promiscuous mode, and the MAC address of the corresponding host NIC is changed to the configured address. The original MAC address is restored upon emulator exit. The format of the MAC address is: XX-XX-XX-XX-XX-XX where X is a hexadecimal number. Please note: the above behavior is new starting with version 3.0.1 build 21.500. In older versions, when the MAC address was changed, it was not reset automatically when the emulator was stopped.
initialize_command	Command(s) to initialize the host interface for use with the Charon emulator. For physical interfaces (RAW): all offload parameters active on the interface should be turned off, as shown by the example in the configuration file template. For TAP interfaces: the TAP interface should be activated, if needed, and added to the appropriate bridge interface (example: `"ip link set $IFACE up; ip link set $IFACE master br0"`); the exact configuration depends on the customer requirements. Not needed if a MACVTAP interface is used. The variable IFACE is set by the emulator and defined automatically for the execution of the initialization command.
adapter_mode	Defines the speed and duplex settings of the interface that are reported to the guest system. Possible values: auto, 10BaseT-HD, 10BaseT-FD, 100BaseT-HD, 100BaseT-FD Default: 100BaseT-FD
legacy_mode	New starting with version 3.0.1 build 21.500. Only applicable to mapping_mode RAW with a manually configured MAC address. Possible values: true - non-promiscuous mode; if a custom MAC address was set, it will be set on the physical NIC during emulator operation and reset to the burned-in MAC address when the emulator stops. false - promiscuous mode; if a custom MAC address was set, it will not be be set on the physical NIC (not required for the guest communication due to promiscuous mode) Default: false
pkg_dump	Can be used to enable a packet dump to the log file. Possible values: true or false Default: false
rx_fifo_size	Can be used to set the size of the RX FIFO buffer (in KB). Do not change unless advised to do so by Stromasys support. Possible values: 0, or 16 to 1024 Default: 0 = disabled
ignore_tx_start_error	Possible values: true or false Default: true By default, this parameter enables a workaround for DMA failures at the adapter startup. If needed, the workaround can be disabled by setting the parameter to false. Introduced by build 3.0.6-22001.

Logging configuration

This section defines how Charon-PAR handles logging. Note that the default log file location is the directory in which the emulator was started.
This can be changed with the emulator command-line option -l (or --logfile-path).

Log File Parameters

The following table shows the parameters relevant to the log file and their values:

Parameter	Description
`log.name="path/log-file-name"`	log-file-name specifies the base name of the log file. The full log file name will be created using the base name combined with date, time and serial number. Default: charon-par.X_log. A link with the name `log-file-name.log` will be created that points to the active log file. After a log rotation, the link will be set to the new active log file. The `path` specification is optional. It can be absolute or relative and indicates where the log file and the log-file link will be created. Default is the directory in which the emulator is started. The specified directory must exist - otherwise the emulator will not start.
`log.on_console= false \| true`	Defines if logging output should be sent to the Charon-PAR console. Default: true.
`log.disable= false \| true`	Enable or disable logging. Default: false.
`log.no_rotate= false \| true`	If set to false, once the line limit for a log file has been reached, the old log file will be closed and a new one will be opened with the last number in the log-file name incremented.. Default: false.
`log.line_limit = value`	Maximum number of lines in the log file before rotation. Default: 100000.

Log File Format

Starting with version 3.0.1 the log file has the following format:

YYYYMMDD:hhmmss.uuuuuu:<severity><message>

   where

YYYY   - year
MM     - month
DD     - day
hh     - hour
mm     - munites
ss     - seconds
uuuuuu - usecs

<severity> := '(warn|err|ERR):' or empty

warn   - warning
err    - error
ERR    - fatal error

<message> the component's message in free form

Parameter system.license_logging_level

Starting with Charon-PAR version 1.11, periodic (once per hour) log messages indicating a successful periodic license check are disabled by default to avoid cluttering the log file. They can be re-enabled by adding this parameter to the emulator configuration file.

Syntax:

system.license_logging_level = value

Parameters:

If value is set to 2, the messages are enabled.
If value is set to 0 or 1, the messages are disabled.

Please note that this parameter must be placed towards the end of the configuration file and will not work if placed before the memory configuration.

SuperIO Configuration

General Information

The SuperIO module is included in the Astro chipset and emulates a PCI board with PC style peripherals used in historic 64-bit PA-RISC systems:

parallel port
2 serial ports
dual-channel IDE controller
floppy disk controller
USB controller
timer
PIC interrupt controller

The current version of Charon-PAR supports only a subset of these devices. And the SuperIO module is only supported on models that are based on the Astro chipset (rp24xx and rp54xx).

Currently supported are (depending on support by the emulated model and guest operating system)

two serial ports
one parallel port

Loading the SuperIO device

Before any devices of the module can be configured and used, the module must be loaded in the emulator configuration file.

The SuperIO module can be loaded in any system model with PCI bus support.

Use the following syntax to load this module into a slot on the default bus:

load SUPERIO sio <bus-number> <slot-number>

Example:

load SUPERIO sio 0 6

Use the following syntax to load this module into an PCI expansion slot:

load SUPERIO sio PCI <slot-number>

where the slot number is the number listed in the configuration file template or in Emulated Model Hardware Configuration Details for the expansion I/O slot selected.

Please note:

Only one SuperIO module can be loaded in the configuration. Multiple SuperIO instances will not work properly.
The usable bus numbers and slot numbers depend on the emulated model and the already loaded devices.
If another PCI device is already installed in the specified PCI slot, the load command will fail with an error message.
The correct bus/slot location of the device is important to preserve the correct GSP (service processor) console configuration:
- If the SuperIO module is inserted in a slot before the normal system serial console, the service processor console (GSP console) is set to the first SuperIO serial port.
- HP-UX does not support the SuperIO serial port as GSP console. With such a configuration, it will crash early-on in the boot process. Therefore, take care to always use a slot number higher than the one where the correct system console line has been loaded.

After booting the guest HP-UX system, the example above will result in an ioscan output similar to the following:

ba          1  0/0/6/1      superio   CLAIMED     BUS_NEXUS    PCI Core I/O Adapter
tty         1  0/0/6/1/1    asio0     CLAIMED     INTERFACE    Built-in RS-232C
tty         2  0/0/6/1/2    asio0     CLAIMED     INTERFACE    Built-in RS-232C
ext_bus     4  0/0/6/1/3    SCentIf   CLAIMED     INTERFACE    Built-in Parallel Interface
unknown    -1  0/0/6/1/4              UNCLAIMED   UNKNOWN      Built-in Floppy Drive

SuperIO Serial Ports

Serial ports installed on SuperIO module can be configured the same as other serial ports. Please see chapter Serial Line Emulation Notes for more information.

Path names for serial devices in the emulator configuration:

superio_001.uart0 - COM0 port
superio_001.uart1 - COM1 port

Serial ports configuration example:

superio_001.uart0.device.type="telnet"
superio_001.uart0.device.port=":30001"

superio_001.uart1.device.type="telnet"
superio_001.uart1.device.port=":30002"

SuperIO Parallel Port

The parallel port installed on a SuperIO module connects to the host system parallel port device /dev/parport0. The parallel port output from the guest OS is redirected to the host parallel port. No additional configuration for the parallel port is required.

However, it may be necessary to install the required kernel drivers in HP-UX and rebuild the kernel to activate the interface.

If the ioscan command shows the parallel port as UNCLAIMED, perform the following steps:

Use the kcmodule command to verify the status of the required drivers:
# kcmodule |grep CentIf
CentIf static explicit
SCentIf static explicit
If the status is unused, load the modules into the kernel using the commands:
# kcmodule CentIf=best
# kcmodule SCentIf=best
You will be informed that this change can only become active after the next reboot. If you confirm, the kernel will be modified and you can reboot the system.

Once the ioscan command shows that the parallel port as CLAIMED by the correct driver, you can, for example, use SAM to configure a printer on the parallel port
(Printers and Plotters > LP Spooler > Printers and Plotters > Action > Add Local Printer > Add Parallel Printer). On HP-UX 11.31, use SMH for this task. Please note that at the time of writing SMH only worked with the emulator when being used over the network (not on the serial console).

If no parallel port device exists on the host system, an error message similar to the one below will be printed to the emulator log. It does not affect system operation, but the parallel port redirection will not work.

err:open('/dev/parport0', O_RDWR) is failed (errno 2) No such file or directory
err:ioctl(handle, PPCLAIM) is failed (errno 9) Bad file descriptor

Modern host systems often have no physical parallel port. In such cases, a USB-LPT adapter or a software redirector (such as LPT-over-IP) can be used. The emulated parallel port operation depends on the host parallel port operation and some USB-LPT adapters may not produce reliable results.

Other Parameters

Parameter system.do_timer_correction

If the system time of the emulated system deviates too much from the correct time, it can cause application problems in the emulated system. If this cannot be solved by other means (e.g., NTP), the parameter described here can be used to adjust the system time of the emulated system based on the host system's NTP adjusted time.

Syntax:

system.do_timer_correction = false | true

Parameters:

If set to false, no time correction will take place.
If set to true, the time of the emulated system will be corrected as described above.

Default: false

Parameter fma_check

Charon-PAR requires a host CPU that supports the FMA capability. Normally, an emulator will not run when trying to start it on a CPU without the required capabilities.

This parameter allows you to disable the FMA check. However, this may lead to unexpected problems with the guest operating system.

Please note: Do not use this parameter if you run PA9 instances. For PA3 instances, use the configuration option at your own risk.

Syntax:

fma_check = false | true

Parameters:

If set to false, Charon-PAR will not check the FMA support of the host CPU.

Default: the check is enabled.

Parameters system.stop_on_halt and system.stop_on_halt_timeout

These parameters are applicable to emulated systems in which a HP-UX guest operating system runs.

When HP-UX is shut down with the shutdown -h command, the guest system will be halted. By default, the emulated system will be powered off automatically when a halt is detected (that is, the Charon-PAR process will be stopped).

Depending on the Charon-PAR version one of the following two parameters can be used to influence this behavior.

Charon-PAR Versions 3.0.5 to 3.0.12 (system.stop_on_halt)

The system.stop_on_halt parameter has the following syntax:

Syntax:

system.stop_on_halt = false | true

Parameters:

If set to false, Charon-PAR will not stop the emulated system automatically after the guest operating system has been halted. The emulator must be stopped from the Charon-PAR console (at the pa9-64> or pa9-32> prompt).

Default: true. the emulated system will be stopped automatically after the HP-UX guest operating system has been halted.

Charon-PAR Versions 3.0.13 and Higher (system.stop_on_halt_timeout)

The system.stop_on_halt_timeout parameter has the following syntax:

Syntax:

system.stop_on_halt_timeout = <number-of-seconds>

Parameter:

If number-of-seconds is set to 0, Charon-PAR will not stop the emulated system automatically after the HP-UX guest operating system has been halted. The emulator must be stopped from the Charon-PAR console (at the pa9-64> or pa9-32> prompt).

If number-of-seconds is set to a value higher than 0, Charon-PAR will stop the emulated system automatically after the HP-UX guest operating system has been halted using a timeout corresponding to the specified number of seconds.

This parameter has no default value. To restore the default behavior of the system, comment out or remove the parameter from the emulator configuration file.

Parameter system.do_affinity

If enabled, the emulator will calculate a CPU affinity mask based on the host system and the emulator configuration. The affinity mask shows which CPUs will be used for emulated CPUs and which for I/O.

Syntax:

system.do_affinity = false | true

Parameters:

Default: false. The emulator will not follow any preferred host CPU affinity settings.

If set to true, Charon-PAR will calculate a hexadecimal affinity mask according to which emulated CPU and I/O threads will be distributed across the Charon host CPUs. The calculated mask is shown in the emulator log file.

Every bit in the calculated affinity mask corresponds to one host CPU (counting from 0). For example: 00000001 corresponds to to CPU 0, 00000003 corresponds to CPU 0 and 1.

The CPUs that can be used by the emulator can be limited by starting the emulator with an explicit affinity mask defined by the taskset command.
Example: # taskset 2f /opt/charon/bin/charon-par -f myconfigfile.cfgThis would set the affinity mask such that the emulator would only use CPUs 0-3 and 5. If do_affinity is enabled, the automatic calculation will be restricted to the CPUs allowed by the taskset command.

Contents

Overview

License Configuration

Parameter license_key_id

Parameter Use for HASP Licenses

Parameter Use for VE Licenses

Parameter license_use_any_key

Parameter license_id

Problem Handler Parameters

Machine State Parameters

System Model Configuration

Charon-PAR Model Names

Model Name Rules

Model Name Examples

Memory Configuration

I/O Slot Configuration

System Console and Serial Line Configuration

Built-in Serial Lines

Super/IO Module

Configuration Syntax

Serial port options

type

port

command

stop_command

out_log

in_log

keep_on_reset

port_defaults

Console Communication

SCSI Controllers and Devices

Preloaded SCSI Device Controllers

Load Device Command for SCSI Devices

The image Subcommand

The devname Subcommand

Tape autoload Subcommand

Tape size Subcommand

Tape Subcommands for Physical Tape Devices

Typical System Disk Configuration

Network Card Configuration

General information

Ethernet Card Device Names

Ethernet Configuration Parameters

Logging configuration

Log File Parameters

Log File Format

Parameter system.license_logging_level

SuperIO Configuration

General Information

Loading the SuperIO device

SuperIO Serial Ports

SuperIO Parallel Port

Other Parameters

Parameter system.do_timer_correction

Parameter fma_check

Parameters system.stop_on_halt and system.stop_on_halt_timeout

Charon-PAR Versions 3.0.5 to 3.0.12 (system.stop_on_halt)

Charon-PAR Versions 3.0.13 and Higher (system.stop_on_halt_timeout)

Parameter system.do_affinity

Browser not supported