Dave,
I am able to connect a floppy drive to do the initial “download” to the
system. If I boot from a dos floppy, I can see the pseudo floppy drive as my
B: drive, and use loadqnx.sys in the config.sys file to start the ifs file I
copy to the drive. This limits the ifs file to about 1.2Mb, but all I have
to do is copy the new file to the drive to change it, no formatting, or
anything like that.
I got qnet to work after asking the right questions, and looking over some
example code. That is working out fine for testing intermediate versions of
the code (writing to the 32Mb flash IDE drive we have for development). It
just doesn’t help me with the option to update the pseudo floppy drive while
I am running QNX.
Unfortunately, I can’t see the pseudo drive from QNX at all. That makes it
hard to update the image while I am running QNX. The documentation for the
Prometheous card says that this is the remainder of a 2Mb flash and 512K of
it is used for BIOS, the rest is managed by BIOS to emulate a floppy drive.
Does anyone know how I would access this under QNX. I assume BIOS is dead
and gone by then, or is there a qnx driver that wraps around BIOS calls for
floppy access??
It could be rather tricky if I try to access the area with the flash file
system under Qnx, and a FAT12 file system on bootup or from DOS, so I am not
sure if I really want to try this. I am also concerned about blowing away
the BIOS if I set the flash filesystem parameters wrong.
Thanks,
John Eddy
“Dave Edwards” <Dave.edwards@abicom-international.com> wrote in message
news:3EBF8F3C.6020709@abicom-international.com…
Hi John,
Another way that we tackled this problem was to write a mini file
loader. This would accept Srecord Images and download them into memory,
once loaded, another routing would then burn the image into flash.
I guess that the question here is if you have a file system available
for download. If not then the mini loader approach would probably work.
You would use mkifs to generate an os image, then convert it to srecord
format.
Once done, sent it to the target and burn it into the appropriate
location.
The other option would be to have a look at the image_download_8250
function written by QNX. I’ve also used this as part of the initial
bootstrap to allow an OS image to be loaded onto the board.
Regards
Dave
John Eddy wrote:
Dave,
I seem to recall way back in my pdp-11 days, using kermit to get data
over
to a laptop running dos 5 from a system running RT-11, but it has been
quite
a while since I messed with it.
I am using a Prometheus PC-104 card from Diamond systems. It is a 486
DX2
100 pc compatable SBC with built in 16 channel analog inputs, 4 channel
analog outputs, 24 digital IO lines, one 16 bit counter, one 24 bit
counter,
4 serial ports, ethernet (ns83815), 2 usb, 1 parallel, kbd, mouse.
I am also exploring ethernet as a possiblity, but I was hoping for
something
with a much smaller footprint for transferring files to the system. It’s
final configuration will be to boot from a built in pseudo floppy
(really
leftover flash memory after end of bios, handled by bios code) drive
with
1.44 Mb of space. This floppy is visible to bios and dos, but not to
QNX, so
everything will need to be in the boot image.
Thanks,
John
“Dave Edwards” <> Dave.edwards@abicom-international.com> > wrote in message
news:> 3EB1338D.6040602@abicom-international.com> …
Have you thought about using Kermit?
I had a similar problem a while back and had the same problems as you
with qcp.
If you have a look at C-Kermit Version 6.0, I beleieve that it does not
have the networking implemented and hence is smallish in size.
What platform/processor are you working with? I might have a copy of it
lying around here.
Best regards
Dave
John Eddy wrote:
I just found out that qcp is not working in 6.2.1 release.
Now, the question is… what are my alternatives?
Way back in the qnx2 / qnx4 days, I would just have used sz or rz
automatically, but are they still available??
What package would they be in on the 3rd party disk, or where can I
download
them??
I am still working on trying to get the networking up on the embedded
box,
but no luck yet.
Thanks,
John Eddy
\