Has anyone tried the following method before. Below are the instructions from “BSP User Guide
Generic x86 BIOS and APIC”. The issues are, I could not get the usb to boot. The IFS is not executed because screen was simply blank. Any comments would be appreciated.
Build and install the BSP (off-line method using host tools)
To boot QNX Neutrino RTOS 6.6 on your x86 target, you must prepare a bootable USB
device.
Create a bootable USB device
To use the offline method with host tools to create a bootable USB device, you must
have the following patch: patch-660-3885-diskimage.tar.
The steps for creating a bootable USB device using the offline method with host tools
are as follows:
Change directory into the BSP’s ${BSP_ROOT_DIR}/images directory. If you are
in the BSP root directory:
cd images
Create a plain text file root.build file to describe the root file system contents
for your USB disk image. This file should have the following contents:
[num_sectors=524288]
.boot/ifs-x86-generic.bin=ifs-x86-generic.bin
Create the QNX6 partition image:
mkxfs -t qnx6fsimg root.build partition.img
Create a plain text file disk.cfg with the following contents that describe the
partition layout of your USB disk image:
[heads=64]
[sectors_per_track=32]
[sector_size=512]
[cylinders=513]
[start_at_cylinder=1]
[partition=1 type=177 num_sectors=524288 boot=true]
“partition.img”
Create the USB disk image:
diskimage -o usb.img -c disk.cfg -b
$QNX_TARGET/x86/boot/sys/ipl-diskpc1
$QNX_TARGET is set for a Linux host. If you are using a Windows host,
either use bash or change $QNX_TARGET to use Windows syntax.
It is due to issue of my Notebook computer.
The loaded IFS is not or can not execute after it is being loaded onto the RAM location. Don’t know what causes it. However, the same USBstick works on other notebook computer.
The one works is 32-bit system; the one does not work is 64-bit. Can’t really compare BIOS settings of two machine because they are different, and different manufacturers. However, the BIOS for user like is mainly to set it to boot from USB.
The messages shown on the screen said that the IFS has been loaded and control being transferred to it. However, immeidately after the control transfer, the system reset and back to loading up the IFS, and reset in endless cycle.
I could think of the possibility of corrupted memory due to the loaded memory locations may be used by some internal system, like the integrated graphic RAM and others. Hence, I changed the memory location to 0x400, 4m, 256m, 1024m, etc. Nothing positive so far. I am using ASUS Vivobook model S550CM.
QNX supports the I5 processor which is what’s in your machine.
Are you sure that patch-660-3885-diskimage.tar is the right BSP for your hardware?
This is the link I found for your machine but I have no idea whether the hardware for this machine (hybrid drive, video card etc, touch screen input etc) is supported
QNX supports the I5 processor which is what’s in your machine.
Yes, you are right.
Are you sure that patch-660-3885-diskimage.tar is the right BSP for your hardware?
this is what it says for running x86-generic BSP for SDP 6.60.
In addition, with the same USBstick, I could run on other notebook.
This is the link I found for your machine but I have no idea whether the hardware for this machine (hybrid drive, video card etc, touch screen input etc) is supported notebookcheck.net/Review-Asu … 830.0.html
QNX official website does not mention anything about the peripheral, but only the processor. Hence, this question is really a grey area, isn’t it. I am a bit disappointed because I had tried to avoid incompatibility issues and had done very extensive research. And found out that there is much information except the processor supported lists especially things related in Intel processors. Now I see very little I could do with the notebook computer.
What’s in the BSP boot image (ie what drivers is QNX trying to start).
It’s good to see you aren’t starting too many things in the boot image. That should help track things down faster.
I assume when you entered io-usb-v6-hc that you meant io-pkt-v6-hc.
Can you add some display messages during the boot process to help diagnose where things are going wrong. What you want to do is add in display_msg “Some Text” as I have shown below.
[+script] startup-script = {
# To save memory make everyone use the libc in the boot image!
# For speed (less symbolic lookups) we point to libc.so.2 instead of libc.so
procmgr_symlink ../../proc/boot/libc.so.2 /usr/lib/ldqnx.so.2
# Default user programs to priorty 10, other scheduler (pri=10o)
display_msg "Starting pci_bios"
[pri=10o] PATH=/proc/boot pci-bios &
# Disk Driver
display_msg "Starting eide driver"
devb-eide eide noslave blk cache=2m,automount=hd0t79:/ &
# Wait until the disk manifests itself
display_msg "waiting for drive to mount"
waitfor /x86 10
# Some common servers and drivers (serial)
display_msg "Starting some drivers"
devc-ser8250 -u1 3f8,4 2f8,3 -u3 3e8,11 -u4 2e8,10 &
}
Essentially you want a display_msg before each item that you are starting. That will show which one the boot process is getting hung up on.
Before the boot-script, I believe the IFS would run from the specified memory location which is in my case at 0x400 (see below). From the screen-shot, it shows that the IFS had been loaded, and transfer the control to the IFS at 0x400. However, nothing happen after that. I can not tell if the startup-bios failed, or the bios of [virtual=x86, bios] failed mainly because nothing was being displayed and it went on with system reset.
Would it possible it caused by 64-bit architecture?
[image=0x400]
[virtual=x86,bios] boot = {
This build file uses startup-bios by default; if you wish to use startup-apic instead, comment out the following line, and uncomment the one below it
startup-bios -vvv
# startup-apic -v # if you uncomment this line, be sure to also uncomment the line linking pci-bios to pci-bios-v2, in the 'data=c' section below
PATH=/proc/boot:/bin:/usr/bin:/opt/bin/sbin:/usr/sbin LD_LIBRARY_PATH=/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib procnto-smp-instr -v
Looking at your screen shot I agree the IPL ran fine and began transferring the IFS image to memory. Whether it completed it and transferred control to startup-bios we can’t tell.
This is a real long shot but on your “startup-bios -vvv” line can you add ‘-K console’. That tells startup-bios that Kernel debugging messages go to the screen instead of the serial port. That may give more information or at least let you know if the boot process is reaching procnto-smp-instr.
Do you have more than 4 Gigs of Ram on this Notebook (vs the other one)? There is a -x option for that or there are other options to limit the RAM available to QNX to a certain size.
Without knowing if the crash is in startup-bios or procnto-smp-instr it’s impossible to say anything about 64 bit architecture being an issue. To me it’s far more likely the problem occurs in startup-bios when the code is trying to get hardware info from the BIOS. That’s where BSP’s provide custom startup-? files for the BIOS of the BSP.
This is a real long shot but on your “startup-bios -vvv” line can you add ‘-K console’.
tried this with
startup-bios -K console
The same outcome, which system got reset after control transfer.
Do you have more than 4 Gigs of Ram on this Notebook (vs the other one)?
Yes, I have 8Gig RAM in it.
There is a -x option for that or there are other options to limit the RAM available to QNX to a certain size.
I am not sure where to put the -x option. I tried to search for the memory options things, but not getting anything back from google. Hence, I simply add it to
startup-bios -K console -x
Re-made that. Unfortunately, the same outcome as well.
If there is another one I can’t find any mention of it nor does QNX seem to publish a list of supported chipsets anywhere. You can try asking on Foundry 27 (QNX forums there) about this chipset.
Tim
P.S. One way to confirm it’s a chipset issue is to build an image using a nobios boot option and see if that starts.
There are a few version of Vivobook S550CM. The one I own is notebookcheck.net/Review-Asu … 830.0.html. Processor i5-3371 is of Ivy-bridge( 3rd generation ) which QNX says it supports in x86-generic BSP.
Would you elaborate the booting process without BIOS, please? Did you mean not to include the startup-bios binary into the system image?
Help me to understand this please. Upon power-up BIOS of PC would be invoked to init and set the peripherals, RAM etc. With that QNX IPL is then read form USB (in our case) and place it in RAM, and then control transfer to the IPL. The IPL then reads the IFS onto RAM and and transfer control to IFS. IFS consists of boot file and script. From the screen shot, the IPL was working fine, and reading the IFS, the control is then transferred to boot file which fails at the moment. However, we could not know if the IFS itself or the boot-file is failing.
I have removed 4GB RAM and left 4GB in the Notebook computer. Re-ran QNX from the USBStick. However, the outcome is still the same. Tried with another USBStick, similar outcome. Unfortunately, my Eval key has expired. Hence can’t compile the code now.
I have found that the integrated graphic card RAM can be configure from 64M - 512MB. However, I don’t really know where those memory locations are mapped onto RAM. Does anyone know ?