Booting from compact flash memory

Hi,

Booting from compact flash memory gave me the same problem as it gave Kit
Plummer (no reply to his post).

It recognises the flash memory as boot device, starts booting and then
crashes before giving a prompt…
(only displaying “Hit Esc for .altboot…S”, or in a
previous atempt: “Hit Esc for .altbootQ” )

I’m using a PC104 miniPC (Pentium1 166Mhz), with internal Rom On Chip drive
and external Compact Flash memory drive (from which I’m trying to boot). QNX
version 6.3.0.

Thanks for any help!

Joost de Folter.



------------- Original mail from Kit Plummer:

Anybody know of any quirk with booting QNX to a FlashDrive? My install
hangs after the “Hit Esc for .altboot” with …S

I can boot to my install using a CD, just not the BIOS or bootloader on
the drive.

Thanks in advance for any insight.

Kit

  1. From what I remember (it’s been a year since I dealt with that issue)
    there’s two somewhat different kinds of CF cards. Let’s call them ‘old’ and
    ‘new’ for the lack of better name. I do not remember exact difference, but
    it had something to do with the way the card reports itself to BIOS.

  2. There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way using
    fdisk utility and ‘new’ way using dloader utility.

  3. It appears that fdisk only worked for ‘old’ type of CF cards. New ones
    only worked when using dloader. It also seemed to work for old ones…

– igor

“Joost de Folter” <joost.defolter@innovamedica.com.mx> wrote in message
news:cvj2ot$e7b$1@inn.qnx.com

Hi,

Booting from compact flash memory gave me the same problem as it gave Kit
Plummer (no reply to his post).

It recognises the flash memory as boot device, starts booting and then
crashes before giving a prompt…
(only displaying “Hit Esc for .altboot…S”, or in a
previous atempt: “Hit Esc for .altbootQ” )

I’m using a PC104 miniPC (Pentium1 166Mhz), with internal Rom On Chip
drive and external Compact Flash memory drive (from which I’m trying to
boot). QNX version 6.3.0.

Thanks for any help!

Joost de Folter.



------------- Original mail from Kit Plummer:

Anybody know of any quirk with booting QNX to a FlashDrive? My install
hangs after the “Hit Esc for .altboot” with …S

I can boot to my install using a CD, just not the BIOS or bootloader on
the drive.

Thanks in advance for any insight.

Kit

Igor Kovalenko wrote:

  1. There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way using
    fdisk utility and ‘new’ way using dloader utility.

Are you sure? I can’t test such ideas but reading the docs for dloader it only puts a bootblock on a disc. As far as I can tell it’s the same bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting but my best guess so far is simply a mis-match between BIOS’s view of the geometry while the bootblocks’ are using it until /.boot is loaded vs devb-eide’s view of the geometry when fdisk is used to specify where the partitions are located.

There is good chance that all CF card’s that are configured “partitionless” will boot just fine.


Evan

Hello again,

I tried using fdisk (creating a QNX 77 partition manually) / using dloader
(using the comon hd/pc type), all had the same effect:
When booting, the CF is not recognised as bootable device at all.

When comparing pc bios info with qnx, the format does read differently (see
at the bottom of my mail).

The only way that got me up to the point where I was (where the device did
boot, but crashed), is by removing all partitions (like you in fact
suggested Evan), and then using the dinit comand:
dinit -h /dev/hd1 (on the RAW partition; in QNX my CF is detected (in an usb
reader) as a hard disk.)

Could the boot image be the problem?
I tried various, also the new disc on chip build file, but removed the
d.o.c. driver in the startup.

Thanks again!
Joost.

I have a CF type: Kingston 128MB CF (NAND type) (not their latest Elite type
of CF).

QNX:
heads: 32
sectors/track: 32
block size: 512
cylinders: 244

PC bios:
heads: 32
sectors/track: 63
block size: 128
cylinders: 489





“Evan Hillas” <evanh@clear.net.nz> escribió en el mensaje
news:cvkabd$ckj$1@inn.qnx.com

Igor Kovalenko wrote:
2) There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way
using fdisk utility and ‘new’ way using dloader utility.


Are you sure? I can’t test such ideas but reading the docs for dloader it
only puts a bootblock on a disc. As far as I can tell it’s the same
bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting but
my best guess so far is simply a mis-match between BIOS’s view of the
geometry while the bootblocks’ are using it until /.boot is loaded vs
devb-eide’s view of the geometry when fdisk is used to specify where the
partitions are located.

There is good chance that all CF card’s that are configured
“partitionless” will boot just fine.


Evan

“Joost de Folter” <joost.defolter@innovamedica.com.mx> wrote in message
news:cvku7u$r02$1@inn.qnx.com

Hello again,

I tried using fdisk (creating a QNX 77 partition manually) / using dloader
(using the comon hd/pc type), all had the same effect:
When booting, the CF is not recognised as bootable device at all.

If I might ask a really dumb question. I’ve had zero experience with the
devices you are using but I just have to ask: Did you tell fdisk to make
that partition bootable (in addition to having it write the Loader)?

Kevin


When comparing pc bios info with qnx, the format does read differently
(see
at the bottom of my mail).

The only way that got me up to the point where I was (where the device did
boot, but crashed), is by removing all partitions (like you in fact
suggested Evan), and then using the dinit comand:
dinit -h /dev/hd1 (on the RAW partition; in QNX my CF is detected (in an
usb
reader) as a hard disk.)

Could the boot image be the problem?
I tried various, also the new disc on chip build file, but removed the
d.o.c. driver in the startup.

Thanks again!
Joost.

I have a CF type: Kingston 128MB CF (NAND type) (not their latest Elite
type
of CF).

QNX:
heads: 32
sectors/track: 32
block size: 512
cylinders: 244

PC bios:
heads: 32
sectors/track: 63
block size: 128
cylinders: 489





“Evan Hillas” <> evanh@clear.net.nz> > escribió en el mensaje
news:cvkabd$ckj$> 1@inn.qnx.com> …
Igor Kovalenko wrote:
2) There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way
using fdisk utility and ‘new’ way using dloader utility.


Are you sure? I can’t test such ideas but reading the docs for dloader
it
only puts a bootblock on a disc. As far as I can tell it’s the same
bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting
but
my best guess so far is simply a mis-match between BIOS’s view of the
geometry while the bootblocks’ are using it until /.boot is loaded vs
devb-eide’s view of the geometry when fdisk is used to specify where the
partitions are located.

There is good chance that all CF card’s that are configured
“partitionless” will boot just fine.


Evan

Hi,

Good point indeed!
I actually forgot to make the partition bootable the last few times I used
fdisk.
However, trying again (making the partition bootable) didn’t get me any
further either.
I included the technical stuff just in case the info would help, the only
really relevant thing is that I’m using compact flash memory as a hard disk.

Here’s a link with a lot more info on the subject (thanks Frank):
http://www.openqnx.com/PNphpBB2-viewtopic-t3043-.html

Anyway, I finalty got it working, this is how:

  • Removed all partitions from CF
  • Added FAT partition in win2000 (Kingston 128MB: CHS = 15:255:63)
  • Back to QNX: into fdisk: Removed partition
  • Added partition: Type 77 (QNX), start/end cylinders at default values
  • Rebooted QNX
  • Mounted everything:
    (mount -e /dev/hd1 , mount /dev/hd1 /fs/hd1 , mount -t qnx4 /dev/hd1t77
    /fs/hd1t77)
  • dinit -h /dev/hd1t77
  • cp test.ifs /fs/hd1t77/.boot

Please note that I’m not sure everything is essential here, just to make it
reprodicable.

By the way, every time starting fdisk in msdos/qnx, a different CHS was
reported until it finally seemed to ‘stabilize’ at CHS = 15:255:63
This is not the CHS reported in the pc bios.


nntp.qnx.com” <k@s.com> escribió en el mensaje
news:cvl1o3$c3$1@inn.qnx.com

“Joost de Folter” <> joost.defolter@innovamedica.com.mx> > wrote in message
news:cvku7u$r02$> 1@inn.qnx.com> …
Hello again,

I tried using fdisk (creating a QNX 77 partition manually) / using
dloader
(using the comon hd/pc type), all had the same effect:
When booting, the CF is not recognised as bootable device at all.

If I might ask a really dumb question. I’ve had zero experience with the
devices you are using but I just have to ask: Did you tell fdisk to make
that partition bootable (in addition to having it write the Loader)?

Kevin



When comparing pc bios info with qnx, the format does read differently
(see
at the bottom of my mail).

The only way that got me up to the point where I was (where the device
did
boot, but crashed), is by removing all partitions (like you in fact
suggested Evan), and then using the dinit comand:
dinit -h /dev/hd1 (on the RAW partition; in QNX my CF is detected (in an
usb
reader) as a hard disk.)

Could the boot image be the problem?
I tried various, also the new disc on chip build file, but removed the
d.o.c. driver in the startup.

Thanks again!
Joost.

I have a CF type: Kingston 128MB CF (NAND type) (not their latest Elite
type
of CF).

QNX:
heads: 32
sectors/track: 32
block size: 512
cylinders: 244

PC bios:
heads: 32
sectors/track: 63
block size: 128
cylinders: 489





“Evan Hillas” <> evanh@clear.net.nz> > escribió en el mensaje
news:cvkabd$ckj$> 1@inn.qnx.com> …
Igor Kovalenko wrote:
2) There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way
using fdisk utility and ‘new’ way using dloader utility.


Are you sure? I can’t test such ideas but reading the docs for dloader
it
only puts a bootblock on a disc. As far as I can tell it’s the same
bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting
but
my best guess so far is simply a mis-match between BIOS’s view of the
geometry while the bootblocks’ are using it until /.boot is loaded vs
devb-eide’s view of the geometry when fdisk is used to specify where
the
partitions are located.

There is good chance that all CF card’s that are configured
“partitionless” will boot just fine.


Evan
\

I am pretty sure that I had the problem with exactly the same software setup
(my own installation CD) failing (that is, installing but then failing to
boot) with some models of CF and working with others (on the same machine).
I am equally sure that I fixed it by playing with fdisk/dloader. Now that I
think of it, I recall it was more tricky than I said. I believe I ended up
using some combination of fdisk and dloader commands and that was the only
way I could find to make it work with either ‘old’ or ‘new’ CF cards.

I will try to dig up that stuff and post details.

“Evan Hillas” <evanh@clear.net.nz> wrote in message
news:cvkabd$ckj$1@inn.qnx.com

Igor Kovalenko wrote:
2) There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way
using fdisk utility and ‘new’ way using dloader utility.


Are you sure? I can’t test such ideas but reading the docs for dloader it
only puts a bootblock on a disc. As far as I can tell it’s the same
bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting but
my best guess so far is simply a mis-match between BIOS’s view of the
geometry while the bootblocks’ are using it until /.boot is loaded vs
devb-eide’s view of the geometry when fdisk is used to specify where the
partitions are located.

There is good chance that all CF card’s that are configured
“partitionless” will boot just fine.


Evan

Here is the sequence that will make all types (that I have seen anyway) of
CF cards bootable (assuming you have CF card as /dev/hd0 and you have
created and populated QNX partition type 79):

fdisk /dev/hd0 loader
fdisk /dev/hd0 boot -t79

dloader /dev/hd0 /boot/sys/ipl-diskpc1

dloader /dev/hd0t79 /boot/sys/ipl-diskpc2

I know that it seems redundant and at first look does not make any sense.
But we have shipped a product with bootable CF card and our own installation
CD, so believe me - we had to make it work and this was found to be a
working solution by long and exhaustive trial/error process. Note the order
is important. Also note that QNX kept messing with fdisk command line
switches so current version may not recognize this syntax, but there should
be an equivalent.

– igor

“Igor Kovalenko” <kovalenko@comcast.net> wrote in message
news:cvpk54$dpe$1@inn.qnx.com

I am pretty sure that I had the problem with exactly the same software
setup (my own installation CD) failing (that is, installing but then
failing to boot) with some models of CF and working with others (on the
same machine). I am equally sure that I fixed it by playing with
fdisk/dloader. Now that I think of it, I recall it was more tricky than I
said. I believe I ended up using some combination of fdisk and dloader
commands and that was the only way I could find to make it work with either
‘old’ or ‘new’ CF cards.

I will try to dig up that stuff and post details.

“Evan Hillas” <> evanh@clear.net.nz> > wrote in message
news:cvkabd$ckj$> 1@inn.qnx.com> …
Igor Kovalenko wrote:
2) There’s two ways to set up a bootable disk in QNX6 - the ‘old’ way
using fdisk utility and ‘new’ way using dloader utility.


Are you sure? I can’t test such ideas but reading the docs for dloader
it only puts a bootblock on a disc. As far as I can tell it’s the same
bootblock files, namely /boot/sys/ipl-diskpc*, that fdisk also uses.

I have had much trouble in understanding the real cause of CF booting but
my best guess so far is simply a mis-match between BIOS’s view of the
geometry while the bootblocks’ are using it until /.boot is loaded vs
devb-eide’s view of the geometry when fdisk is used to specify where the
partitions are located.

There is good chance that all CF card’s that are configured
“partitionless” will boot just fine.


Evan