Booting from DiskOnModule

[Eric_Berdahl]

Greetings,

I’m experimenting with a DOM (DiskOnModule) device. (QNX RTOS 6.0)

I can partition the sucker (with /sbin/fdisk) and format it (with
/sbin/dinit -h), but I can’t get the bloody thing to boot. I get as far
as:

QNX Loader
Boot Partition 1
Press Esc for alternate OS…

and then nothing. The system just hangs there, as if it didn’t find the
…boot file on the disk.

I’ve confirmed (with fdisk) that the sucker has a QNX loader and the
partition is marked bootable. I’ve confirmed that there is a reasonable
…boot file on the volume.

The same disk image (.boot file and other pieces of the file system)
work just fine when on CompactFlash or a standard hard drive, but don’t
seem to be happy on DOM.

Any clues?

Thanks in advance,
Eric

[Hardware_Support_Acc]

Hi Eric,

What are you using for a filesystem driver? I haven’t heard
of the DOM before, who makes it? M-Systems has a driver for
their DOC (disk on chip) but is the DOM from M-Systems or
is it similar to DOC?

E.


Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

Greetings,

I’m experimenting with a DOM (DiskOnModule) device. (QNX RTOS 6.0)

I can partition the sucker (with /sbin/fdisk) and format it (with
/sbin/dinit -h), but I can’t get the bloody thing to boot. I get as far
as:

QNX Loader
Boot Partition 1
Press Esc for alternate OS…

and then nothing. The system just hangs there, as if it didn’t find the
.boot file on the disk.

I’ve confirmed (with fdisk) that the sucker has a QNX loader and the
partition is marked bootable. I’ve confirmed that there is a reasonable
.boot file on the volume.

The same disk image (.boot file and other pieces of the file system)
work just fine when on CompactFlash or a standard hard drive, but don’t
seem to be happy on DOM.

Any clues?

Thanks in advance,
Eric

[Eric_Berdahl]

In article <9n83ie$lsr$1@nntp.qnx.com>,
Hardware Support Account <hw@qnx.com> wrote:

What are you using for a filesystem driver? I haven’t heard
of the DOM before, who makes it? M-Systems has a driver for
their DOC (disk on chip) but is the DOM from M-Systems or
is it similar to DOC?

Thanks for your response and interest!

I am using devb-eide for the driver. DOM is “just another IDE device”.
It snaps onto the same IDE ribbon cable as my regular hard drive.
Basically, it’s an IDE hard drive which uses flash technology instead of
a platter for storage. So, unlike DOC, it should use the same drivers as
every other IDE device. The biggest difference is that my DOM device is
tiny (16MB) compared to regular hard drives.

The device I’m using is manufactured by PQI http://www.pqi.com.tw.
I’ve looked at all their datasheets and other documentation and they all
talk about the device as if it were any other IDE device.

I have learned a few other things in the past couple days (all through
various experimentation). Notably, if I repartition the device and put a
QNX filesystem on it using fdisk and dinit in the standard fashion (upon
which I will elaborate if that helps clear thing up), the filesystem
looks good (i.e. chkfsys is happy). If I then reboot the machine, with
the ‘shutdown’ command for example, chkfsys finds a bunch of errors on
the disk after the system reboots.

Further, if I re-run chkfsys after it rewrites the “fixed” bitmap, it
continues to find one error consistently AND reports that the NEW bitmap
is equal to the OLD bitmap. I don’t understand that at all.

Is there something I need to do to accomodate the fact that the device
is small compared to a regular hard disk? Or for the fact that it is
slow compared to a hard disk? The boot image I’m using is the same image
which works fine when installed on CompactFlash.

What do you suggest?

Thanks in advance,
Eric

[Hardware_Support_Acc]

Hi Eric,

Try the following.

Setup the DOM and get it going (like you have in the past).
Then using the dd command make an image on the local hd to
check against. Reboot the system then do a diff on /dev/DOM or
whatever against the image you got from the dd command.

BTW what errors has chkfsys found? Are they always the same? or
do they change?

Thanks

Erick.


Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

In article <9n83ie$lsr$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

What are you using for a filesystem driver? I haven’t heard
of the DOM before, who makes it? M-Systems has a driver for
their DOC (disk on chip) but is the DOM from M-Systems or
is it similar to DOC?

Thanks for your response and interest!

I am using devb-eide for the driver. DOM is “just another IDE device”.
It snaps onto the same IDE ribbon cable as my regular hard drive.
Basically, it’s an IDE hard drive which uses flash technology instead of
a platter for storage. So, unlike DOC, it should use the same drivers as
every other IDE device. The biggest difference is that my DOM device is
tiny (16MB) compared to regular hard drives.

The device I’m using is manufactured by PQI <> http://www.pqi.com.tw> >.
I’ve looked at all their datasheets and other documentation and they all
talk about the device as if it were any other IDE device.

I have learned a few other things in the past couple days (all through
various experimentation). Notably, if I repartition the device and put a
QNX filesystem on it using fdisk and dinit in the standard fashion (upon
which I will elaborate if that helps clear thing up), the filesystem
looks good (i.e. chkfsys is happy). If I then reboot the machine, with
the ‘shutdown’ command for example, chkfsys finds a bunch of errors on
the disk after the system reboots.

Further, if I re-run chkfsys after it rewrites the “fixed” bitmap, it
continues to find one error consistently AND reports that the NEW bitmap
is equal to the OLD bitmap. I don’t understand that at all.

Is there something I need to do to accomodate the fact that the device
is small compared to a regular hard disk? Or for the fact that it is
slow compared to a hard disk? The boot image I’m using is the same image
which works fine when installed on CompactFlash.

What do you suggest?

Thanks in advance,
Eric

[Eric_Berdahl]

Hi Erick,

In article <9nar19$e25$1@nntp.qnx.com>,
Hardware Support Account <hw@qnx.com> wrote:

Setup the DOM and get it going (like you have in the past).
Then using the dd command make an image on the local hd to
check against. Reboot the system then do a diff on /dev/DOM or
whatever against the image you got from the dd command.

dinit -h /dev/hd1t77

/sbin/chkfsys -u /fs/hd1-qnx4

[no errors detected]

dd if=/dev/hd1 of=dom.before

shutdown

… after reboot and logging back in

diff /dev/hd1 dom.before

6,7c6,7
< < —

dd if=/dev/hd1 of=dom.after

diff dom.before dom.after

6,7c6,7
< < —

So, there does appear to be a difference induced by the reboot.

BTW what errors has chkfsys found? Are they always the same? or
do they change?

The errors are always the same. They look like this:

\

/sbin/chkfsys /fs/hd1-qnx4

Checking filesystem on file /dev/hd1t77
Severe error (uses one or more blocks marked free in the bitmap: 0x7FF9).
[ /fs/hd1-qnx4 ]
Will mark as used if the bitmap is saved (data probably OK).
fix (Y/n) ? Y
Dir /fs/hd1-qnx4/
Severe error (uses one or more blocks marked free in the bitmap: 0x13).
[ /fs/hd1-qnx4/.inodes ]
Will mark as used if the bitmap is saved (data probably OK).
fix (Y/n) ? Y
Dir /fs/hd1-qnx4/lost+found
Severe error (uses one or more blocks marked free in the bitmap: 0x23).
[ /fs/hd1-qnx4/lost+found/ ]
Will mark as used if the bitmap is saved (data probably OK).
fix (Y/n) ? Y

Comparing new bitmap to old and checking released blocks

Directories Files Extents Blocks
Available
31984/disk
Totals 2/disk 4/disk 4/disk
14/disk
Maximums 7/dir 1/file
16/file
Averages 2/dir 1/file
3/file

24 block(s) recoverable - previously marked in the bitmap: FIXABLE
32 block(s) newly marked as used - SEVERE ERROR: FIXABLE
write new bitmap (Y/n) ? Y


