Build an OS image filesystem (QNX)
mkifs [-?] [-a suffix] [-h] [-l inputline] [-n[n]] [-o directory] [-p patchfile] [-r rootdir] [-s section] [-v] [buildfile] [directory] [outputfile]
Linux, Mac, Microsoft Windows
When mkifs adds files to an IFS image, it uses the timestamp information from the file on the host machine. If mkifs is creating an inline file (which doesn't exist on the host machine), it has to generate its own timestamp information. By default, it's the time that the image is generated.
This results in different checksum values for two identical builds (because the file's creation or modification times are different). If you use -n, the checksum value is the same on all identical builds.
The -nn option addresses a quirk in NTFS relating to daylight savings time. This option forces the modification time for all files in the IFS image to be set to 0. This ensures that subsequent builds of the same IFS image have the same checksum.
The structure of the directory paths under rootdir must be identical to that of the default paths under ${QNX_TARGET}, but rootdir itself may be any path you choose. For example, if you wanted to include /dev/armle-v7/sbin/devb-eide, you would specify the option like this:
-r /devNotice that you don't include ${PROCESSOR} in rootdir.
By default, mkifs doesn't strip the following sections:
You can use the keepsection attribute to specify the sections not to be stripped from specific files in the image. For files in the bootstrap section (like startup or procnto), you must use an explicit [keepsection=] attribute; the global keep-section list affected by -s does not apply to these files.
The mkifs utility is used to create an OS image filesystem from a buildfile specification.
You specify the input and output on the command line:
If you don't specify either a buildfile or a directory, a buildfile is expected as input from standard input. The output is always an image file; if you don't specify outputfile, image-file data will be produced on standard output.
License checking
The mkifs utility checks for a valid QNX license key before performing any operation. If the license check fails, the utility stops running and displays a diagnostic message. A license check may fail if the license key is expired, missing, or not currently activated, or if the key doesn’t contain the permissions needed to run the utility.
The buildfile uses the same grammar as the mkefs command, but supports different attributes.
The buildfile specifies a list of files of various types; these files are placed by mkifs into the output image. As well as the files to be included, you can specify various attributes that are used to set parameters of the files or the image as a whole.
In a buildfile, a pound sign (#) indicates a comment; anything between it and the end of the line is ignored. There must be a space between a buildfile command and the pound sign.
Each line is in the form:
[attributes] file_specification
where the attributes (with the enclosing square brackets) and the file specification are both optional.
You can use an attribute:
[attribute] A B C
[attribute] A B C
Enclose the attributes in square brackets; when combining attributes (e.g., to specify both the user ID and the group ID), enclose both attribute tokens in the same pair of square brackets. For example:
# correct way [uid=5 gid=5] filename # incorrect way [uid=5] [gid=5] filename
There are two types of attributes:
A question mark (?) before an attribute makes the setting conditional. The attribute is set only if it hasn't already been set. For example, ?+bigendian sets the +bigendian attribute only if +bigendian or -bigendian hasn't been specified.
The file_specification takes one of the following forms:
Closing braces (}) and backslashes (\) in an inline file must be escaped with a backslash.
Either class of file may be preceded by zero or more attributes. These attributes specify the file's characteristics (e.g., the user ID that is to own the file on the target system, the type of file, etc.).
By default, mkifs doesn't strip the following sections:
You can use the -s option or the keepsection attribute to specify an alternative list of sections not to be stripped.
You can enclose a filename in double quotes ("") if it includes spaces or unusual characters.
The mkifs command supports the following attributes:
An OR-bar indicates that either the first or second element must be present, but not both (e.g., +|- bigendian means either +bigendian or -bigendian, but not +-bigendian).
autolink attribute (boolean)
+|-autolink
If the autolink attribute is on (which it is by default), when mkifs detects that it's processing a shared object, it looks inside the image for the SONAME (specified by the linker -h option). This internal name is the shared object name, and must include the version number (e.g., libc.so.1). The mkifs command puts the file into the image filesystem under the name with the version number and makes the name without the version number into a symbolic link to the file. For example, specifying:
libc.so
in the buildfile makes libc.so.1 the name of the file and libc.so a symlink to it. Specifying:
libc.so.1
in the buildfile gives the same results. You end up with the name with and without the version number in the image filesystem no matter which one you specify in the buildfile.
If the name that would be used as the symbolic link is already specified somewhere else in the buildfile, the symbolic link isn't created. For example:
libc.so.1 libc.so.2 [type=link] libc.so=libc.so.2
ensures that libc.so is pointing at the proper version of the library.
You can disable this feature by specifying the -autolink attribute.
big_pages attribute (boolean)
+|-big_pages
This attribute makes mkifs attempt to align binaries and shared libraries at the appropriate address, based on the size of the text segment. You can use the pagesizes attribute to indicate the page sizes that the underlying hardware supports. You can specify these attributes in the buildfile or in the bootfile. The big_pages attribute is off by default.
A phys_align attribute overrides the big_pages alignment hint. For example:
[+big_pages pagesizes=4k,64k] libc.so [-big_pages]a_binary_that_doesnt_want_bigpages [phys_align=1m]explicit_override_for_this_file
bigendian attribute (boolean)
+|-bigendian
Set the byte order for the image filesystem to either big (via +bigendian) or little (via -bigendian) endian. This option doesn't normally need to be specified when building a bootable image, since the bootfile provides the required byte order. If you aren't building a bootable filesystem, or the bootfile doesn't say which byte order to use, mkifs uses the host system's byte order in building the image filesystem.
cd attribute
cd=path
Set the current working directory to the specified pathname before attempting to open the host file. Default is the directory from which mkifs was invoked.
You can specify variables in the attribute's value. For information on how they're expanded (i.e., evaluated to a value used in their place), see the mkxfs section on processing variables.
chain attribute
chain=addr
Set the address at which the operating system will find the next image filesystem. Default is none.
cksum attribute
cksum=number
Specify the expected checksum (as calculated by cksum) of the file that the attribute applies to. If you specify this attribute, mkifs calculates the checksum of the host file imported into the image and compares it to the expected value; if a mismatch is found, the program terminates with an error.
compress attribute
+|-compress compress=algorithm
Set whether the image is compressed. The default is false.
The first (boolean) form turns compression on or off. The algorithm is the default, UCL8.
The second form (note there's no leading + or - sign) turns compression on and specifies the algorithm by number:
dperms attribute
dperms=dperms_spec
Set the access permissions of the directory. The dperms_spec can be one of the following:
[who] operator permissions[, ...]
Character | Meaning |
---|---|
u | User |
g | Group |
o | Others |
a | All (the default if you don't specify who) |
Character | Meaning |
---|---|
- | Delete the specified permissions |
= | Explicitly set the permissions |
+ | Add the specified permissions |
Character | Meaning |
---|---|
r | Read permission |
w | Write permission |
x | Execute permission, or search permission for directories |
s | When executed, set the user ID |
g | When executed, set the group ID |
t | Sticky bit |
You can include multiple symbolic mode strings, separating them with commas (,).
The default dperms_spec is *.
When running on a Windows host, mkifs might guess at the permissions, so you should use the dperms attribute to specify them explicitly. You might also have to use the uid and gid attributes to set the ownership correctly.
You can't use the dperms attribute to change the sticky bit setting assigned to certain executable files. This assignment is done by mkifs independently and after processing the buildfile.
For more information, see the perms attribute, Sticky bit updating below, and Directory Protection in The Open Group Base Specifications Issue 7, 2018 edition/IEEE Std 1003.1-2017 specification.
filter attribute
filter=filter_spec
Run the host file through the filter program specified, presenting the host file data as standard input to the program, and use the standard output from the program as the data to be placed into the image filesystem. Default is no filter.
To illustrate the use of a filter, consider storing a compressed file in the image filesystem, where the file exists in its uncompressed form on the host filesystem:
[filter="compress"] data.Z = data
This runs compress from a shell, passing it the contents of data as standard input. The compress command runs and generates the compressed version of its standard input on its standard output. The standard output is then placed into the image filesystem as the data.Z file.
You can specify a filter_spec of none. This is useful if you need to override a global filter specification.
followlink attribute (boolean)
[+|-followlink]target_path=host_path
Whether to resolve any symbolic links and include the target files or directories instead of the links.
You can specify variables in the attribute's value. For information on how they're expanded (i.e., evaluated to a value used in their place), see the mkxfs section on processing variables.
If you specify +followlink or omit it, whenever an item taken from the host filesystem is a symbolic link, mkifs resolves the link and includes its target file or directory.
If you specify -followlink, then:
gid attribute
gid=id_spec
Set the group ID number for the file. The value of this attribute may be either a number or an asterisk (*). If it's an asterisk, the group ID is taken from the host file; for an inline file, the group ID is the group of the user running mkifs. The default value for this attribute is *.
image attribute
image=[start_addr][-end_addr][,maxsize][=totalsize][%align]
Set the base and size limits for the image filesystem. The format for this attribute consists of an optional starting address, followed by zero or more parameters for sizing the address space. You can use a case-insensitive suffix of k, m, or g on the addresses and sizes.
Check your board documentation for information about where the board expects to find the bootable image. For ARM boards, this location tends to be board-specific. For x86 boards, the default may work, but, as with ARM boards, you need to consider the following:
keeplinked attribute (boolean)
+|-keeplinked
If true, and mkifs has to run a linker to position the executable within the image filesystem, the output file from the link is the basename of the host path with .sym appended. For example, if the host name is ../foo/bar, the output name is bar.sym. If false, a generated temporary name is used for the output file, and it's deleted after mkifs has run. The default is false.
keepsection attribute
keepsection=section_list
Don't strip the specified sections from an ELF executable. Use commas to separate the names in the section_list.
By default, mkifs doesn't strip the following sections:
You can use the -s option to prevent sections from being stripped from all ELF files.
linker attribute
linker=[linker_id_spec]linker_spec
When building a bootable image, mkifs sometimes needs to run a linker on relocatable objects to position them within the image. This option lets you specify printf-like macro expansions to tell mkifs how to generate the linker command line (see Linker Specification, below for details).
You don't normally need to specify this option, since mkifs or a bootfile provides a default. You can use different linkers for different types of ELF files.
The attribute value consists of an optional linker ID specification and a linker specification. The linker ID specification, if present, consists of:
If the ID specification is present, the linker specification is used only if the machine number of the ELF input file matches one of the given numbers, and the ELF file type of input file matches one of the given numbers and at least one of the program segment types in the input file matches one of the given numbers:
module attribute
module=module_name
Use this attribute to add optional modules to procnto.
For example, in order to use the adaptive partitioning scheduler, you must rebuild your OS images with the option [module=aps] added to the PATH= statement of your buildfile:
[module=aps] PATH=/proc/boot ./procnto-smp-instr -vv
You can now create partitions and launch applications within a particular partition for the adaptive partitioning scheduler.
For information on creating a partition, see Creating partitions in the Setting Up and Using the Adaptive Partitioning Scheduler chapter of the Adaptive Partitioning User's Guide.
For information on launching applications within a particular partition, see Launch processes in partitions in the Setting Up and Using the Adaptive Partitioning Scheduler chapter of the Adaptive Partitioning User's Guide.
mount attribute
mount=path
(QNX Neutrino 7.0.1 or later) Specify the mountpoint of the image filesystem. The default is /.
You can specify variables in the attribute's value. For information on how they're expanded (i.e., evaluated to a value used in their place), see the mkxfs section on processing variables.
If you use the default values of the mount and prefix attributes (/ and proc/boot, respectively), the files in the image filesystem end up under /proc/boot. This default value has a performance cost which can be significant for larger systems because the system's /proc filesystem is always mounted first and is always searched first for any file that starts with /proc, such as /proc/boot/libc.so.5. You can reduce the time spent searching by specifying something like this:
[prefix=""] [mount="/ifs"]
This makes sure the image filesystem isn't mounted at /, as its name is different from the /proc filesystem mountpoint.
mtime attribute
mtime=time_spec
Set the timestamps of the files or directories to the specified time. The time_spec must be either:
or:
YYYY-MM-DD-HH:MM:SS
You must provide all six elements. The time is always interpreted as UTC.
Timestamps specified with the mtime attribute aren't affected by the -n option.
optional attribute (boolean)
+|-optional
If true, and the host file can't be found, output a warning and continue building the image filesystem. If false, and the host file can't be found, output an error message and exit mkifs. The default is true. You can't set this attribute to true for bootstrap executables (see the virtual attribute for more information).
page_align attribute (boolean)
+|-page_align
If true, align the file on a page boundary. The mkifs utility always aligns executables and shared objects on page boundaries, so this attribute has an effect only on data files and files that you specify +raw for.
pagesizes attribute
pagesizes=size[,size]...
This attribute defines the page sizes that the underlying hardware supports, for use with the big_pages attribute. The sizes can be in any order, and can include a case-insensitive suffix of k, m, or g.
You can specify these attributes in the buildfile or in the bootfile.
perms attribute
perms=perms_spec
Set the access permissions of the file. The perms_spec can be one of the following:
[who] operator permissions[, ...]
Character | Meaning |
---|---|
u | User |
g | Group |
o | Others |
a | All (the default if you don't specify who) |
Character | Meaning |
---|---|
- | Delete the specified permissions |
= | Explicitly set the permissions |
+ | Add the specified permissions |
Character | Meaning |
---|---|
r | Read permission |
w | Write permission |
x | Execute permission, or search permission for directories |
s | When executed, set the user ID |
g | When executed, set the group ID |
t | Execute in place |
You can include multiple symbolic mode strings, separating them with commas (,).
The default perms_spec is *.
When running on Windows, mkifs can't get the setuid (set user ID) or setgid (set group ID) permissions from the file, and it might guess at the read, write, and execute permissions, so you should use the perms attribute to set the permissions explicitly. You might also have to use the uid and gid attributes to set the ownership correctly. To learn whether a utility needs to have the setuid or setgid permission set, see its entry in the Utilities Reference.
ELF executables and shared objects are automatically marked as executable (unless you specify [+raw]).
You can't use the perms attribute to change the sticky bit setting assigned to certain executable files. This assignment is done by mkifs independently and after processing the buildfile; for more information, see Sticky bit updating below.
Additionally, QNX recommends that you don't use the sticky bit for files (i.e., set with the perms attribute); POSIX doesn't define its sematics, and these may change with future versions of mkifs and mkefs.
phys_align attribute
phys_align=size[,group]
The phys_align attribute lets you align IFS objects on specific physical address boundaries to take advantage of large pages. The size is an integer, optionally followed by k, m, or g in lower- or uppercase. This attribute overrides the +|-big_pages attribute.
For example, to align a file on a 64 KB boundary, potentially allowing the use of 64 KB pages to map 64 KB chunks of the file, specify:
[phys_align=64k] some_executable
You can use the group option to group shared objects together based on an alignment size:
[phys_align=16M,group] first.so second.so third.so [phys_align=0] # ends alignment
In this example, first.so is aligned to 16 MB, and each successive shared object either completely fits within that same 16 MB page, or is bumped to the next 16 MB boundary.
physical attribute
physical=[cpu_name,]boot_filename [filter_args]
This attribute indicates that a bootable filesystem is being built. You can specify it only once in a buildfile. The image will be run in physical memory mode.
prefix attribute
prefix=prefix_spec
Set the prefix for the target file names. Default is proc/boot when building a bootable image, and the empty string when not. This prefix is added to the path specified by the mount attribute.
You can specify variables in the attribute's value. For information on how they're expanded (i.e., evaluated to a value used in their place), see the mkxfs section on processing variables.
ram attribute
ram=[start_addr][-end_addr][,maxsize][=totalsize][%align]
Set base and size limits for the read-write memory required by executables in the image filesystem. This attribute consists of an optional starting address, followed by zero or more parameters for sizing the address space. You can use a case-insensitive suffix of k, m, or g on the addresses and sizes.
You need to specify this attribute if the actual image is going to be stored on a read-only device such as ROM or flash memory. Use the image attribute to specify the location.
raw attribute (boolean)
+|-raw
If the raw attribute is false (the default), mkifs strips debugging information from executable files.
If you specify +raw for a file, the file is treated as a data file, even if it would normally be treated as an executable and relocated.
If you use the default attribute (-raw) and you specify that the data segment is to be used in place, the file's sticky bit will not be set. This identifies the executable to the QNX Neutrino process manager, which will prevent the program from running more than once, avoiding the possibility of running a program with corrupted static data.
… [+raw] # Don't strip debugging information my_app1 [-raw] esh # Only esh is affected [-raw] # Turn off +raw, since shared objects libphrender.so # can't be shared if +raw is enabled libph.so [+raw] my_app2 # We want debugging information for this # file only. The -raw flag is # still in effect for other files. libc.so # Still affected by -raw flag …
script attribute (boolean)
+|-script
If true, the host file is opened and processed as a script file after the process manager has initialized itself. Each line is parsed as a command line to be run. If multiple files are marked with +script, they're merged sequentially into a single file in the image filesystem; the file's name is the first script filename in the buildfile. The filenames for the subsequent script files are ignored, but they must be unique. See Script Files, below for more details on the command-line syntax.
search attribute
search=path:path:…
This attribute specifies that mkifs is to search for the file in the named locations on the host system. The search directory portion of the host file name isn't included in the name that's stored in the image filesystem. The default is the contents of the MKIFS_PATH environment variable.
You can specify variables in the attribute's value. For information on how they're expanded (i.e., evaluated to a value used in their place), see the mkxfs section on processing variables.
To ensure that mkifs searches the current directory, near the beginning of your buildfile use the [search] attribute to specify the directory. For example, the following ensures that mkifs will search the current directory before searching the other, standard directories:
[search=.:${MKIFS_PATH}]
You can reset the search paths setting to its default at any time with the following:
[search=${MKIFS_PATH}]
sha256 attribute
sha256=hex_string
Specify the expected SHA256 hash of the file that the attribute applies to. If you specify this attribute, mkifs calculates the SHA256 hash of the host file imported into the image and compares it to the expected value; if a mismatch is found, the program terminates with an error. You must specify the expected hash as a string of 64 hexadecimal digits, without a prefix or any delimiters. For example, instead of specifying 0xaa,0xbb,0xcc,..., specify aabbcc....
type attribute
type=file_type
Set the type of the files being created in the image filesystem. Allowable types are:
[type=dir]/usr/bin=/usr/nto/x86_64/bin
creates an empty directory named /usr/bin, with the same owner and permissions as for the host directory. To recursively copy /usr/nto/x86_64/bin to /usr/bin, you just need to specify:
/usr/bin=/usr/nto/x86_64/bin
uid attribute
uid=id_spec
Set the user ID number for the file. The value of this attribute may be either a number or an asterisk (*). If it's an asterisk, the user ID is taken from the host file; for an inline file, the user ID is the user running mkifs. The default value for this attribute is *.
virtual attribute
virtual=[cpu_name,]bootfile_name [filter_args]
This attribute specifies that a virtual address system is being built.
If there's a comma (,) or slash (/) in the value, the string in front of it is taken as the CPU type of the target system. If you don't specify a CPU type, and the PROCESSOR environment variable is set, mkifs uses its value; if you don't specify a CPU type, and the PROCESSOR environment variable isn't set, mkifs assumes the CPU type is x86_64. The utility sets the PROCESSOR environment variable to the CPU type, which affects the MKIFS_PATH search path for host files.
Bootfile | CPU types | Description |
---|---|---|
binary.boot | aarch64le, armle-v7, x86_64 | Create a simple binary image (without the jump instruction that
raw.boot adds). If you build a binary image, and you want to load it with U-Boot (or some other bootloader), you have to execute mkifs -vvvv buildfile imagefile, so that you can see what the actual entry address is, and then pass that entry address to the bootloader when you start the image. If you modify the startup code, the entry address may change, so you have to obtain it every time. With a raw image, you can just have the bootloader jump to the same address that you downloaded the image to. |
bios.boot | x86_64 | Create an image that's suitable for machines with a BIOS. Information that's gathered from the BIOS is put into the startup headers. |
elf.boot | aarch64le, armle-v7, x86_64 | Create an image that looks like an ELF executable. |
kpi.boot | x86_64 | Create an image that can be loaded by Intel's Automotive Boot Loader. |
multiboot.boot | x86_64 | Create an image for use with a multiboot-capable loader (e.g., GRUB). |
raw.boot | aarch64le, armle-v7 | Create a binary image with an instruction sequence at its beginning to jump to the offset of startup_vaddr within the startup header. The advantage is that when you download a raw image to memory using a bootloader, you can then instruct it to run right at the beginning of the image, rather than having to figure out what the actual startup_vaddr is each time you modify the startup code. |
srec.boot | aarch64le, armle-v7, x86_64 | Create an image in S-record format. |
uefi.boot | x86_64 | Create an image that's suitable for machines with a Unified Extensible Firmware Interface (UEFI). |
For more details on the contents of the file, see Bootfile, below.
Any characters in the attribute value following a blank are used as arguments to any image filter command specified by the bootfile, like this:
[virtual="aarch64le,srec -b"] boot = {
The contents of the host file that this attribute applies to are parsed to discover the bootstrap executables used to bring up the system. Each line identifies one bootstrap executable:
As mentioned above, by specifying the [+script] attribute, you're telling mkifs that the specified file is a script file, a sequence of commands to be executed when the process manager has completed its startup.
The bootfile typically sets the _CS_PATH configuration string, and might set _CS_LIBPATH. You can set environment variables, such as PATH and LD_LIBRARY_PATH, in a script file.
Script files, for the most part, look just like regular shell scripts, except that:
The script file consists of one or more lines, with each line having the following syntax:
[modifiers] [command_line [&]]
The modifiers consist of a list, enclosed in square brackets, of blank-separated items that modify how QNX Neutrino runs the specified command_line. If there's a command line following the modifiers, the modifiers affect only that one command line. If there's no command line, the modifiers affect all subsequent command lines.
The modifiers are described below, and include:
Those marked as boolean accept a plus (+) or minus (-) character to enable or disable the effect; the others accept a parameter.
argv0 modifier
Sets the argv[0] element of the command argument entry. By default, this is the same as the command name. This option is typically used to simulate invoking a command via a different name; the classical example is the compress command, which can be invoked as uncompress:
[argv0=uncompress] compress filename.Z
cpu modifier
Specifies the CPU on which to launch the following process (or, if the attribute is used alone on a line without a command, sets the default CPU for all following processes). This modifier is useful for setting up bound multiprocessing (BMP). Specify the CPU as a zero-based processor number:
[cpu=0] my_program
A value of * allows the processes to run on all processors:
[cpu=*] my_program
At boot time, if there isn't a processor with the given index, a warning message is displayed, and the command is launched without any runmask restriction.
external modifier (boolean)
Ordinarily, mkifs recognizes certain commands as internal commands, ones that aren't loaded from the host's filesystem, but are understood directly by mkifs. These commands are:
The optional wait_time specifies the maximum number of seconds to wait for the file to appear. It can include one decimal place to specify tenths of a second. The default is 5.0 seconds.
The +external modifier instructs mkifs to search for the specified command on the host filesystem, rather than assume the internal meaning for the command. The default is -external.
pri modifier
Lets you specify the command's priority and optionally the scheduling policy. The pri modifier accepts a numeric priority, optionally followed by one of the letters:
See the System Architecture guide for a description of the various priority levels and scheduling algorithms.
For example, to start up the console driver, devc-con at priority 20, with FIFO scheduling, specify:
[pri=20f] devc-con -n9 &
sched_aps modifier
Launch the process (or, if the attribute is used alone on a line without a command, all following processes) in the adaptive partition with the specified name:
sched_aps=partition_name
For example:
[+sessionpri=35 sched_aps=DebugReserve] ksh &
launches a high-priority shell in the DebugReserve partition.
sched_aps name budget
For more information, see the Adaptive Partitioning User's Guide.
session modifier (boolean)
If +session is specified, make the process a session leader (as per POSIX), and make the process's stdin the controlling terminal (i.e., direct Ctrl C at this process group). If -session is specified, don't make the process a session leader. The default is -session.
This parameter is typically used for the shell:
[+session] esh
When building a bootable filesystem, you must specify a bootfile via the physical or virtual attribute. Note that the bootfile must be the first file specification within the buildfile. If the first character of the bootfile is a left square bracket ([), a list of configuration attributes is given in the same syntax as the buildfile. The list of attributes is terminated by a right square bracket (]). The allowed attributes, and their formats, are:
See Image filter, below for an example of using the image_filter_spec.
phys_addr = virt_addr + number
The default is zero.
Following the closing square bracket character (]) of the bootfile attributes, mkifs searches for the string boot. If it's found, mkifs considers all data immediately following, through to the end of the file, to be boot prefix code. This data is placed at the start of the image file. If the len attribute was given and is larger than the size of the boot prefix code, the image file is padded out to the size given.
You can specify an image filter within the specification for the bootfile, and optionally specify macro expansions to it. These macro expansions are documented above, in the description of the filter attibute for the bootfile.
The image filters include the following:
mkifsf_elf [-Lpaddr_loc,entry_loc,vaddr_loc] [-melf_machine_number] [-eenv_num] [-4] [-8] [elf_machine_number] startup-offset image-file
mkifsf_openbios startup-offset image-file
mkifsf_srec [-b] [-c] [-l] [-Lpaddr_loc,entry_loc] input-image-file output-srec-file
The options include:
mkifsf_uefi [-eenv_entry_num] [-MPE_machine] [-melf_machine_number] [-ssubsystem_number] startup-offset image-file
The options include:
Generally, image filters are expected to take the file specified by the %i variable and modify it in place. If this isn't possible (e.g., the file changes size as a result of the filter program), specifying %I causes mkifs to store the original file in a temporary filename (named by %I), and expect the modified file in the filename given by %i. This happens only when the %I macro expansion is specified.
The contents of the variable are compared against the constant and if the result is true, the text following the comma is included in the command string being built. If the comparison is false, the contents of the string following the comma are omitted.
Variable: | Value: |
---|---|
e | 0 == little endian 1 == big endian |
d | Data segment address |
f | 0 == startup file 1 == bootstrap file 2 == normal file |
h | Executable header address |
m | Machine number from the ELF header |
v | 0 == file linked physically 1 == file linked virtually |
V | 0 == physical system 1 == virtual system |
Here's the default linker command specification for mkifs:
static char default_linker[] = { "qcc" /* -bootstrap : Link statically and use "$QNX_TARGET/$CPU/lib/nto.link" script. */ /* -nostdlib : Don't use the ld_startup_* or ld_stdlib sections. */ /* -Wl,--no-keep-memory: Reduce ld memory footprint. */ /* -Vgcc_nto: Prefix of linker variant to invoke; cpu-specific suffix is */ /* generated in lines below. */ " -bootstrap -nostdlib -Wl,--no-keep-memory -Vgcc_nto" /* If ELF machine type is 40, ... */ /* ...append "arm" to "-Vgcc_nto" if architecture is ARM */ /* ...append "armv7" to "-Vgcc_nto" if architecture is ARM-v7 */ "%(m==40,%(a==0,arm%)%(a==7,armv7%)%)" /* If ELF machine type is 62, append "x86_64" to "-Vgcc_nto" */ "%(m==62,x86_64%)" /* If ELF machine type is 183, append "aarch64" to "-Vgcc_nto" */ "%(m==183,aarch64%)" /* If type is not 3, 6, or 62 (i.e., non-x86*), add "-EL" or "-EB" for endianness */ "%(m!=3,%(m!=6,%(m!=62,%(e==0, -EL%)%(e==1, -EB%)%)%)%)" /* If type is 62 (x86_64), set max page size to 4k */ "%(m==62, -Wl,-z -Wl,\"max-page-size=4096\"%)" /* If text address is given, relocate .text section */ "%(h!=0, -Wl,--section-start -Wl,.text=0x%t%)" /* If data address is given, relocate .data section */ "%(d!=0, -Wl,--section-start -Wl,.data=0x%d%)" /* Avoid GOTPCREL issue */ " -Wl,--no-relax" /* Specify output and input files */ " -o%o %i" /* For all specified modules (e.g. APS), link in the appropriate lib */ "%[M -L%^i -Wl,-uinit_%^n -lmod_%n%]" };
For the meaning of the parameters specified, see qcc.
The image created by mkifs has the following layout:
Although it isn't necessary to have a detailed understanding of the format of an image to make one, a general understanding is worthwhile.
The first section (called the boot prefix) is controlled by the bootfile that you specified in the virtual= or physical= attribute. For many systems this section doesn't occupy any space in the image. When it's present, it's typically used to address one of the following issues:
A boot on a standard x86 PC is a good example of the need for placing code here. When a PC boots, it transfers control while in 16-bit real mode. The startup program assumes the processor is running in 32-bit protected mode. So, an image with a PC BIOS boot contains code here that switches the processor into 32-bit protected mode. It also does a series of BIOS calls to gather information from the BIOS, since the protected mode startup program is unable to make any BIOS calls itself.
An example of this is a network boot in which the image needs to be wrapped in something that was loaded in its entirety into memory on the target (e.g., ELF object file structures). In this case, an external program makes a copy of the image, adding information to the front, and possibly the end, of the image. If the wrapper prefix is a small fixed size, you may wish to include a boot prefix that's zero-filled, which an external program can overwrite. This saves you having to make a file copy of a large image to append to the wrapper. You can always append a wrapper directly to the end of an image file.
This section contains information about the image, which is used by our IPL and startup programs.
Part of this section is written to by mkifs. Another part is set to zero, and is written to by the IPL code to pass data (determined at runtime) to startup. The data is in the form of a set of structures (for more information, see The info member in the Initial Program Loaders chapter of Building Embedded Systems).
If an image isn't bootable, this section is omitted.
This section contains the code and data for the startup program. This code must be executed in RAM. If the image is in ROM/FLASH, our standard IPL code uses information in the startup header to always copy the startup into RAM and transfer control to it there.
If an image isn't bootable, this section is omitted.
A checksum for use by startup. If an image isn't bootable, this section is omitted.
Information on the image filesystem that follows.
A series of directory entries for each file in the image filesystem.
The files within the image filesystem. Executables that are executed in place are aligned on page boundaries. An attempt is made to fill any holes created by this alignment with small data files that have no alignment needs.
A checksum for the image.
Patch files let you override the user ID, group ID, and permissions of certain files, depending on their location and filename pattern. Patches are applied after all files have been collected (from the buildfile and/or the specified directory). Consequently, patch files can override settings specified in the buildfile.
Patch files must contain only lines of the form:
#comment
or:
type:path:pattern:uid:gid:perms
In comment lines, # must be the very first character. The entire line is regarded as a comment and is ignored.
The type is either d or f, optionally followed by r. Type d patches are applied only to directories, and type f patches are applied only to files. If you improperly specify a path (e.g., you provide a directory entry but with an f type), the patching isn't done for that path. An r indicates that the patch should be applied recursively within path; without r, the patch is applied to path only.
The pattern is a filename pattern that specifies which files to apply the patch to. The uid and gid must be decimal numbers, while perms must be an octal number (see chmod). Note that it isn't possible to set only the user ID, group ID, or permissions; for each match, all three are affected.
After collecting the files from the buildfile and applying the instructions specified in the patch file (if -p was given), mkifs updates (and potentially alters) the sticky bit for certain executable files. The files affected are:
For more information about the sticky bit, see the perms attribute, and Sticky bit in the QNX Neutrino User's Guide.
Here's a very simple buildfile that specifies the operating system, a console driver, and a shell:
[virtual=x86_64,bios] .bootstrap = { startup-x86 PATH=/proc/boot procnto-smp-instr } [+script] .script = { devc-con -n9 & reopen /dev/con1 [+session] esh & } libc.so libgcc_s.so.1 ldqnx-64.so.2 devc-con esh [type=link] /usr/lib/ldqnx-64.so.2=/proc/boot/ldqnx-64.so.2
You can now build an image from the above, like this (assuming that the buildfile is called simple.bld, and that we want the resultant image to be called simple.ifs):
mkifs simple.bld simple.ifs
Here's a buildfile with EIDE disk support:
[virtual=x86_64,bios +compress] .bootstrap = { startup-x86 PATH=/proc/boot procnto-smp-instr } [+script] .script = { devc-con -e & devb-eide & reopen /dev/con1 [+session] PATH=/proc/boot esh & } libc.so libgcc_s.so.1 ldqnx-64.so libcam.so cam-disk.so io-blk.so fs-qnx6.so devc-con esh ls devb-eide [type=link] /usr/lib/ldqnx-64.so.2=/proc/boot/ldqnx-64.so.2
The next example includes an inline /etc/hosts file that's used to resolve addresses used at boot time by programs such as fs-nfs3; it also shows how to pass environment variables to different commands.
[image=0x1f0000] [virtual=armle-v7,raw] .bootstrap = { startup-my_board-smp -v -Nmy_board-5 -D0x800003f8^0.9600 PATH=/proc/boot:/bin:/usr/bin:/sbin:/usr/sbin \ LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll \ procnto-smp-instr -v } [+script] startup-script = { # Programs expect to find the runtime linkers in /usr/lib/, but they're # in /proc/boot, so we set up symbolic links to them. procmgr_symlink ../../proc/boot/ldqnx.so.2 /usr/lib/ldqnx.so.2 pci-server & waitfor /dev/pci io-pkt-v4-hc -d abc100 irq=2,media=9,vid=0x1011,did=0x9 -ptcpip if_up -p en0 ifconfig en0 my_board-5 up if_up en0 fs-nfs3 -ru ra:/my_system /my_system & waitfor /my_system/target/qnx6/armle-v7/usr/sbin/slogger2 360 # setup environment variables TZ=est05edt04 procmgr_symlink /my_system/target/qnx6/armle-v7/bin /bin procmgr_symlink /my_system/target/qnx6/armle-v7/lib /lib procmgr_symlink /my_system/target/qnx6/armle-v7/sbin /sbin procmgr_symlink /my_system/target/qnx6/armle-v7/usr/bin /usr/bin procmgr_symlink /my_system/target/qnx6/armle-v7/usr/sbin /usr/sbin procmgr_symlink /my_system/target/qnx6/armle-v7/usr/lib /usr/lib procmgr_symlink /my_system/target/qnx6/etc /etc slogger2 & waitfor /dev/slog devc-ser8250 -e -c1846200 -b 9600 0x800003f8,104 0x800002f8,103 & waitfor /dev/ser1 pipe waitfor /dev/pipe devc-pty & waitfor /dev/ptyp0 mqueue inetd & tinit } [type=link] /tmp=/dev/shmem [type=link] /dev/con1 = /dev/ser1 # Data files are created in the named directory /etc/hosts = { 127.0.0.1 localhost 192.168.1.1 ra 192.168.1.111 my_board-5 } # Include the current libc.so. It will be created as a real file using # its internal SONAME, with libc.so being a symlink to it. The symlink # will point to the last libc.so.*, so if an earlier libc is needed # (e.g., libc.so.4), add it before libc.so. libc.so.4 libc.so libgcc_s.so.1 ldqnx.so.2 devnp-abc100.so libsocket.so pci-server io-pkt-v4-hc if_up ifconfig fs-nfs3
Does virtual specify the CPU type? | Is PROCESSOR set? | Value used |
---|---|---|
Yes | Don't care | virtual attribute's CPU type |
No | Yes | $PROCESSOR |
No | No | x86_64 |
Any changes that mkifs makes to PROCESSOR last only until the utility exits.