Table of Contents

Creation of your own configuration file using a template

By default, all the Charon templates are located in the "/opt/charon/cfg" folder. Copy the appropriate template configuration file(s) to your home directory or to any directory intended for CHARON-AXP, name them meaningfully and set proper privileges.

Example:

Please do not edit the original template configuration files since they can be updated or even removed on update/deinstallation of Charon-AXP

Once the file has been created you can open it in your favorite editing tool and proceed with modifications to reflect the exact features of the system you are going to emulate.

We will review all the parameters step by step issuing some recommendations and guidelines.

Note: the lines preceded by the comment sign "#" inside the configuration files will not be interpreted. You can use this sign to debug your configuration.

Alpha model specification

The first configuration statement is the specification of the exact Alpha hardware model to emulate.

Example:

You must leave this line untouched.

If you create the Charon-AXP configuration file from scratch, it must be the very first uncommented line in the configuration file.

Configuration name

The next configuration statement is the "Configuration name" option.

Example:

You can optionally uncomment this line to differentiate this Charon-AXP instance from all others in a multi-instances environment. The configuration name can be any label that is meaningful. It is reported in the log file and is used to set the log file name for rotating log (see further: Rotating log (default) ).

Log file parameters

Execution of CHARON-AXP creates one log file or a set of log files reflecting the progress of its start-up and ongoing operation - start and end time of execution, system information, license and configuration details, warnings, reports on problems that may occur, etc. In case of possible problems either with the running CHARON-AXP or the emulated system configuration (such as the absence or malfunction of certain devices), the log file(s) is the primary source to be analyzed for troubleshooting. If it becomes necessary to contact Stromasys for support, the configuration and log files, plus the license number, will be requested to begin problem resolution.

The next group of parameters defines the name of the Charon-AXP log file and how Charon-AXP will use it:

Rotating log (default)

By default Charon-AXP utilizes a so-called "rotating log" mechanism. This means that a new default log file is created each time Charon starts and can switch to another log file if the size of the log file exceeds 4 MB (this behavior can be changed with the "set session log_file_size" and "set session log_rotation_period" parameters; see more details in the "General Settings" chapter of this guide).

This mode is turned on if the log_method is not specified or the "session_log" parameter is pointing to an existing directory rather than to a file. If a directory is specified, the log files will be created in that directory.

The names of the rotating log files are composed as follows:

If the "Configuration name" parameter described before is omitted (commented out), the log name has the following format instead:

Note that "xxxxxxxxx" is an increasing decimal number starting from "000000000". During a session (the time between start and stop of the emulator), when the log file is rotated, this number will be incremented by 1.

Please note: only an existing directory can be used as a value of the "log" parameter.

Single log

Alternatively it is possible to use a single log file: uncomment the "set session log" line and specify the desired Charon-AXP log file name. Optionally, a path can be added to the log file name. If the path is not specified, the log file is created in the directory from where the guest (emulated machine) is started.

The log file can be extended ("log_method = append") or overwritten ("log_method = overwrite") by Charon-AXP.

Below is a specification of a Charon-AXP log file located in the "/my_logs" directory which will be appended each time Charon-AXP starts:

CPU affinity

This setting binds the running instance of the emulator CPUs to particular host CPUs. This should be used for soft partitioning host CPU resources or for isolating multiple Charon instances on the same host from each other. By default the emulator instance allocates as many host CPUs as possible.

“Affinity” overrides the default and allows explicit specification of which host CPUs will be used by the instance. Affinity does not reserve the CPU for exclusive use.

Example:

The example above directs Charon-AXP to use CPU 0,1,2 and 3.

If this parameter is omitted Charon host will allocate available CPUs automatically.

Note that the number of the specified host CPUs must correspond to the number of the emulated CPUs (one host CPU for one emulated CPU; this value is specific for each Alpha model) and number of CPUs needed for Charon application itself ("n_of_io_cpus").

Number of host CPUs dedicated to Charon I/O

This parameter reserves host CPUs for use by the emulator for I/O handling. By default the emulator instance reserves one third of the number host CPUs for I/O processing (rounded down, at least one). 

The “n_of_io_cpus” overrides the default by specifying the number of I/O host CPUs explicitly

Example:

The example above directs Charon-AXP to use 2 CPUs for Charon I/O operations.

Note that the number of the specified CPUs dedicated to Charon I/O operations can NOT exceed the total number of host CPUs minus the number of Alpha emulated CPUs.

Setting a specific Alpha model

Charon-AXP allows to specify an exact model of Alpha.

For example for AlphaServer ES40 family the "es40.cfg" sample configuration file contains the following options:

Just uncomment the provided lines to apply a certain model (It is "AlphaServer ES40 6/667" in the example above).

The full description of the parameters, with other models that can be also configured, is available in the "Configuration details" chapter of this User's Guide.

Do not change the basic Alpha model ("DS10", "DS20", "ES40", "ES45", etc). You should always start with the appropriate configuration template file for the model you wish to emulate in /opt/charon/cfg/.

Configuring the number of emulated CPUs

If the number of emulated CPUs is not specified, the emulator will try to create the maximum number of CPUs as determined by the Alpha model being emulated. See the Software Product Description to determine the maximum number of CPUs possible for a particular Alpha model.

If you wish to emulate fewer CPUs that the maximum, for example because the Charon host does not contain enough CPUs to emulate the maximum number of  CPUs provided by a certain Alpha model, it is possible to specify the number of emulated Alpha CPUs in the configuration:

This parameter can also be used to avoid warning messages in the log if the number of CPUs allowed by the license is less than the default number of CPUs of the emulated Alpha model.  For example, the default number of CPUs for an Alpha DS20 is 2.  Many DS20 installations have only 1CPU and are licensed that way.  To avoid any warning messages, the use of the command above would be advised.  Please note that the warning message is just that and will not cause any problems or issues.

Setting system serial number

This parameter is used to set a specific system serial number instead of the default one:

TOY and ROM containers

The next objects to be configured are TOY and ROM containers (their presence depends on the Alpha model). It is always recommended to enable them. If a container file of the given name does not exist, Charon-AXP will create it. It is recommended to specify the path for each file so that time and console parameters will be kept whatever the current directory is when starting the guest.

TOY means "Time of Year"; its container records time, date and some console parameters while Charon-AXP is not running. To enable the TOY, uncomment the following line:

The ROM container stores an intermediate state of the Flash ROM and some console parameters. It is highly recommended to define its location:

Emulated memory (RAM) size

The next parameter defines the amount of host memory the chosen CHARON-AXP model reserves for the emulation.

Example:

The amount of RAM is specified in MB. It cannot exceed or be lower than certain values specific for each Alpha model. It is very important to keep the listed predefined increment between possible memory values.

The following table lists all the parameters per model:

It is possible to leave the RAM line commented out. In this case the model's default RAM amount is used. 

Note that in some particular orders your license may restrict the maximum RAM amount of each Alpha model.

Console

Mapping to system resources

The next step is the specification of the Alpha console (OPA0) serial line.

Example:

The goal of this configuration step is to tell Charon-AXP what host device to use as the virtual system console. The following options are available:

The default setting for OPA0 is "line = (console)".

The second serial line "COM2"/"TTA0" can be also optionally configured for all Alpha models ("TTA0" is a predefined alias for "COM2"):

There are a number of additional parameters for Charon-AXP serial lines configuration. Follow this link for details.

Exit on pressing F6 key

Charon-AXP can be exited by issuing the "power off" command on the SRM console. It is also possible to configure a hot key to immediately terminate the emulator from the console:

This line configures the "F6" key to send the emulator the signal to immediately stop itself. Unless you have no choice, you should never stop the emulator if the guest is still running.

Improve granularity of emulated timer

The next configuration option can be applied for improving granularity of emulated CHARON-AXP timer:

Do not uncomment this parameter unless there are some problems with system time or system clock intervals in guest OS.

Networking

Charon-AXP supports DE435, DE450, DE500AA, DE500BA, DE602 and DE602AA virtual network adapters.

All of them are configured in a similar way:

In the examples above the first line loads DE500BA/DE602 virtual adapter with a name "EWA"/"EIA" (note that "/i8255x" syntax must be used only in case of DE602 and DE602AA adapters); the following line maps it to host network interface "eth0". Note that the mapping is performed in 2 steps:

