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. But before the kernel has initialized, no interrupts are available. 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) 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 –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 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.