Freescale Semiconductor SEC2SWUG 7 VxWorks Environment

SEC 2.0 Reference Device Driver User’s Guide, Rev. 0

40 PRELIMINARY—SUBJECT TO CHANGE WITHOUT NOTICE Freescale Semiconductor

VxWorks Environment

Operation of the SEC2 device in user mode is slightly more complex than in kernel mode. In particular, the transition

from user to kernel memory space creates two complicat io n s for use r mo de ope ration:

1. User memory buffers can't be passed directly to the driver; instead, in this driver edition, the user must

allocate and place data in kernel memory buffer for operation. This can be accomplished via SEC2_MALLOC,

SEC2_FREE, SEC2_COPYFROM, and SEC2_COPYTO requests (see Section 3.3.1, “I/O Control Codes” for

more information).

Note: extreme caution must be exercised by the user in transferrin g memory in this fashi on; kernel memory

space may easily be corrupted by the caller, causing target system instability.

2. Standard notification callbacks cannot work, since the routines to perf orm the callback are in user memory

space, and cannot safely execute from kernel mode. In their place, standard POSIX signals can be used to

indicate I/O completion by placing the process ID of the user task in the notification members of the

request, and flagging NOTIFY_IS_PID in the notifyFlags member. The driver uses SIGUSR1 to

indicate normal request completions, and SIGUSR2 to indicate error completions.

The example suite available with the driver illustrates the co ntra st bet w een the two different application

environments. Within the testAll.c file, there is a set of functions that shows the difference between the two

operations. Building the example testing application with __KERNEL__ on (building a kernel mode test) shows the

installation and usage of standard completion callbacks and a mutex used for interlock. Conversely, building the

example testing application with USERMODE turned on shows the installation of signal handlers and their proper

setup.

In USERMODE, this example also shows one possible means for handling the user to kernel memory trans ition via the

use of three functions for transferring user buffers to and from kernel memory.

A common necessity of loadable modules for Linux is the inclusion of a li cense macr o (MODULE_LICENSE) that

declares a string defining the type of license terms under which the module's code has been published. In the case

of the SEC2 driver module, this code is delivered in source form under the terms of a restricted lic ense agreement.

Therefore, this macro has been passed a name of “Freescale Restricted” to acknowledge the existence of this

agreement.

When loading the driver object, the existence of a non-GPL, non-BSD license string will cause a warning message

to be printed to the console, stating that loading a module with a proprietary license will “taint” the kernel. This

message is normal, expected, and will not cause any adverse operation of your running system.

7 VxWorks Environment

The following sections describe the installation of the SEC2 security processor software drivers, BSP integration,

and distribution archives.

To install the software drivers, extract the archive containing the drive r source files into a suitable installation

directory. If you want the driver and tests to be part of a standard VxWorks source tree, place them in: