You can choose to build a QNX Hypervisor system from inside the HHBSP framework, or outside the HHBSP framework.
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 to the locations you have chosen (see “Specify the component locations”).
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-700_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 use QNX Neutrino 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 and QNX660_GUEST_BSP_LOCATION variables, as needed. For example, for a QNX Neutrino OS 7.0 guest:
# unzip ~/Downloads/BSP_hypervisor-guest-x86_64_br-mainline_be-700_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 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 “Hypervisor disk image partitions” in this chapter, and “diskimage configuration file” in the 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 utiltiy 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” in the “Getting Started” chapter.
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 hypervisor” in the “Getting Started” chapter.
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 reference by $BOARD_SPECIFIC_BSP_LOCATION). These modifications include, where needed:
If you are using QOS 2.0, you must specify module=qvm-qos_capable instead of module=qvm.
The script attempts to keep existing attributes, so the final buildfile may include duplicate entries.
For Intel Broadwell NUC 5i5 platforms only, the script also does the following:
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.
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.