Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel
6. Where and how do I create a new EPICS application?  How do I setup a new IOC to use linuxRT-86 OS? 

(a) Create directories and files as shown below using ioc-b34-bd32 as an example:
$IOC/ioc-b34-bd32

 $IOC_DATA/ioc-b34-bd32

 $IOC_DATA/ioc-b34-bd32/screenlog.0

 $IOC_DATA/vioc-b34-bd32

$IOC_DATA/vioc-b34-bd32/autosave

$IOC_DATA/vioc-b34-bd32/autosave-req

$IOC_DATA/vioc-b34-bd32/iocInfo

Note to Ernest: Please create above directories automatically via a single python or perl script.

$APP/Test (look at this as an example) 

Now create your EPICS application called 'MyTest' as below using standard templates and scripts in a sandbox area called Development.

(b) cd $APP/Test

As MyTest development continues, this is where you will be creating/checking out from CVS, several versions of your MyTest application.

Now create a sandbox area for MyTest.

mkdir Development

(c) cd Development

You are currently in:

/afs/slac/g/lcls/epics/R3-14-12-3_1-0/iocTop/Test/Development

This is the top directory for MyTest and referred as $(TOP).

(d) Using a perl script that automates the process, create MyTest:
makeBaseApp.pl -t slac MyTest

The perl script had populated your application using icdTemplates module that provides templates

that are used by ICD to support our style of IOC Application Building for the facilities we support.

The location for icdTemplates module was set as below when you sourced go_epics_3-14-12-3_1-0.bash.

EPICS_MBA_TEMPLATE_TOP=/afs/slac/g/lcls/epics/R3-14-12-3_1-0/modules/icdTemplates/icdTemplates-R1-0-1

If you would like to know more about makeBaseApp.pl, type:

makeBaseApp.pl -help

(e) Now, open the configure/RELEASE file.

(i) Notice how the following line appears towards the beginning:
include $(TOP)/RELEASE_SITE

The above sets the paths for EPICS base, modules, packages, tools etc. to point to version R3-14-12-3_1-0. 

(ii) The file has the following line towards the end of it:

# Location of Linux Kernel Modules:

LINUX_KERNEL_MODULES=$(PACKAGE_SITE_TOP)/linuxKernel_Modules

 (iii) configure/RELEASE file may need some modifications from what was automatically generated: 
 
Change the various module version numbers as needed for your application.
Ensure that the specific versions included in your RELEASE file DO EXIST under the modules directory and are consistent. 

They must also have been built for the linuxRT-x86 target. If something is missing, contact Ernest.

For EVENT module, Kukhee recommends us to use event-R4-1-3 or greater with this base.
 
EVENT_MODULE_VERSION=event-R4-1-3

(f) Open  MyTestApp/src/Makefile and notice that the IOC application is referred to as 'MyTest". 

(g) Now it is time to add your linuxRT-x86 virtual ioc (vioc) startup scripts. vioc-b34-bd32 is used here as an example.

From $(TOP) type the following command to create a boot directory for 'vioc-b34-bd32':

makeBaseApp.pl -i -t slac vioc-b34-bd32

When prompted to choose target architecture, choose linuxRT-x86.

Two files are modified based on this selection.

(1) vioc-b34-my01/st.cmd

(2) vioc-b34-my01/Makefile.

When prompted with 'Application name?'  type 'MyTest'.

This will use the application name MyTest that was created in MyTestApp/src/Makefile as described in step (f).

If you just hit 'Enter' without specifying your application name, then your ioc name vioc-b34-bd32 will be used as the default for the dbd file in the st.cmd

Now iocBoot directory has been created under $(TOP) and underneath it, 'vioc-b34-bd32' has been created.

Open iocBoot/vioc-b34-bd32/Makefile and notice that ARCH is set to linuxRT-x86.
Open iocBoot/vioc-b34-bd32/st.cmd and notice that this script is setup to pick the binary from  linuxRT-x86 directory.

(h) If you have an EVR in your system, uncomment the following lines in MyTestApp/src/Makefile:

 

# MyTest_DBD += evrSupport.dbd
# MyTest_DBD += devMrfEr.dbd

Ensure the following lines are not commented as well:

MyTest_LIBS += evrSupport
MyTest_LIBS += devMrfEr

....

ifeq ($(T_A),linuxRT-x86)
    MyTest_LIBS += drvMrf
endif

For a PMC EVR230 or PCI-e EVR300 that is installed in your system, the above is all you need.

Replace the macros in the EPICS database files, or add more databases and modify MyTestApp/Db/Makefile as needed.

(i) Now 'make' your application from the top level directory $(TOP) to ensure your changes to  RELEASE files are good:

There should be no build errors.

Having tested this phase, you can now uninstall the binaries and cleanup the make-generated files using the following command:

make clean uninstall

Do the above before committing the files to CVS.

Currently Ernest is working on changes to the icdTemplates module that provides default templates.

Until he is done with that work, we have to manually make several changes to the  MyTestApp/Db/* files and iocBoot/vioc-b34-bd32/st.cmd.

For now, follow the example MyTest and create similar database files and st.cmd.

The EVR-related screens have been added for vioc-b34-bd32. 

 You can see them when the vioc-b34-bd32 is running as follows from lcls-dev2:

lclshome -> User Dev Displays.... -> Test IOCs/Dev Event IOCs....

The buttons for the various panels for VIOC:B34:BD32 are towards the bottom of this screen.

For easy access to your IOC's EVR panels in LCLSDEV, add the necessary buttons to this page.

The 'Pattern' button brings up the 'Pattern Diagnostics' screen.

'PMC EVR:B34:BD32' button brings up the Low Level 'Diagnostics' screen for EVR;B34:BD32

'Triggers' button brings up 'Trigger Configuration' setup screen.

(c) Add your application to CVS and commit the source files.

Ernest has created some slides that explains some guidelines for importing new applications into CVS:

cvs-vendor-import.txt

CVS-Importing-Merging.pdf

CVS-At-SLAC.pdf

Panel
7. What is PXE, DHCP, TFTP and NFS and why are they needed by my linuxRT IOC?

LinuxRT is installed on our system using the Preboot Execution Environment (PXE) method of network booting.

We enable the PXE/network-booting method in the BIOS.

In order to use PXE there is a boot-server that will allow our client system to :
(a) Request an IP address (via DHCP)
(b) Download a kernel (via TFTP)

With both of these services in place any system which supports PXE/network-booting
should be able to gain an IP address, fetch a kernel, and boot without an installed operating system.

PXE uses three distinct network protocols that map to three server processes to perform the installation.
In our case, some of the processes run on lcls-dev1 (LCLSDEV daemon)

Both  DHCP and TFTP services run on the LCLSDEV host 'dhcp3' maintained by SCCS.

(a) Dynamic Host Configuration Protocol (DHCP)

PXE uses DHCP to deliver initial network configuration options to client nodes.
The DHCP server supplies the PXE boot plug-in with
(i) IP address
(ii) TFTP server address
(iii) Stage 1 image boot-loader name from which to download and execute the image.

As the supplied PXE installation environments are non-interactive and will unconditionally reinstall a client machine,
we have the client associate its MAC address with a specific OS installation before starting the PXE boot.

The configuration information, in our case, in addition to IP/MAC address, includes a hostname and a pointer to the Master Starupt script in afs for our IOC.
It has an optional root-path variable pointing to the afs area which hosts the boot image that is served via TFTP.
This can be over-ridden as will be seen later.

When the Linux server is rebooted or power-cycled, PXE will attempt the network booting method first
and as a first step it will contact the DHCP server to retrieve the network configuration information.

Hence, every new linuxRT ioc (host) needs to be added to the DHCP server configuration file in afs.

This file is in /afs/slac/service/dhcp-pxe/dhcpd.conf

Note that the DHCP service running on dhcp3 is intended only for booting embedded devices like our linuxRT servers that are connected to the LCLSDEV and SSRL subnets.

The MAC addresses for such devices must be registered in CANDO and assigned fixed IP addresses.

The IP/MAC address of the primary ethernet that will fetch the linuxRT boot image is defined here.
To add a new host to the DHCP configuration, contact Thuy.

After a new ioc is added to dhcpd.conf, the DHCP service must be restarted.

To restart DHCP Server

From a Unix command line:

remctl dhcp3 dhcp check

remctl dhcp3 dhcp restart

For help:

remctl dhcp3 dhcp help

Currently only Thuy, Ernest and a couple of others have permissions to perform this restart on dhcp3.

Here's is an example - ioc-b34-bd32:

host ioc-b34-bd32 {
# SuperMicro (INTELx86)
#
hardware ethernet 00:25:90:D1:95:1E;
fixed-address 134.79.218.190;
option host-name "ioc-b34-bd32";
if ( substring( option vendor-class-identifier, 0, 5 ) = "udhcp" ) {
filename "/afs/slac/g/lcls/epics/iocCommon/ioc-b34-bd32/startup.cmd";
option root-path "afsnfs1:/afs/slac:/afs/slac";
}
}

To find out more about how our linux server boots up linuxRT, click on the following link:

 How does the Linux Server boot up linuxRT?


(b) Trivial File Transfer Protocol (TFTP)

PXE uses TFTP that defines a simple UDP protocol for delivering files over a network.
PXE delivers kernels and initial bootstrap software to client nodes using TFTP.

tftpboot is mounted in afs area in LCLSDEV on the server dhcp3, which runs both the TFTP an DHCP services:

 /tftpboot -> /afs/slac.stanford.edu/service/dhcp-pxe/tftpboot/

The iocs retrieve the linuxRT boot image from the TFTP server from the following location:

/afs/slac/g/lcls/tftpboot/linuxRT/boot

In this location, there are several linuxRT-x86 bootimages.
These were custom-built by T.Straumann for the various Linux Servers/IPCs that we currently have setup to boot with linuxRT OS.

Of these images, '3.14.12-rt9' is the latest and it has in-built support for the
Broadcom networking ethernet chipset that are used in our dev Poweredge Dell Servers.

(c) Network File System (NFS)

The NFS service is used by the installation kernel to read all of the packages necessary to the installation process.

NFS services run on the LCLSDEV hosts afsnfs1 and afsnfs2  maintained by SCCS.

 This service makes available the boot directory to all linuxRT targets that boot as diskless clients.

All clients have read-only permissions to this directory.

The linuxRT iocs need some additional NFS Mount Points to write their data some where.

surrey04b is an NFS Appliance and is used by iocs for data and have both read and write permissions to the data directory ($IOC_DATA).

In LCLSDEV, we must obtain permissions for the iocs to write to the $IOC_DATA directory.

 Fill out an online form provided by SCCS to obtain permissions for your ioc to write to this directory:

https://www-rt.slac.stanford.edu/rt3/SelfService/Forms/IocNfs.html

...