BSP structure and contents

For most BSP components, QNX provides both the binary files and the source code. However, if there are restrictions on the distribution of the source code, only the binary files are made available. The About this BSP chapter of every BSP User's Guide lists the BSP components and specifies which ones are provided as binary files only.

If you use the QNX Momentics IDE to extract the BSP contents, the IDE places the contents in the directory you specify when you import the BSP archive. Unless you specify otherwise, the IDE uses a subdirectory in the ide-version-workspace directory of your host system (see the IDE User's Guide). If you use the command-line unzip utility to extract the BSP, the utility places the BSP contents in the directory where you extract the archive (see Building a BSP).

BSP directories

The BSP structure and contents aren't affected by the method you use (command line or IDE) to extract the BSP from its archive, or by the location to which you extract it.

All QNX BSPs use the same basic directory structure, and have the same contents: IPL, startup code, IFS, drivers, etc. However, since BSPs are hardware-specific, every BSP is in some way unique, not just in its contents but also in the organization of its directories.

Typically, extracting a BSP's .zip archive creates the following subdirectories in the directory you chose on your host system:

/images

The /images directory is the location of:

the BSP's default buildfile after the BSP has been built
any boot images (such as the IFS image, the IPL binary, etc.) after they have been generated

/install

The /install directory is empty until the BSP is built. When this happens, the contents of the /prebuilt directory are copied into the /install directory.

When the IFS image is being generated, the /install directory is the first location that the IFS generation process scans for the components specified in the BSP's buildfile. If the IFS generation process doesn't find a component in the /install directory, it scans the QNX SDP's /target directory for the component.

Note:

If you have modified any BSP component's source code, run make install to rebuild it. Then, run make install in the src directory to copy your modified components to the BSP's /install directory. This second step overwrites the prebuilt versions that were supplied with the BSP.

/prebuilt

The /prebuilt directory includes all of the BSP components, prebuilt and ready to use. When you build the BSP, the contents of the /prebuilt directory are copied to the BSP's /install directory (see Prebuilt binaries and libraries below).

/src

The /src directory contains all source code that ships with the BSP. Source code is organised into subdirectories, such as /hardware, /lib, /utils, etc. When the BSP is built, all source code in the BSP (including the code in these subdirectories) is built.

For information about the Makefiles in these directories, see Conventions for Recursive Makefiles and Directories in the QNX Neutrino Programmer's Guide.

Component locations

The table below shows the default locations of common BSP components. ${BSP_ROOT_DIR} is the name of the directory where you extracted the BSP archive. ${CPU_VARIANT} is the specific CPU architecture for which this BSP was developed (e.g., x86_64).


File	Location
Prebuilt OS image	`${BSP_ROOT_DIR}/images`
IPL and/or startup binaries	`${BSP_ROOT_DIR}/install/${CPU_VARIANT}/boot/sys`
Source code for device drivers, libraries, and utilities	`${BSP_ROOT_DIR}/src/hardware/…` `${BSP_ROOT_DIR}/src/lib/…` `${BSP_ROOT_DIR}/src/utils/…`
Prebuilt libraries	`${BSP_ROOT_DIR}/prebuilt/${CPU_VARIANT}/lib/dll}` `${BSP_ROOT_DIR}/prebuilt/${CPU_VARIANT}/usr/lib}`
Prebuilt binaries	`${BSP_ROOT_DIR}/prebuilt/${CPU_VARIANT}/sbin` `${BSP_ROOT_DIR}/prebuilt/${CPU_VARIANT}/bin` `${BSP_ROOT_DIR}/prebuilt/${CPU_VARIANT}/usr/bin`
Generic header files (not architecture-specific)	`${BSP_ROOT_DIR}/install/usr/include`

File naming conventions

Files included in a BSP archive use the following naming conventions to identify their different types:


Prefix	Description	Example
efs-	Embedded filesystem file; generated by mkefs	efs-`board_name`.raw
ifs-	Image filesystem (IFS) file; generated by mkifs	ifs-`board_name`.elf
ipl-	Initial Program Loader (IPL) file	ipl-`board_name`.raw
Extension
.bin	Binary format file	ifs-`board_name`.bin
.build	Buildfile	`board_name`.build
.efs	Embedded filesystem file; generated by mkefs	efs-`flash_filesystem`.efs
.efi	UEFI (Unified Extensible Firmware Interface) file	x86_64-`uefi`.efi
.elf	ELF (Executable and Linking Format) file	ipl-ifs-`board_name`.elf
.raw	Raw binary data (no jump-to information)	ifs-`board_name`.raw
.srec	S-record format file	ifs-`board_name`.srec
.ui	User interface (configuration) file	ifs-`s32v-evb`.ui

Prebuilt binaries and libraries

Prebuilt binaries and libraries are packaged with the BSP, regardless of whether the source code for these components is also included with the BSP. Starting with QNX SDP 6.6, QNX supplies prebuilt binaries and libraries for all BSP components (device drivers, libraries, utilities, etc.).

The BSP's /images directory includes a prebuilt QNX IFS image. This prebuilt IFS image allows you to quickly verify the operation of the QNX OS on your target board by simply transferring the prebuilt image directly to your target, without first building the BSP.

Because this prebuilt image is overwritten by a new IFS when you build the BSP, you may want to make a copy of the prebuilt image for future reference. If you forget to make a copy of the prebuilt image, you can recover it by extracting the BSP from the original .zip archive into a new directory.