Hi All in QNX Land
Could some one be so kind as to tell me where I would find information
on the three following commands.
MKFFS
MKCIS
ROMQNX
Seems that these commands do not appear in any documentation that I
have.
Thanks
Hi John,
If they are not in your helpviewer, then you probably have old docs, however
I am surprised these didn’t come with the updated version of QNX. I checked
the docs (for QNX 4.25) and all three commands were listed in the online docs,
under “Utils”.
What version of QNX are you running?
Erick
John Parsons <parsonsj@esi.com> wrote:
Hi All in QNX Land
Could some one be so kind as to tell me where I would find information
on the three following commands.
MKFFS
MKCIS
ROMQNXSeems that these commands do not appear in any documentation that I
have.Thanks
Hi Erick,
I’m using QNX4.24 with Photon1.12. We have problems converting our code to QNX4.25
(question/message is in the news group) so we have had to stay at the 4.24 level.
Is there a way I can get the information on these commands. The commands do not
appear on the QNX web page any where.
John
Erick Muis wrote:
Hi John,
If they are not in your helpviewer, then you probably have old docs, however
I am surprised these didn’t come with the updated version of QNX. I checked
the docs (for QNX 4.25) and all three commands were listed in the online docs,
under “Utils”.What version of QNX are you running?
Erick
John Parsons <> parsonsj@esi.com> > wrote:
Hi All in QNX LandCould some one be so kind as to tell me where I would find information
on the three following commands.MKFFS
MKCIS
ROMQNXSeems that these commands do not appear in any documentation that I
have.Thanks
John Parsons <parsonsj@esi.com> wrote:
: Hi Erick,
: I’m using QNX4.24 with Photon1.12. We have problems converting our code to QNX4.25
: (question/message is in the news group) so we have had to stay at the 4.24 level.
: Is there a way I can get the information on these commands. The commands do not
: appear on the QNX web page any where.
At one point, these utilities were described only in a separate booked
called QNX → QNX/Neutrino Development Utilities. This book was distributed
with the QNX 4 Ekit and Neutrino 1.1.
Here are the descriptions of those utilities (the formatting is a little
rough):
=========================================================================
mkcis
create a Card Information Structure (QNX)
Syntax:
mkcis [-2] [-f outfile] [-o outfile] [-q] [-w level] file
Options:
-2
Output level 2 tuples only.
Note: Don’t use the -2 option if you’re using Efsys.file. Efsys.file can’t read the level 2 structures.
-f outfile
Generate an image of the Flash device in outfile.
-o outfile
Output the CIS to this file (default is standard output).
-q
Be quiet.
-w level
Set the warning level.
Description:
The mkcis utility reads a file containing a text description of the memory regions and partitions that make up an
EFS socket. The utility attempts to find the optimal placement of partitions and creates a CIS containing this
information. An Initial Program Loader (IPL) may precede the CIS on embedded filesystems used for booting.
The input file is made up of a sequence of sections. A section can be a description either of the geometry of a
memory device or of a region. A region section may contain any number of partition sections. You determine the
placement of each partition by assigning various attributes to it. These attributes tell mkcis the types of
accesses that will be made and the alignment restrictions that the partition must conform to.
The input file consists of lines in this format:
[spaces/tabs] keyword [value]…
Prefix every comment with the # character, which causes all input to the end of line to be ignored.
You can specify numbers in decimal (the default) or in hex by prefixing them with 0x. A number can have M or K
suffixes to signify multiplication by 1024x1024 or by 1024. The case of these suffixes doesn’t matter.
Card Information Structure
Here’s the file structure:
jedec
id number
type [dram|sram|flash|eprom|eeprom]
size number
write_disrupt number
erase_disrupt number
erase number
write number
region
jedec number
size number
offset number
interleave number
boot_file “filename”
partition
type [efs|image]
file “filename”
size number
attribute [erase|write|execute|write_align|
erase_align|largest]*
jedec section
The jedec section defines the type and geometry of a memory device used in the EFS. Standard device definitions
can be found in the file /etc/jedecs and are read by mkcis at startup. You can specify the following attributes:
id
Memory devices are identified by a 16-bit jedec number. ROM, DRAM, and SRAM devices don’t need jedec
information.
type
The type of memory device, which can be one of dram, sram, flash, eeprom or eprom.
size
The size of the device in bytes.
write_disrupt
When a memory device is performing a write operation, access to other memory locations may be disrupted
until the write has completed. For SRAM devices this value is usually 1, meaning that only the location
being written to is inaccessible. For many Flash devices the entire chip is unavailable for reads until
the write has completed. For example, the Intel 28F008 chip has a write_disrupt value of 1M.
erase_disrupt
Same as above but for erase operations. For example, the Intel 28F008 chip has an erase_disrupt value of
1M.
erase
The minimum number of bytes that can be erased in a single operation (the erase block size).
write
The minimum number of bytes that can be written in a single operation.
region section
A region section must be defined for each region in the EFS. Each section contains the following attributes:
jedec
The jedec number of the memory devices in the region.
size
The size of the region in bytes.
offset
The offset in bytes of the start address of the region from the start of the EFS (default is 0).
interleave
The number of devices that the region is interleaved across.
boot_file
The name of a binary file containing an IPL. The IPL code is placed before the CIS on the EFS.
Each partition in a region has the following attributes:
type
The partition type, which can be efs or image.
file
The name of a binary file containing an image to be placed in the partition. Usually generated by mkffs or
romqnx.
size
The size of the partition in bytes.
attribute
The functional attributes of the partition, including:
write
The partition will be written to.
erase
The partition will have erase operations.
write_align
The partition must be aligned on a write block boundary.
erase_align
The partition must be aligned on an erase block boundary.
xip_align
The partition should be aligned on a 4K boundary.
largest
The partition should take up the largest free area in the region.
Note: When specifying an embedded filesystem with a file directive, attribute largest and size are ignored and
shouldn’t be specified.
Examples:
Create a card information structure (CIS) from input file exm2a.info and write the CIS to raw device /dev/skt1:
mkcis -o /dev/skt1 -f exm2a.img exm2a.info
Here’s a sample CIS information file for an Octagon 5025A system with a single EFS consisting of Intel 28F020
Flash memory devices. The EFS is configured to contain only a bootable image partition.
Configure CIS for Octagon 5025A
jedec
id 0x89bd
type flash
write_disrupt 256k
erase_disrupt 256k
erase 256k
write 1
size 256k
region
size 256K
interleave 1
jedec 0x89bd
boot_file “/boot/sys/boot.5025a”
partition
type image
attribute largest
partition
type ffs
file “ffs.img”
This input file creates a CIS suitable for an Intel EXPLR2 board:
Sample configuration for EXPLR2
region
size 2M
jedec 0x89A0
boot_file “/boot/rom.explr2”
partition
type image
file “nto.image”
See also:
mkffs, mkipl, mknto, romqnx
=========================================================================
mkffs
make a Flash (embedded) filesystem image (QNX)
Syntax:
mkffs [options] -o fname root_directory
Options:
-o fname
Write the output of mkffs to fname.
-b bsize
Specify the block size of the component blocks in the Flash device. This value is specified in bytes or
kilobytes. The default value is 64K.
-c
Compress all files.
-m[anu]
Translate case for filenames:
a
always convert to lowercase
n
never convert to lowercase
u
convert uppercase-only filenames to lowercase
The default for QNX is -mn; for Windows NT, it’s -mu.
-p
Select POSIX mode. In this mode, user IDs and group IDs are stored for the filename directories in the
Flash device, in accordance with POSIX.
-r spare
Keep spare spare blocks for use during reclamation (default is 1, the maximum is 
. If you specify 0
spare blocks, the embedded filesystem is read-only.
Note: There’s no real advantage to having more than one spare block.
-s fsize
If the resulting embedded filesystem image file is less than fsize, fill the rest of the image file with
0xFF characters and appropriate format to fill it to fsize bytes. This can be specified in bytes or
kilobytes.
-q
Be quiet - warnings aren’t displayed.
-v
Be verbose.
Description:
The mkffs utility creates a Flash (that is, embedded) filesystem image in the specified fname, based on the files
contained in the root_directory parameter. The optional bsize parameter is used to specify the block size of each
erasable subdevice within the embedded filesystem.
Note that the directory structure created is of the entire specified directory and any subdirectory entries. The
specified directory becomes the root of the created embedded filesystem.
Note: When building an image with mkffs, symbolic links found in and below the root directory are ignored. These
links and/or the files they refer to aren’t included in the image. To include these files in the image, use a
hard link or the file itself.
The -s fsize flag is used to fill the embedded filesystem image with 0xFFs and appropriate formatting
information. If the embedded filesystem exceeds fsize, mkffs exits with an error.
Note: Unless at least one spare block is specified (using the -r option), the filesystem won’t be able to reclaim
space in other blocks.
Examples:
To create an embedded filesystem image called flash_1, from the files contained in the directory
/home/jwall/flash:
mkffs -o flash_1 /home/jwall/flash
To create an embedded filesystem image, as above, specifying that the erase block size on the device is 64K:
mkffs -b 64k -o flash_1 /home/jwall/flash
See also:
mkcis, mkipl, mknto, romqnx
romqnx
convert a buildqnx image to a ROM image (QNX)
Syntax:
romqnx [options] buildqnx_image rom_image
Targets:
QNX 4
Options:
-c
Compress the RAM portion.
-d module#
Force this entire module into RAM. A value of 0 means all modules.
-R addr
The EPROM/Flash/SRAM address (the default is 15M).
-r addr
The RAM address (the default is 4K).
-v
Be verbose.
Description:
The romqnx utility takes an OS image produced by buildqnx and modifies it to make it suitable for placing in ROM
or Flash. The resulting image consists of code and data for each module in the original buildfile. You must
always copy the data portion of each module to RAM. You may execute the code portion in place (XIP) out of ROM or
Flash, or you may copy it to RAM with the data.
Note: If your ROM or Flash is bank-switched, you must copy all code to RAM. You can execute only out of linearly
mapped ROM or Flash.
Since you’ll always be copying the data, it’s advantageous to compress it in ROM or Flash and expand it into RAM.
To do this, use the -c option. This approach typically results in significant Flash/EPROM savings.
Note that the -c option causes romqnx to run bpe to perform the compression.
Systems that can execute out of ROM or Flash often pay a performance penalty. It’s not uncommon for ROM or Flash
to have extra wait states or a narrow bus interface (8 or 16 bit). By default, romqnx sets up the image to
execute out of ROM or Flash; by using the -d option, you can force any module to be copied to RAM. If your ROM or
Flash is bank-switched, you must specify -d 0 to force all modules into RAM. If you build the system debugger
(/boot/sys/Debugger) into the image, the debugger is always copied to RAM.
The romqnx utility needs to know the address of the ROM where the image will be placed and the address of the RAM
where data (or code) will be copied. The default is 15M (0xF00000) for ROM and 4K (0x1000) for RAM.
Note: These addresses must be multiples of 4096 (0x1000), which is the page size of the processor.
If you specify -d 0 to copy all modules into RAM, the -R addr option is ignored.
Examples:
Build a ROM image for an embedded system in which the code runs out of ROM and the data is decompressed from ROM
into RAM. The ROM is at 63M and the OS RAM data starts at the default address of 4K:
cd /boot
buildqnx build/386ex images/386ex
romqnx -c -R 0x3f00000 images/386ex images/386ex.rom
The same as above except that the Process Manager and Kernel are copied into RAM, which may be faster that the
ROM:
cd /boot
buildqnx build/386ex images/386ex
romqnx -c -R 0x3f00000 -d 1 images/386ex images/386ex.rom
See also:
bpe
buildqnx in the QNX 4 Utilities reference