CHARON-AXP for Windows configuration
Table of Contents
Creation of your own configuration file using a template
By default, all the CHARON templates are located in the "C:\Program Files\CHARON\Build_XXXXX\x64" folder. Copy the appropriate template configuration file(s) to your home directory (or to any directory intended for CHARON-AXP).
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 "Notepad" editor (or use the "CHARON Launcher" utility to open the configuration file) and proceed with modification 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: lines preceeded by the comment sign "#" inside the configuration files will not be interpreted. You can use this sign to debug your configuration.
HP Alpha model specification
The first configuration statement is the specification of the exact HP Alpha hardware model to emulate, for 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:
|
You can optionally uncomment this line to differentiate this CHARON-AXP instance from all others in a multi-instance environment. The configuration name can be any label that is meaningful.
It is possible to specify a configuration name containing spaces, in this case use quotation marks:
set session configuration_name = "My ES40" |
The configuration name 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.
Here is an example of a field test CHARON-AXP log file:
20151020:103504:INFO :0:00000249:ethane.cxx(9611): Logging started. |
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". This means that a new default log file is always created each time CHARON starts and can switch to another log file if the size of the log file exceeds 64Kb.
This mode is turned on if all the log parameters above are disabled (commented out) or the "session_log" parameter is pointing to a directory rather than to a file. If a directory is specified, the log files will be created in that directory.
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" to separate log files with the same time of creation.
Only existing directory can be used as a value of the "log" parameter.
Single log
Alternatively it is possible to use just 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 specifying "log_method = append" (*recommended for reporting issues*) or overwritten, specifying "log_method = overwrite".
Below is a specification of a CHARON-AXP log file located in the "C:\CHARON logs" directory which will be overwritten 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.
|
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 HP 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 setting reserves host CPUs (of those specified by “affinity” parameter, if any) for use by the emulator for I/O handling. By default the emulator instance reserves one third of available host CPUs for I/O processing (round 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 must correspond to the total number of available for CHARON CPUs (restricted by "affinity" parameter if needed) and the number of the virtual HP Alpha CPUs to be emulated.
Setting a specific HP Alpha model
CHARON-AXP allows to specify an exact model of HP Alpha.
For example for HP AlphaServer ES40 family the "es40.cfg" sample configuration file contains the following options:
#============================================================================ #set ace cpu_architecture = EV6 #============================================================================ set ace cpu_architecture = EV67 |
Just uncomment the provided lines to apply a certain model (It is "AlphaServer ES40 6/667" in the example above).
Full description of the parameters and other models that can be also configured is available in the "Configuration details" chapter of this User's Guide.
Reducing number of emulated CPUs
If CHARON host contains not enough CPUs to emulate full range of the CPUs provided by a certain HP Alpha model it is possibe to direct CHARON-AXP to reduce number of the emulated Alpha CPUs in the configuration:
|
Setting system serial number
The next configuration option that can be applied is setting 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 HP 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, 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:
#set ram size=4096 |
The amount of RAM is specified in MB. It cannot exceed or be lower than certain values specific for each HP Alpha model. It is very important to keep the listed predefined increment between possible memory values.
The following table shows all the parameters:
Hardware Model | RAM size (in MB) | |||
Min | Max | Default | Increment | |
AlphaServer 400 | 64 | 1024 | 512 | 64 |
AlphaServer 800 | 256 | 8192 | 512 | 256 |
AlphaServer 1000 | 256 | 1024 | 512 | 256 |
AlphaServer 1000A | 256 | 1024 | 512 | 256 |
AlphaServer 1200 | 256 | 32768 | 512 | 256 |
AlphaServer 2000 | 64 | 2048 | 512 | 64 |
AlphaServer 2100 | 64 | 2048 | 512 | 64 |
AlphaServer 4000 | 64 | 32768 | 512 | 64 |
AlphaServer 4100 | 64 | 32768 | 512 | 64 |
AlphaServer DS10 | 64 | 32768 | 512 | 64 |
AlphaServer DS15 | 64 | 32768 | 512 | 64 |
AlphaServer DS20 | 64 | 32768 | 512 | 64 |
AlphaServer DS25 | 64 | 32768 | 512 | 64 |
AlphaServer ES40 | 64 | 32768 | 512 | 64 |
AlphaServer ES45 | 64 | 32768 | 512 | 64 |
AlphaServer GS80 | 256 | 65536 | 512 | 256 |
AlphaServer GS160 | 512 | 131072 | 512 | 512 |
AlphaServer GS320 | 1024 | 262144 | 1024 | 1024 |
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 HP Alpha model.
Console
Mapping to system resources
The next step is the specification of the HP Alpha console (OPA0) serial line:
#load physical_serial_line OPA0 line="COM1:" |
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:
Option | Description | |||||||
---|---|---|---|---|---|---|---|---|
physical_serial_line | Mapping to host "\\.\COM<n>" ("COM<n>:") physical serial line. | |||||||
virtual_serial_line | Mapping to an IP port of CHARON-AXP host.
Example:
In the example above, CHARON-AXP use the IP port "10003" for the HP Alpha console and starts the "Putty" terminal emulator (included in each CHARON distributive) with the "OPA0" saved session directing it to connect to the IP port "10003". If the terminal emulator is closed, it is always possible to reopen it with the "Show Console" command from the CHARON system tray icon: |
The default setting is "load virtual_serial_line/chserial OPA0 port=10003 application="putty.exe -load OPA0".
The second console line "TTA0" can be also optionally configured (for 1 CPU models such as HP AlphaServer 400, HP AlphaServer 800, HP AlphaServer 1000, HP AlphaServer 1000A, HP AlphaServer DS10, HP AlphaServer DS10L and HP AlphaServer DS15):
|
Note there are a number of additional parameters for CHARON-AXP serial lines configuration. Follow this link for details.
Exit on pressing F6 button
Despite the fact that CHARON-AXP can exit with "power off" command given in its SRM console it is also recommended to set a hot key to stop the guest from the console in addition to the system tray icon:
set OPA0 stop_on = F6 |
This line provides CHARON-AXP the ability to exit by pressing the "F6" button.
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.
ATAPI CD/DVD-ROM configuration
If the sample configuration file provides this parameter it is possible to map this particular CHARON-AXP emulator's "DQA0" CD-ROM to the host CD/DVD-ROM with the following setting:
|
Networking
CHARON-AXP supports DE435, DE450, DE500AA, DE500BA, DE602 and DE602AA virtual network adapters.
All of them are configured in a similar way:
|
load DE602/i8255x EIA interface=EIA0 load packet_port/chnetwrk EIA0 interface="connection:Charon" |
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 having a name "Charon" ("connection" is a key word). Note that the mapping is performed in 2 steps:
- A mapping object "packet_port" with a name "EWA0"/"EIA0" is loaded and connected to host interface having a name "Charon", so CHARON-AXP will use this interface for its networking
- The loaded DE500BA/DE602 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, HP AlphaServer DS15 contains 2 preloaded adapters EWA and EWB), so their configuration is even more simple:
|
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:
- File representing a physical disk of the HP Alpha system (disk image)
"<file-name>.vdisk"
These files can be created from scratch with "MkDisk" utility. Data and OS disks backups are transferred from the original system via tapes or network and restored into these container files.
Mapping may also include the full path (recommended), for example: "C:\My disks\my_boot_disk.vdisk"Using compressed folders to store virtual disks and tapes is not supported
.
- Physical disk
- "\\.\PhysicalDrive<N>"
Be careful not to destroy all the information from the disk dedicated to CHARON-AXP by mistake.These disks must not be formatted by the host OS.
.
- "\\.\PhysicalDrive<N>"
- Physical disk by its WWID
- "\\.\PhysicalDrive(DevID =XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX)"
Be careful not to destroy all the information from the disk dedicated to CHARON-AXP by mistake.These disks must not be formatted by the host OS.
DevID addresses the target physical disk by its WWID (hexadecimal 128-bit identifier assigned to the disk drive by its manufacturer/originator).
Example:
set PKA container[100]="\\.\PhysicalDrive(DevID= 6008-05F3-0005-2950-BF8E-0B86-A0C7-0001)"
.
- "\\.\PhysicalDrive(DevID =XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX)"
- iSCSI disks
"\\.\PhysicalDrive(iScsiTarget = <iSCSI target>, LUN = <LUN number>)"
Parameter Description iScsiTarget Addresses the disk by its iSCSI target name. LUN Specifies LUN on connected iSCSI disk. Example:
set PKA container[200]="\\.\PhysicalDrive(iScsiTarget= iqn.2008-04:iscsi.charon-target-test1, LUN= 1)"
.
- SCSI device unknown to Windows for direct mapping, for example, a SCSI disk or tape reader
"\\.\Scsi<N>:<X>:<Y>:<Z>"
The values of N, X, Y and Z can be collected using special utility "Host Device Check" included in the CHARON distributive - or manually by investigation of the devices connected to CHARON host in the "Device Manager" applet.Parameter Description N A logical number assigned by host operating system (Microsoft Windows) to logical or host’s physical storage resource such as physical SCSI HBA X An internal SCSI bus number (usually 0) on host’s physical SCSI HBA Y A SCSI ID of physical SCSI target device attached to host’s physical SCSI HBA Z A logical unit number inside physical SCSI target device attached to host’s physical SCSI HBA .
- CD-ROM device
- "\\.\CdRom<N>"
.
- "\\.\CdRom<N>"
- ISO file for reading distribution CD-ROM image
- "<file-name>.iso"
Mapping may also include the full path (recommended), for example: "C:\My disks\vms_distributive.iso"
.
- "<file-name>.iso"
- Host tape device
- "\\.\Tape<N>"
.
- "\\.\Tape<N>"
- File representing the tape (tape image)
"<file-name>.vtape"
These files are created automatically.
Mapping may also include a full path (recommended), for example: "C:\My tapes\backup.vtape"Using compressed folders to store virtual disks and tapes is not supported
.
- Floppy drive
- "\\.\A:"
.
- "\\.\A:"
- Other type of drive, for example magneto-optical drive
- "\\.\<N>:"
.
- "\\.\<N>:"
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
Parameter | Range | Description | |
---|---|---|---|
XX | 0...15 | Stands for SCSI ID of each connected unit. Note that KZPBA itself has some ID associated with it. By default it is 7, but it can be changed in the following way:
In this example an instance "PKA" of KZPBA controller is assigned with SCSI ID 0. | |
YY | 00...07 | Stands for LUN. |
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 HP Alpha systems emulated by CHARON-AXP have already had one or two KZPBA controllers pre-loaded. 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:
load KZPBA PKA bus=pci_1 device=1 function=0 irq_bus=isa irq=24 |
Follow this link for details of KZPBA controllers configuration.
Back to Table of Contents
KGPSA-CA PCI FC disk controller
Optionally it is possible to configure KGPSA-CA FC disk controller.
It can be configured in 3 modes:
- Direct mapping to the host resources
- Usage of "presentation mode" of connected or external storage controllers
- 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.
Back to Table of Contents
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:
|
The first line ("load KGPSA FGA") loads disk controller KGPSA with name "FGA", followed by 2 group of lines showing different ways of mapping to the host resources:
- File representing a physical disk of the HP Alpha system (disk image)
"<file-name>.vdisk"
These files can be created from scratch with "MkDisk" utility. Data and OS disks backups are transferred from the original system via tapes or network and restored into these container files.
Mapping may also include the full path (recommended), for example: "C:\My disks\my_boot_disk.vdisk"Using compressed folders to store virtual disks and tapes is not supported
.
- Physical disk
- "\\.\PhysicalDriveN"
Be careful not to destroy all the information from the disk dedicated to CHARON-AXP by mistake.These disks must not be formatted by the host OS.
.
- "\\.\PhysicalDriveN"
- Physical disk by its WWID
- "\\.\PhysicalDrive(DevID =XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX)"
Be careful not to destroy all the information from the disk dedicated to CHARON-AXP by mistake.These disks must not be formatted by the host OS.
DevID addresses the target physical disk by its WWID (hexadecimal 128-bit identifier assigned to the disk drive by its manufacturer/originator).
Example:
set PKA container[100]="\\.\PhysicalDrive(DevID= 6008-05F3-0005-2950-BF8E-0B86-A0C7-0001)"
.
- "\\.\PhysicalDrive(DevID =XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXX)"
- iSCSI disks
"\\.\PhysicalDrive(iScsiTarget = <iSCSI target>, LUN = <LUN number>)"
iScsiTarget addresses the disk by its iSCSI target name. LUN specifies LUN on connected iSCSI disk.Example:
set PKA container[200]="\\.\PhysicalDrive(iScsiTarget= iqn.2008-04:iscsi.charon-target-test1, LUN= 1)"
.
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.
Back to Table of Contents
KGPSA-CA mapping to a storage controller using its "presentation" mode
Some storage controllers allows CHARON-AXP to use their resources using so called "presentation" mode.
In this type of mapping CHARON-AXP automatically creates a set of virtual FC devices for each of the units provided by the storage controller and connects to them through its KGPSA-CA FC adapter.
The main benefit in this type of mapping is a flexible way of the virtual disks management depending on the mapped storage controller configuration. For example if an extra disk is added to the storage controller it automatically appears as a new disk unit on the corresponding KGPSA-CA virtual adapter mapped to that storage controller.
Below is an example of KGPSA-CA PCI FC disk controller, mapped to some storage controller (for example SAN) using its "presentation" mode:
|
This line loads an instance of KGPSA-CA controller and maps it to some external controller having ID "5008-05F3-0005-2950-5008-05F3-0005-2951".
Type of mapping | Description |
---|---|
storage_controller_path_id = <Storage controller path ID> | "Storage controller path ID" is a storage (for example SAN) controller path ID. This ID can be obtained from the special utility "Host Device Check". Once specified, all the disks attached to the storage are automatically mapped as disk units to CHARON-AXP. |
Back to Table of Contents
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:
|
The "host_bus_location" parameter addresses the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter in the following way:
Parameters | Description |
---|---|
"PCI bus X" | PCI bus number of the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
"device Y" | PCI bus device number of the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
"function Z" | The "function" parameter of the the host EMULEX LightPulse PCI/PCI-X/PCIe FC adapter |
To establish "pass through" mode do the following:
- Install the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter (see below for a list of supported models) to some spare PCI/PCI-X/PCIe slot of the host system
- Boot a Windows operating system
- Install the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter driver from the following directory "C:\Program Files\CHARON\Drivers\EMULEX_X.X.0.XXXXX" by choosing the "Install from a list or specific location (Advanced)" option and then selecting the "emulex_lp_ppt_amd64.inf" file.
- Reboot the host
Now it is possible to collect the parameters for CHARON-AXP mapping to the EMULEX LightPulse PCI/PCI-X/PCIe FC adapter.
Open “Computer Management” application and select “Device Manager”:
On the right panel select desired physical EMULEX LP FibreChannel adapter under "CHARON PCI Pass Through":
Open its properties sheet by double-clicking on selected adapter:
The “Location:” on the above picture gives X, Y, and Z for the "host_bus_location" parameter, for example:
|
Non-US-EN installations of Windows may present “Location:” string in local language, but "host_bus_location" parameter requires English notation, so the words “PCI”, “bus”, “device”, and “function” must be specified in English.
The following is the list of EMULEX LightPulse PCI/PCI-X/PCIe FC adapters supported by CHARON-AXP PCI Pass Through driver and suitable for emulation ofKGPSA-CA PCI FC adapter in CHARON PCI Pass Through mode:
Supported | Not Supported | Not tested |
---|---|---|
LP8000 | LPe1150 (FC2142SR, A8002A) | LPe11000 |
Back to Table of Contents
FDDI support via DEFPA PCI FDDI controller in "pass through" mode
Optionally it is possible to configure DEFPA PCI FDDI controller in "pass through" mode, mapped to a physical DEFPA FDDI adapter installed on the host:
|
Pay attention to proper placement of the emulated DEFPA adapter on the virtual HP Alpha PCI bus (it is controlled by "bus", "device", "function", "irq" and "irq_bus" parameters). Refer to this chapter of this Guide for more information.
The "host_bus_location" parameter addresses the host DEFPA FDDI adapter in the following way:
Parameters | Description |
---|---|
"PCI bus X" | PCI bus number of the host DEFPA FDDI adapter |
"device Y" | PCI bus device number of the host DEFPA FDDI adapter |
"function Z" | The "function" parameter of the the host DEFPA FDDI adapter |
To establish the "pass through" mode do the following:
- Install the DEFPA FDDI adapter to some spare PCI slot of the host system.
Note that PCIe and PCI-X are not supported by the DEFPA FDDI adapter. - Boot a Windows operating system
- Install the DEFPA FDDI adapter driver from the following directory: "C:\Program Files\CHARON\Drivers\DEFPA_X.X.X.XXXXX" by choosing the "Install from a list or specific location (Advanced)" option and then selecting the "defpa_ppt_amd64.inf" file.
- Reboot the host
Now it is possible to collect the parameters for CHARON-AXP mapping to the DEFPA FDDI host adapter.
Open “Computer Management” application and select “Device Manager”:
On the right panel select the installed DEFPA adapter:
Open its properties sheet by double-clicking on the selected adapter:
The “Location:” on the above picture gives X, Y, and Z for the "host_bus_location" parameter, for example:
|
Non-US-EN installations of Windows may present “Location:” string in local language, but "host_bus_location" parameter requires English notation, so the words “PCI”, “bus”, “device”, and “function” must be specified in English.
Back to Table of Contents
Serial lines support via emulated PBXDA-xx family PCI controllers in "pass through" mode
Optionally it is possible to configure the folIowing models of PBXDA-xx family controllers mapped to specific models of the physical DIGI serial lines adapters installed on CHARON-AXP host:
DEC PBXDA-xx adapter | Name of the device to map to | Controller | Vendor ID | Device ID |
---|---|---|---|---|
PBXDA-BA | DIGI AccelePort 4r 920 | ASIC PCI | 114Fh | 0026h |
PBXDA-BB | DIGI AccelePort 8r 920 | ASIC PCI | 114Fh | 0027h |
PBXDA-AC | DIGI AccelePort Xem | ASIC PCI | 114Fh | 0004h |
PBXDA-AC | DIGI AccelePort Xem | ASIC PCI | 114Fh | 0008h |
Below is an example of mapping to a physical DIGI adapter installed on the host:
|
Pay attention to proper placement of the emulated PBXDA-xx adapter on the virtual HP Alpha PCI bus (it is controlled by "bus", "device", "function", "irq" and "irq_bus" parameters). Refer to this chapter of this Guide for more information.
The "host_bus_location" parameter addresses the host DIGI adapter in the following way:
Parameters | Description |
---|---|
"bus X" | PCI bus number of the host DIGI adapter |
"device Y" | PCI bus device number of the host DIGI adapter |
"function Z" | The "function" parameter of the the host DIGI adapter |
To establish the "pass through" mode do the following:
- Install the DIGI adapter of the required type to some spare PCI/PCI-X/PCIe slot of the host system.
- Boot a Windows operating system
- Install the DIGI adapter driver from the following directory: "C:\Program Files\CHARON\Drivers\DIGI_X.X.X.XXXXX" by choosing "Install from a list or specific location (Advanced)" option and then selecting the "digi_ppt_amd64.inf" file.
- Reboot the host
Now it is possible to collect the parameters for CHARON-AXP mapping to the DIGI host adapter.
Open “Computer Management” application and select “Device Manager”:
On the right panel select proper physical DIGI adapter:
Open its properties sheet by double-clicking on the selected adapter:
The “Location:” on the above picture gives X, Y, and Z for the "host_bus_location" parameter, for example:
|
Non-US-EN installations of Windows may present “Location:” string in local language, but "host_bus_location" parameter requires English notation, so the words “PCI”, “bus”, “device”, and “function” must be specified in English.
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
|
© Stromasys, 1999-2024 - All the information is provided on the best effort basis, and might be changed anytime without notice. Information provided does not mean Stromasys commitment to any features described.