6.41 is very close in functionality to 6.5. All the QNX 6’s to my knowledge used a convention that startup files were in /etc/rc.d. Files in this directory were all prefixed by pr. The main script file was rc.sysinit. rc.local was the intended place that you put local commands so that if you upgraded the system, it would not be overwritten.
Note I said by convention. There is no reason that someone configuring a system, especially an embedded system needs to use this convention. Here are the startup steps that occur in booting QNX 6 from a hard drive.
The bios reads in the first second which is a partition loader and jumps into it. The code uses the bios to read the disk and looks for the active partition and then loads the first sector of this partition and jumps to it. It also throws up a option to choose a different partition. That’s if you are using the QNX loader.
The partition loader looks in the partition for a file .boot or a directory .boot. In the later case things get a little more complicated but basically a boot file is loaded into memory and jumped to.
The system is initialized. The steps involved are documented, but basically the kernel is started and it starts running script. The residue of the script can be dumped from directory /proc/boot. By convention at the end of that script a disk driver has been loaded, the QNX partition has been mounted and the script /etc/rc.d/rc.sysinit is started.
The end of step 3 is where your problem is. If you don’t have the boot build file you don’t know what is happening. It would be challenging for a novice to figure out. If another script is run then that is what you need to update. It is possible that the entire startup is all within the .boot file in which case you would need to update the build file, which you might not have, rebuild it and copy it into place. These are things you should not attempt unless you know what you are doing.
A good suggestion, but I don’t think so. net.cfg is maintained by a Photon GUI program called phlip. You can edit the file yourself. Looking at the window phlip puts up I can see that you can add additional IP’s to the gateway in the like listed as “route” but there isn’t anything to set up a specific route.
My issue is that I don’t know the Syntax to add. I don’t have access to use Phlip. So if anyone could let me know what would be added into that file, it would be great.
I would think that Gateway would be 192.168.2.1 / Destination would be 1.2.3.4 / and Netmask would be 255.255.255.255. And then if someone did an add, what would it add to that file?
suggests you can add the routes to net.cfg and the netmanager will pick them up. That implies that netmanger was used to configure TCPIP (it only runs once then exits so we can’t know if it was used but its quite likely it was).
Your system runs on PPC, this means it is not a PC based system. So the boot process is different than the one explained by maschoen.
Do you have knowledge of the hardware ? Do you know which peripheral it boots from (SDcard, FLASH memory…) ?
More importantly, do you have the BSP sources for your hardware ?
I know that it boots from flash. But I don’t have much knowledge of the inter-workings of the hardware itself and how it was programmed at this level. So no BSP resources.
I am most familiar with the application that it running on the hardware which is for building automation. The static routing function isn’t something that is supported in their GUI/programming tools.
There is a need for this functionality. I am just trying to accomplish a solution that is outside of the software that is running on the device.
If the device boots from flash there may not even be any writable medium (hard disk, CF card etc). How big is the physical device and do you know if it has a writable medium. If it doesn’t there is NO way you will be able to modify routes in a permanent manner.
If you can’t open the device or judge by it’s size whether it has writable medium then can you try doing a ‘df’ command and see what it reports for disks. It’s entirely possible there is nothing but flash memory that contains a bootable QNX image (which essentially can’t be modified).
On embedded systems, most of the time, there is an in-RAM file system initialised at startup. This file system is populated with the content of the QNX image created with BSP tools. So, you get a writeable file system that is reinitialised at each boot.
It looks like you get a “Flash File System” on your machine.
To go further, can you send me the content of /proc/boot/.scritp file in a private message ?
Copy/paste will not work as this is a binary file (with text inside).
This script file is executed at startup. Decoding it will show what’s executed at startup. Maybe another writeable script file is executed from it.
Beware that this file can contain private data so you might not want to share it.
procmgr_symlink ../../proc/boot/libc.so.3 /usr/lib/ldqnx.so.2
optslotscan
dbgjmpr
reopen /dev/serconsole
display_msg Welcome to QNX Neutrino 6.4 on the NPM 2xx (ppc405)
ksh /sys/bin/rc.local
ksh /sys/bin/tinit &
In order of execution :
The fisrt line is always there in .script files. : libc.so.3 is redirected to ldqnx.so.2
optslotscan and dbgjmpr are executed.
Standard input, standard output, and standard error are redirected to /dev/serconsole
Display the Welcome message
Execute /sys/bin/rc.local through ksh
Execute /sys/bin/tinit through ksh in background
ksh refers to /proc/boot/ksh
optslotscan and dbgjmpr are executed with no environment variables defined.
/sys/bin/rc.local and /sys/bin/tinit are executed with the following environment variables :
SYSNAME=nto
TERM=qansi
HOME=/
PATH=:/proc/boot:/bin:/usr/bin:/opt/bin:/sys/bin:
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll:/opt/lib: