BIOS MCSDK 2.0 User Guide
15
/* Initialize PA, done from each core */
/* Get a PA buffer */
Pa_getBufferReq(&paSize, sizes, aligns);
/* Create a PA instance */
Pa_create (&paCfg, bases, &paInst);
/* Register RM with PA */
paStartCfg.rmHandle = rmHandle;
Pa_startCfg (paInst, &paStartCfg);
}
For a working example please see the rm_testproject under the test/ directory of the RM LLD.
Chip Support Library (CSL)
The Chip Support Library constitutes a set of well-defined APIs that abstract low-level details of the underlying SoC
device so that a user can configure, control (start/stop, etc.) and have read/write access to peripherals without having
to worry about register bit-field details. The CSL services are implemented as distinct modules that correspond with
the underlying SoC device modules themselves. By design, CSL APIs follow a consistent style uniformly across
Processor Instruction Set Architecture and are independent of the OS. This helps in improving portability of code
written using the CSL.
CSL is realized as twin-layer – a basic register-layer and a more abstracted functional-layer. The lower register layer
comprises of a very basic set of macros and type definitions. The upper functional layer comprises of “C” functions
that provide an increased degree of abstraction, but intended to provide “directed” control of underlying hardware.
It is important to note that CSL does not manage data movement over underlying h/w devices. Such functionality is
considered a prerogative of a device driver and serious effort is made to not blur the boundary between device driver
and CSL services in this regard.
CSL does not model the device state machine. However, should there exist a mandatory (hardware-dictated)
sequence (possibly atomically executed) of register reads/writes to setup the device in chosen “operating modes” as
per the device data sheet, then CSL does indeed support services for such operations.
The CSL services are decomposed into modules, each following the twin layer of abstraction described above. The
APIs of each such module are completely orthogonal (the API of one module does not internally call API of another
module) and do not allocate memory dynamically from within. This is key to keeping CSL scalable to fit the specific
usage scenarios and ease the effort to ROM a CSL-based application.
The source code of the CSL is located under $(TI_PDK_C66##_INSTALL_DIR)\packages\ti\csl directory.
Note: The CSL is built with LLD using same script. Please refer the LLD build section for details.