| Updated: April 19, 2023 |
The system page contains essential information about the system, including the system page's size, information about the hardware platform (including IRQs and the CPU), the cache size, and the location of kernel callouts in memory.
The system page is implemented by a data structure containing constants, references to other data structures, and a union shared by the different processor architectures that QNX Neutrino RTOS supports.
One of the startup program's main tasks is to initialize the system page with the information that the OS needs to run on the current hardware (see “Startup tasks” in the Startup Programs chapter). After the startup program initializes the system page, it is populated with data that describes the current system and OS, allowing applications to retrieve the information they need.
The standard location for header files, including sys/syspage.h, is on your host system in ${QNX_TARGET}/usr/include, where ${QNX_TARGET} is the directory that holds the target-related components. Architecture-specific header files are kept in ${QNX_TARGET}/usr/include/arch, where arch is the architecture of the target system. For example, ${QNX_TARGET}/usr/include/x86_64/syspage.h contains the architecture-specific definitions for x86 64-bit. Note, however, that the correct header file to include is the general one that contains definitions for all architectures and is stored in the standard header file location (e.g., /my_qnx_sdp/target/qnx71/usr/include/sys/syspage.h).
A QNX SDP product patch or OS update can replace this and other header files (and other components such as binaries and libraries) with newer versions.
However, because QNX regularly updates header files between patches and updates, a specific BSP component often requires a newer version of a header file. When an updated header file is required, it is included with the BSP and the version in the QNX SDP exists independently. When you build the BSP, the build process automatically uses the version shipped with it. Any other coding operations you do outside the context of that specific BSP use the QNX SDP version of the header file.
struct syspage_entry {
_Uint16t size;
_Uint16t total_size;
_Uint16t type;
_Uint16t num_cpu;
syspage_entry_info system_private;
_SP_OLD_ARRAY(asinfo);
syspage_entry_info DEPRECATED_SECTION_NAME(meminfo);
syspage_entry_info hwinfo;
_SP_OLD_ARRAY(cpuinfo);
_SP_OLD_ARRAY(cacheattr);
syspage_entry_info qtime;
syspage_entry_info callout;
syspage_entry_info callin;
syspage_entry_info typed_strings;
syspage_entry_info strings;
_SP_OLD_ARRAY(intrinfo);
syspage_entry_info smp;
syspage_entry_info pminfo;
_SP_OLD_ARRAY(mdriver);
_Uint32t spare0[1];
union {
struct {
_Uint32t __x86_spacer;
struct x86_syspage_entry x86;
};
struct {
_Uint32t __arm_spacer;
struct arm_syspage_entry arm;
};
struct x86_64_syspage_entry x86_64;
struct aarch64_syspage_entry aarch64;
_Uint64t filler[20];
} un;
_SP_NEW_ARRAY(asinfo);
_SP_NEW_ARRAY(cpuinfo);
_SP_NEW_ARRAY(cacheattr);
_SP_NEW_ARRAY(intrinfo);
_SP_NEW_ARRAY(mdriver);
};
The size of the system page entry plus the referenced substructures; effectively the size of the entire system-page database.
The startup library sets this member automatically, but other library calls may adjust (grow) it later as required.
This member is used to indicate the CPU family for determining which union member in the un element to use. It can be SYSPAGE_ARM for supported ARM 32-bit CPU architectures, or one of SYSPAGE_X86_64 or SYSPAGE_AARCH64, for the supported 64-bit architectures.
The library sets this member automatically.
A literal pool used for typed strings. Each entry consists of a four-byte number and a NULL-terminated string. The number represents the string type and corresponds to a specific constant from the system header file <confname.h> (see the C library function confstr()).
Usually, the init_*() library functions populate the typed strings literal pool. However, if you need to add something, you can call the add_typed_string() function from the startup library.
A literal pool used for non-typed strings. To use one of these strings, specify the appropriate index in strings (e.g., cpuinfo's name member).
Usually, the init_*() library functions populate the non-typed strings literal pool. However, if you need to add something, you can call the add_string() function from the startup library.
The _SP_NEW_ARRAY macro defines the data structures for several syspage_entry members, including asinfo, cpuinfo, cacheattr, intrinfo, and mdriver. It is a union of the old and the new syspage_array_info structures:
#define _SP_NEW_ARRAY(__sect) \
union { \
syspage_array_info new_##__sect; \
syspage_array_info __sect; \
}
The _SP_OLD_ARRAY macro defines pre-64-bit data structures for the same syspage_entry members as are defined by _SP_NEW_ARRAY:
#define _SP_OLD_ARRAY(__sect) syspage_entry_info old_##__sect
The syspage_array_info data structure is used by _SP_NEW_ARRAY and _SP_OLD_ARRAY. It is defined as follows:
typedef struct {
_Uint16t entry_off;
_Uint16t entry_size;
_Uint16t element_size;
} syspage_array_info;
QNX SDP 7.0 introduces support for 64-bit processing on x86 and ARM platforms. This support introduces changes to the system page, including the addition of new definitions for system page types:
/*
* System page types
*/
enum {
SYSPAGE_X86,
SYSPAGE_PPC,
SYSPAGE_MIPS,
SYSPAGE_SPARE,
SYSPAGE_ARM,
SYSPAGE_SH,
/* additional 32 bit architectures go here */
SYSPAGE_64BIT = 0x100,
SYSPAGE_X86_64 = SYSPAGE_64BIT,
SYSPAGE_AARCH64,
/* additional 64 bit architectures go here */
};