bootable partitions

Hello,

I’m working on setting up a QNX6.1 system which I planned on having 3
partitions on the only storage device (in this case a CompactFlash on an IDE
interface of a PC104 card).
Partition 1 will be small and only contain the OS boot image, 2 will have a
QNX filesystem with additional needed file, utilities, etc. and partition 3
will be used for logging data. The problem is that I would like the system
to boot as fast as possible avoiding the prompt asking for the boot
partition, as I only plan on using the first partition for booting. I tried
deleting the .boot files of the 2nd and 3rd partition, but always received
the message that the resource was busy (even though I had booted from a
completely different device (a DOC)).

Is it possible to indicate that only certain partitions should be candidates
for booting? If so, how?
Also, is it possible to reduce the time spent with the “Hit Esc for
…altboot”? (like I said, boot time is critical for this app).
After partitioning a device, is it absolutely necessary to run dinit on the
partitions which won’t be used as bootable partitions?

Thanks for any tips,

Jason

“Jason Wycoff” <jason@socratec.de> wrote in
news:a8rn9f$bkd$1@inn.qnx.com:

Hello,

I’m working on setting up a QNX6.1 system which I planned on having 3
partitions on the only storage device (in this case a CompactFlash on
an IDE interface of a PC104 card).
Partition 1 will be small and only contain the OS boot image, 2 will
have a QNX filesystem with additional needed file, utilities, etc. and
partition 3 will be used for logging data. The problem is that I would
like the system to boot as fast as possible avoiding the prompt asking
for the boot partition, as I only plan on using the first partition for
booting. I tried deleting the .boot files of the 2nd and 3rd
partition, but always received the message that the resource was busy
(even though I had booted from a completely different device (a DOC)).

You should write the OS loader into the first 512 bytes, instead of the
partition loader. The .boot files should always be present (they occupy
reserved inode numbers). You can zero them if you wish, but not remove
them.


Is it possible to indicate that only certain partitions should be
candidates for booting? If so, how?

You just mentioned you only want to boot from the first partition - what
other candidates could there be? If you want the choice, use the partition
loader, otherwise only use the OS loader.

Also, is it possible to reduce the time spent with the “Hit Esc for
.altboot”? (like I said, boot time is critical for this app).
After partitioning a device, is it absolutely necessary to run dinit on
the partitions which won’t be used as bootable partitions?

Purchase the BSP for a x86 reference board, and write the IPL/OS loader to
suit your project needs.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

Hello again,

thanks for the response,

You should write the OS loader into the first 512 bytes, instead of the
partition loader. The .boot files should always be present (they occupy
reserved inode numbers). You can zero them if you wish, but not remove
them.

now I’m starting to get a little (not much), but somewhat, smarter.
Unfortunately, as a greenhorn, I’m not up to snuff on all the differences
between the boot loader, the OS loader, and any other loader which there
might be. I’ve tried to glean it from the docs, but just haven’t got it
yet. fdisk offers an option for setting one “loader” and dinit installs yet
another loader.

You just mentioned you only want to boot from the first partition - what
other candidates could there be?

Personally, there is for me only one true candidate, however one of the
loaders always asks “Press F1-F4 to select drive”… yadayada, which led me
to believe that the loader (based on what I tried to learn from the
Developer Discussion Article “Making Buildfiles for QNX ROTS Part 2”, this
would be the Master Boot Loader) “sees” several candidate partitions. I was
assuming that as a .boot file and a loader is always added to each partition
by dinit, that the Master Boot Loader sees these potential (OS?) loaders and
images and thus offers us the option to choose one. Apparently that’s not
the case, could you please clarify how it really works?

After all this, it will be time to get loaded myself :wink:

Many thanks,

Jason

“Jason Wycoff” <jason@socratec.de> wrote in
news:a91kj1$n47$1@inn.qnx.com:

now I’m starting to get a little (not much), but somewhat, smarter.
Unfortunately, as a greenhorn, I’m not up to snuff on all the
differences between the boot loader, the OS loader, and any other
loader which there might be. I’ve tried to glean it from the docs, but
just haven’t got it yet. fdisk offers an option for setting one
“loader” and dinit installs yet another loader.

It’s more of a generic x86 boot strapping process, than it is QNX specific.
Fdisk writes the parition loader (since it only has knowledge of
partitions), and dinit/dloader load the OS loader.

Personally, there is for me only one true candidate, however one of the
loaders always asks “Press F1-F4 to select drive”… yadayada, which led
me to believe that the loader (based on what I tried to learn from the
Developer Discussion Article “Making Buildfiles for QNX ROTS Part 2”,
this would be the Master Boot Loader) “sees” several candidate
partitions. I was assuming that as a .boot file and a loader is always
added to each partition by dinit, that the Master Boot Loader sees
these potential (OS?) loaders and images and thus offers us the option
to choose one. Apparently that’s not the case, could you please
clarify how it really works?

Essentially, the parition loader is the one asking about which parition to
boot. AFAICR, It defaults to the parition marked as bootable in the
partition table, but you can choose any one you wish. Based on the
selection, it then copies the first 512 bytes of the partition, and jmp’s
to it. This next loader is the OS loader, which finds the OS, copies it
and jmps to it.

Hope that helps.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

It may be too late, but I’ll gladly add my 2cents here.
I used to have to deal with this kind of problem a lot.

Some basic functions of a standard BIOS are to setup some
useful functions, such as read sector, check the keyboard, etc,
and then load the first sector on your hard drive into memory,
and if it has the right signature on it, jump into it.

This first sector is called the partition loader. The last
64 or so bytes are the partition data. This is purely by
convention. If you want to write your own partition-loader,
you are free to change things around at your own risk.
Don’t expect any OS, QNX6 included, to figure this out
easily.

A typical simple partition loader will just load the first
sector of the “ACTIVE” partition, and again check for a
signature before jumping in. This is the so called OS
loader.

The suggestion that you copy the os loader to the partition
loaders place, the first sector on the disk, may or may not
work. You’ll have to try. I’ve seen in the past combinations
of partition/os loader where the partition loader left some
information in memory about which partition was booted off of.
I suspect that QNX6 does not suffer from this problem.

Since the partition loader can only be 1 sector’s worth of
code, either that or it must itself bootstrap more into
memory, it is an interesting exersize to reverse engineer it.
I’ve done this with QNX’s partition loader in the past.
The purpose of such an exersize would be to modify the code
directly to not wait for a keypress. This might be something
you could do with appropriate NOP’s x90 in the right places.

Likewise it might be possible to eliminate the keypress in
the OS loader. You also might be able to get the source
code from QSSL and take a more direct approach.



Mitchell Schoenbrun --------- maschoen@pobox.com