ARTICLE: The QNX Boot Process

bridged with qdn.public.articles
Alain Bonnefoy

Re: ARTICLE: The QNX Boot Process

Post by Alain Bonnefoy » Mon Jan 29, 2001 7:55 am

Bill at Sierra Design a écrit :
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.

I'm not agree with you, if it's certainly better to start an embedded system
like you say, it's a big step to be able to install and start a qrtp on any pc
compatible. For us, qrtp is not only an embedded OS but also a development
platform. As PC chips are never the sames (it's like that), we thanks the
enumerators.

This is a condition for the qrtp success, and the qrtp success is a condition
for more drivers, more applications, more support.

It was possible 10 years ago, to support an OS without enumerator, now, it's not
possible, the technology moves too quickly. We cannot know every hardware
shipped on motherboards, it has to do by QSSL first, it will be done by hardware
manufacturers if QRTP is a success.

Alain.

Marisa Giancarla

Re: ARTICLE: The QNX Boot Process

Post by Marisa Giancarla » Mon Jan 29, 2001 9:42 pm

"Igor Kovalenko" <kovalenko@home.com> wrote in message
news:94vlel$a5c$1@inn.qnx.com...
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.
The BIOS does support booting off of them, both the PCMCIA drives that
appear to be modern ATA devices as well as the older ones that are not ATA.
In fact I can go into BIOS setup on them and it will display the proper
drive parameters, and win9x can "fdisk /mbr" and then format the drives and
the system will boot off of them fine..

So my thoughts are either that the RTP kernal as supplied can't boot from
them as they are not detected by the default enumerator, or that it is
seeing a different drive geometry. Which would be odd considering the
largest drive is only 270mb, but when linux has a similar issue with the
geometry being off LILO produces symptoms similar to what the QNX boot
loader appears to do...
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.
Hmm, I didn't do that, but did select the option once fdisk was running that
put the QNX loader onto the disk, and running fdisk again after it does show
the loader as "QNX" the the (only one on drive) partition is listed as type
79 & bootable..
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.
Great tip, I'll try it... What should I do if it sees the geometry wrong? Is
there a way to make it match what the BIOS sees?
3. OS/Partition loader.
Will be invoked by loader. Use dinit to write it into partition and 'fdisk
boot' command to mark partition active.
Is there something other than a "dinit /dev/hd1t79" I need to do to make
sure the OS loader is put in there?

Thanks for all the other useful tips, I'll give them a try and see if it
helps!

Marisa

Igor Kovalenko

Re: ARTICLE: The QNX Boot Process

Post by Igor Kovalenko » Tue Jan 30, 2001 12:16 am

Marisa Giancarla wrote:
"Igor Kovalenko" <kovalenko@home.com> wrote in message
news:94vlel$a5c$1@inn.qnx.com...
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.

The BIOS does support booting off of them, both the PCMCIA drives that
appear to be modern ATA devices as well as the older ones that are not ATA.
In fact I can go into BIOS setup on them and it will display the proper
drive parameters, and win9x can "fdisk /mbr" and then format the drives and
the system will boot off of them fine..
Then you should be fine.
So my thoughts are either that the RTP kernal as supplied can't boot from
them as they are not detected by the default enumerator, or that it is
seeing a different drive geometry. Which would be odd considering the
largest drive is only 270mb, but when linux has a similar issue with the
geometry being off LILO produces symptoms similar to what the QNX boot
loader appears to do...
If you see 'OS not found' it means RTP did not even get control yet. The
message comes from BIOS and usually means BIOS can't see MBR on the
drive.

Until you see 'Press ESC to boot alternate OS' message you should not
worry about RTP seeing the drive. Only when it appears you know that
/.boot file is being actually loaded into memory. Then start worrying
about passing proper parameters to the driver in the boot image.
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.

Hmm, I didn't do that, but did select the option once fdisk was running that
put the QNX loader onto the disk, and running fdisk again after it does show
the loader as "QNX" the the (only one on drive) partition is listed as type
79 & bootable..
The 'fdisk loader' is just command line way of doing that. You should be
fine as long as geometry was right when you did that thing. Otherwise
fdisk probably misplaced it so BIOS does not see it.
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.

Great tip, I'll try it... What should I do if it sees the geometry wrong? Is
there a way to make it match what the BIOS sees?
There is (very poorly documented) cam-disk option for that.
Should look like 'disk translation=heads:sectors:path:target:lun'. You
can see path, target and lun when driver starts. For eide drive there is
also eide-specific way to set it, look at docs.
3. OS/Partition loader.
Will be invoked by loader. Use dinit to write it into partition and 'fdisk
boot' command to mark partition active.

Is there something other than a "dinit /dev/hd1t79" I need to do to make
sure the OS loader is put in there?
It must be 'dinit -h' for hard drives actually. If you going to use RTP
boot procedure (diskboot) then 'dinit -hR' to create /.diskroot. Nothing
else. In fact I don't know for sure if QNX loader is really chained. May
be the main loader does everything, but nonetheless dinit must write
some things into partition for it to work.

- igor

Marisa Giancarla

Re: ARTICLE: The QNX Boot Process

Post by Marisa Giancarla » Wed Jan 31, 2001 11:36 pm

"Igor Kovalenko" <Igor.Kovalenko@motorola.com> wrote in message
news:3A7607C3.530C3D61@motorola.com...
Then you should be fine.
I would think so, but it hasn't worked out so far..
If you see 'OS not found' it means RTP did not even get control yet. The
message comes from BIOS and usually means BIOS can't see MBR on the
drive.
The "os not found" gets displayed after it says "QNX Boot Loader" or
something like that. I don't have the drive here to stick in a machine to
get the exact text. But it is definately getting as far as the MBR loader,
but then failing to start QNX itself..
Until you see 'Press ESC to boot alternate OS' message you should not
worry about RTP seeing the drive. Only when it appears you know that
/.boot file is being actually loaded into memory. Then start worrying
about passing proper parameters to the driver in the boot image.
I think it is getting that far, but then failing before it can load the
/.boot file.
The 'fdisk loader' is just command line way of doing that. You should be
fine as long as geometry was right when you did that thing. Otherwise
fdisk probably misplaced it so BIOS does not see it.
I'm wondering if the geometry that is seen by default under QNX differs from
what the target machine uses - I'm sticking the drive in a modern laptop to
do the fdisk/dinit and then putting it in a older machine to actually boot.
Maybe I should write down what the target machine's BIOS detects the drives
as, and then make sure that that is the geometry passed to the devb-eide
command-line used to mount & prepare the drive for use in the target..
There is (very poorly documented) cam-disk option for that.
Should look like 'disk translation=heads:sectors:path:target:lun'. You
can see path, target and lun when driver starts. For eide drive there is
also eide-specific way to set it, look at docs.
Great, thanks.
It must be 'dinit -h' for hard drives actually. If you going to use RTP
Right, I was putting a "-h" and also a "-R" too.

Marisa

Steve Reid

Re: ARTICLE: The QNX Boot Process

Post by Steve Reid » Thu Feb 01, 2001 2:13 pm

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
: There is (very poorly documented) cam-disk option for that.
: Should look like 'disk translation=heads:sectors:path:target:lun'. You
: can see path, target and lun when driver starts. For eide drive there is
: also eide-specific way to set it, look at docs.

I've added the missing pieces. Here they are:

The disk options control the driver's interface to cam-disk.so. If
specified, they must follow the disk keyword:

name=prefix
Specify the device prefix (default: hd);

nobios
Don't use the geometry from BIOS int 13. By default, if you don't
specify the translation option, the BIOS geometry is used.

noptab
Don't use the geometry from the partition table. The geometry from
the partition table is used if you specify the nobios option, or the
BIOS geometry is invalid.

translation:heads[:sectors[:path_ID[:target[:lun]]]]
Specify the geometry explicitly; this overrides the geometry from
the BIOS and the partition table. The arguments are:

+ heads and sectors - report this many heads (and optionally,
sectors) to io-blk.so for hard disks (default is 64 heads and 32
sectors). The QNX filesystem doesn't need this information for
normal operation. It's needed only to let fdisk write the correct
boot cylinder for booting.

+ path_ID - the number of the controller to use, where the first
controller is 0 (the default).

+ target - for IDE, this is the master (0) or slave (1); for SCSI,
it's the SCSI ID the device is jumpered for. The default is 0.

+ lun - the Logical Unit Number for SCSI; not needed for IDE.
The default is 0.

Thanks for pointing it out.

------------------------------------------
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
------------------------------------------

Igor Kovalenko

Re: ARTICLE: The QNX Boot Process

Post by Igor Kovalenko » Thu Feb 01, 2001 4:39 pm

Steve Reid wrote:
Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
: There is (very poorly documented) cam-disk option for that.
: Should look like 'disk translation=heads:sectors:path:target:lun'. You
: can see path, target and lun when driver starts. For eide drive there is
: also eide-specific way to set it, look at docs.

I've added the missing pieces. Here they are:
thanks.
The disk options control the driver's interface to cam-disk.so. If
specified, they must follow the disk keyword:

name=prefix
Specify the device prefix (default: hd);

nobios
Don't use the geometry from BIOS int 13. By default, if you don't
specify the translation option, the BIOS geometry is used.
You have conflicting 'defaults' here. See below.
noptab
Don't use the geometry from the partition table. The geometry from
the partition table is used if you specify the nobios option, or the
BIOS geometry is invalid.
How does it know if BIOS geometry is invalid?
What if partition table does not yet exist?
translation:heads[:sectors[:path_ID[:target[:lun]]]]
Specify the geometry explicitly; this overrides the geometry from
the BIOS and the partition table. The arguments are:

+ heads and sectors - report this many heads (and optionally,
sectors) to io-blk.so for hard disks (default is 64 heads and 32
What does 'default' mean? How does it relate to getting geometry from
int13 or partition table?
In my experience it simply always report 64:32, unless 'translation' is
specified.
sectors). The QNX filesystem doesn't need this information for
normal operation. It's needed only to let fdisk write the correct
boot cylinder for booting.
Not quite. If geometry was wrong when partition table was created and
the drive is big then none of partitions will be recognized by io-blk at
all.
+ path_ID - the number of the controller to use, where the first
controller is 0 (the default).

+ target - for IDE, this is the master (0) or slave (1); for SCSI,
it's the SCSI ID the device is jumpered for. The default is 0.

+ lun - the Logical Unit Number for SCSI; not needed for IDE.
The default is 0.
What is really missing in QNX is a way to identify drives. When I have
bunch of them, how do I know which one is which? Driver only shows that
information once, when it starts.

Would be nice if path/target/lun were used in device naming scheme. Or
if there was a way to query driver to find out mapping between 'hdXX'
and path/target/lun.

- igor

Igor Kovalenko

Re: ARTICLE: The QNX Boot Process

Post by Igor Kovalenko » Fri Feb 02, 2001 10:18 pm

No further comments?
nobios
Don't use the geometry from BIOS int 13. By default, if you don't
specify the translation option, the BIOS geometry is used.


You have conflicting 'defaults' here. See below.

noptab
Don't use the geometry from the partition table. The geometry from
the partition table is used if you specify the nobios option, or the
BIOS geometry is invalid.


How does it know if BIOS geometry is invalid?
What if partition table does not yet exist?

translation:heads[:sectors[:path_ID[:target[:lun]]]]
Specify the geometry explicitly; this overrides the geometry from
the BIOS and the partition table. The arguments are:

+ heads and sectors - report this many heads (and optionally,
sectors) to io-blk.so for hard disks (default is 64 heads and 32

What does 'default' mean? How does it relate to getting geometry from
int13 or partition table?
In my experience it simply always report 64:32, unless 'translation' is
specified.

sectors). The QNX filesystem doesn't need this information for
normal operation. It's needed only to let fdisk write the correct
boot cylinder for booting.

Not quite. If geometry was wrong when partition table was created and
the drive is big then none of partitions will be recognized by io-blk at
all.

+ path_ID - the number of the controller to use, where the first
controller is 0 (the default).

+ target - for IDE, this is the master (0) or slave (1); for SCSI,
it's the SCSI ID the device is jumpered for. The default is 0.

+ lun - the Logical Unit Number for SCSI; not needed for IDE.
The default is 0.


What is really missing in QNX is a way to identify drives. When I have
bunch of them, how do I know which one is which? Driver only shows that
information once, when it starts.

Would be nice if path/target/lun were used in device naming scheme. Or
if there was a way to query driver to find out mapping between 'hdXX'
and path/target/lun.

- igor

Steve Reid

Re: ARTICLE: The QNX Boot Process

Post by Steve Reid » Wed Feb 07, 2001 2:27 pm

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
: No further comments?

Sorry, I've been away for a couple of days. I guess Kevin doesn't follow
this newsgroup, so I'll have to go bug him in person.

------------------------------------------
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
------------------------------------------

Paul

Re: ARTICLE: The QNX Boot Process

Post by Paul » Mon Mar 19, 2001 3:19 am

Igor Kovalenko <Igor.Kovalenko@motorola.com> wrote:
: There is (very poorly documented) cam-disk option for that.
: Should look like 'disk translation=heads:sectors:path:target:lun'. You
: can see path, target and lun when driver starts. For eide drive there is
: also eide-specific way to set it, look at docs.

I've added the missing pieces. Here they are:

The disk options control the driver's interface to cam-disk.so. If
specified, they must follow the disk keyword:

name=prefix
Specify the device prefix (default: hd);

nobios
Don't use the geometry from BIOS int 13. By default, if you don't
specify the translation option, the BIOS geometry is used.

noptab
Don't use the geometry from the partition table. The geometry from
the partition table is used if you specify the nobios option, or
the BIOS geometry is invalid.

translation:heads[:sectors[:path_ID[:target[:lun]]]]
Specify the geometry explicitly; this overrides the geometry from
the BIOS and the partition table. The arguments are:

+ heads and sectors - report this many heads (and optionally,
sectors) to io-blk.so for hard disks (default is 64 heads and 32
sectors). The QNX filesystem doesn't need this information for
normal operation. It's needed only to let fdisk write the correct
boot cylinder for booting.

+ path_ID - the number of the controller to use, where the first
controller is 0 (the default).

+ target - for IDE, this is the master (0) or slave (1); for SCSI,
it's the SCSI ID the device is jumpered for. The default is 0.

+ lun - the Logical Unit Number for SCSI; not needed for IDE.
The default is 0.

Thanks for pointing it out.
i`m not able to receave the net to collect email/news for some time
so forgive me if i seem late replying now and in the future, i am
polling when time and place allow so i will eventually see replys here
assuming the inn.com server isnt clearing posts before i re-poll.

assumeing your text above is as exactly as updated in the docs, that
+lun confused me for a second, perhaps a slight rejig like so to be clear.

+lun - the Logical Unit number For SCSI, The Default Is 0 (zero)

this Lun option is posific to SCSI drives and is not required
by IDE drives, if present it will be ignored for IDE. ( i assume ?)
----------------------------------------------

a real world example *here* at the bottom of each command syntax would be
a very GOOD thing if someones got the time to add them next revision.

for example even though i`d read the `mount` command syntax to see what it
could mount (i was looking to see if it could mount .ZIP files, it seems
it cant yet, if ever?) and it didnt click with me that i could mount
cd images very easyly, thats since turned out to be VERY useful.

a simple ` selection of real world examples` would have made it pritty
clear that cd images (.ISO, what else can `mount` mount?) can be mounted
(in that commands instance) very easly, if you see what i mean.

------------------------------------------
Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems
------------------------------------------
Paul May, Manchester, UK,
*Phoenix* Core © 1999, Phoenix Developer Consortium © 2000, *Team* Phx © 1999
Phinixi Technologies International LTD © 2000, Phinixi © 2000

Paul

Re: ARTICLE: The QNX Boot Process

Post by Paul » Mon Mar 19, 2001 6:02 am

"Igor Kovalenko" <Igor.Kovalenko@motorola.com> wrote in message
news:3A7607C3.530C3D61@motorola.com...
Then you should be fine.

I would think so, but it hasn't worked out so far..

If you see 'OS not found' it means RTP did not even get control yet. The
message comes from BIOS and usually means BIOS can't see MBR on the
drive.

The "os not found" gets displayed after it says "QNX Boot Loader" or
something like that. I don't have the drive here to stick in a machine to
get the exact text. But it is definately getting as far as the MBR loader,
but then failing to start QNX itself..

Until you see 'Press ESC to boot alternate OS' message you should not
worry about RTP seeing the drive. Only when it appears you know that
/.boot file is being actually loaded into memory. Then start worrying
about passing proper parameters to the driver in the boot image.

I think it is getting that far, but then failing before it can load the
/.boot file.

The 'fdisk loader' is just command line way of doing that. You should be
fine as long as geometry was right when you did that thing. Otherwise
fdisk probably misplaced it so BIOS does not see it.

I'm wondering if the geometry that is seen by default under QNX differs from
what the target machine uses - I'm sticking the drive in a modern laptop to
do the fdisk/dinit and then putting it in a older machine to actually boot.
Maybe I should write down what the target machine's BIOS detects the drives
as, and then make sure that that is the geometry passed to the devb-eide
command-line used to mount & prepare the drive for use in the target..
i would hope that your problem is solved by now but i feel i might
type my thoughts for consideration anyway, keep in mind that i`m
an amiga user at heart and learning RTP as i go, but it seems to me you might
be too close to the problem and over looked some basic things.

you said earlyer that your BIOS can see and boot the device, BUT were you
talking about the `modern laptop` OR the `older machine` can see and boot
device(PCMCIA) ?.

one other thing that might be werth trying is a slight variation on
what i tryed one an old 486 with very small IDE drive.

i found out very early on that while you need a windows OS to install
your first binaryfile RTP version, you dont need to have windows installed
in any other machine you might try running RTP on.

to explain, i didnot have a cdrom or big enough hardrive on that 486
to install both windows and the RTP binary image, SO i thought seeing
as the RTP always trys to `auto config` (amiga speak for enumerate)
on every boot, that it should be simply a case of getting the binary
image on a drive thats been formated and made bootable for DOS
in the right dir c:/proram files/qnx.boot/fs and adding the RTP
boot script to the config.sys, it works i tell you LOL.

assuming you have a binaryfile RTP handy try format /s the PCMCIA device
in that older machine ,placing in the modern laptop and do the above,
if oit works you have a good chance it boot to RTP in the old one
and a far as i can tell the binaryimage seems as fast as a native
partition with the added advantage that its dead easy to backup
to cdr in a windows for safe keeping.

on the subjust of RTP binary files, i`d love a tuturial on
`how to make a blank RTP hardfile` a assume a shell command
but a 3rd party ? GUI front end would be nice too.

`how to mount/initalise said empty hardfile in a running RTP, then
transfer a fully working standard RTP install (+ my 3rd party progs)
on a *partition* to that blank hardfile.

the ideal thing for me would be a shell command/script with front end
(i do like to use Photon more than shell) lets call it ohh say.....
a *non* linux 2 letter cryptic type name id hope LOL
`Phank-God-RTP-has-This-easy-backup-tool-as-standard.x` and when run
it would ask you what drive or files you wanted backing up, were
you would like it placed and by what name you want it called, it would then
proceed to work out what size HardFile would be needed, or fixed size if
you prefer (for 640meg cd storage perhaps), create the HF on the fly,
even make it a bootable image if you wish.

i know i made it over the top with the name , but i really would like a
generally simple hardfile making tool (optional gui but nice to have it IMO)
and a way to mount several at a time (i assume it can be done ?) would
be a very good way to backup and indeed run them at boot time if you wish,
i might have one setup for a web/file server, one for gimp or some
amiga style gfx program, yet another for MOD creation if thats ported
and boot them as i please, yet again i might decide to have several
networked machines, eather local or *secure* web(how?) connected
that can boot from their own special RTP Hardfile served from this machine.

as you might guess, i DO like the Hardfile option over the partition option
due simply to the fact its so simple to backup and keep track of them
not to mention configure them to *my* personal task in an easy way
(once i work out the easyest way to backup a full RTP install to hardfiles
and make/install them from scratch if course).

while i`m ranting on, i`d also like to ask someone to consider another
related app, i can currently take an IDE harddrive with a dos and qnx4
partition on it place it in my real amiga and mount these file systems
qnx4 $4d $4e and $4f (and many more) inside amigados useing a small
tool called mountdos (with full amiga E source), given that windows9x
has a tool called winImage that can mount floppy drive images and
cd images (virtual Daemon is better for CD ISO`s though).