1. A mapping object "packet_port" with a name "EWA0"/"EIA0" is loaded and connected to host interface "eth0", so Charon-AXP will use this interface for its networking
2. The loaded virtual adapter "EWA"/"EIA" is connected to the "packet_port" object "EWA0"/"EIA0"

It is possible to load several DE435, DE450, DE500AA, DE500BA or DE602 controllers, for example (for DE500BA): 

 

Some network adapters available in Charon-AXP are preloaded (for example, an AlphaServer DS15 contains 2 preloaded adapters EWA and EWB), so their configuration is even more simple:

Charon supports VLAN adapters. If used, proceed with their installation and configuration according to the network adapter vendor User's Guide and then use the resulting VLAN interface the same way as the regular network interface. 

Please note:

The AlphaServer DS15 and DS25 contain two built-in PCI Ethernet adapters. Models and names (EI* or EW*) of them depend on configuration addon. Choose one of the two or none, but not both. The first instantiates onboard network interfaces as EIA and EWA. While the second - EWA and EWB (enabled by default for backward compatibility)

Example:
#include ds25-onboard-nics.icfg
include ds25-onboard-nics-ew.icfg

It could be necessary to specify the path to the .icfg file if you use your own configuration file using the "include /opt/charon/cfg/ds25-onboard-nics-ew.icfg" syntax.

Follow this link for more details of CHARON-AXP network controllers configuration.

Disk/tape subsystem

The next step is configuration of the disk/tape subsystem and mapping it to system resources using the samples given in the template configuration files.

Charon-AXP supports KZPBA and KGPSA-CA adapters.

KZPBA PCI SCSI disk/tape controller

Below is the typical configuration options for KZPBA PCI SCSI disk/tape controller:

The first line ("load KZPBA PKA") loads disk controller KZPBA with name "PKA", followed by 8 group of lines showing different ways of mapping to the host resources:

Additionally it is possible to specify a parameter "media_type" to assign the type of the attached media explicitly.

Example:

Numbers in the square brackets represent SCSI addresses and LUNs associated with each container of the KZBPA controller. They have the following structure:

[XXYY], where

It is possible to load several KZPBA controllers: DKB, DKC, etc. by configuring specific placement for them on the PCI bus. It is discussed in details in the "Configuration details" chapter of this Guide.

Some Alpha systems emulated by CHARON-AXP have already had one or two KZPBA controllers preloaded. If the system has only one preloaded controller, the template configuration file usually provides some sample line on how to add another one, for example:

Follow this link for details of KZPBA controllers configuration.

KGPSA-CA PCI FC disk controller

Optionally it is possible to configure KGPSA-CA FC disk controller.

It can be configured in 2 modes:

• CHARON-AXP for Linux configuration#KGPSA-CA mapping to the host resources
• CHARON-AXP for Linux configuration#KGPSA-CA pass through mode

Below is an example of KGPSA-CA controller loading:

Optionally another KGPSA-CA adapter can be loaded similar way:

Follow this link for details of KGPSA-CA controllers configuration.

KGPSA-CA mapping to the host resources

Below is the typical configuration options for KGPSA-CA PCI FC disk controller, mapped to the host resources ("L" is letter here):

The first line ("load KGPSA FGA") loads disk controller KGPSA with name "FGA", followed by 2 groups of lines showing different ways of mapping to the host resources:

Numbers in the square brackets represent KGPSA-CA units. They can be in the range 0..32766, but no more than 255 units can be configured on a single controller.

KGPSA-CA pass through mode

It is also possible to use the emulated KGPSA-CA in "pass through" mode to address a physical EMULEX LightPulse PCI/PCI-X/PCIe FC adapter plugged into the host’s PCI/PCI-X/PCIe slot.

The sample configuration file provides a template for this type of mapping:

Follow this link for detailed description of building and installation of an EMULEX LightPulse PCI/PCI-X/PCIe FC adapter driver.

Auto boot

Charon-AXP can be configured to automatically boot an operating system at start up by specifying the default boot device and setting the 'auto_action' parameter to 'restart' from the console.

Example: dka0 is defined as the default boot device

Network boot

Charon-AXP can be configured to boot on network if the legacy operating system allows it via MOP. MOPv3 (DECnet) and MOPv4 (LANCP) are supported.

Usage/example:

Both EW and EI adapters are supported for MOP network boot.