Having now “fixed” the file system, chkfsys will continue to report one
of those errors again and again and again.

\

/sbin/chkfsys /fs/hd1-qnx4

Checking filesystem on file /dev/hd1t77
Severe error (uses one or more blocks marked free in the bitmap: 0x7FF9).
[ /fs/hd1-qnx4 ]
Will mark as used if the bitmap is saved (data probably OK).
fix (Y/n) ? Y
Dir /fs/hd1-qnx4/
Dir /fs/hd1-qnx4/lost+found

Comparing new bitmap to old and checking released blocks

Directories Files Extents Blocks
Available
31984/disk
Totals 2/disk 4/disk 4/disk
46/disk
Maximums 7/dir 1/file
16/file
Averages 2/dir 1/file
11/file

NEW bitmap is equal to OLD bitmap

Other ideas?

Thanks in advance,
Eric

[Hardware_Support_Acc]

Hi Eric,

Interesting. I am going to see about ordering one of these things
for our testing group. But in the mean time I am still going to see
if I can figure out anything. Can you upgrade to the lastest version
of the OS (6.1) and see if the problems still exists?

Thanks

E.

Hardware Support Account <hw@qnx.com> wrote:

Hi Eric,

Try the following.

Setup the DOM and get it going (like you have in the past).
Then using the dd command make an image on the local hd to
check against. Reboot the system then do a diff on /dev/DOM or
whatever against the image you got from the dd command.

BTW what errors has chkfsys found? Are they always the same? or
do they change?

Thanks

Erick.



Eric Berdahl <> berdahl@intelligentparadigm.com> > wrote:
In article <9n83ie$lsr$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

What are you using for a filesystem driver? I haven’t heard
of the DOM before, who makes it? M-Systems has a driver for
their DOC (disk on chip) but is the DOM from M-Systems or
is it similar to DOC?

Thanks for your response and interest!

I am using devb-eide for the driver. DOM is “just another IDE device”.
It snaps onto the same IDE ribbon cable as my regular hard drive.
Basically, it’s an IDE hard drive which uses flash technology instead of
a platter for storage. So, unlike DOC, it should use the same drivers as
every other IDE device. The biggest difference is that my DOM device is
tiny (16MB) compared to regular hard drives.

The device I’m using is manufactured by PQI <> http://www.pqi.com.tw> >.
I’ve looked at all their datasheets and other documentation and they all
talk about the device as if it were any other IDE device.

I have learned a few other things in the past couple days (all through
various experimentation). Notably, if I repartition the device and put a
QNX filesystem on it using fdisk and dinit in the standard fashion (upon
which I will elaborate if that helps clear thing up), the filesystem
looks good (i.e. chkfsys is happy). If I then reboot the machine, with
the ‘shutdown’ command for example, chkfsys finds a bunch of errors on
the disk after the system reboots.

Further, if I re-run chkfsys after it rewrites the “fixed” bitmap, it
continues to find one error consistently AND reports that the NEW bitmap
is equal to the OLD bitmap. I don’t understand that at all.

Is there something I need to do to accomodate the fact that the device
is small compared to a regular hard disk? Or for the fact that it is
slow compared to a hard disk? The boot image I’m using is the same image
which works fine when installed on CompactFlash.

What do you suggest?

Thanks in advance,
Eric

[Eric_Berdahl]

In article <9noa5b$od8$2@nntp.qnx.com>,
Hardware Support Account <hw@qnx.com> wrote:

Interesting. I am going to see about ordering one of these things
for our testing group.

They are quite interesting when they work. My colleagues overseas speak
very highly of them. Of course, they do most of their work with DOS.
This is the first time we’ve tried booting QNX RTOS with the sucker.

But in the mean time I am still going to see
if I can figure out anything.

Rock on.

Can you upgrade to the lastest version
of the OS (6.1) and see if the problems still exists?

In a word, no. I can’t update the system on which I am testing the DOM
module because we are still qualifying the 6.1 toolset for our product.
The only other QNX machine I have available is doing that qualification.

I thought I could install 6.1 on a second partition on my hard disk.
Unfortunately, the QNX installer will only install onto the 79 partition
for some reason which escapes reasoning. [Side note: I have perfectly
valid 77 and 78 partitions. Why won’t the installer let me install
there? This seems utterly stupid.]

That said, we have used the 6.1 tools (fdisk and dinit) to initialize
the disk. In that process, we discovered that dinit was putting the
floppy loader onto the device instead of the hard disk loader. I’m
guessing that a something similar to the old dinit-CompactFlash bug is
at work here. However, we used “dinit -B…” to force using the
non-floppy loader.

The end result was no difference. When the device boots, we get the “QNX
Loader” message, the “Press esc for…” message, a bunch of little dots,
and then nothing.

Further, I have yet to see a DOM device survive a reboot without
corrupting the file system. If I take a “dd” snapshot of the device just
prior to “shutdown” (and after a few "sync"s, just to be paranoid), and
take a “dd” snapshot of the device just after the system reboots, the
snapshots are always different. Could something in the devb-eide be
responsible for that (not accusing, just asking)?

[Issam_Haddad]

We experience very similar behavior with devb-eide and a Compact Flash on
our ppc embedded target. The situation is a lot better with 6.1, but we
still get “corrupt file system” messages once out of every 5 or 6 times
devb-eide is loaded. I suspect it might be the io-blk driver. Of course,
we’re even not attempting to use it as a boot device, for obvious reasons.

“Eric Berdahl” <berdahl@intelligentparadigm.com> wrote in message
news:berdahl-B0130F.18255413092001@nntp.qnx.com…

In article <9noa5b$od8$> 2@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Interesting. I am going to see about ordering one of these things
for our testing group.

They are quite interesting when they work. My colleagues overseas speak
very highly of them. Of course, they do most of their work with DOS.
This is the first time we’ve tried booting QNX RTOS with the sucker.

But in the mean time I am still going to see
if I can figure out anything.

Rock on.

Can you upgrade to the lastest version
of the OS (6.1) and see if the problems still exists?

In a word, no. I can’t update the system on which I am testing the DOM
module because we are still qualifying the 6.1 toolset for our product.
The only other QNX machine I have available is doing that qualification.

I thought I could install 6.1 on a second partition on my hard disk.
Unfortunately, the QNX installer will only install onto the 79 partition
for some reason which escapes reasoning. [Side note: I have perfectly
valid 77 and 78 partitions. Why won’t the installer let me install
there? This seems utterly stupid.]

That said, we have used the 6.1 tools (fdisk and dinit) to initialize
the disk. In that process, we discovered that dinit was putting the
floppy loader onto the device instead of the hard disk loader. I’m
guessing that a something similar to the old dinit-CompactFlash bug is
at work here. However, we used “dinit -B…” to force using the
non-floppy loader.

The end result was no difference. When the device boots, we get the “QNX
Loader” message, the “Press esc for…” message, a bunch of little dots,
and then nothing.

Further, I have yet to see a DOM device survive a reboot without
corrupting the file system. If I take a “dd” snapshot of the device just
prior to “shutdown” (and after a few "sync"s, just to be paranoid), and
take a “dd” snapshot of the device just after the system reboots, the
snapshots are always different. Could something in the devb-eide be
responsible for that (not accusing, just asking)?

[Hardware_Support_Acc]

Hi Eric,

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

See if that helps. Please let us know how it turns out.

Thanks

Erick.


Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

In article <9noa5b$od8$> 2@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Interesting. I am going to see about ordering one of these things
for our testing group.

They are quite interesting when they work. My colleagues overseas speak
very highly of them. Of course, they do most of their work with DOS.
This is the first time we’ve tried booting QNX RTOS with the sucker.

But in the mean time I am still going to see
if I can figure out anything.

Rock on.

Can you upgrade to the lastest version
of the OS (6.1) and see if the problems still exists?

In a word, no. I can’t update the system on which I am testing the DOM
module because we are still qualifying the 6.1 toolset for our product.
The only other QNX machine I have available is doing that qualification.

I thought I could install 6.1 on a second partition on my hard disk.
Unfortunately, the QNX installer will only install onto the 79 partition
for some reason which escapes reasoning. [Side note: I have perfectly
valid 77 and 78 partitions. Why won’t the installer let me install
there? This seems utterly stupid.]

That said, we have used the 6.1 tools (fdisk and dinit) to initialize
the disk. In that process, we discovered that dinit was putting the
floppy loader onto the device instead of the hard disk loader. I’m
guessing that a something similar to the old dinit-CompactFlash bug is
at work here. However, we used “dinit -B…” to force using the
non-floppy loader.

The end result was no difference. When the device boots, we get the “QNX
Loader” message, the “Press esc for…” message, a bunch of little dots,
and then nothing.

Further, I have yet to see a DOM device survive a reboot without
corrupting the file system. If I take a “dd” snapshot of the device just
prior to “shutdown” (and after a few "sync"s, just to be paranoid), and
take a “dd” snapshot of the device just after the system reboots, the
snapshots are always different. Could something in the devb-eide be
responsible for that (not accusing, just asking)?

[Hardware_Support_Acc]

Hi Eric,

Also another few things to try:

When creating the partition, try creating it 1 block smaller than the entire disk.
or better yet try 1/2 the size of the disk and see if that still exibits the problem.

Is DMA running on the DOM? If so try turning it off in the BIOS and make certain that
the eide driver doesn’t start DMA.

What happens if you init the DOM, then copy a file to it, then copy the exact same file
back. Is there a difference in the size of the file? or anything else (try diff).

Thanks

Erick.



Hardware Support Account <hw@qnx.com> wrote:

Hi Eric,

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

See if that helps. Please let us know how it turns out.

Thanks

Erick.



Eric Berdahl <> berdahl@intelligentparadigm.com> > wrote:
In article <9noa5b$od8$> 2@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Interesting. I am going to see about ordering one of these things
for our testing group.

They are quite interesting when they work. My colleagues overseas speak
very highly of them. Of course, they do most of their work with DOS.
This is the first time we’ve tried booting QNX RTOS with the sucker.

But in the mean time I am still going to see
if I can figure out anything.

Rock on.

Can you upgrade to the lastest version
of the OS (6.1) and see if the problems still exists?

In a word, no. I can’t update the system on which I am testing the DOM
module because we are still qualifying the 6.1 toolset for our product.
The only other QNX machine I have available is doing that qualification.

I thought I could install 6.1 on a second partition on my hard disk.
Unfortunately, the QNX installer will only install onto the 79 partition
for some reason which escapes reasoning. [Side note: I have perfectly
valid 77 and 78 partitions. Why won’t the installer let me install
there? This seems utterly stupid.]

That said, we have used the 6.1 tools (fdisk and dinit) to initialize
the disk. In that process, we discovered that dinit was putting the
floppy loader onto the device instead of the hard disk loader. I’m
guessing that a something similar to the old dinit-CompactFlash bug is
at work here. However, we used “dinit -B…” to force using the
non-floppy loader.

The end result was no difference. When the device boots, we get the “QNX
Loader” message, the “Press esc for…” message, a bunch of little dots,
and then nothing.

Further, I have yet to see a DOM device survive a reboot without
corrupting the file system. If I take a “dd” snapshot of the device just
prior to “shutdown” (and after a few "sync"s, just to be paranoid), and
take a “dd” snapshot of the device just after the system reboots, the
snapshots are always different. Could something in the devb-eide be
responsible for that (not accusing, just asking)?

[Eric_Berdahl]

Hi Erick,

In article <9nt2su$pq1$1@nntp.qnx.com>,
Hardware Support Account <hw@qnx.com> wrote:

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

I am both dos- and windows-challenged. However, I do have a QNX4
partition I can boot. Are you suggesting that I boot into QNX4, and run
makedisk on the DOM with your cf_dsk.nto image?

[Hardware_Support_Acc]

Hi Eric,

Actually if you have a QNX4 system, then try using the dinit from that to init
the disk and then take it to your QNX 6 system and put the OS and the rest on
it there. I just want to see if dinit is messing up the DOM.

Thanks

E.


Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

Hi Erick,

In article <9nt2su$pq1$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

I am both dos- and windows-challenged. However, I do have a QNX4
partition I can boot. Are you suggesting that I boot into QNX4, and run
makedisk on the DOM with your cf_dsk.nto image?

[John_Bowen]

I’m in the same boat here! I have a CompactFlash system that needs the QNX4
bootloader tweak applied to it. I know how to fix it, but I can’t find the
QNX4 boot floppy image anywhere. In addition, when I try to go to the
~emuis link below, I get an “You are not authorized to view this page” error
in my browser. Is there someplace else I can get it?

Thanks!
John

“Hardware Support Account” <hw@qnx.com> wrote in message
news:9o59cl$s8c$1@nntp.qnx.com…

Hi Eric,

Actually if you have a QNX4 system, then try using the dinit from that to
init
the disk and then take it to your QNX 6 system and put the OS and the rest
on
it there. I just want to see if dinit is messing up the DOM.

Thanks

E.


Eric Berdahl <> berdahl@intelligentparadigm.com> > wrote:
Hi Erick,

In article <9nt2su$pq1$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the
destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

I am both dos- and windows-challenged. However, I do have a QNX4
partition I can boot. Are you suggesting that I boot into QNX4, and run
makedisk on the DOM with your cf_dsk.nto image?

[Hardware_Support_Acc]

Hi John,

Goto http://www.geocities.com/erickmuis/files/nto/

There is a file called cf_dsk.zip

Download it, then download this:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Then on a Windows based system, format a floppy then use makedisk
with the uncompressed image (uncompress the .zip).

Then boot the floppy on the system with the CF. Fsys.eide and dinit
are located on the floppy image.

Erick.



John Bowen <John.Bowen@grc.nasa.gov> wrote:

I’m in the same boat here! I have a CompactFlash system that needs the QNX4
bootloader tweak applied to it. I know how to fix it, but I can’t find the
QNX4 boot floppy image anywhere. In addition, when I try to go to the
~emuis link below, I get an “You are not authorized to view this page” error
in my browser. Is there someplace else I can get it?

Thanks!
John

“Hardware Support Account” <> hw@qnx.com> > wrote in message
news:9o59cl$s8c$> 1@nntp.qnx.com> …
Hi Eric,

Actually if you have a QNX4 system, then try using the dinit from that to
init
the disk and then take it to your QNX 6 system and put the OS and the rest
on
it there. I just want to see if dinit is messing up the DOM.

Thanks

E.


Eric Berdahl <> berdahl@intelligentparadigm.com> > wrote:
Hi Erick,

In article <9nt2su$pq1$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the
destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

I am both dos- and windows-challenged. However, I do have a QNX4
partition I can boot. Are you suggesting that I boot into QNX4, and run
makedisk on the DOM with your cf_dsk.nto image?

[John_Bowen]

Thanks!
“Hardware Support Account” <hw@qnx.com> wrote in message
news:9odaqo$1k8$3@nntp.qnx.com…

Hi John,

Goto > http://www.geocities.com/erickmuis/files/nto/

There is a file called cf_dsk.zip

Download it, then download this:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Then on a Windows based system, format a floppy then use makedisk
with the uncompressed image (uncompress the .zip).

Then boot the floppy on the system with the CF. Fsys.eide and dinit
are located on the floppy image.

Erick.



John Bowen <> John.Bowen@grc.nasa.gov> > wrote:
I’m in the same boat here! I have a CompactFlash system that needs the
QNX4
bootloader tweak applied to it. I know how to fix it, but I can’t find
the
QNX4 boot floppy image anywhere. In addition, when I try to go to the
~emuis link below, I get an “You are not authorized to view this page”
error
in my browser. Is there someplace else I can get it?

Thanks!
John

“Hardware Support Account” <> hw@qnx.com> > wrote in message
news:9o59cl$s8c$> 1@nntp.qnx.com> …
Hi Eric,

Actually if you have a QNX4 system, then try using the dinit from that
to
init
the disk and then take it to your QNX 6 system and put the OS and the
rest
on
it there. I just want to see if dinit is messing up the DOM.

Thanks

E.


Eric Berdahl <> berdahl@intelligentparadigm.com> > wrote:
Hi Erick,

In article <9nt2su$pq1$> 1@nntp.qnx.com> >,
Hardware Support Account <> hw@qnx.com> > wrote:

Could you try the following:

On my home site

http://staff.qnx.com/~emuis/files/nto/

There is a file called “cf_dsk.nto”. Download this on a
Windows based system. Then using the makedisk util:

http://quics.qnx.com/cgi-bin/search/usr/free/?srch=makedisk&select=1

Use a dos formatted floppy, then run the makedisk util with the
destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

Then boot your QNX 6.0 box and put on the data that you did before
(don’t init the DOM now though).

I am both dos- and windows-challenged. However, I do have a QNX4
partition I can boot. Are you suggesting that I boot into QNX4, and
run
makedisk on the DOM with your cf_dsk.nto image?

[Eric_Berdahl]

Hi Erick,

Sorry for the long pause in this thread. I’ve been tied up with a few
details (shipping a release, etc) and just recently got back to my DOM
experiments.

Could you try the following:
[snip]
Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

As I mentioned in my previous response to this thread, I do not run
either DOS or Windows. So, that’s no good. I have a QNX4 system on one
partition, but it was installed when I was using a different machine and
I cannot get it to boot on the machine I now use, so that’s out.

Also another few things to try:

When creating the partition, try creating it 1 block smaller than the entire
disk.
or better yet try 1/2 the size of the disk and see if that still exibits the
problem.

Is DMA running on the DOM? If so try turning it off in the BIOS and make
certain that
the eide driver doesn’t start DMA.

What happens if you init the DOM, then copy a file to it, then copy the
exact same file
back. Is there a difference in the size of the file? or anything else (try
diff).

This I can do. In fact, I’ve been able to jury rig a 6.1 setup on my
test machine. Namely, I set up the DOM, master, and a CD-ROM, slave, on
the primary IDE bus and a CompactFlash on the secondary IDE bus. I boot
from a 6.1 CD in the CD-ROM drive. The software I eventually want to
install on the DOM lives on the CompactFlash.

With this setup, I ran 6.1’s fdisk on the DOM, making the partition 10
blocks smaller than the capacity of the DOM (the DOM has 500 blocks, I
made the partition 490 blocks). After restarting the system (from the CD
again), I ran 6.1’s dinit on the DOM. dinit told me it was using the
floppy loader, so I used ‘dinit -h -B /dev/hd0t77’
to initialize the DOM.

From that point, restarting the system no longer caused chkfsys to
report errors on the DOM.

I then installed my software, copying it from the CompactFlash to the
DOM. I double checked everything to make sure the software came over
correctly (including the all-important .boot file). When I boot from the
DOM, I now get different behavior from before, although it still doesn’t
boot properly:

Boot Partition 4 ? 4
Hit Esc for .altboot…[lots of periods]

After this point, the system spontaneously reboots. Previously, the
system just hung here.

After three or four iterations of print-reboot, print-reboot. I got a
new message after the periods:

could not allocate 0xe1d180d8 bytes for syspage/cpupage

That seems like an excessive amount of memory to allocate (particularly
since there’s only 64MB RAM in this little tyke).

I don’t know whether to call this an improvement or not. It’s still not
working, but we’re getting different, possibly more traceable, behavior.
Where shall we go from here?

Thanks in advance.

Regards,
Eric

[Hardware_Support_Acc]

Hi Eric,

Thanks for the info. Just wondering, was DMA turned off in the BIOS,
and on the driver in the OS image?

Thanks

Erick.



Eric Berdahl <berdahl@intelligentparadigm.com> wrote:

Hi Erick,

Sorry for the long pause in this thread. I’ve been tied up with a few
details (shipping a release, etc) and just recently got back to my DOM
experiments.

Could you try the following:
[snip]
Use a dos formatted floppy, then run the makedisk util with the destination
drive and the file “cf_dsk.nto”.

Then using that disk boot a system and use the driver Fsys.eide and
the dinit util on the disk to dinit the DOM.

OR

If you have a QNX4 system handy you can use that instead.

As I mentioned in my previous response to this thread, I do not run
either DOS or Windows. So, that’s no good. I have a QNX4 system on one
partition, but it was installed when I was using a different machine and
I cannot get it to boot on the machine I now use, so that’s out.

Also another few things to try:

When creating the partition, try creating it 1 block smaller than the entire
disk.
or better yet try 1/2 the size of the disk and see if that still exibits the
problem.

Is DMA running on the DOM? If so try turning it off in the BIOS and make
certain that
the eide driver doesn’t start DMA.

What happens if you init the DOM, then copy a file to it, then copy the
exact same file
back. Is there a difference in the size of the file? or anything else (try
diff).

This I can do. In fact, I’ve been able to jury rig a 6.1 setup on my
test machine. Namely, I set up the DOM, master, and a CD-ROM, slave, on
the primary IDE bus and a CompactFlash on the secondary IDE bus. I boot
from a 6.1 CD in the CD-ROM drive. The software I eventually want to
install on the DOM lives on the CompactFlash.

With this setup, I ran 6.1’s fdisk on the DOM, making the partition 10
blocks smaller than the capacity of the DOM (the DOM has 500 blocks, I
made the partition 490 blocks). After restarting the system (from the CD
again), I ran 6.1’s dinit on the DOM. dinit told me it was using the
floppy loader, so I used ‘dinit -h -B /dev/hd0t77’
to initialize the DOM.

From that point, restarting the system no longer caused chkfsys to
report errors on the DOM.

I then installed my software, copying it from the CompactFlash to the
DOM. I double checked everything to make sure the software came over
correctly (including the all-important .boot file). When I boot from the
DOM, I now get different behavior from before, although it still doesn’t
boot properly:

Boot Partition 4 ? 4
Hit Esc for .altboot…[lots of periods]

After this point, the system spontaneously reboots. Previously, the
system just hung here.

After three or four iterations of print-reboot, print-reboot. I got a
new message after the periods:

could not allocate 0xe1d180d8 bytes for syspage/cpupage

That seems like an excessive amount of memory to allocate (particularly
since there’s only 64MB RAM in this little tyke).

I don’t know whether to call this an improvement or not. It’s still not
working, but we’re getting different, possibly more traceable, behavior.
Where shall we go from here?

Thanks in advance.

Regards,
Eric

[Eric_Berdahl]

Hi Erick,

Thanks for the info.

No charge. Thanks for all your help. I appreciate your efforts to help
debug this from a distance.

Just wondering, was DMA turned off in the BIOS,
and on the driver in the OS image?

I have not turned off DMA from the BIOS.

The image on the DOM typcially starts devb-eide without specifying
anything for dma on the eide bus. So, I use the devb-eide default.
However, I put a display_msg at the very top of the startup script (i.e.
before devb-eide starts). That message never prints out, so I presume
that devb-eide isn’t getting started either.

As for the state of the eide bus at the time the DOM is being written, I
use a stock RTP installation. So, whatever that default image uses for a
dma setting is what’s in force.

Does this give you ideas for other things to try?

Regards,
Eric