ARTICLE: The QNX Boot Process

bridged with qdn.public.articles
Kim Bigelow

ARTICLE: The QNX Boot Process

Post by Kim Bigelow » Mon Jan 22, 2001 6:46 pm

Programming Tools - The QNX Boot Process
By Chris McKillop, QNX Software Systems Ltd.

This series of articles will talk about how the QNX Realtime
Platform boots and how you can change the boot behavior
of your system.

This first article covers:
* the two different ways that current installs are booting
* what's in a boot buildfile
* how to make a boot image.


Two ways to boot

In the current RTP release, there are two different ways that
QNX can be booted:
* directly from a QNX partition using the QNX boot loader
* indirectly from a FAT partition using a DOS device driver.


QNX boot loader

The QNX boot loader loads the images residing in /.boot (or
/.altboot if you hit the ESC key when prompted to boot an
alternate OS) directly from the QNX partition. So when you
make a new image, you can copy the image (.ifs) file to
/.altboot and hit ESC at boot time to try out your new
image. (If you're already hitting ESC to boot the non-DMA
image, consider swapping your current .altboot for .boot so
you don't have to hit ESC anymore.)

DOS device driver

The DOS device driver has a little more flexibility than the
QNX boot loader, since there's already a set of rudimentary
I/O services provided by DOS when the driver loads. You can
also take advantage of the DOS config.sys menu system. Here's
a sample config.sys from an installed system:

[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbas~1.ifs
[WIN]

[COMMON]



To add a new boot image, simply add a new menuitem line and
a properly labeled configuration block. For example, if you had a
new boot image called custom.ifs in C:\Program Files\qnx\boot\fs,
you could do the following:


[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menuitem=CUST, QNX custom.ifs
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.m information
for the kernel, putting the kernel in the right position in memory,
and starting the execution of the kernel.

What's in a boot buildfile?

Unlike many operating systems, the .ifs boot image is more then
just a kernel and its startup code. There are actually programs
and libraries stored in the image as well as a simple startup
shell script.

The image is built with a program called mkifs (Make Image
FileSystem), which reads in a buildfile that tells mkifs what you
want in your image and what actions the startup shell script
should perform.

You'll find several buildfiles on every installed system in the
directory /boot/build. We're going to examine the file
qnxbasedma.build, one of the standard buildfiles found in that
directory. Here's a full listing of that file:


[virtual=x86,bios +compress] boot = {
startup-bios -s 64k
PATH=/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=
/proc/boot:/lib:/usr/lib:/lib/dll procnto
}

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

[pri=10o] PATH=/proc/boot diskboot -D1
}

[type=link] /dev/console=/dev/con1

libc.so
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so

libcam.so
io-blk.so
cam-disk.so
fs-qnx4.so
fs-dos.so
cam-cdrom.so
fs-cd.so

[data=c]
seedres
pci-bios
devb-eide
devb-ncr8
devb-aha8
diskboot
slogger



The full syntax of these buildfiles is covered in the online docs
for mkifs (in the Neutrino Utilities Reference).

The first section of this file tells mkifs what processor this
buildfile is for (x86) and what IPL to use (bios). It then lists the
startup program to use (startup-bios) and the kernel to use
(procnto). You'll probably never need to change these lines
when booting on a standard x86 PC. The next section is where
things start to get interesting.

The block that starts with [+script] is a script that's run after
the kernel has started. This script lists the programs that will
be run and actions that will be taken as the system boots.

In this buildfile, the first program is slogger, the System Logger
that logs system events and messages. After slogger has started,
seedres is run in order to populate the system resource database
with information on the hardware of the system (IRQs, I/O ranges,
etc.). The pci-bios server provides PCI services to applications
and device drivers. This is a very critical program, because nearly
everything that runs on a modern PC needs PCI to function properly.
To ensure that the PCI server is running before the rest of the
programs are started, the script waits for /dev/pci to appear in
the filesystem.

Finally, the program diskboot is run. The diskboot program detects
what kind of hard drive controller is in your system and probes
all the different partitions to look for a bootable QNX
installation.

The lines that follow after the closing } of the startup script
are libraries and binaries that will be included in the system.
Libraries are listed first, since they're shared items. The line
[data=c] signals that the files that follow are binaries that need
unique data sections, but can share code. If you type ls -l
/proc/boot on a running system, you'll actually see the files
that are stored in the image you booted.

How to make a boot image

To conclude this first article, let's make a small change to
qnxbasedma.build, build an image, and try booting it.
1. Make a local copy of the buildfile by copying it into your home
directory:

cp /boot/build/qnxbasedma.build $HOME

2. Now, using your favorite editor, let's add a line to this
buildfile. (Make sure if you're using the Photon Editor (ped)
that it isn't saving formatting data to the end of the file.) In
the startup-script block, we want to add a line to display a
message when we boot. So, make your script section look
like this:

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

display_msg "QNX Realtime Platform - Custom Boot Image #1"

[pri=10o] PATH=/proc/boot diskboot -D1
}



We've added the line with display_msg. This will print a string
before diskboot starts so you'll know you're booting the new image
you've made.
3. Now we need to run mkifs and install the resulting image file.
Simply open a terminal window (pterm), go into your home
directory, and then run:

% mkifs -v qnxbasedma.build custom.ifs




You'll see a bunch of information printed to the terminal about the
different files in the image. When it's finished building, you'll have
a nice custom.ifs file that you can either copy to /.altboot or into
a DOS directory (normally found in /fs/hd0-dos/Program Files/qnx
/boot/fs). If you're using DOS to boot your image, be sure to edit
config.sys under DOS, NOT under QNX - some QNX editors will
save the config.sys file in a UNIX format that DOS won't understand.

Now when you reboot, you should see your message displayed
on the screen as the boot script runs.

In the next article in this series, we'll make two custom boot
scripts. One that does the work of diskboot and one that simply
starts a shell and lets you interact with the system without
mounting any hard drives!

In the third and last article in this series, you'll see how to
make a QNX boot floppy suitable for setting up a simple network
server or as a recovery floppy.

Happy booting! :-)

rectech

Re: ARTICLE: The QNX Boot Process

Post by rectech » Tue Jan 23, 2001 4:28 pm

Bill,
I agree with you 100% - this is exactly how I operate also. Please listen QSSL.

KenR

Bill at Sierra Design wrote:
Hello Kim,

There are some things I'd like you to address in your next articles.

RTP has taken a SHARP TURN toward Microslobism in that it is trying to make
the OS too smart. And as a result too much information is being hidden from
the user.

When I generate an OS image I know EXACTLY what hardware I expect to find in
the computer that I am generating the image for. I don't what software that
is going to go out and tickle all of my hardware to try to determine what
exists. I might not want to include support for a device that DOES exist in
my system.

So, if I know all the drivers that I want loaded and their exact port
addresses and interrupts, DMA, etc. I want to be able to code all of that on
the command lines for those drivers. That way, when the system boots, it
doesn't have to try things. It can just load the drivers and be done with
it. Either it works or it doesn't work. If it doesn't work, then I have a
hardware problem or I generated a bad image for this system. Either way,
it's my problem to deal with.

The main benefit here is that the system should boot in about 1/4 of the
time. AND I will know exactly what is being driven from where.

Microslob designs systems for (as my coworker puts it) the typical
housewife, who doesn't know and doesn't want to know anything. Don't go
there QSSL!

I won't run software unless I know everythng, what's loaded, where it's
loaded and why it's loaded.

Kim Bigelow <kbigelow@qnx.com> wrote in message
news:94hv6l$kkh$1@nntp.qnx.com...
Programming Tools - The QNX Boot Process
By Chris McKillop, QNX Software Systems Ltd.

This series of articles will talk about how the QNX Realtime
Platform boots and how you can change the boot behavior
of your system.

This first article covers:
* the two different ways that current installs are booting
* what's in a boot buildfile
* how to make a boot image.


Two ways to boot

In the current RTP release, there are two different ways that
QNX can be booted:
* directly from a QNX partition using the QNX boot loader
* indirectly from a FAT partition using a DOS device driver.


QNX boot loader

The QNX boot loader loads the images residing in /.boot (or
/.altboot if you hit the ESC key when prompted to boot an
alternate OS) directly from the QNX partition. So when you
make a new image, you can copy the image (.ifs) file to
/.altboot and hit ESC at boot time to try out your new
image. (If you're already hitting ESC to boot the non-DMA
image, consider swapping your current .altboot for .boot so
you don't have to hit ESC anymore.)

DOS device driver

The DOS device driver has a little more flexibility than the
QNX boot loader, since there's already a set of rudimentary
I/O services provided by DOS when the driver loads. You can
also take advantage of the DOS config.sys menu system. Here's
a sample config.sys from an installed system:

[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbas~1.ifs
[WIN]

[COMMON]



To add a new boot image, simply add a new menuitem line and
a properly labeled configuration block. For example, if you had a
new boot image called custom.ifs in C:\Program Files\qnx\boot\fs,
you could do the following:


[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menuitem=CUST, QNX custom.ifs
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.m information
for the kernel, putting the kernel in the right position in memory,
and starting the execution of the kernel.

What's in a boot buildfile?

Unlike many operating systems, the .ifs boot image is more then
just a kernel and its startup code. There are actually programs
and libraries stored in the image as well as a simple startup
shell script.

The image is built with a program called mkifs (Make Image
FileSystem), which reads in a buildfile that tells mkifs what you
want in your image and what actions the startup shell script
should perform.

You'll find several buildfiles on every installed system in the
directory /boot/build. We're going to examine the file
qnxbasedma.build, one of the standard buildfiles found in that
directory. Here's a full listing of that file:


[virtual=x86,bios +compress] boot = {
startup-bios -s 64k
PATH=/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=
/proc/boot:/lib:/usr/lib:/lib/dll procnto
}

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

[pri=10o] PATH=/proc/boot diskboot -D1
}

[type=link] /dev/console=/dev/con1

libc.so
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so

libcam.so
io-blk.so
cam-disk.so
fs-qnx4.so
fs-dos.so
cam-cdrom.so
fs-cd.so

[data=c]
seedres
pci-bios
devb-eide
devb-ncr8
devb-aha8
diskboot
slogger



The full syntax of these buildfiles is covered in the online docs
for mkifs (in the Neutrino Utilities Reference).

The first section of this file tells mkifs what processor this
buildfile is for (x86) and what IPL to use (bios). It then lists the
startup program to use (startup-bios) and the kernel to use
(procnto). You'll probably never need to change these lines
when booting on a standard x86 PC. The next section is where
things start to get interesting.

The block that starts with [+script] is a script that's run after
the kernel has started. This script lists the programs that will
be run and actions that will be taken as the system boots.

In this buildfile, the first program is slogger, the System Logger
that logs system events and messages. After slogger has started,
seedres is run in order to populate the system resource database
with information on the hardware of the system (IRQs, I/O ranges,
etc.). The pci-bios server provides PCI services to applications
and device drivers. This is a very critical program, because nearly
everything that runs on a modern PC needs PCI to function properly.
To ensure that the PCI server is running before the rest of the
programs are started, the script waits for /dev/pci to appear in
the filesystem.

Finally, the program diskboot is run. The diskboot program detects
what kind of hard drive controller is in your system and probes
all the different partitions to look for a bootable QNX
installation.

The lines that follow after the closing } of the startup script
are libraries and binaries that will be included in the system.
Libraries are listed first, since they're shared items. The line
[data=c] signals that the files that follow are binaries that need
unique data sections, but can share code. If you type ls -l
/proc/boot on a running system, you'll actually see the files
that are stored in the image you booted.

How to make a boot image

To conclude this first article, let's make a small change to
qnxbasedma.build, build an image, and try booting it.
1. Make a local copy of the buildfile by copying it into your home
directory:

cp /boot/build/qnxbasedma.build $HOME

2. Now, using your favorite editor, let's add a line to this
buildfile. (Make sure if you're using the Photon Editor (ped)
that it isn't saving formatting data to the end of the file.) In
the startup-script block, we want to add a line to display a
message when we boot. So, make your script section look
like this:

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

display_msg "QNX Realtime Platform - Custom Boot Image #1"

[pri=10o] PATH=/proc/boot diskboot -D1
}



We've added the line with display_msg. This will print a string
before diskboot starts so you'll know you're booting the new image
you've made.
3. Now we need to run mkifs and install the resulting image file.
Simply open a terminal window (pterm), go into your home
directory, and then run:

% mkifs -v qnxbasedma.build custom.ifs




You'll see a bunch of information printed to the terminal about the
different files in the image. When it's finished building, you'll have
a nice custom.ifs file that you can either copy to /.altboot or into
a DOS directory (normally found in /fs/hd0-dos/Program Files/qnx
/boot/fs). If you're using DOS to boot your image, be sure to edit
config.sys under DOS, NOT under QNX - some QNX editors will
save the config.sys file in a UNIX format that DOS won't understand.

Now when you reboot, you should see your message displayed
on the screen as the boot script runs.

In the next article in this series, we'll make two custom boot
scripts. One that does the work of diskboot and one that simply
starts a shell and lets you interact with the system without
mounting any hard drives!

In the third and last article in this series, you'll see how to
make a QNX boot floppy suitable for setting up a simple network
server or as a recovery floppy.

Happy booting! :-)

Bill at Sierra Design

Re: ARTICLE: The QNX Boot Process

Post by Bill at Sierra Design » Tue Jan 23, 2001 4:38 pm

Hello Kim,

There are some things I'd like you to address in your next articles.

RTP has taken a SHARP TURN toward Microslobism in that it is trying to make
the OS too smart. And as a result too much information is being hidden from
the user.

When I generate an OS image I know EXACTLY what hardware I expect to find in
the computer that I am generating the image for. I don't what software that
is going to go out and tickle all of my hardware to try to determine what
exists. I might not want to include support for a device that DOES exist in
my system.

So, if I know all the drivers that I want loaded and their exact port
addresses and interrupts, DMA, etc. I want to be able to code all of that on
the command lines for those drivers. That way, when the system boots, it
doesn't have to try things. It can just load the drivers and be done with
it. Either it works or it doesn't work. If it doesn't work, then I have a
hardware problem or I generated a bad image for this system. Either way,
it's my problem to deal with.

The main benefit here is that the system should boot in about 1/4 of the
time. AND I will know exactly what is being driven from where.

Microslob designs systems for (as my coworker puts it) the typical
housewife, who doesn't know and doesn't want to know anything. Don't go
there QSSL!

I won't run software unless I know everythng, what's loaded, where it's
loaded and why it's loaded.



Kim Bigelow <kbigelow@qnx.com> wrote in message
news:94hv6l$kkh$1@nntp.qnx.com...
Programming Tools - The QNX Boot Process
By Chris McKillop, QNX Software Systems Ltd.

This series of articles will talk about how the QNX Realtime
Platform boots and how you can change the boot behavior
of your system.

This first article covers:
* the two different ways that current installs are booting
* what's in a boot buildfile
* how to make a boot image.


Two ways to boot

In the current RTP release, there are two different ways that
QNX can be booted:
* directly from a QNX partition using the QNX boot loader
* indirectly from a FAT partition using a DOS device driver.


QNX boot loader

The QNX boot loader loads the images residing in /.boot (or
/.altboot if you hit the ESC key when prompted to boot an
alternate OS) directly from the QNX partition. So when you
make a new image, you can copy the image (.ifs) file to
/.altboot and hit ESC at boot time to try out your new
image. (If you're already hitting ESC to boot the non-DMA
image, consider swapping your current .altboot for .boot so
you don't have to hit ESC anymore.)

DOS device driver

The DOS device driver has a little more flexibility than the
QNX boot loader, since there's already a set of rudimentary
I/O services provided by DOS when the driver loads. You can
also take advantage of the DOS config.sys menu system. Here's
a sample config.sys from an installed system:

[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbas~1.ifs
[WIN]

[COMMON]



To add a new boot image, simply add a new menuitem line and
a properly labeled configuration block. For example, if you had a
new boot image called custom.ifs in C:\Program Files\qnx\boot\fs,
you could do the following:


[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menuitem=CUST, QNX custom.ifs
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.m information
for the kernel, putting the kernel in the right position in memory,
and starting the execution of the kernel.

What's in a boot buildfile?

Unlike many operating systems, the .ifs boot image is more then
just a kernel and its startup code. There are actually programs
and libraries stored in the image as well as a simple startup
shell script.

The image is built with a program called mkifs (Make Image
FileSystem), which reads in a buildfile that tells mkifs what you
want in your image and what actions the startup shell script
should perform.

You'll find several buildfiles on every installed system in the
directory /boot/build. We're going to examine the file
qnxbasedma.build, one of the standard buildfiles found in that
directory. Here's a full listing of that file:


[virtual=x86,bios +compress] boot = {
startup-bios -s 64k
PATH=/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=
/proc/boot:/lib:/usr/lib:/lib/dll procnto
}

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

[pri=10o] PATH=/proc/boot diskboot -D1
}

[type=link] /dev/console=/dev/con1

libc.so
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so

libcam.so
io-blk.so
cam-disk.so
fs-qnx4.so
fs-dos.so
cam-cdrom.so
fs-cd.so

[data=c]
seedres
pci-bios
devb-eide
devb-ncr8
devb-aha8
diskboot
slogger



The full syntax of these buildfiles is covered in the online docs
for mkifs (in the Neutrino Utilities Reference).

The first section of this file tells mkifs what processor this
buildfile is for (x86) and what IPL to use (bios). It then lists the
startup program to use (startup-bios) and the kernel to use
(procnto). You'll probably never need to change these lines
when booting on a standard x86 PC. The next section is where
things start to get interesting.

The block that starts with [+script] is a script that's run after
the kernel has started. This script lists the programs that will
be run and actions that will be taken as the system boots.

In this buildfile, the first program is slogger, the System Logger
that logs system events and messages. After slogger has started,
seedres is run in order to populate the system resource database
with information on the hardware of the system (IRQs, I/O ranges,
etc.). The pci-bios server provides PCI services to applications
and device drivers. This is a very critical program, because nearly
everything that runs on a modern PC needs PCI to function properly.
To ensure that the PCI server is running before the rest of the
programs are started, the script waits for /dev/pci to appear in
the filesystem.

Finally, the program diskboot is run. The diskboot program detects
what kind of hard drive controller is in your system and probes
all the different partitions to look for a bootable QNX
installation.

The lines that follow after the closing } of the startup script
are libraries and binaries that will be included in the system.
Libraries are listed first, since they're shared items. The line
[data=c] signals that the files that follow are binaries that need
unique data sections, but can share code. If you type ls -l
/proc/boot on a running system, you'll actually see the files
that are stored in the image you booted.

How to make a boot image

To conclude this first article, let's make a small change to
qnxbasedma.build, build an image, and try booting it.
1. Make a local copy of the buildfile by copying it into your home
directory:

cp /boot/build/qnxbasedma.build $HOME

2. Now, using your favorite editor, let's add a line to this
buildfile. (Make sure if you're using the Photon Editor (ped)
that it isn't saving formatting data to the end of the file.) In
the startup-script block, we want to add a line to display a
message when we boot. So, make your script section look
like this:

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

display_msg "QNX Realtime Platform - Custom Boot Image #1"

[pri=10o] PATH=/proc/boot diskboot -D1
}



We've added the line with display_msg. This will print a string
before diskboot starts so you'll know you're booting the new image
you've made.
3. Now we need to run mkifs and install the resulting image file.
Simply open a terminal window (pterm), go into your home
directory, and then run:

% mkifs -v qnxbasedma.build custom.ifs




You'll see a bunch of information printed to the terminal about the
different files in the image. When it's finished building, you'll have
a nice custom.ifs file that you can either copy to /.altboot or into
a DOS directory (normally found in /fs/hd0-dos/Program Files/qnx
/boot/fs). If you're using DOS to boot your image, be sure to edit
config.sys under DOS, NOT under QNX - some QNX editors will
save the config.sys file in a UNIX format that DOS won't understand.

Now when you reboot, you should see your message displayed
on the screen as the boot script runs.

In the next article in this series, we'll make two custom boot
scripts. One that does the work of diskboot and one that simply
starts a shell and lets you interact with the system without
mounting any hard drives!

In the third and last article in this series, you'll see how to
make a QNX boot floppy suitable for setting up a simple network
server or as a recovery floppy.

Happy booting! :-)

Chris McKillop

Re: ARTICLE: The QNX Boot Process

Post by Chris McKillop » Tue Jan 23, 2001 7:24 pm

Bill at Sierra Design <BC@sierradesign.com> wrote:
There are some things I'd like you to address in your next articles.

RTP has taken a SHARP TURN toward Microslobism in that it is trying to make
the OS too smart. And as a result too much information is being hidden from
the user.
:) Actually, I think you will find that most people like having the enumerators,
but there is nothing stopping you from not running them and starting everything
by hand like the old QNX4 days.

Once I am doing covering the boot images (including starting everything you need
without diskboot and having a nice little test image) I want to do an article
on the RTP boot process so people will know where they can take over and do
things by hand. But as a hint look at /etc/rc.d/rc.devices and /etc/system/sysinit.

chris


--
cdm@qnx.com "The faster I go, the behinder I get."
Chris McKillop -- Lewis Carroll --
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Thomas Fletcher

Re: ARTICLE: The QNX Boot Process

Post by Thomas Fletcher » Tue Jan 23, 2001 8:03 pm

Chris McKillop <cdm@qnx.com> wrote:
Bill at Sierra Design <BC@sierradesign.com> wrote:

There are some things I'd like you to address in your next articles.

RTP has taken a SHARP TURN toward Microslobism in that it is trying to make
the OS too smart. And as a result too much information is being hidden from
the user.

:) Actually, I think you will find that most people like having the enumerators,
but there is nothing stopping you from not running them and starting everything
by hand like the old QNX4 days.

Once I am doing covering the boot images (including starting everything you need
without diskboot and having a nice little test image) I want to do an article
on the RTP boot process so people will know where they can take over and do
things by hand. But as a hint look at /etc/rc.d/rc.devices and /etc/system/sysinit.
Not to mention the fact that we have an entire bookset (Building Embedded Systems)
that is pretty clear on what is going on in the boot process. QRTP (and the boot
process accordingly) is designed to be a facilitating technology. That is it
should be easy to get up and running. No doubt you won't be running inside
another filesystem when you boot on your target.

Reading through the Building Embedded Systems book, and a pidin listing, should
give you all the information that you need to write your own custom snappy
image that does what you want.

Of course be prepared for some possible un=predictable results the next
time that you try to upgrade this "souped-up" system to the next patch.

Thomas

Bill at Sierra Design

Re: ARTICLE: The QNX Boot Process

Post by Bill at Sierra Design » Tue Jan 23, 2001 8:23 pm

Thomas Fletcher <thomasf@qnx.com> wrote in message
news:94ko32$aa1$1@nntp.qnx.com...
Reading through the Building Embedded Systems book, and a pidin listing,
should
give you all the information that you need to write your own custom snappy
image that does what you want.
No. It doesn't!

This material is all "Clear Only If Known". If you are starting from
scratch, it doesn't tell you where to go look to ask the questions you are
not sure you need to ask. I will add that these articles ARE a big help.

I've been useing QNX for 14 years now. I love it and I'm one of your
biggest bigots. And I love the wonderful multi-threading support and. for
the most part, your support for shared libraries.

But your overall design of the OS (by that I mean kernal + drivers) is a big
step in the wrong direction. RTP is not (yet) the OS for the typical
housewife. When it succcedes at that, God Bless QSSL and it's financial
success. But that will be the day I stop using it.

Of course be prepared for some possible un=predictable results the next
time that you try to upgrade this "souped-up" system to the next patch.
Given. If you just document the imcompatabilities, I'll keep fixing my
system to be compatable. That is my choice!


P.S. I'm sorry. I didn't intend for this to be a flame. I still love QSSL
and I'm very optimistic about it. But, let face it. RTP is a very
different beast from QNX 4. Almost nothing about low level configuration is
the same. Robert Krten's book is fantastic about teaching about
multi-threading and the necessary features that go with it. But it falls
way short as a tutorial on Getting Started with QNX Neutrino. The System
Architecture document is also very helpful. But you still need to know what
to look up. What you need for this beast is a TUTORIAL on the OS.

Keep up the good work QSSL. I'm serious. I'm still very optimistic.

Brian Stecher

Re: ARTICLE: The QNX Boot Process

Post by Brian Stecher » Tue Jan 23, 2001 8:37 pm

Bill at Sierra Design <BC@sierradesign.com> wrote:
Thomas Fletcher <thomasf@qnx.com> wrote in message
news:94ko32$aa1$1@nntp.qnx.com...
Reading through the Building Embedded Systems book, and a pidin listing,
should
give you all the information that you need to write your own custom snappy
image that does what you want.

No. It doesn't!

This material is all "Clear Only If Known". If you are starting from
scratch, it doesn't tell you where to go look to ask the questions you are
not sure you need to ask. I will add that these articles ARE a big help.
What are the questions? The doc people are sure to want to know.
But your overall design of the OS (by that I mean kernal + drivers) is a big
step in the wrong direction. RTP is not (yet) the OS for the typical
housewife. When it succcedes at that, God Bless QSSL and it's financial
success. But that will be the day I stop using it.
We are never, ever going _require_ people to use the enumeration
technology - why would you want it in an embedded device that has
no plug in slots? Unlike MS, all this stuff is driven by user
replacable shell scripts. If you know what/where your devices are,
just write your own shell scripts to start them.

--
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8

Igor Kovalenko

Re: ARTICLE: The QNX Boot Process

Post by Igor Kovalenko » Tue Jan 23, 2001 8:37 pm

Bill at Sierra Design wrote:
Hello Kim,

There are some things I'd like you to address in your next articles.

RTP has taken a SHARP TURN toward Microslobism in that it is trying to make
the OS too smart. And as a result too much information is being hidden from
the user.

When I generate an OS image I know EXACTLY what hardware I expect to find in
the computer that I am generating the image for. I don't what software that
is going to go out and tickle all of my hardware to try to determine what
exists. I might not want to include support for a device that DOES exist in
my system.

So, if I know all the drivers that I want loaded and their exact port
addresses and interrupts, DMA, etc. I want to be able to code all of that on
the command lines for those drivers.
PCI BIOS assigns those dynamically. How would you assign them in command
line? What if you insert another card or remove one? Going to regenerate
the image?
That way, when the system boots, it
doesn't have to try things. It can just load the drivers and be done with
it. Either it works or it doesn't work. If it doesn't work, then I have a
hardware problem or I generated a bad image for this system. Either way,
it's my problem to deal with.

The main benefit here is that the system should boot in about 1/4 of the
time. AND I will know exactly what is being driven from where.

Microslob designs systems for (as my coworker puts it) the typical
housewife, who doesn't know and doesn't want to know anything. Don't go
there QSSL!

I won't run software unless I know everythng, what's loaded, where it's
loaded and why it's loaded.
If everyone was like you QSSL could indeed save themselves the trouble
of doing that. But now when they have million copies downloaded there
bound to be quite a lot of users who don't know the old Jedi art. They
will flood newsgroup with complains that 'my xxx board does not work'.
In fact they do even now...

I like to have control too, but who prevents you from doing your own
images in the way you like it? For our product I generate my own images
from my own templates, which are being edited by sed based on variable
parameters. Those images are part of my very own installation procedure
which is based on my very own bootable CD with my very own packages
formatted in my very own way...

- igor
Kim Bigelow <kbigelow@qnx.com> wrote in message
news:94hv6l$kkh$1@nntp.qnx.com...
Programming Tools - The QNX Boot Process
By Chris McKillop, QNX Software Systems Ltd.

This series of articles will talk about how the QNX Realtime
Platform boots and how you can change the boot behavior
of your system.

This first article covers:
* the two different ways that current installs are booting
* what's in a boot buildfile
* how to make a boot image.


Two ways to boot

In the current RTP release, there are two different ways that
QNX can be booted:
* directly from a QNX partition using the QNX boot loader
* indirectly from a FAT partition using a DOS device driver.


QNX boot loader

The QNX boot loader loads the images residing in /.boot (or
/.altboot if you hit the ESC key when prompted to boot an
alternate OS) directly from the QNX partition. So when you
make a new image, you can copy the image (.ifs) file to
/.altboot and hit ESC at boot time to try out your new
image. (If you're already hitting ESC to boot the non-DMA
image, consider swapping your current .altboot for .boot so
you don't have to hit ESC anymore.)

DOS device driver

The DOS device driver has a little more flexibility than the
QNX boot loader, since there's already a set of rudimentary
I/O services provided by DOS when the driver loads. You can
also take advantage of the DOS config.sys menu system. Here's
a sample config.sys from an installed system:

[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbas~1.ifs
[WIN]

[COMMON]



To add a new boot image, simply add a new menuitem line and
a properly labeled configuration block. For example, if you had a
new boot image called custom.ifs in C:\Program Files\qnx\boot\fs,
you could do the following:


[menu]
menuitem=WIN, Windows
menudefault=WIN,30
menuitem=QNXDMA, QNX Realtime Platform
menuitem=QNX, QNX Realtime Platform (DMA Disabled)
menuitem=CUST, QNX custom.ifs
menucolor=7,0
[QNX]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.sys
C:\PROGRA~1\QNX\boot\fs\qnxbase.ifs
[QNXDMA]
DEVICE=C:\PROGRA~1\QNX\boot\bin\loadqnx.m information
for the kernel, putting the kernel in the right position in memory,
and starting the execution of the kernel.

What's in a boot buildfile?

Unlike many operating systems, the .ifs boot image is more then
just a kernel and its startup code. There are actually programs
and libraries stored in the image as well as a simple startup
shell script.

The image is built with a program called mkifs (Make Image
FileSystem), which reads in a buildfile that tells mkifs what you
want in your image and what actions the startup shell script
should perform.

You'll find several buildfiles on every installed system in the
directory /boot/build. We're going to examine the file
qnxbasedma.build, one of the standard buildfiles found in that
directory. Here's a full listing of that file:


[virtual=x86,bios +compress] boot = {
startup-bios -s 64k
PATH=/proc/boot:/bin:/usr/bin LD_LIBRARY_PATH=
/proc/boot:/lib:/usr/lib:/lib/dll procnto
}

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

[pri=10o] PATH=/proc/boot diskboot -D1
}

[type=link] /dev/console=/dev/con1

libc.so
[type=link] /usr/lib/ldqnx.so.1=/proc/boot/libc.so

libcam.so
io-blk.so
cam-disk.so
fs-qnx4.so
fs-dos.so
cam-cdrom.so
fs-cd.so

[data=c]
seedres
pci-bios
devb-eide
devb-ncr8
devb-aha8
diskboot
slogger



The full syntax of these buildfiles is covered in the online docs
for mkifs (in the Neutrino Utilities Reference).

The first section of this file tells mkifs what processor this
buildfile is for (x86) and what IPL to use (bios). It then lists the
startup program to use (startup-bios) and the kernel to use
(procnto). You'll probably never need to change these lines
when booting on a standard x86 PC. The next section is where
things start to get interesting.

The block that starts with [+script] is a script that's run after
the kernel has started. This script lists the programs that will
be run and actions that will be taken as the system boots.

In this buildfile, the first program is slogger, the System Logger
that logs system events and messages. After slogger has started,
seedres is run in order to populate the system resource database
with information on the hardware of the system (IRQs, I/O ranges,
etc.). The pci-bios server provides PCI services to applications
and device drivers. This is a very critical program, because nearly
everything that runs on a modern PC needs PCI to function properly.
To ensure that the PCI server is running before the rest of the
programs are started, the script waits for /dev/pci to appear in
the filesystem.

Finally, the program diskboot is run. The diskboot program detects
what kind of hard drive controller is in your system and probes
all the different partitions to look for a bootable QNX
installation.

The lines that follow after the closing } of the startup script
are libraries and binaries that will be included in the system.
Libraries are listed first, since they're shared items. The line
[data=c] signals that the files that follow are binaries that need
unique data sections, but can share code. If you type ls -l
/proc/boot on a running system, you'll actually see the files
that are stored in the image you booted.

How to make a boot image

To conclude this first article, let's make a small change to
qnxbasedma.build, build an image, and try booting it.
1. Make a local copy of the buildfile by copying it into your home
directory:

cp /boot/build/qnxbasedma.build $HOME

2. Now, using your favorite editor, let's add a line to this
buildfile. (Make sure if you're using the Photon Editor (ped)
that it isn't saving formatting data to the end of the file.) In
the startup-script block, we want to add a line to display a
message when we boot. So, make your script section look
like this:

[+script] startup-script = {
slogger -l /dev/text
seedres
pci-bios
waitfor /dev/pci

display_msg "QNX Realtime Platform - Custom Boot Image #1"

[pri=10o] PATH=/proc/boot diskboot -D1
}



We've added the line with display_msg. This will print a string
before diskboot starts so you'll know you're booting the new image
you've made.
3. Now we need to run mkifs and install the resulting image file.
Simply open a terminal window (pterm), go into your home
directory, and then run:

% mkifs -v qnxbasedma.build custom.ifs




You'll see a bunch of information printed to the terminal about the
different files in the image. When it's finished building, you'll have
a nice custom.ifs file that you can either copy to /.altboot or into
a DOS directory (normally found in /fs/hd0-dos/Program Files/qnx
/boot/fs). If you're using DOS to boot your image, be sure to edit
config.sys under DOS, NOT under QNX - some QNX editors will
save the config.sys file in a UNIX format that DOS won't understand.

Now when you reboot, you should see your message displayed
on the screen as the boot script runs.

In the next article in this series, we'll make two custom boot
scripts. One that does the work of diskboot and one that simply
starts a shell and lets you interact with the system without
mounting any hard drives!

In the third and last article in this series, you'll see how to
make a QNX boot floppy suitable for setting up a simple network
server or as a recovery floppy.

Happy booting! :-)

Marisa Giancarla

Re: ARTICLE: The QNX Boot Process

Post by Marisa Giancarla » Wed Jan 24, 2001 9:13 pm

"Thomas Fletcher" <thomasf@qnx.com> wrote in message
news:94ko32$aa1$1@nntp.qnx.com...
Not to mention the fact that we have an entire bookset (Building Embedded
Systems)
that is pretty clear on what is going on in the boot process. QRTP (and
the boot
Please don't take this the wrong way, but the section of the manual you
mention is NOT clear at all for someone who has no familiarity with QNX, and
who is used to Linux or other Unix ways of customizing system startup. The
article that Kim posted is MUCH better about the very issues I didn't find
answered well in the "building embedded systems" portion of the manual,
which is very heavily slanted to installation on a flash drive/limited
hardware and not towards an entire PC-compatible (with rotating media etc)
that is embedded or being retasked..

I think this article was a great start, and if someone could come up with a
detailed set of instructions on how to create a custom boot environment that
DOES do the PC-like hardware detection, includes minimal photon, etc. I'd be
in heaven..

Marisa

Bill at Sierra Design

Re: ARTICLE: The QNX Boot Process

Post by Bill at Sierra Design » Thu Jan 25, 2001 4:25 pm

I agree with Marisa.

The documenataion so far is probibly good reference material. But it is NOT
a good tutorial.


Marisa Giancarla <mgiancarla@macromedia.com> wrote in message
news:94ngf4$9tu$1@inn.qnx.com...
"Thomas Fletcher" <thomasf@qnx.com> wrote in message
news:94ko32$aa1$1@nntp.qnx.com...
Not to mention the fact that we have an entire bookset (Building
Embedded
Systems)
that is pretty clear on what is going on in the boot process. QRTP (and
the boot

Please don't take this the wrong way, but the section of the manual you
mention is NOT clear at all for someone who has no familiarity with QNX,
and
who is used to Linux or other Unix ways of customizing system startup. The
article that Kim posted is MUCH better about the very issues I didn't find
answered well in the "building embedded systems" portion of the manual,
which is very heavily slanted to installation on a flash drive/limited
hardware and not towards an entire PC-compatible (with rotating media etc)
that is embedded or being retasked..

I think this article was a great start, and if someone could come up with
a
detailed set of instructions on how to create a custom boot environment
that
DOES do the PC-like hardware detection, includes minimal photon, etc. I'd
be
in heaven..

Marisa

Chris McKillop

Re: ARTICLE: The QNX Boot Process

Post by Chris McKillop » Thu Jan 25, 2001 8:01 pm

Marisa Giancarla <mgiancarla@macromedia.com> wrote:
Please don't take this the wrong way, but the section of the manual you
mention is NOT clear at all for someone who has no familiarity with QNX, and
who is used to Linux or other Unix ways of customizing system startup. The
article that Kim posted is MUCH better about the very issues I didn't find
answered well in the "building embedded systems" portion of the manual,
which is very heavily slanted to installation on a flash drive/limited
hardware and not towards an entire PC-compatible (with rotating media etc)
that is embedded or being retasked..

I think this article was a great start, and if someone could come up with a
detailed set of instructions on how to create a custom boot environment that
DOES do the PC-like hardware detection, includes minimal photon, etc. I'd be
in heaven..
Well - the next part in the series is going to cover making a small boot
image with a shell and network access. After that I am going to cover
booting RTP without diskboot. As I said before I also hope to get cover
the steps AFTER the boot image is complete - right up to when photon gets
started.

chris

--
cdm@qnx.com "The faster I go, the behinder I get."
Chris McKillop -- Lewis Carroll --
Software Engineer, QSSL
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Marisa Giancarla

Re: ARTICLE: The QNX Boot Process

Post by Marisa Giancarla » Thu Jan 25, 2001 10:26 pm

"Chris McKillop" <cdm@qnx.com> wrote in message
news:94q0nn$d7b$1@nntp.qnx.com...
Well - the next part in the series is going to cover making a small boot
image with a shell and network access. After that I am going to cover
booting RTP without diskboot. As I said before I also hope to get cover
the steps AFTER the boot image is complete - right up to when photon gets
started.
That will be excellent.

Marisa

Thomas Fletcher

Re: ARTICLE: The QNX Boot Process

Post by Thomas Fletcher » Fri Jan 26, 2001 1:38 pm

Marisa Giancarla <mgiancarla@macromedia.com> wrote:
"Thomas Fletcher" <thomasf@qnx.com> wrote in message
news:94ko32$aa1$1@nntp.qnx.com...
Not to mention the fact that we have an entire bookset (Building Embedded
Systems)
that is pretty clear on what is going on in the boot process. QRTP (and
the boot

Please don't take this the wrong way, but the section of the manual you
mention is NOT clear at all for someone who has no familiarity with QNX, and
who is used to Linux or other Unix ways of customizing system startup. The
article that Kim posted is MUCH better about the very issues I didn't find
answered well in the "building embedded systems" portion of the manual,
which is very heavily slanted to installation on a flash drive/limited
hardware and not towards an entire PC-compatible (with rotating media etc)
that is embedded or being retasked..

I think this article was a great start, and if someone could come up with a
detailed set of instructions on how to create a custom boot environment that
DOES do the PC-like hardware detection, includes minimal photon, etc. I'd be
in heaven..
I'm glad that the article(s) are helping you out. Chris has some good
follow up ones coming down the line.

In the interest of improving our documentation and the overall end user
experience, how can we/should we improve the documentation on building
your own image and customizing the boot process?

What QNX does with the RTP is really just an extention of this normal
boot process, rather than run a large script section with a number of
different executables starting, QNX has made a custom binary (diskboot)
which will probe for the appropriate block device hardware, then probe
some more looking for an appropriate root filesystem volume. From
that point on it is all just the invocation of shell scripts which
each in turn spawn off some process that might do some auto detection
(such as the enumerators) or might start a service (such as photon).
Until Chris's follow up articles come out you might want to take a
peek through Dave Whelan's start of the System Administrators guide
on qdn.qnx.com in the Docs section.

Thomas

Marisa Giancarla

Re: ARTICLE: The QNX Boot Process

Post by Marisa Giancarla » Fri Jan 26, 2001 8:57 pm

With some of the hardware I'm trying to use I would even be happy with just
taking the "qnxbase.*" sets of files and ".boot" and ".altboot" and copying
them onto a drive and starting out with that as I would like pretty much
everything that would include anyway.. What I keep getting stuck on is how
to get the drive initally set up - even with patch A just doing a
"fdisk/dinit/copy on .boot and /boot/fs files" results in a system that
displays the initial QNX loader message, but then always says "os not
found"...

I'm guessing it is because it doesn't know to look for the boot drive in a
PCMCIA slot as when I mount it in an existing system to partition it etc. I
need to manually start another devb-eide process and give it the IRQ&IO
addresses to use...
It gets very frustrating as I don't see any documentation on how to make a
bootable harddrive, only flash drives & the like..

Marisa

Igor Kovalenko

Re: ARTICLE: The QNX Boot Process

Post by Igor Kovalenko » Sat Jan 27, 2001 11:22 pm

"Marisa Giancarla" <mgiancarla@macromedia.com> wrote in message
news:94soa4$ids$1@inn.qnx.com...
With some of the hardware I'm trying to use I would even be happy with
just
taking the "qnxbase.*" sets of files and ".boot" and ".altboot" and
copying
them onto a drive and starting out with that as I would like pretty much
everything that would include anyway.. What I keep getting stuck on is how
to get the drive initally set up - even with patch A just doing a
"fdisk/dinit/copy on .boot and /boot/fs files" results in a system that
displays the initial QNX loader message, but then always says "os not
found"...
I really can't understand how did they screw it that way. Earlier versions
of Neutrino (OEM distributions, not RTP) worked just fine. I used
fdisk/dinit shipped with them to initialize empty drives of all types,
floppy, SCSI, EIDE, including CompactFlash EIDE. I still use them, since I
saved them away when later versions started to break that functionality.

There was only one problem - with drive geometry detection. It never worked
right and for some weird reason I had to force geometry on SCSI drives while
doing so on EIDE prevented them from booting ;)
I'm guessing it is because it doesn't know to look for the boot drive in a
PCMCIA slot as when I mount it in an existing system to partition it etc.
I
need to manually start another devb-eide process and give it the IRQ&IO
addresses to use...
You BIOS must support booting from whatever device you use. I never heard
about systems booting from PCMCIA drives... My CompactFlash drives are
inserted into special sockets on motherboard, so they looks like 'real' EIDE
devices.
It gets very frustrating as I don't see any documentation on how to make a
bootable harddrive, only flash drives & the like..
It is not all that complex at all. A drive must have:
1. MBR.
Could be any loader, QNX, LILO, you name it. QNX loader will be written by
'fdisk loader' command. It will be invoked by BIOS.

2. Valid partition table.
Use fdisk again. There is gotcha - if you have attempted to write partition
table when drive geometry was wrong, it will be screwed until you zero out
the partition table. Use dd utility (copy 512 bytes from /dev/zero to
/dev/hdXX). I have habit (learned hard way) of always clearing partition
table as part of initialization.

3. OS/Partition loader.
Will be invoked by loader. Use dinit to write it into partition and 'fdisk
boot' command to mark partition active.

4. Valid filesystem and initial boot image.
For DOS you need io.sys and msdos.sys. For QNX it is /.boot file. The
partition loader will read it (it knows where from because /.boot and
/.altboot files have fixed position in the root directory and there is root
block on partition which points to the beginning of root directory), load
into memory and pass control to procnto. From that moment on everything is
in your hands, normally all you have to do in the /.boot is start filesystem
manager and mount root filesystem to get access to the rest of files needed
to start system up and call some 'init' script to do that.

I simply start shell passing it name of my own init script and from there I
do something like SysV startup procedure (master script looks to some
directory and executes all executable files it can find there in
alphabetical order). It allows for much easier customizations of boot
sequence, since you can plug-in your own scripts and turn off existing ones
(by removing execute mode). Much easier to add/remove new packages to
system. And much less chance that a customer will make system unbootable by
improperly editing single startup script.

- igor

Post Reply

Return to “qdn.public.articles”