i was hopeing that someone here had the skill and willingness to make
a winows 9x app sumiular to these that would mount a real RTP partition
and more so RTP HardFiles? (amiga HFs too if your able), im hopeing
that the RTP hardfile is layed out in the same way as the WinUAE
amiga HFs (HardFiles) (32 sectures, 1 surface, 512 blocks and 2 reserved)

what is the official RTP hardfile formular/spec ?.

IF that app existed then i would be able to read/write any RTP install
from win9x (running WinUAE, THOR and Cygnus ED as RTP email/news apps
cant compare ATM, perhaps a THOR/CED RTP port/clone one day ?)
even through WinUAE perhaps if the windows App could fool windows OS
in to seeing the RTP mounted R/W sections rather than
as i think winimage5 does it, only useable from inside itself,
but even thats enough as a starting point.

one one thing thats REALLY missing from current RTP though to make backup
so much easyer is a generic UDF CDRW driver for RTP, it would be so
useful to be able to simply any files you want to what must be the best
value for money and ease of use to date, a CDRW drive, id think that
just about everyone could/would make good use of a UDF CDRW inside RTP
and thats including the new users and longtime embedded people such as Igor
( write your latest update, plug in your CDRW at the clients plant and
deploy , make final ajusments, and back it up there and then in case of
operator c*ckup)

