![[Previous]](../prev.gif) |
![[Contents]](../contents.gif) |
![[Index]](../keyword_index.gif) |
![[Next]](../next.gif) |
|
|
|
|
Build an OS image filesystem (QNX)
mkifs [-l inputline] [-n[n]] [-r rootdir] [-v]
[buildfile [imagefile]]
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 the NTFS filesystem 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 this file:
/dev/ppcbe/sbin/pci-ppc405
you would specify the option like this:
-r /devNotice that you don't include ${PROCESSOR} in rootdir.
 |
If you set MKIFS_PATH, mkifs ignores the -r option. |
The mkifs utility is used to create an OS image filesystem from a buildfile specification.
|
Currently, you can use mkifs to create only bootable images.
Don't confuse this command with mkefs, which builds an embedded filesystem. |
The files are specified on the command line:
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.
|
You can't use a backslash (\) to break long lines into smaller pieces. |
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 in two ways:
Attributes are enclosed 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 already been set.
The file_specification takes one of the following forms:
|
The mkifs utility doesn't parse the contents of an inline file for
anything but the closing brace.
For example, mkifs doesn't interpret
a pound sign (#) in an inline file as the beginning of a comment.
The syntax of the inline file depends on what it's used for on the
target system.
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 are used to specify the characteristics of the file (e.g. user ID that the file should be owned by on the target system, type of file, etc.)
|
By default, mkifs strips usage messages, debugging information, and Photon resources from executable files that you include in the image. Doing this helps to reduce the size of the image. To keep this information, specify the +raw attribute. |
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
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 is typically the shared object name, including 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; the name without is made 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.
+|-bigendian
Set the byte order for the image file system 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 a bootable file system isn't being built, or the bootfile doesn't say which byte order to use, the host system byte order is used in building the image file system.
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.
chain=addr
Set the address at which the operating system will find the next image filesystem. Default is none.
code=uip_spec
Set whether the code segment of an executable is used directly from the image file system (uip or u) or copied (copy or c) when invoked. The default is to use the code segment in place (uip). For more information, see "Notes on XIP versus copy," below.
+|-compress
Set whether the image is compressed. Default is false.
data=uip_spec
Set whether the data segment of an executable is used directly from the image filesystem (uip or u) or copied (copy or c) when invoked. The default is to use the data segment in place (uip). For more information, see "Notes on XIP versus copy," below.
dperms=perm_spec
Set the access permissions of the directory. See the perms attribute for more information.
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 file system. 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.
[+|-followlink]target_path=host_path
If you specify +followlink or omit it, mkifs follows any links and makes target_path a copy of host_path.
If you specify -followlink, mkifs creates a link called target_path that points to whatever host_path points at. It's up to you to make sure that the file pointed to is placed in the image.
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=addr_space_spec
Set the base and size limits for the image file system. The format for this attribute consists of an optional starting address, followed by zero or more address space sizing parameters.
The starting address is the base address of the image, and matters only when building a bootable image. Its default depends on the bootfile selected. For example, on an x86 using the bios.boot file, the image address begins at 4M.
|
If you don't specify the ram attribute, the image is assumed to be in RAM. For more information, see "Notes on XIP versus copy," below. |
+|-keeplinked
If true, and mkifs has to run a linker to position the executable within the image file system, 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.
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).
This option doesn't normally need to be specified, since mkifs or a bootfile provides a default. Different linkers can be used 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:
+|-optional
If true, and the host file can't be found, output a warning and continue building the image file system. If false, and the host file can't be found, output an error message and exit mkifs. The default is true. This attribute can't be set to true for bootstrap executables (see the virtual attribute for more information).
perms=perm_spec
Set the access permissions of the file. If specified as a number, the permissions are set to that number (just like the chmod command). If specified as an asterisk (*), the host file's permissions are used; for an inline file, the permissions are obtained from the umask of the user running mkifs. Otherwise, a symbolic mode string (which is a subset of chmod's) is used to delete, add, or set permissions.
The symbolic mode string consists of:
You can include more than one symbolic mode string, separating them with a comma (,).
The default is *.
physical=cpu_name,boot_filename filter_args
This attribute indicates that a bootable file system is being built. It may be specified only once in a control file. The image will be run in physical memory mode.
|
The physical attribute isn't currently implemented; use virtual. |
For more information, see the virtual 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.
ram=addr_space_spec
Set base and size limits for the read-write memory required by executables in the image file system. This attribute consists of an optional starting address, followed by zero or more address space sizing parameters.
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.
The starting address specifies the base address of the RAM, and matters only when building a bootable image. The default is dependent on whatever bootfile is selected.
For information about how everything interacts, see "Notes on XIP versus copy," below.
+|-raw
If the raw attribute is false (the default), mkifs strips usage messages, debugging information, and Photon resources 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.
|
Don't specify the +raw attribute for shared objects; it prevents
them from being shared.
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 process manager, which will prevent the program from running more than once, avoiding the possibility of running a program with corrupted static data. |
Here's a fragment from a build file that demonstrates the use and scope of the raw attribute:
...
[+raw] # Don't strip usage, debugging or
othello # Photon resources from binaries
[-raw] esh # Only esh is affected
pwm # Still affected by +raw flag
pfm
[-raw] # Turn off +raw, since shared objects
libphrender.so # can't be shared if +raw is enabled
libph.so
[+raw] my_ph_app # We want Photon resources for this
# file only. The -raw flag is
# still in effect for other files.
libc.so # Still affected by -raw flag
...
|
If you use Windows tools to build your image, files specified as +raw will not have executable permission when the image is booted. This is because the win32 file system cannot set a file's executable bit. To make such files executable, specify perms=+x when using +raw in the build file. |
+|-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 file system; 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=filename:filename:...
This attribute specifies that mkifs should 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 file system. The default is the contents of the MKIFS_PATH environment variable.
|
Colon separators and forward slashes in the paths are the standard UNIX conventions, but for Windows searches, you must use the standard Windows conventions such as semicolon separators and backslashes in the paths. |
type=file_type
Set the type of the files being created in the image filesystem. Allowable types are:
|
Specifying [type=dir] tells mkifs a directory on the target system; you don't need to specify the type when you're copying the
contents of a directory. For example, to copy /usr/nto/x86/bin to /usr/bin, you a
just need to specify:
/usr/bin=/usr/nto/x86/bin |
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=cpu_name,bootfile_name filter_args
This attribute specifies that a virtual address system is being built.
If there's a comma (,) in the value, the string in front of it is taken to be the CPU type of the target system. If no CPU type is specified, the host system CPU type is used. The PROCESSOR environment variable is set to that string (this affects the MKIFS_PATH search path for host files).
The characters after the comma (or the equal sign for the attribute if there's no comma) up to the first blank character are taken to be the name of the bootfile. The suffix .boot is appended to the given name and MKIFS_PATH is searched for the file. You can find default bootfiles in ${QNX_TARGET}/${PROCESSOR}/boot/sys. 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="x86,srec -b"] boot = {
|
If the value of the virtual attribute includes a space, put
quotation marks around the string.
Startup code can't decompress in place. In other words, the address where the compressed version of the image is located has to be different from where the image is while running. |
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 that should be executed when the process manager has completed its startup.
|
In order to run a command, its executable must be available when the script is executed. You can add the executable to the image, or get it from a filesystem that's started before the executable is required. The latter approach results in a smaller image. |
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.
If you specify an ampersand (&) after the command line, the program runs in the background, and Neutrino doesn't wait for the program to finish before continuing with the next line in the script. If you don't specify the ampersand, and the program doesn't exit, then the rest of the script is never executed.
The modifiers are described below. Those marked as "boolean" accept a plus (+) or minus (-) character to enable or disable the effect; the others accept a parameter.
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
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 digit 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.
|
Using +external is a dubious practice. Specifying an external modifier on a command that isn't an internal command is redundant. |
Lets you specify the command's priority and optionally the scheduling algorithm. 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:
[pri=20f] devc-con -n9 &
The default for this modifier is the same as the default used by procnto.
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 file system, a bootfile must be specified via the physical or virtual attributes. Note that the bootfile must be the first file specification within the buildfile. If the first character of the bootfile is an 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 specified 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 filter description.
The following image filters are currently available:
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 linker specification lets you control how the linker command line is built when mkifs needs to turn a relocatable object into an executable running at a particular address. It operates much like a printf() format string, with characters being copied from the format to the command line until a percent character (%) is found. The following formatting codes after a percent character are supported:
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.
The conditional is terminated by percent character followed by a closing parenthesis, %). Conditionals can nest. The variables that can be tested are:
| 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 const char default_linker[] = {
"(;1;)gcc --no-keep-memory -nostdlib -nostartfiles -nodefaultlibs"
" -bnto%(m==3,x86%)%(m==6,x86%)%(m==8,mips%)%(m==20,ppc%)"
"%(e==0, -EL%)%(e==1, -EB%)"
"%(h!=0, -Ttext 0x%t%)%(d!=0, -Tdata 0x%d%)"
" -o%o %i"
};
For the meaning of the parameters specified, see gcc.
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 filename 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 prepend 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 Customizing IPL Programs in 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.
The code=copy|uip and data=copy|uip attributes may be applied to executables in the image.
|
Shared objects currently assume code=uip and data=copy. To get the effect of code=copy, manually copy the shared object to /dev/shmem and set LD_LIBRARY_PATH as appropriate. To save ROM/Flash space, compress the shared object in the image filesystem and decompress it into /dev/shmem. |
When an executable is run, these attributes determine whether the code or data for that executable is to be used in place or copied to RAM. An image filesystem may exist in either RAM or linearly addressable ROM/FLASH. Images in RAM are usually loaded from a device that isn't linearly addressable. This includes disk boots, network boots, and boots from bank switched ROM/FLASH devices. It also includes any image that's been compressed.
For example, a compressed image may reside in linearly addressable flash, but it can't be used until it's decompressed into RAM. The following combinations exist for any image in RAM:
| Code | Data | Comments |
|---|---|---|
| uip | uip | Run once (default) |
| uip | copy | Run multiple |
| copy | uip | Run once but wasteful |
| copy | copy | Run multiple but wasteful |
The default assumes that you want to run both code and data in place. This would be fine for an executable that has a large amount of static data and that you need to run only once (e.g. a resource manager or driver that starts when the system boots). Running data in place modifies the only copy of the data as the program runs, so you can't start the program again.
|
In this case, the file's sticky bit will not be set. This identifies the executable to the QNX Neutrino process manager which will prevent the program running more than once, so avoiding the possibility of running a program with corrupted static data. |
That's why you have to specify data=copy if you want to run the executable multiple times.
The two cases listed as "wasteful" fall out of the combinations but they provide no additional capabilities and waste memory by copying the code unnecessarily. Since the code is read-only and can't be modified, it can always be used in place.
If you are creating an image in ROM/FLASH, the following combinations exist:
| Code | Data | Comments |
|---|---|---|
| uip | uip | Run once |
| uip | copy | Run multiple (default) |
| copy | uip | Run once |
| copy | copy | Run multiple (slow ROM/FLASH) |
|
You have to specify both image and ram file attributes if you want to create the image in ROM/FLASH, otherwise the process manager assumes that the image is in RAM. The data=copy attribute is assumed for an image in ROM/Flash. |
The cases where code is copied may seem wasteful (as in the RAM image example) but it may make sense for systems where the ROM/FLASH is slow -- perhaps it has an 8-bit interface or requires extra wait states for access to it. In that case, you may wish to copy it to RAM, so that it executes faster.
Here's a very simple buildfile that specifies the operating system, a console driver, and a shell:
[virtual=x86,bios] .bootstrap = {
startup-bios
PATH=/proc/boot procnto
}
[+script] .script = {
devc-con -n9 &
reopen /dev/con1
[+session] esh
}
libc.so
[data=copy]
devc-con
esh
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so
|
The runtime linker is expected to be found in a file called ldqnx.so.2, but the runtime linker is currently contained within the libc.so file, so we make a process manager symbolic link to it. |
An image can then be built from the above (assume 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,bios +compress"] .bootstrap = {
startup-bios
PATH=/proc/boot procnto
}
[+script] .script = {
devc-con -e &
devb-eide &
reopen /dev/con1
[+session] PATH=/proc/boot esh
}
libc.so
libcam.so
cam-disk.so
io-blk.so
fs-qnx4.so
[data=copy]
devc-con
esh
ls
devb-eide
[type=link] /usr/lib/ldqnx.so.2=/proc/boot/libc.so.2
This 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 environment variables can be passed to different commands:
[image=0x1f0000]
[virtual=ppcbe,raw] .bootstrap = {
startup-mtx604-smp -v -Nmtx604-5 -D0x800003f8^0.9600
PATH=/proc/boot:/bin:/usr/bin:/sbin:/usr/sbin LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll procnto-600-smp -v
}
[+script] startup-script = {
procmgr_symlink ../../proc/boot/libc.so.2 /usr/lib/ldqnx.so.2
pci-raven &
waitfor /dev/pci
io-net -dtulip irq=2,media=9,vid=0x1011,did=0x9 -ptcpip &
if_up -p en0
ifconfig en0 mtx604-5 up
if_up en0
fs-nfs3 -ru ra:/qssl/QNXsdk /qssl/QNXsdk &
waitfor /qssl/QNXsdk/target/qnx6/ppcbe/usr/sbin/slogger 360
# setup environment variables
TZ=est05edt04
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/bin /bin
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/lib /lib
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/sbin /sbin
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/usr/bin /usr/bin
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/usr/sbin /usr/sbin
procmgr_symlink /qssl/QNXsdk/target/qnx6/ppcbe/usr/lib /usr/lib
procmgr_symlink /qssl/QNXsdk/target/qnx6/etc /etc
slogger &
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 mtx604-5
}
libc.so
devn-tulip.so
npm-tcpip.so
libsocket.so
[data=uip]
pci-raven
io-net
[data=copy]
if_up
ifconfig
fs-nfs3
For more examples, see ${QNX_TARGET}/${PROCESSOR}/build.
Making an OS Image and the Sample Buildfiles appendix in Building Embedded Systems
|
|
|
|