| |
|
|
|
8 REFERENCE
8.1 User Commands Reference
The following sections contain - in alphabetical order - the manual pages for the user commands included in the interface of the modules:
This command creates an environment directory from scratch.
All files are copied from a template corresponding to <type>.
However, the created files are not configured in any way.
This must be done explicitly with dedicated tools.
Arguments can either be put on the command-line directly,
or will be asked interactively.
When prompted for input, the default will be shown in square brackets.
<env> Name of the environment.
If not given then interactive input is expected.
<type> Type of the environment: LCU | RTAP | QSEMU
Default: derived from <env> as follows:
if <env> matches "l*" then LCU
else if <env> matches "w*qs" then QSEMU
else if <env> matches "w*" then RTAP
else error
<dest> Directory under which environment files shall be created.
This must not already exist!
Default: $VLTDATA/ENVIRONMENTS/<env>
$VLTROOT/templates/forEnvs/<type> - source template directories
$VLTDATA/ENVIRONMENTS/<env> - default target directory
> envsCreate -e wt1tcs
> envsCreate
Enter Environment Name []: wt1tcs
Enter Target Directory Name [/vlt/data/ENVIRONMENTS/wt1tcs]: ./wt1tcs
Enter Type of Environment (LCU,RTAP,QSEMU) [RTAP]:
creating RTAP environment wt1tcs under "./wt1tcs" ...
setting default protection of "./wt1tcs" ...
This program has to be started up with every RTAP environment used for
engineering purposes.
When envsKill gets the Command KILLENV it will send a mail to the
owner that started the environment and wait for 4 minutes.
Within this grace period owner can inhibit the pending shutdown by simply
killing envsKill
After the 4 minutes the environment is shut down.
KILLENV <user name>
Username has to be a valid user name, which is propagated to
the owner of the environment.
Error handling should be improved!
As the command KILLENV would take about 5 minutes if it was synchronous
it returns immediately and doesn't wait until the shutdown.
The killer has to watch completion of the environment shutdown otherwise.
This panel allows to generate the most important files needed
for an LCU environment, in particular:
- the boot-script executed by the LCU upon start-up
- the processes-file used by engineering interfaces
If an explicit <environment-name> is given at the command-line,
then it is immediately selected and the panel's contents is updated
from the current configuration files, when present.
Otherwise it can be selected interactively.
The following sections describe the usage of each corresponding
section in the panel.
The first action must always be the selection of the LCU environment
that shall be modified. This is done by selection from the menu
at the top left in the panel. The derived values like node-name,
IP-address and associated boot-host are queried from the central
configuration database - see VccInfo(n) - provided it is active.
Otherwise these values have to be typed in.
The "Target LCU" parameters refer to the environment as a whole
and to the booting interface of it. In case of slave CPU systems
this may not be obvious; see MULTIPLE CPU SYSTEMS for more.
The "Boot WS" environment can be arbitrarily selected.
Remote file operations are performed if the "Boot Host" is not
identical to the workstation where this panel is running on.
Note that these remote accesses are much slower that local accesses.
"Target LCU" - values related to the LCU to be configured
"Boot WS" - values related to the WS the LCUs boots from
"Environment" - name of the environment, as "lt1alt", "wt1tcs"
"Host" - host where the environment is located
"IP Address" - IP address of that host, eg. "11.22.33.44"
"TCP Port" - assigned TCP port number of the environment
"CPU" - CPU name, eg. "MC68040"; must match "vw/bin/<cpu>"
"Host Type" - architecture of the host, eg. "68k" (for info only)
When a new "Target LCU Environment" is selected, the corresponding
values will be queried from the configuration database as far as
available. If defined, also the "Boot WS" is automatically selected.
Similarly, when a new "Boot WS Environment" is selected, the values
are queried, and the available modules are updated as if the "Reset"
button in the MODULES CONFIGURATION section was pressed (see there).
"Boothome" - directory where the environment resides
"VXROOT" - VxWorks target root directory
"BSP" - VxWorks board-support-package name, eg. "mv167".
Values as "mv167-p0" indicate master/slave versions.
See MULTIPLE CPU SYSTEMS for special issues.
BOOTHOME is derived from VLTDATA, meaning that the -->TARGET FILES
will be read from resp. written to that area, and that the LCU will
finally boot with the boot-script located there.
The type of system is indicated with the radio-buttons:
"Single" - for a normal system with only one CPU
"Master" - for the master in the system
"Slave" - for slave #1 in the system (> 1 not supported)
The selection has only indirect effect on the BSP value,
which in turn results in the dedicated VxWorks kernel being loaded.
See MULTIPLE CPU SYSTEMS for more details.
The variables BOOTHOME, VLTROOT, and optionally INTROOT must exist
in the LCU environment. The contents of the entries is by default
set to the same values of the corresponding shell variables on the
selected "Boot WS" host. They may be edited by the user.
VLTROOT and INTROOT may reside on a different host than BOOTHOME.
Implicit NFS mounts will be done on the LCU as appropriate.
Note that path names must be given as seen from the LCU. This might
in some cases be different from the path names on the WS, eg. when
there are links in the path. Only the physical path is allowed.
Lateron, however, the LCU NFS-mount may use different local names.
"VLTROOT" - host name and physical path to the VLTROOT area
"INTROOT" - host name and physical path to the INTROOT area
The "IP" field must contain the IP address in dot-notation of
the selected host, if it is different from the "Boot WS" host.
When a new host is selected, the available modules are updated as if
the "Reset" button in the MODULES CONFIGURATION section was pressed.
The defaults in these entries will fit in most cases:
"Boot User" specifies under which user-name the LCU is accessing
the boot-script. It is usually `vx'.
"Password" specifies the password of the "Boot User".
It is usually empty, so that remote shell access is
used; otherwise FTP is applied.
"NFS User" specifies under which user ID the LCU is accessing
files via NFS. It is usually `vx'.
The first entry with the user name is only for
convenience. The second entry is the important one,
and it must contain the corresponding numeric ID.
"NFS Group" specifies under which group ID the LCU is accessing
files via NFS. It is usually the group of user `vx'.
It applies the same as for "NFS User"
"Main Host(IP)" specifies the parameters of the on-board CPU network
interface; this is usually the same as the booting
interface specified above, except for slave CPUs
which are booting over shared memory backplane.
"2nd Host (IP)" specifies the parameters of an optional network
interface, eg. additional ethernet board.
"3rd Host (IP)" dto. for further interface.
"Subnet-Mask" must be set to the network's inherent value.
"Gateway IP" is the gateway IP address to the "Boot WS" host.
It should be empty when both host are on the same net.
This value is discarded in MULTIPLE CPU SYSTEMS.
"Backplane IP" is the IP address assigned to the backplane interface.
This value is discarded in MULTIPLE CPU SYSTEMS.
The user-ID and group-ID for NFS accesses is mandatory and must be
set corresponding to a valid user on the boot-host. All valid user
and groups are permitted, by default the IDs of user "vx" are taken.
The names of modules to be loaded must be specified in the two boxes.
Modules in the "System" box are normally always needed and their
order should not be changed. Modules in the "User" box usually
require all the system-modules and are not always needed, depending
on the LCU hardware etc.
Individual changes to the lists can be done by selecting an entry and
using the buttons on the right of the boxes.
For each module listed, there must exist a module-boot-script named
"<module>.boot" in one of the directories listed in -->FILES,
which should contain the auto-loading and initialization of the
module, using the functions of lcuboot(1).
"Add below" - add the module from the entry below the selection
"Remove" - remove the selected module
"Config..." - open panel for individual module configuration
"Help..." - display help for selected module (if available)
"Reset..." - fill listboxes with all available modules. This
implies that the available module-boot-scripts on
the selected hosts (Boot WS, VLTROOT, INTROOT)
are scanned to resolve module dependencies.
For remote accesses this can take a while.
All hardware-devices on the LCU can be installed automatically,
using the facilities of lcuboot(1). The devices configuration therefore
consists only in checking that the required number of devices have
actually been installed by that procedure.
An explicit number can be given, or the special value `?' resp. `-1',
meaning that no explicit check shall be done. This is useful when
the board configuration in a LCU often changes. No modification in
the boot-script would be necessary then.
"Count" - the number of expected devices, or `-1' for auto-config
"Remove" - remove the selected device family from the listbox
"Reset" - reset the listbox to the default
This box contains the names of the LCU processes that shall be
accessible by commands via the message-system. The list is normally
only used by engineering interfaces (lccei, ccsei) to provide user-
menus, but not to restrict any access.
"Add" - add the process from the entry to the listbox
"Remove" - remove the selected process from the listbox
"Reset" - reset the listbox to the default
This box contains the names of files that shall be processed when
the action-button for "Read Files" or "Write Files" is pressed
(see -->ACTIONS).
"Reset" - reset the listbox to the default
"Remove" - omit the selected target file from any processing
"Edit..." - open an editor for the selected target file
All action buttons are disabled until an LCU environment is selected.
"Create Env" create a new set of LCU environment files under
VLTDATA on the selected boot-host. The operation
fails if the environment to be created already exists.
"Read Files" read the files listed in the "Target Files" box and
parses their contents, so that the sections in the
panel are updated accordingly.
Note that the behaviour for reading files not produced
with this tool is undefined!
"Write Files" write the files listed in the "Target Files" box
according to selections in the panel's sections.
A confirmation is requested before overwriting any
existing files.
"Configure LCU" write the boot-line according to the selections in the
panel, i.e. host-names, IP-addresses etc.;
it uses the VxWorks `bootChange' command.
See -->DIAGNOSTICS for potential failures.
"Reboot LCU" restart the LCU and execute the selected boot-script.
A transient window appears displaying the elapsed
boot time. The default waiting time before closing
the connection can be adjusted with the scale.
- NOTE THAT THE DEFAULT TIME MUST BE HIGHER THAN THE
ACTUAL BOOTING TIME, THERE IS NO SYNCHRONIZATION -
The "Close Connection" button aborts the connection
explicitly, eg. when the booting has completed.
The output during start-up is redirected to the
terminal where the panel was started from.
See -->DIAGNOSTICS for potential failures.
An LCU may contain additional "passive" network interface boards.
Each of them must be assigned with a hostname and IP address.
In such case, there must be a list of hostnames assigned to this
environment in the configuration database, where normally is only
one single hostname. The first in the list is always the on-board
main interface. The IP addresses are then resolved from the names.
Under the VxWorks shell there will be special variables defined,
which can be used by the network driver to setup the interfaces.
These are: LOCALHOST_n and LOCALIPADDRESS_n, with n = 1,2.
Up to two additional interfaces are supported.
The special case of multiple CPU systems is discussed here.
The master CPU will be configured to boot over its ethernet port,
as for a normal single CPU system. A specilized VxWorks kernel is
required in order to support booting of the slaves via the master
as gateway, see below.
The slave CPUs will be configured to boot over the backplane;
note that the hostname and IP addresses in the ENVIRONMENTS SELECTION
have to reflect this! The booting interface, and not the on-board
ethernet port, must be specified there.
By VLT convention multi-CPU systems shall use Proxy-ARP.
This implies different VxWorks kernels for master and slave CPUs,
where the following kernel options must be set:
- master CPU with proxy-server:
INCLUDE_SM_NET include backplane net interface
INCLUDE_PROXY_SERVER proxy arp server (Master Board)
INCLUDE_PROXY_DEFAULT_ADDR ethernet addr to generate bp addrs
INCLUDE_SM_SEQ_ADDR SM network auto address setup
- slave CPU with proxy-client:
INCLUDE_SM_NET include backplane net interface
INCLUDE_PROXY_CLIENT proxy arp client (Slave Board)
INCLUDE_SM_SEQ_ADDR SM network auto address setup
The VCC configuration distinguishes between master and slave CPUs
based on the value of the BSP field. If it has the form:
<basename>-p<procnum>-s<memsize>
then <memsize> indicates the CPU's decimal memory-size in MB and
<procnum> (0..15) indicates the processor-number, ie. zero
for the master and 1..15 for the slaves.
The corresponding VxWorks kernel must then exist under the
location derived from the full BSP value, see FILES.
Slave CPUs will be configured to boot over shared memory located
in the master with the SM anchor set according to the memory-size,
namely: anchor = 2 * memorysize + 0x600.
This requires corresponding and consistent configuration in
sysLib.c in the struct sysPhysMemDesc.
Due to the above mentioned kernel options, inet addresses for
backplane of master and slaves, as well as gateway of slaves will
be determined automatically by incrementing the masters ethernet
inet address. Explicit assignment of those is not supported.
When mv167 boards are booted over backplane, the on-board ethernet
interface is NOT automatically attached (although documented so).
Therefore explicit instructions are written into the bootScript
NETWORK section to do this. Note however that the ethernet i/f
will remain detached until the bootScript is executed.
VLTDATA path to VLT data area
VLTROOT path to VLT code area
INTROOT path to private integration code area (optional)
VXROOT path to VxWorks files
VLT_VCCENV name of configuration database environment (optional)
VLT_VCCBOOTTIME time in seconds after which reboot session is closed
(optional, default is 120 seconds)
VLT_VCCTIMEOUT timeout in seconds for LCU reboot with VxWorks only
(optional, default is 30 seconds)
Other variables see VccInfo(n).
Under VLTDATA the following files may be read and/or written:
ENVIRONMENTS/<env>/bootScript - boot-script for <env>
ENVIRONMENTS/<env>/userScript - user-script for <env>
ENVIRONMENTS/<env>/devicesFile - LCC software-devices for <env>
ENVIRONMENTS/<env>/PROCESSES - process-file for <env>
ENVIRONMENTS/<env>/*.boot - module-boot-scripts
Under VLTROOT or INTROOT the following files may be read only:
vw/bin/*.boot - module-boot-scripts
vw/bin/<cpuName>/*.boot - module-boot-scripts
Under VXROOT the following files may be read only:
config/<bsp>/vxWorks - VxWorks kernel
See also VccInfo(n) and lcuboot(5) for accessed files.
The -->ACTIONS "Configure LCU" and "Reboot LCU" require a `rlogin'
to the target LCU. The panel might be blocked when this remote login
fails, e.g. when another session is active on the same LCU.
To recover from this situation, the user must manually "kill" all
active rlogin processes to this LCU node.
This may also happen when the LCU has "crashed".
The action-button "Reboot LCU" does an `rlogin' to the target-LCU.
This remote-login is terminated after the time set with
VLT_VCCBOOTTIME and is not synchronized with the boot-script execution.
A message appears on stdout when the connection is finally closed.
vccEnvCreate -e <env> ...
vccEnvDelete -e <env> ...
vccEnvInit -e <env> ...
vccEnvStart -e <env> ...
vccEnvStop -e <env> ...
The `vccEnv' program family allows to create, delete, and control
environments in a uniform way, so that the environment type can be
anything of LCU, RTAP, or QSEMU, and will be automatically handled
in the correct way. Also remote operation will be done automatically
depending on the host to which the environment is assigned to.
This is done based on the information in the configuration database,
where for each environment and host all relevant data are stored.
The usual sequence during an environment life-time is:
Create --> Init --> Start <--> Stop --> Delete
^ |
|___________________|
where:
Create: create the environment files from scratch
Init: initialize and reset the environment
Start: put the environment into running state
Stop: put the environment into stopped state
Delete: remove the environment files
All programs will enter an interactive mode when called with no
arguments.
The man-pages of each individual program contain the detailed
steps that are performed, and the supported options.
The following arguments are supported in principle everywhere,
but some of them will be ignored by several programs.
If no value is given, then the default will be taken from the
configuration database, or queried in some other way.
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
If not given, then interactive input is expected.
<type> Type of environment: LCU | RTAP | QSEMU
default_1: as defined in configuration database
default_2: derived from <env>
<host> Name of the WS host where environment files shall reside.
default_1: as assigned in configuration database
default_2: local host
For LCU environments this can also be a colon-separated
list of not more than four hosts (all are optional),
meaning "<boot-host>:<vlt-host>:<int-host>:<mod-host>".
They refer to the host where VLTROOT, INTROOT, and MODROOT
reside, and default to <boot-host> if omitted.
All given hosts are then NFS-mounted in the LCU.
<dest> Name of destination directory,
default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
<src> Name of directory to be used as user-template.
Must be prefixed with "<host2>:" if not residing on <host>.
All files and directories under this path will be merged
with the standard template and have priority.
At least one file must be in this directory.
Note that there is a special handling of LCU bootScript files,
and that dbl files are not modified to match for <env>!
Default: no user-template
<lcu-host> For LCU environments the node-name of the LCU host
can be specified.
Default: as assigned in configuration database
<ws-env> For LCU environments the name of the assigned WS boot
environment can be specified.
Default: as assigned in configuration database
<mods> For LCU environments the user-modules to be loaded can be
specified by a colon-separated list of module names,
eg. "inducer:mot". System- and user-modules are automatically
distinguished.
The list can also contain the special keywords "minimum"
or "maximum" to request a standard system modules
configuration with either a minimal or maximal set of modules.
The single keyword "template" causes the module-configuration
to be propagated from the user-template <src>.
The -m option can also be given more than once.
The following options may be given:
-i(nteractive) asks for input
-j(nteractive) "pseudo-interactive" on display, but no input required
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
All programs use rcp(1) and remsh(1)/rsh(1) for remote file access.
It must be made sure that all relevant environment variables are
defined while the r-command executes on the remote host.
They should therefore be set in "~/.cshrc" or equivalent rc-files.
See VccInfo(n) for configuration database related environment.
vccEnvCreate(1), vccEnvDelete(1), vccEnvInit(1),
vccEnvStart(1), vccEnvStop(1),
VccInfo(n),
rcp(1), remsh(1), rsh(1)
Checks the environment <env> with the following steps:
1. check existence of directory <dest>
2. check essential global configuration files for <env>
(this is only a rough check, no precise parsing!)
3. send PING command to all essential environment processes, i.e.
for LCU: lccServer msgServer rdbServer
for RTAP and QSEMU: cmdManager msgServer logManager
Note that an OK result cannot guarantee that the environment is
running properly in all respects.
Only a FAILED result ensures that the environment is NOT OK.
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
Mandatory, no default.
<host> Name of the host where environment files reside,
default_1: as assigned in configuration database
default_2: local host
<dest> Name of destination directory,
default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
The following option may be given in any combination:
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
The system configuration files are not updated!
This should be done by updating the configuration database, and then
generating the configuration files using vccMake(1).
Files under the directory given by <dest> are read.
Depending on the type of environment also:
/etc/services
/etc/hosts
/etc/$RTAPROOT/RtapEnvList (Rtap >= 6.7) or $RTAPROOT/etc/RtapEnvList
$VLTDATA/config/logLCU.config
$VLTDATA/config/CcsEnvList
vccEnvCreate -e <env> [-t <type>] [-h <host>] [-d <dest>] [-s <src>]
vccEnvCreate ... -l <lcu-host> -w <ws-env> -m <mods>:... (for type LCU)
vccEnvCreate -i (interactive)
Creates the environment directory and files for the given <type>.
All directories and files are created on <host> under the
directory <dest> from the standard template, optionally taking
<src> as additional higher prioritzed user template.
<dest> must not already exist.
Created files are not fully configured, ie. depending on <type>
they may have to be edited or processed with dedicated tools in
order to make them fully usable.
Detailed actions depending on <type> are:
LCU: 1. create files from standard template and set protections
2. merge with user-defined template from <src>
3. make database
4. target-specific bootScript configuration
RTAP: 1. create files from standard template and set protections
2. merge with user-defined template from <src>
3. make database
QSEMU: 1. create files from standard template and set protections
2. merge with user-defined template from <src>
3. make database
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
If not given, then interactive input is expected.
<type> Type of environment: LCU | RTAP | QSEMU
default_1: as defined in configuration database
default_2: derived from <env>
<host> Name of the host where environment files shall reside,
default_1: as assigned in configuration database
default_2: local host
For LCU environments this can also be a colon-separated
list of not more than four hosts (all are optional),
meaning "<boot-host>:<vlt-host>:<int-host>:<mod-host>".
They refer to the host where VLTROOT, INTROOT, and MODROOT
reside, and default to <boot-host> if omitted.
All given hosts are then NFS-mounted in the LCU.
See ENVIRONMENT for these variables, and CAUTIONS for MODROOT.
<dest> Name of destination directory.
For off-line creation (ie. on another machine than <host>)
it can be prefixed with "<desthost>:" so that the files are
created on <desthost> and can later be moved to <host>.
A warning will be generated in such a case.
If "<desthost>:" (remark the colon) is given, then the
path may also be omitted so that the default is taken.
Default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
<src> Name of directory to be used as user-template.
Must be prefixed with "<host2>:" if not residing on <host>.
All files and directories under this path will be merged
with the standard template and have priority.
At least one file must be in this directory.
Note that there is a special handling of LCU bootScript files,
and that dbl files are not modified to match for <env>!
Default: no user-template
<lcu-host> For LCU environments the node-name of the LCU host
can be specified.
Default: as assigned in configuration database
<ws-env> For LCU environments the name of the assigned WS boot
environment can be specified.
Default: as assigned in configuration database
<mods> For LCU environments the user-modules to be loaded can be
specified by a colon-separated list of module names,
eg. "inducer:mot". System- and user-modules are automatically
distinguished.
The list can also contain the special keywords "minimum"
or "maximum" to request a standard system modules
configuration with either a minimal or maximal set of modules.
The single keyword "template" causes the module-configuration
to be propagated from the user-template <src>.
The -m option can also be given more than once.
The following option may be given in any combination:
-i(nteractive) asks for input
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
The system configuration files are not updated for the new environment!
This should be done by updating the configuration database, and then
generating the configuration files using vccMake(1).
MODROOT: it will be problematic to define MODROOT dynamically!
All xxxROOT/DATA environment variables shall be defined during
the shell rc routines (.cshrc etc.) to allow remote operation.
Otherwise they may be left undefined and produce unexpected results.
Files under the directory given by <src> are read.
Files under the directory given by <dest> are written.
You must have priviledge to write the specified target file(s),
otherwise the operation will fail.
The mode and owner of the generated file will be set to
world-readable and group-writable, unless otherwise noted.
See ENVIRONMENTS_<type>(5) for detailed target-file lists.
Create LCU environment in interactive mode (with error):
> vccEnvCreate
vccInfo: connected to VCC database at wte49
usage: vccEnvCreate [-iqv] -e <env> [...]
(will use interactive mode now, enter -- to continue non-interactive)
Enter Environment Name []: lte41
Enter Type of lte41 (LCU,RTAP,QSEMU) [LCU]:
Enter LCU Host of lte41 [te41]:
Enter WS Boot Environment of lte41 [wte49]:
Enter WS Host of wte49 [te49]:
Enter Home Directory of lte41 on te49 [$VLTDATA/ENVIRONMENTS/lte41]:
Enter Template Directory for lte41 (host:path) []:
Enter that you are sure to continue (yes,no)? [no]: yes
vccEnvCreate: copy standard template to "/vlt/data/ENVIRONMENTS/lte41" ...
vccEnvCreate@te49: Error: failed to copy standard template to "..."
envsCreate: /vlt/data/ENVIRONMENTS/lte41 already exists
Create LCU environment named `lt0hb' on host `te49',
with NFS mount of VLTROOT on the same host, and INTROOT on te13:
> vccEnvCreate -e lt0hb -h te49::te13 -w wte49
vccInfo: connected to VCC database at wte49
vccEnvCreate: copy standard template to "/vlt/data/ENVIRONMENTS/lt0hb" ...
vccEnvCreate: make database from "/vlt/data/ENVIRONMENTS/lt0hb/dbl" ...
vccEnvCreate: make DB branch world writable ...
vccEnvCreate: generate bootScript using: minimum ...
vccEnvCreate: generate bootChange sequence scripts ...
Create RTAP environment named `wte4910' using `wte49' as template:
> vccEnvCreate -e wte4910 -s /vlt/data/ENVIRONMENTS/wte49
vccInfo: connected to VCC database at wte49
vccEnvCreate: copy standard template to "/vlt/data/ENVIRONMENTS/wte4910"
vccEnvCreate: merge with template from "/vlt/data/ENVIRONMENTS/wte49" ...
vccEnvCreate: make database from "/vlt/data/ENVIRONMENTS/wte4910/dbl" ...
vccEnvCreate: make DB branch world writable ...
vccEnv(1), vccMake(1), envsCreate(1),
ENVIRONMENTS_LCU(5), ENVIRONMENTS_RTAP(5), ENVIRONMENTS_QSEMU(5),
Deletes the environment directory and files for <env>.
All files on <host> under the directory <dest> are deleted.
To be sure that the environment is stopped before, use vccEnvStop(1).
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
Mandatory, no default.
<host> Name of the host where environment files reside,
default_1: as assigned in configuration database
default_2: local host
<dest> Name of destination directory.
For off-line deletion (ie. on another machine than <host>)
it can be prefixed with "<desthost>:" so that the files are
deleted on <desthost> rather than <host>.
A warning will be generated in such a case.
If "<desthost>:" (remark the colon) is given, then the
path may also be omitted so that the default is taken.
Default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
The following option may be given in any combination:
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
The system configuration files are not updated!
This should be done by updating the configuration database, and then
generating the configuration files using vccMake(1).
Files under the directory given by <dest> are deleted.
You must have priviledge to write the target directory and file(s),
otherwise the operation will fail.
Delete RTAP environment named `wte49':
> vccEnvDelete -e wte49
vccInfo: connected to VCC database at wte49
vccEnvDelete: locate environment directory "/vlt/data/ENVIRONMENTS/wte49"
vccEnvDelete: unprotect env files under "/vlt/data/ENVIRONMENTS/wte49"
vccEnvDelete: delete env files under "/vlt/data/ENVIRONMENTS/wte49"
Initializes the environment <env> of the given <type>.
Detailed actions depending on <type> are:
LCU: 1. remove snapshot file
2. configure boot-line with bootChange(1), reboot
RTAP: 1. create empty database from *.empty snapshots
2. load database from DB branch into snapshots
3. restore normal RtapEnvTable
QSEMU: 1. remove snapshot file
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
Mandatory, no default.
<type> Type of environment: LCU | RTAP | QSEMU
default_1: as defined in configuration database
default_2: derived from <env>
<host> Name of the host where environment files reside,
default_1: as assigned in configuration database
default_2: local host
<dest> Name of destination directory,
default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
The following option may be given in any combination:
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
This program calls vccRemExpect(1) to execute remote commands,
which requires the `expect' interpreter.
Files under the directory given by <dest> may be modified.
You must have priviledge to write the target directory and file(s),
otherwise the operation will fail.
Initialize LCU environment named `lte41' (also increase the rlogin
timeout to 20 seconds because of slow network or so):
> setenv VLT_VCCTIMEOUT 20
> vccEnvInit -e lte41
vccInfo: connected to VCC database at wte49
vccEnvInit: execute bootChange sequence on LCU te41 and reboot ...
Initialize RTAP environment named `wte49':
> vccEnvInit -e wte49
vccInfo: connected to VCC database at wte49
vccEnvInit: create empty database in "/vlt/data/ENVIRONMENTS/wte49"
vccEnvInit: load database from DB branch ...
vccEnvInit: restore normal RtapEnvTable ...
Starts the environment <env> of the given <type>.
Detailed actions depending on <type> are:
LCU: 1. reboot LCU with VxWorks only
2. install bootScript in boot-line with bootChange(1)
3. execute bootScript
In case of interactive mode (see OPTIONS -j), a pop-window
is exposed to display the output during booting.
RTAP: 1. run RtapScheduler(1) in background
2. wait and check for correct start-up of RtapScheduler
3. wait and check for full database start-up
QSEMU: 1. run ccsScheduler(1) in background
2. wait and check for correct start-up of ccsScheduler
3. wait and check for full database start-up
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
Mandatory, no default.
<type> Type of environment: LCU | RTAP | QSEMU
default_1: as defined in configuration database
default_2: derived from <env>
<host> Name of the host where environment files reside,
default_1: as assigned in configuration database
default_2: local host
<dest> Name of destination directory,
default: "$VLTDATA/ENVIRONMENTS/<env>" on <host>
The following option may be given in any combination:
-i(nteractive) asks for input
-j(nteractive) "pseudo-interactive" (no input, only pop-up window)
-j<timeout> dto. but pop-up window is automatically deleted
after <timeout> seconds after completion of start.
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
This program calls vccRemExpect(1) to execute remote commands,
which requires the `expect' interpreter.
Do not try to start QSEMU environments on systems that are
not installed with CCS-lite!
Files under the directory given by <dest> are read.
A temporary file is used to store the LCU reboot output.
VLT_VCCBOOTTIME specifies the timeout in seconds to be used for
LCUs while waiting for bootScript completion.
If not defined, then the default is 120 seconds.
DISPLAY (optional) for display of pop-up window during LCU reboot.
See also vccEnv(1).
Start LCU environment named `lte41', also set timeout to complete
booting to 100 seconds:
> setenv VLT_VCCBOOTTIME 100
> vccEnvStart -e lte41
vccInfo: connected to VCC database at wte49
vccEnvStart: reboot LCU te41 with VxWorks only ...
vccEnvStart: install bootScript in boot-line on LCU te41 ...
vccEnvStart: execute bootScript on LCU te41 (timeout: 100 s) ...
Start RTAP environment named `wte49':
> vccEnvStart -e wte4910
vccInfo: connected to VCC database at wte49
vccEnvStart: run RtapScheduler in background ...
RTAP/Plus Copyright (c) Hewlett-Packard (Canada) Ltd. 1988-1994
All rights reserved.
Real-Time Applications Platform (RTAP/Plus) release A.06.60
CCS Shared Memory (Id = 828) : ACTIVE
Stops the environment <env> of the given <type>.
Detailed actions depending on <type> are:
LCU: 1. uninstall bootScript in boot-line with bootChange(1)
2. reboot the system with VxWorks only
RTAP: 1. shutdown with RtapShutdown(1) or envsKill(1)
QSEMU: 1. shutdown with ccsShutdown
<env> Name of environment, eg. lt1hb, wt1tcs, wte1qs
Mandatory, no default.
<type> Type of environment: LCU | RTAP | QSEMU
default_1: as defined in configuration database
default_2: derived from <env>
<host> Name of the host where environment files reside,
default_1: as assigned in configuration database
default_2: local host
The following option may be given in any combination:
-q(uiet) inhibits output to stdout
-v(erbose) outputs more information than normally
This program calls vccRemExpect(1) to execute remote commands,
which requires the `expect' interpreter.
Stop LCU environment named `lte41':
> vccEnvStop -e lte41
vccInfo: connected to VCC database at wte49
vccEnvStop: uninstall bootScript and reboot te41 with VxWorks only
8.2 Functions Reference
The following sections contain - in alphabetical order - the manual pages for the functions and macros included in the programmatic interface of the modules.
lcubootAutoDrv,
lcubootAutoDevRegister,
lcubootAutoDrvInstall,
lcubootAutoDevCreate,
lcubootAutoDevCheck
- Automatic LCU Driver and Device Installation Facility
int lcubootAutoDevRegister(const char *devName,
int addrSpace, void *busAddr,
int lccArg1, ... lccArg3)
int lcubootAutoDrvInstall(const char *moduleName,
int numDevices,
const char *drvFuncName,
const char *devFuncName,
int drvArg1, ... drvArg6)
int lcubootAutoDevCreate(const char *devName, int arg1, ... arg9)
int lcubootAutoDevCheck(const char *devBaseName, int nominalCount)
These functions support the automatic installation of LCU
drivers and devices. All functions are intended to be
used directly from the VxWorks shell in a boot-script.
The script is aborted when a fatal error condition occurs, which
is signalled as a log message in the form:
<tid> (tShell): lcuboot: <message>: <faulty item>:<errno | faulty item>
<tid> (tShell): --- SCRIPT ABORTED ---
lcubootAutoDevRegister - registers a device for later creation and
registration in LCC. Internal variables are set that are used
in subsequent calls of `lcubootAutoDrvInstall' to install the
driver and `lcubootAutoDevCreate' to create the devices.
`busAddr' must be a valid VMEbus address in `addrSpace':
VMEbus Address Modifier addrSpace busAddr
----------------------- --------------- -------------
VME_AM_SUP_SHORT_IO 0x2d 0 .. 0xffff
VME_AM_STD_SUP_DATA 0x3d 0 .. 0xffffff
VME_AM_EXT_SUP_DATA 0x0d 0 .. 0xffffffff
`lccArg1' ff. are are saved and passed to `lccRegisterDevice'
in a subsequent call of `lcubootAutoLccRegisterDevs' to make
all devices known to LCC, see lccRegisterDevice(3).
The number of devices found so far is returned. This count is
reset to zero by `lcubootAutoDrvInstall'.
The script is aborted if the internal device table is full,
or if the given address-space and bus-address could not be
converted into a valid local address.
lcubootAutoDrvInstall - conditionally loads and installs a driver
and prepares all data for subsequent device installation.
`moduleName' is searched in BINPATH and loaded.
The rest of the parameters are usually defaulted (see below).
No operation is done and OK is returned if the number of
devices evaluates to zero (see `numDevices' below),
otherwise the installation is done accordingly.
`drvFuncName' is the driver install function (e.g "xxxDrv").
`devFuncName' is the device install function ("xxxDevCreate").
`drvArg1' ff. are passed to the driver install function.
The script is aborted in the following cases:
- the driver module could not be found or loaded.
- the driver installation failed, i.e. it did not return OK
- the device installation function could not be found
The following parameters are defaulted - when omitted - with:
`numDevices' = effective count from `lcubootAutoDevRegister',
or - if this is zero - from the variable
`lcubootProbeCount' as set by `lcubootAutoProbe'.
Both counts are reset to zero by the function.
`drvFuncName' = "`moduleName'`lcubootAutoDrvFuncSuffix'"
`devFuncName' = "`moduleName'`lcubootAutoDevFuncSuffix'"
`drvArg1' = `numDevices' (after resolving as above)
`drvArg2' = `lcubootAutoDrvArg2'
`drvArg3' = `lcubootAutoDrvArg3'
See VARIABLES for the contents of `lcubootAutoD...'.
To install the corresponding devices, at least as many
consecutive calls of `lcubootAutoDevCreate' must follow
as the evaluated number of devices implies.
lcubootAutoDevCreate - performs the installation of a device using
the function previously defined with `lcubootAutoDrvInstall'.
The name of the device is given by `devName', which is passed
with up to nine further arguments to the install-function.
No operation is done and OK is returned if the number
of devices to be installed as defined before with
`lcubootAutoDrvInstall' has already been reached,
or if the corresponding address given with
`lcubootAutoDevRegister' is empty.
It returns OK is the device installation is successful,
otherwise the script is aborted.
Note that there must be as many calls of this function stated
in the boot-script as the maximum number of devices that shall
be supported. However, usually fewer devices are actually
installed.
Note also that the base-addresses given as arguments to this
function may be different from the probe-addresses stated
in the call of `lcubootAutoDevRegister'.
lcubootAutoDevCheck - checks whether the number of devices installed
in the system are equal to a given value.
`devBaseName' denotes the name-prefix of the device family,
e.g. "/acro" for digital I/O devices.
`nominalCount' is the expected number of installed devices, a
negative value means no check shall be done and returns OK.
OK is returned if the actual and nominal count are equal,
otherwise the script is aborted.
This can be used at the end of the boot-script to verify that
the expected number of devices are actually installed.
Note however that the boot-script must then be updated
according to the HW configuration.
The following global variables are provided and can be modified by
the user in exceptional cases:
lcubootAutoDrvFuncSuffix - Default suffix to the module-name to
yield the driver install function.
The variable is preset with: "Drv"
The maximum length is 15 chars.
lcubootAutoDevFuncSuffix - Default suffix to the module-name to
yield the device install function.
The variable is preset with: "DevCreate"
The maximum length is 15 chars.
lcubootAutoDrvArg2 - Default 2nd parameter for the driver install
function, usually the number of channels.
The variable is preset with: 25
Note that that this parameter can be explicitly given as
argument to `lcubootAutoDrvInstall'.
lcubootAutoDrvArg3 - Default 3rd parameter for the driver install
function, usually the timeout in ticks.
The variable is preset with: 100
Note that that this parameter can be explicitly given as
argument to `lcubootAutoDrvInstall'.
Most functions are not reentrant and should therefore only be used
from LCU boot-scripts, where reentrancy is not important!
Not more than 64 devices are supported in one LCU.
The global variable `lcubootAutoDrvArg2' contains the default number
of device channels that can be opened to all devices of a driver.
When very many devices are present, this might have to be increased.
This example automatically loads and installs the "acro" driver if
at least one acro-device is present, and then installs the found
number of devices, up to four.
After that the found devices are registed in LCC.
acroN = lcubootAutoDevRegister("/acro0",0x2d,0x1000,1,1,1)
acroN = lcubootAutoDevRegister("/acro1",0x2d,0x1400,1,1,1)
acroN = lcubootAutoDevRegister("/acro2",0x2d,0x1800,1,1,1)
acroN = lcubootAutoDevRegister("/acro3",0x2d,0x1c00,1,1,1)
lcubootAutoDrvInstall "acro"
lcubootAutoDevCreate "/acro0",0x1000,0xb0,1
lcubootAutoDevCreate "/acro1",0x1400,0xb1,1
lcubootAutoDevCreate "/acro2",0x1800,0xb2,1
lcubootAutoDevCreate "/acro3",0x1c00,0xb3,1
lcubootAutoExec acroN,"sysIntEnable",1
lcubootAutoSpawn acroN,"tintACRO",200,0x18,2000,"acroInt"
...
lcubootAutoLccRegisterDevs
A similar - but maybe less elegant - implementation:
acroN = lcubootAutoProbe(0xffff1000,0xffff1400,0xffff1800,0xffff1c00)
lcubootAutoDrvInstall "acro",acroN,"acroDrv","acroDevCreate",acroN,5,80
# or with defaults simply: lcubootAutoDrvInstall "acro"
lcubootAutoDevCreate "/acro0",0x1000,0xb0,1
lcubootAutoDevCreate "/acro1",0x1400,0xb1,1
lcubootAutoDevCreate "/acro2",0x1800,0xb2,1
lcubootAutoDevCreate "/acro3",0x1c00,0xb3,1
e=calloc(512,1)
lcubootAutoExec acroN>0,"lccRegisterDevice","/acro0",0xffff1000,1,1,1,e
lcubootAutoExec acroN>1,"lccRegisterDevice","/acro1",0xffff1400,1,1,1,e
lcubootAutoExec acroN>2,"lccRegisterDevice","/acro2",0xffff1800,1,1,1,e
lcubootAutoExec acroN>3,"lccRegisterDevice","/acro3",0xffff1c00,1,1,1,e
free e
These functions support the automatic setup of LCU shell environment.
All functions are intended to be used directly from the VxWorks shell
in a boot-script.
The script is aborted when a fatal error condition occurs, which
is signalled as a log message in the form:
<tid> (tShell): lcuboot: <message>: <faulty item>:<errno | faulty item>
<tid> (tShell): --- SCRIPT ABORTED ---
lcubootAutoEnvInit - initialize shell environment variable from the
LCU boot-line settings and set the shell-prompt.
The following variables are derived from the LCU boot-line
or derived from other variables, but only if they are not
already defined:
LOCALHOST := <bootParams.targetName>
LOCALIPADDR := <bootParams.ead>
LOCALENV := l${LOCALHOST}
HOSTNAME := <bootParams.hostName>
HOSTIPADDR := <bootParams.had>
HOSTENV := w${HOSTNAME}
BOOTHOME (see below)
BOOTROOT (see below)
BOOTDB := ${BOOTHOME}/DB
LOGFILE := ${BOOTHOME}/logfile
BOOTHOME corresponds to the directory of the startup-script
as specified in the boot-line. BOOTROOT is derived from that
by going two level up in the directory hierarchy. This should
be the same then as VLTDATA on the host workstation.
Default search-paths are also set for binary files (BINPATH)
and module-boot-scripts (BOOTPATH). The parts with INTROOT
respectively MODROOT are omitted when not defined. The
CPU-dependent extension is omitted when CPU is not defined.
BINPATH := $BOOTHOME:\
[$MODROOT/bin:]\ (if MODROOT defined)
[$INTROOT/vw/bin[/$CPU]:]\ (if INTROOT defined)
$VLTROOT/vw/bin[/$CPU]
BOOTPATH := $BOOTHOME:\
$BOOTROOT/config:\
[$MODROOT/bin:]\ (if MODROOT defined)
[$INTROOT/vw/bin/$CPU:]\ (if INTROOT/CPU def.)
[$INTROOT/vw/bin:]\ (if INTROOT defined)
$VLTROOT/vw/bin/$CPU:\ (if CPU defined)
$VLTROOT/vw/bin
CONFIGPATH := $BOOTHOME:\
$BOOTROOT/config:\
[$MODROOT/config:]\ (if MODROOT defined)
[$INTROOT/config:]\ (if INTROOT defined)
$VLTROOT/config
The shell-prompt is derived from the local environment name.
Note that VLTROOT, INTROOT and MODROOT are not set!
`lcubootAutoEnvInit' sets the above stated shell variables.
VLTROOT and optionally INTROOT/MODROOT must be set before calling it.
CPU can be optionally set to extend BINPATH and BOOTPATH.
Values are the same as for the VxWorks compiler, e.g. MC68040.
Most functions are not reentrant and should therefore only be used
from LCU boot-scripts, where reentrancy is not important!
Observe the following changes after the JUL95 VLT SW Release:
- The structure under BOOTROOT has been changed.
- The default HOSTENV is no longer appended by "qs".
lcubootAutoGen,
lcubootAutoProbe,
lcubootAutoLoad,
lcubootAutoExec,
lcubootAutoSpawn,
lcubootAutoCd, lcubootAutoCdBoot
- Automatic LCU Module Installation Facility
int lcubootAutoProbe(char *probeAddr0, ... *probeAddr9)
int lcubootAutoLoad(BOOL cond, const char *moduleName,
int reldFlag, int symFlag)
int lcubootAutoExec(BOOL cond, const char *funcName, int arg1, ...arg8)
int lcubootAutoSpawn(BOOL cond, const char *taskName,
int priority, int options, int stackSize,
const char *funcName, int arg1, ..arg4)
int lcubootAutoCd(BOOL cond, const char *searchPath,
const char *fileName)
int lcubootAutoCdBoot(BOOL cond, const char *scriptName)
These functions support the automatic installation of all general
LCU modules. All functions are intended to be
used directly from the VxWorks shell in a boot-script.
The script is aborted when a fatal error condition occurs, which
is signalled as a log message in the form:
<tid> (tShell): lcuboot: <message>: <faulty item>:<errno | faulty item>
<tid> (tShell): --- SCRIPT ABORTED ---
lcubootAutoProbe - tests whether any hardware is present at the given
addresses. Byte-read accesses are executed to verify this.
Up to ten addresses can be given, the function stops after
the first non-successful access.
It returns the number of successful accesses.
The counting begins normally from zero each time the function
is called. If `probeAddr0' is NULL then the counting is
continued from the last value, which is useful when more
than ten addresses must be probed.
This can be used to determine the number of boards/devices
that are present in the system.
Note that it cannot be checked whether the hardware found
at a given address is actually the "correct" one.
Standard pre-defined board addresses must be used as an
essential precondition.
lcubootAutoLoad - if `cond' is TRUE, then it loads the binary module
`moduleName', applying the search-path in the environment
variable BINPATH.
It also loads the module's error-definition files, provided
they exist. It is silently ignored if no error-files are found.
See lcubootErrorLoad(1) for details.
No operation is done and OK is returned for FALSE `cond'.
The same is true if a module with this name is already loaded
and `reldFlag' is zero, otherwise the module is re-loaded.
`symFlag' is usually zero and can be omitted, see loadLib(1).
It returns OK if the module is found and loaded.
It returns ERROR if the module is not found, however,
the script is not aborted then. It aborts the script
only if the module is found but cannot be loaded properly.
This can be used to conditionally/optionally load a module.
lcubootAutoExec - if `cond' is TRUE, then it executes the given
function with the given arguments.
No operation is done and OK is returned for FALSE `cond'.
It returns the called function's return-value, or ERROR
if the function is not found in the symbol-table.
This can be used to conditionally/optionally install a module.
lcubootAutoSpawn - if `cond' is TRUE, then it spawns `funcName' as a
task with the name `taskName', using the given parameters,
as in taskSpawn.
No operation is done and OK is returned for FALSE `cond'.
It returns the return-value of the taskSpawn call, or
ERROR if the function is not found in the symbol-table.
Note that fewer arguments can be passed to the task compared
to a direct call of taskSpawn.
This can be used to conditionally/optionally spawn a task.
lcubootAutoCd - if `cond' is TRUE, then it changes to the directory
in which a given file is found. The file is searched applying
the given colon-separated directory search-path.
No operation is done and OK is returned for FALSE `cond'.
It returns the OK, or ERROR in case of any failure.
Note that after calling this function the current working
directory is not reset to it's previous value.
lcubootAutoCdBoot - is similar to `lcubootAutoCd', but specifically
intended for module-boot-scripts. It searches for `scriptName'
applying the search-path in the environment variable BOOTPATH.
The script is aborted when the module-boot-script could not
be found in any of these directories.
BINPATH - colon-separated directory searchpath for binary modules
BOOTPATH - colon-separated directory searchpath for module-boot-scripts
Most functions are not reentrant and should therefore only be used
from LCU boot-scripts, where reentrancy is not important!
The first example searches for the module-boot-script of "lqs"
and executes it under the shell:
lcubootAutoCdBoot 1,"lqs.boot"
< lqs.boot
This module-boot-script could then have the following contents.
It automatically loads and sets up the "lqs" module.
After that the found lqs task is spawned.
lcubootAutoLoad 1,"lqs"
# Define Ping and Ack timeout(seconds)
lcubootAutoExec 1,"lqsInit",10,"rtap"
lcubootAutoExec 1,"lqsAddEnvTbl","wte13qs","te13","134.171.12.222",2223
lcubootAutoExec 1,"lqsAddEnvTbl","wte19qs","te19","134.171.12.228",2223
lcubootAutoExec 1,"lqsAddEnvTbl","wte13", "te13","134.171.12.222",2155
lcubootAutoExec 1,"lqsAddEnvTbl","wte16", "te16","134.171.12.225",2167
# Spawn the lqs task
lcubootAutoSpawn 1, "tLqs", 90, 0x18, 20000, "lqs"
lcubootAutoEnv(1), lcubootAutoDrv(1), lcubootAutoLcc(1),
lcubootErrorLoad(1),
loadLib(1), symLib(1),
ld(2)
These functions support the automatic installation of LCC,
especially for devices. All functions are intended to be
used directly from the VxWorks shell in a boot-script.
The script is aborted when a fatal error condition occurs, which
is signalled as a log message in the form:
<tid> (tShell): lcuboot: <message>: <faulty item>:<errno | faulty item>
<tid> (tShell): --- SCRIPT ABORTED ---
lcubootAutoLccRegisterDevs - register all devices under LCC that were
previously announced with `lcubootAutoDevRegister'.
The number of registered devices is returned.
The script is aborted when a call to `lccRegisterDevice' fails.
Most functions are not reentrant and should therefore only be used
from LCU boot-scripts, where reentrancy is not important!
int lcubootErrorLoad(const char *modName)
int lcubootErrorGetFormat(const char *modName,
int errNumber,
char *severity,
char *format)
This functions provides the facilities to load ERROR files and
retrieve the information about error text and format for a
given module and error number. lcubootErrorLoad is called automatically
at module loading, but can be used by itself for test purposes.
lcubootErrorLoad - load the ERROR definition file for the given
module, if the module does not have ERROR
files it just return. If the module has the
ERROR file (<mod>_ERRORS) but the index
file is not present (<mod>ERRORS.idx) the
script is aborted.
lcubootErrorGetFormat - retrieves severity and format
definition for the pair
(modName,errNumber).
Returns values: lcubootOK if no problem
lcubootError_MOD_NOT_FOUND if the
module was not found
lcubootError_ERR_NOT_FOUND if the
error number was not found for
the module
lcubootError_INTERNAL if an internal
error occurs.
Error-defition files are accessed read-only under VLTROOT
respectively INTROOT:
ERRORS/<mod>_ERRORS
ERRORS/<mod>ERRORS.idx
where <mod> is the name of the module, as given by `modName'.
Note that the name of the module and the prefix of the
error-definition files must be the same, otherwise the
files will not be found!
lcubootErrorLoad("mod");
lcubootErrorLoad("motci");
status = lcubootErrorGeFormat("mod",mod_ERR_NOT_FOUND,
myFormat, mySeveritty);
if (status != lcudrvOK)
switch (status) {
case lcubootError_MOD_NOT_FOUND: ....
case lcubootError_ERR_NOT_FOUND: ...
default: ...
}
Search for a file with a given search path and open it.
searchPath - colon-separated list of directories
fileName - relative filename
openMode - mode passed as second parameter to `open'
a file-descriptor (> 0) if the file is found and opened
lcubootERROR if the file is not found or cannot be opened
STATUS lcubootLogInit(void);
STATUS lcubootLogFinish(void);
STATUS lcubootLogMsg(char *fmt, int arg1, int arg2, int arg3,
int arg4, int arg5, int arg6)
These functions supports logging of messages generated while
executing the LCU's bootScript.
Messages are logged into the file lcubootLogFile, this file is
located in the boot WS in the directory $VLTDATA/ENVIRONMENTS/<lcuEnv>.
lcubootLogInit - Open the log file and adds its file
descriptor to the VxWorks logging system. To avoid that the
logfile size grows indefinetely, it is re-created
every time the boot process is started and the file
size is greater tha 0.
lcubootLogFinish - Logs "lcuboot end" in the logFile,
closes it and deletes the file descriptor from
the VxWorks's logging system.
If lcubootLogInit have not been called or if it have
failed nothing is done.
lcubootLogMsg - Behaves exactly like vxWorks's logMsg, but
it flushes the buffer of the logfile.
If lcubootLogInit have not been called or if it have
failed nothing is done.
lcubootLogInit - lcubootERROR if it fails to open the
logFile, otherwise lcubootOK.
lcubootLogMsg - lcubootOK.
lcubootLogFinish - lcubootOK.
8.3 Directory Reference
The following sections contain the manual pages for the directory formats for environments.
The directory contains the files needed by an LCU environment:
$VLTDATA/
|
|--ENVIRONMENTS/
| |
| |--<env>/
| | |
| | |-- PROCESSES
| | |-- bootScript
| | |-- devicesFile
| | |-- lcubootLogFile
| | |-- logfile
| | |-- rebootFile
| | |-- userScript
| | |
| | |--dbl/
| | | |--Makefile
| | | |--DATABASE.db
| | | |--USER.db
| | |
| | |--DB/
: :
Each file is created from a template available in $VLTROOT.
<env> name of the LCU environment. Must begin with `l' (ell).
The standard template can be copied with envsCreate(1).
The actual target should be located under:
$VLTDATA/ENVIRONMENTS/<env>/
The directory contains the following files and sub-directories:
Name Purpose
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROCESSES List of processes that accept commands
bootScript Executed during start-up
devicesFile Defines LCC software devices
logfile Used by LCC
lcubootLogFile Used by LCC
rebootFile Used by LCC
userScript For user definition during start-up
dbl/ Database source directory
dbl/DATABASE.db Standard database
dbl/Makefile Accepts `make db' to build database branch
dbl/USER.db Configurable database part
DB/ Directory branch generated by `make db'
The directory contains the files needed by an QSEMU environment:
$VLTDATA/
|
|--ENVIRONMENTS/
| |
| |--<env>/
| | |
| | |-- CcsEnvTable
| | |-- PROCESSES
| | |
| | |--dbl/
| | | |--Makefile
| | | |--DATABASE.db
| | | |--USER.db
| | |
| | |--DB/
: :
Each file is created from a template available in $VLTROOT.
<env> name of the QSEMU environment.
Must begin with `w' and should end with `qs'.
The standard template can be copied with envsCreate(1).
The actual target should be located under:
$VLTDATA/ENVIRONMENTS/<env>/
The directory contains the following files and sub-directories:
Name Purpose
~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROCESSES List of processes that accept commands
CcsEnvTable Process definitions
dbl/ Database source directory
dbl/DATABASE.db Standard database
dbl/Makefile Accepts `make db' to build database branch
dbl/USER.db Configurable database part
DB/ Directory branch generated by `make db'
The directory contains the files needed by an RTAP environment:
$VLTDATA/
|
|--ENVIRONMENTS/
| |
| |--<env>/
| | |
| | |-- PROCESSES
| | |-- RtapEnvTable
| | |
| | |--dbl/
| | | |--Makefile
| | | |--DATABASE.db
| | | |--USER.db
| | |
| | |--DB/
: :
Each file is created from a template available in $VLTROOT.
<env> name of the RTAP environment. Must begin with `w'.
The standard template can be copied with envsCreate(1).
The actual target should be located under:
$VLTDATA/ENVIRONMENTS/<env>/
The directory contains the following files and sub-directories:
Name Purpose
~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
PROCESSES List of processes that accept commands
RtapEnvTable.normal Process definitions for normal operation
RtapEnvTable.startup Process definitions for initial DB load
Rtap*Snap? Rtap snapshot file for normal operation
Rtap*Snap?.empty Rtap snapshot file for initial DB load
dbl/ Database source directory
dbl/DATABASE.db Standard database
dbl/Makefile Accepts `make db' to build database branch
dbl/USER.db Configurable database part
DB/ Directory branch generated by `make db'
Rtap*.empty files are configured to work with 1000 points capacity.
To change this, new *.empty files must be generated by :
- modifying RtapEnvTable to start RtapDbStartup manually:
RtapDbStartup -r
- starting the environment (RtapScheduler -e <...>)
- choosing the option "Create empty database"
- modifying the field "Maximum number of points"
- choosing the option "Accept configuration: startup"
- stopping the environment (RtapShutdown -e <...>)
- renaming newly created files into .empty (RtapDiskDb, RtapHdr*, RtapRam*,
RtapSnapCtrl)
- restoring RtapEnvTable
Note that when running ls_stat or RtapPerfMon, licenses are displayed in
64 points units (16 units = 1000 points; 125 units = 8000 points).
After loading the VxWorks image, an LCU sources a boot-script
to load and initialize all further software it needs.
Module-specific sub-boot-scripts are called from the main
`bootScript' of the LCU for each module that shall be initialized.
For each module there must be a VxWorks boot-script named
"<module>.boot" in one of the directories stated in FILES
that loads and initializes the module.
See Module.boot(5) and Driver.boot(5) for the typical contents
of that file.
For each sub-boot-script there should be a man-page named
"<module>.boot(5)" that explains the contents of the boot-script.
For each driver sub-boot-script there should be a man-page
named "<module>(4)" that explains the respective board-hardware
(jumpers etc.).
The files "bootScript" and "userScript" must be located in:
$VLTDATA/ENVIRONMENTS/<lcu-env>/
This directory is assigned on to the variable BOOTHOME on the LCU.
VLTDATA is only defined on the WS, and corresponds to BOOTROOT on LCU.
Binary files for all modules to be loaded are searched in
BINPATH, which consists by default of the following directories
(cpuName is for instance MC68040):
1. $BOOTHOME
2. $INTROOT/vw/bin/<cpuName>/<module>
3. $VLTROOT/vw/bin/<cpuName>/<module>
The module-boot-scripts are searched in BOOTPATH, which has
the following order of priority:
1. $BOOTHOME/<module>.boot
2. $BOOTROOT/config/<module>.boot
3. $INTROOT/vw/bin/<cpuName>/<module>.boot
4. $INTROOT/vw/bin/<module>.boot
5. $VLTROOT/vw/bin/<cpuName>/<module>.boot
6. $VLTROOT/vw/bin/<module>.boot
All boot-scripts are initially installed under "$VLTROOT/vw/bin".
If you want to insert some changes that shall apply only to
one specific LCU-environment, then copy the respective script
from "$VLTROOT/vw/bin/<cpuName>" to "$VLTDATA/ENVIRONMENTS/<lcu-env>".
If you want to insert some changes that shall apply to all
LCU-environments not having the above mentioned private version,
then copy the respective script either to your INTROOT, or
from "$VLTROOT/vw/bin/<cpuName>" to "$VLTDATA/config/".
VLTROOT - path to global VLT installation area (mandatory)
VLTDATA - path to global VLT data area (mandatory)
INTROOT - path to private installation area (optional)
8.4 Files Reference
The following sections contain the manual pages for the file formats used in the modules.
The LCU boot script allows to load and initialise all the software
running on the LCU:
. drivers and other support modules,
. Q Server,
. LCU Common Software,
. user applications.
Several configuration sections allow to set-up the boot script for a
specific environment and target system.
This version of the boot script is a generic version that must be
customized for each LCU.
Values to be given to customization parameters are indicated by
letters between angle brackets (e.g. <hostName>) and must be replaced
by the actual values.
The following sections correspond to the recommented order of sections
in the bootScript.
Configurable environment variables and parameters
Mandatory variables:
VLTROOT Path of the VLTROOT area on the boot host.
Example: /vlt/DEC95
Optional variables:
INTROOT Path of the INTROOT area on the mounted host.
This variable is optional:
- if not defined then all files are accessed in VLTROOT
- if defined then INTROOT has priority to VLTROOT
Examples: /diskb/userx/INTROOT
/earth/projects/ESO_LCU/INTEGRATION
MODROOT Path of the MODROOT area on the mounted host.
This variable is optional:
- if defined then MODROOT has highest priority.
BOOTHOME Path of the home directory in which the LCU bootScript
etc. are located. The variable is optional, it can
be derived automatically by `lcubootAutoEnvInit'.
Note that the local filenames of xxxROOT can also be fixed to for example
"/VLTROOT" and "/INTROOT", and the assignment to remote filesystems be
done via NFS mounting, see next section.
Files are accessed through NFS by the LCU boards during system loading and
initialisation and for database loading/unloading and backup/restore
operations.
By default, all exported filesystems of the boot server host are mounted
by VxWorks boot procedure. The NETWORK configuration section allows to
mount filesystems from other hosts on the LCU:
nfsAuthUnixSet "<hostName>",<userId>,<groupId>
hostAdd "<hostName>","<ipAddr>"
nfsMount "<hostName>","<fileSystem>","<localName>"
<hostName> Name of remote system. Example: "earth"
<userId> Unix user id (*) to be used by the LCU for NFS access.
Example: 150
<groupId> Unix group id (*) to be used by the LCU for NFS access.
Example: 50
(*) Can be any existing UNIX user, but conventionally
it is the one used by the LCU to boot, namely "vx"
<ipAddr> Internet address of remote system.
Example: "192.9.200.2"
<fileSystem> Name of remote filesystem. Example: "/earth"
<localName> Local name for the filesystem. Example: "/earth"
The "lcuboot" module should be present under VLTROOT and is loaded
usually from there. If it is (also) present in INTROOT then it can
optionally be loaded from there, if explicitly stated.
The module provides the functions that are used during the
further execution of the boot-script.
No user-specific configuration is necessary in this section,
except that the loading from INTROOT can be enabled.
The following environment variables can be configured by the user.
A call of `lcubootAutoEnvInit' automatically defines all variables
that are left undefined by the user with default values, which will
fit in most cases.
LOCALHOST Unix host name of LCU. Example: "moon"
LOCALENV Environment name of LCU. Example: "lmoon"
LOCALIPADDR Internet address of LCU. Example: "192.9.200.45"
LOCALTCPPORT TCP port number of LCU. Example: 2160
HOSTNAME Name of boot server host. Example: "earth"
HOSTENV Environment name of boot server host. Example: "wearth"
HOSTIPADDR Internet address of boot server host. Ex: "192.9.200.2"
HOSTTCPPORT TCP port number of boot server host. Example: 2301
BOOTROOT root-directory from which the LCU is booting
BOOTHOME private LCU boot-directory under BOOTROOT
BOOTDB directory of LCU boot-database
LOGFILE name of LCU log-file
Modules are divided into SYSTEM modules (that are usually always
necessary and should always be loaded in correct order) and USER
modules (that are normally not always necessary).
All modules should be loaded first, and initialized after all modules
have been loaded. Module-specific sub-boot-scripts should be called
to load (if not already done) and initialize each module.
The driver modules can normally always be included, because they
install themselves automatically if corresponding devices are found.
See lcuboot(5) for the search directories of module images and
boot-scripts.
All devices are normally automatically installed when corresponding
hardware is found. To check whether the expected number of devices
for each device-family have actually been installed, the respective
line must be uncommented and the expected device-count must be stated.
In this section the USER modules are initialized by calling their
respective module-boot-scripts.
After that the "userScript" in the LCU's boot-directory is executed,
which can have any user-defined contents.
The devicesFile lists the software devices controlled by LCC. It
contains the definition of a TABLE attribute of the database used
by LCC (:LCC:DEVICES:deviceTable). The table contains the following
fields:
- name of software device (Bytes20),
- name of software device control process (Bytes20),
- initialisation status of software device (UInt32) [LCC internal use],
- reply status of software device (Logical) [LCC internal use],
- simulation status of software device (Logical) [LCC internal use,
updated by lccDevEnterSim and lccDevExitSim],
- state of software device (UInt32) [LCC internal use, updated by
lccSetDeviceState].
The attribute is restored by LCC using the dbRestore function
when the corresponding LCU is rebooted.
<CWP>: :LCC:DEVICES
<ATTRIBUTE>: deviceTable <TYPE>: Table <REC>: 0 - 2 <FIELDS>: 0 - 5
"motor1" "MotorControl1" 1 0 0 1
"motor2" "MotorControl2" 1 0 0 1
"motor3" "MotorControl3" 1 0 0 1
the values 0 - 2 and 0 - 5 in the above example give respectively the
records in the table and the fields of each record.
For an LCU configured without software devices, the devicesFile
shall contain the following line:
<CWP>: :LCC:DEVICES
This script allows to load and initialise application software.
It is called from the LCU boot script (bootScript) after all
drivers and LCC Common Software have been loaded and initialised.
8.5 Panel Widgets and Libraries
 Quadralay Corporation http://www.webworks.com Voice: (512) 719-3399 Fax: (512) 719-3606 sales@webworks.com |
| |
|
|
|