one last nice-to-have app/device you might write would be an RTP equiv of
the amiga style RAM/RAD disk, i.e a real RAMdisk that is both soft reset
proof (is that possible on generic x86 ?/RTP) everything copyed inside it
is retained until power down/hardreset/really bad crash or is deleted,
*and* will auto grow and shrink in size as required so as to not take
up any more ram than is required at the time, as in not a preset size
that you have to preset on first mount, its bootable too if you
set its priority higher than harddrives in amiga OS at least, perhaps
your cleaver enough to make it work in RTP too and willing to try.

amiga RAD is great for booting from and as fast as it gets once the
boot systems copyed to it, an RTP clone would be great, and probably
very useful in an embedded RTP device too, can/will it be done ?.

just some personal thoughts for consideration/work anyway,

later people.
There is (very poorly documented) cam-disk option for that.
Should look like 'disk translation=heads:sectors:path:target:lun'. You
can see path, target and lun when driver starts. For eide drive there is
also eide-specific way to set it, look at docs.

Great, thanks.

It must be 'dinit -h' for hard drives actually. If you going to use RTP

Right, I was putting a "-h" and also a "-R" too.

Marisa


Paul May, Manchester, UK,
*Phoenix* Core © 1999, Phoenix Developer Consortium © 2000, *Team* Phx © 1999
Phinixi Technologies International LTD © 2000, Phinixi © 2000

]{ristoph

Re: ARTICLE: The QNX Boot Process

Post by ]{ristoph » Wed Jun 27, 2001 9:51 am

Chris,

Is there ever going to be a second article in the series?

]{ristoph

"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! :-)

Robert Muil

Re: ARTICLE: The QNX Boot Process

Post by Robert Muil » Tue Jun 03, 2003 12:10 am

Hello,

I am trying to install a custom ifs file as altboot, but cannot overwrite
the .altboot file in the root directory.

The command:
cp -f custom.ifs /.altboot
fails with "Resource Busy"

Any advice?

Robert.

John Garvey

Re: ARTICLE: The QNX Boot Process

Post by John Garvey » Tue Jun 03, 2003 12:25 am

Robert Muil <rmuil@optushome.com.au> wrote:
I am trying to install a custom ifs file as altboot, but cannot overwrite
the .altboot file in the root directory.
The command:
cp -f custom.ifs /.altboot
fails with "Resource Busy"
Any advice?
Don't use "-f" ... this forces an unlink of the file, and .boot and
..altboot are special in that they cannot be removed. Just "cp" it.

Jim Douglas

Re: ARTICLE: The QNX Boot Process

Post by Jim Douglas » Thu Jun 12, 2003 8:08 pm

....or use 'dd'...


"John Garvey" <jgarvey@qnx.com> wrote in message
news:bbgpt8$cvm$1@nntp.qnx.com...
Robert Muil <rmuil@optushome.com.au> wrote:
I am trying to install a custom ifs file as altboot, but cannot
overwrite
the .altboot file in the root directory.
The command:
cp -f custom.ifs /.altboot
fails with "Resource Busy"
Any advice?

Don't use "-f" ... this forces an unlink of the file, and .boot and
.altboot are special in that they cannot be removed. Just "cp" it.

Robert Muil

Re: ARTICLE: The QNX Boot Process

Post by Robert Muil » Fri Jun 13, 2003 1:52 pm

People,

FYI: it wasn't the -f flag, it was Photon: If I booted without photon, I
could copy over the .boot or .altboot files...

Robert.

"Jim Douglas" <jim@dramatec.co.uk> wrote in message
news:bcal8k$ll2$1@inn.qnx.com...
...or use 'dd'...


"John Garvey" <jgarvey@qnx.com> wrote in message
news:bbgpt8$cvm$1@nntp.qnx.com...
Robert Muil <rmuil@optushome.com.au> wrote:
I am trying to install a custom ifs file as altboot, but cannot
overwrite
the .altboot file in the root directory.
The command:
cp -f custom.ifs /.altboot
fails with "Resource Busy"
Any advice?

Don't use "-f" ... this forces an unlink of the file, and .boot and
.altboot are special in that they cannot be removed. Just "cp" it.

Post Reply

Return to “qdn.public.articles”