Remove unnecessary debug printing

QNX SDP8.0Boot Optimization GuideDeveloper

Callouts in either the IPL or the startup program handle any debug printing that happens early in the system boot (before the serial driver is loaded).

These callout routines normally write directly to the registers of the first UART. However, no interrupts are available before the kernel has initialized, so if the UART FIFO is full, the callouts can't insert a character until another character leaves the FIFO. With a standard UART, a fast startup can become slow if you burden the boot process with too many messages.

To prevent this from occurring, follow these practices:
Comment out unneeded kprintf() statements
In IPL or Startup, look for unneeded kprintf() statements in main() and comment them out.
Reduce -v options
In the script block of the buildfile (boot script), find the line that launches the kernel (procnto-smp-instr) and reduce the -v options. For instance, if the line looks like this: 
PATH=:/proc/boot:/bin:/usr/bin
LD_LIBRARY_PATH=:/proc/boot:/lib:/usr/lib:/lib/dll procnto-smp-instr –vvvv
you can replace -vvvv with -v, or simply remove the option altogether.
Remove display_msg calls
In the boot script, remove any display_msg calls that use the startup callouts. These include all display_msg statements that occur before the following sequence: 
waitfor /dev/ser1
reopen /dev/ser1
These statements redirect the serial output to the newly loaded serial driver (typically right above the waitfor), which will be interrupt driven and won't need to wait.
Avoid a slow baud rate
Don't use a console baud rate of less than 115,200 unless you absolutely must. Otherwise, you may potentially execute longer in a loop in the kernel printf(), waiting for the UART FIFO to have enough space to send characters out.
Chances are, you won't do this, for the simple reason that it's inconveniently slow. But in systems with few UARTs, it's tempting to share a 9600-baud GPS device with the default serial console. If you do this and still have some serial debug output in the kernel or startup, you could end up severely throttling back the code to keep pace with the slow baud rate.
Page updated: