I had made USB stick bootable in QNX6.3 initially, but when I reformatted and try to create it again using the same method, now the USB stick doesn’t boot? It says
Boot Partition 1 ? 1
Missing Operating System
I used fdisk to create partition and make it bootable and put the loader. I haven’t used dloader. It seems like maybe the boot image is not getting loaded to the correct area?
this is what I did.
fdisk /dev/hd0 delete -a
fdisk /dev/dh0 add -t79 -p100
mount -e /dev/hd0
dinit -h -q /dev/hd0t79
mount /dev/hd0t79 /usb
cp usbboot.ifs /usb/.boot
fdisk /dev/hd0 boot -s1 -t79
fdisk /dev/hd0 loader
I now have another issue. Why is it that running my software from USB stick is about 3times slower when compared to running it from IDE memory stick? I know that it depends on the software, but in general if there is no disk write shouldn’t be similar? Is caching automatic in usb stick? how can I control the cach size? When running QNX from USB memory stick it seems like there is a bit of hasitation when system stays idle and then tries to do something, the responds is not that good. Any ways to improve the performance in running QNX under USB stick?
What I meant by IDE memory stick was using devices like DiskOnModule (solid state disk). I am running QNX with either solid state disk with eide driver or USB memory stick. I think my hardware supports USB 2.0 but somehow I feel that the QNX driver is running it with USB 1.1. Is there a way to force the driver to run in USB 2.0? In general the software does some db read and write to disk but at a very low frequency (once a sec maybe). But during execution, it does some dynamic linking and loading of .so (dlls). along with 2ms interrupt servicing to SERCOS and 2ms software timer to service frame grabber. With eide, the run time of one execution is about 300ms where as running the same code it takes 900ms to 1s in USB stick.
Generally the performance of flash is such that writes are considerably slower than reads. This is tenable due to their market position as write-once read-often devices (MP3 players).
Having used compact flash devices in the past I can confirm that the large amount of writing that occurs during the linking procedure is the one of the slowest processes encountered when using flash memory.
The solution around this inherent limitation of the medium is to use static links.
It could also be inferred that the bottle-neck represented by the bandwidth of USB 1.1 is not going to be your limiting factor.
Furthermore the problem you are seeing here is most likely due to misinterpretations of the geometry of the disk. Try to determine the geometry (i.e. Cylinders, Heads, Sectors) from the BIOS and then specify the translation when you first load the device. This will allow the MBR to find the secondary loader despite using the geometry from the BIOS.
You are forced to reformat the device to ensure the the partitions are written in the correct geometric view of the device.
…translation if the “geometry” flag in the dev-eide drivers in QNX 6.3
I am using an Advantech box and the BIOS doesn’t provide the geometry information about the usb flash drive.
Also the dynamic linking only happens at the biginning of the system startup.
I am noticing some delays even in pterm when I type ‘ls’ command. It’s feels like I am running the system with CDROM where once the CD starts spinning it reacts quick, but if the interaction is on and off, I notice this delay.
Very often BIOS’s that provide USB booting have option how to interpret USB drive - FDD, HDD, etc (depending on device). As far as I understand this options affect on the geometry that BIOS will use for booting.
When creating USB boot disk you should do it on target system and after deleting all partitions ( fdisk /dev/hd0 delete -a or dd if=/dev/zero of=/dev/hd0 count=1 ) replug the USB device. Geometry that driver see can change after such operation.
Try plugging USB drive to different ports, your system can have different usb controllers. Also check if you are using correct library in QNX (devu-ehci.so).
If nothing will help I think you can create RAM drive and copy necessary files to it or even include key files in QNX image.