You can build a QNX hypervisor system from inside the HHBSP framework, with files in their default locations in the HHBSP directory structure, or elsewhere, as needed.
To build a hypervisor system from inside the HHBSP framework, complete the following tasks:
You don't have to place the BSPs in their default locations in the HHBSP, or even in the HHBSP directory structure. You may place them elsewhere on your development host, as long as you set the relevant variables (either via the command line or by editing the configure.mk configuration file) to point to the locations you have chosen (see “Specify the component locations”).
For information about how to build the hypervisor host outside the HHBSP framework, see “Building the host” in this chapter.
Before you build your hypervisor system from inside the HHBSP framework, you need to set the board type, and specify the locations of the BSPs you will use in you build:
If you haven't done so already, download and unzip the appropriate board-specific BSP into the directory referenced by BOARD_SPECIFIC_BSP_LOCATION. For example:
# unzip ~/Downloads/BSP_intel-x86-64-APL-abl_br-mainline_be-704_SVN830677_JBN6.zip \ -d $BOARD_SPECIFIC_BSP_LOCATION
When you have confirmed that your build environment is correctly set up and that you have the board-specific BSP for the host in the location where the build will look for it, you should be ready to build the hypervisor host and its guests.
If you need to modify the board-specific BSP for the host, you will need to build the host after you have made your changes:
Go to that BSP's root directory. Assuming that you have set BOARD_SPECIFIC_BSP_LOCATION correctly:
# cd $BOARD_SPECIFIC_BSP_LOCATION
Build the host:
# make
To build QOS 2.1 or QNX Neutrino 7.0.4+ OS guests, you need to download the architecture-specific guest BSPs, unzip them, and place them in the directories referenced by your QNX*_GUEST_BSP_LOCATION variables:
Go to your HHBSP's root directory:
# cd hhbsp
where hhbsp is your HHBSP root directory.
Download and unzip QNX guest BSPs into the locations referenced by the QNX7_GUEST_BSP_LOCATION variable, as needed. For example, for a QNX Neutrino OS 7.0 guest:
# unzip ~/Downloads/BSP_hypervisor-guest-x86_64_br-mainline_be-704_SVN832288_JBN22.zip \ -d $QNX7_GUEST_BSP_LOCATION
Go to the root directory for the each modified QNX guest BSP, and run make to rebuild the guest. For example, if you modified the QNX Neutrino OS 7.0.4+ guest:
# cd $QNX7_GUEST_BSP_LOCATION # make
The HHBSP's image/disk_config/ directory includes:
If you need to adjust any of the disk image settings, open and modify these files. For more information about configuring disk images, see “Disk image partitions” in this chapter, and “diskimage configuration file” in the QNX SDP Utilities Reference.
When you have completed all the relevant tasks described above, you can build your hypervisor host system:
You should now be ready to use dd or a similar utility to transfer the disk image to removable media, which you can then use to move your disk image to your target board. For instructions, see “Transferring the disk image”.
The disk image is a complete disk image; it includes a partition table and multiple partitions, so you must copy it directly to the raw disk device.
Don't write to your storage medium's partition file (e.g., /dev/sdb1 or /dev/rdisk3s1). Write to the raw device file.
For instructions on how to boot the hypervisor, see “Booting the host”.
When you run make to build a hypervisor system, the build process:
These buildfiles are, in the order in which the build concatenates them:
The order in which the buildfiles are concatenated is important. The scripts that run when the hypervisor boots expects this order.
The script that is invoked by running make in the HHBSP root directory to build a hypervisor system effects modifications to the host BSP buildfiles (in the directory referenced by $BOARD_SPECIFIC_BSP_LOCATION). These modifications include, where needed:
When the build process is complete it leaves in the HHBSP's generated/ifs/ directory a copy of the buildfile it generated and used to build each IFS. If the build created three IFSs, there should be three of these generated buildfiles.
The build process names these files as follows: hypervisor_FINAL_info.build, where info is information that will allow you to determine which generated buildfile was used to build with which IFS. You can examine these generated buildfiles if you need to review and better understand exactly what went into a particular IFS.
The script attempts to keep existing attributes, so the final buildfile may include duplicate entries.
A single build process creates as many IFSs as there are buildfiles in the images/host_bsp/images/ directory.
Thus, if there are three buildfiles in this directory, the build assembles three distinct concatenations: one for each of these files; each file is placed in a separate concatenation with hypervisor.common.build, then the relevant board-specific hypervisor buildfiles. The result of the build is three different IFSs.
If you are only interested in a single IFS variant, remove the buildfiles for the IFSs you don't want from the images/host_bsp/images/ directory, or rename them so that the build process doesn't find them.
Running make in the HHBSP root directory looks after getting any updated IFSs for the hypervisor host and for guests that are in the HHBSP directory structure and calling mkxfs to produce a disk image.
The build uses the following updated files from the HHBSP directories:
For Linux guests, the build process uses the contents of the entire images/guest_bsps/linux/arch directory (where arch is either arm or x86), which should include everything needed to run a Linux guest (Linux kernel, initrd file, etc.). For more information about building Linux guests, see “Building Linux and Android guests” in this chapter.