5.5. Practical use of the console system

5.5.1. Basic serial debug console
5.5.2. No console at all
5.5.3. Displaying a logo and boot abort

The practical applications of the console system may not be immediately apparent. The flexibility of the system allows for configurations in deployed solutions which meet the needs to the developer.

The following sections outline a few use cases from which a developer should be able to construct many functionalities. Some of these make use of the scripting capabilities which are described in Chapter 3, Command Line Interface.


It is possible to configure the console settings so no input or output can be made to the console! In this case the non volatile ignore jumper on the board should be used to recover the unit. This will cause the default “all” drivers to be used.

5.5.1. Basic serial debug console

In this scenario the requirement is to get a serial console on the first 16550 based serial port only. It should be configured to 9600 baud, eight data bits , no parity and a single stop bits.

This is achieved trivially by setting console.read and console.write to


Example 5.5. Setup of basic serial console

>nvshow console.write
console.write (is unset)
>nvshow console.read
console.read (is unset)
>nvset console.write (u16550_serial0,9600,8n1)
>nvshow console.write
console.write  = (u16550_serial0,9600,8n1)
>nvset console.read (u16550_serial0,9600,8n1)
>nvshow console.read
console.read  = (u16550_serial0,9600,8n1)
verifying written data...

5.5.2. No console at all

In this scenario no console output whatsoever is required. Generally this is only useful when a project has reached final production and a fixed OS image is being retrieved from reliable storage.

This is straightforward to achieve by using the “null” driver. Set the console.read and console.write variables to:


Be sure to set the boot.cmd and other boot variables to correctly boot your OS before setting this or you will need to recover the system with the physical non volatile ignore jumper.

As a precaution against loosing the console completely you can add a

console -a serial

to the end of the boot.cmd variable.

Example 5.6. Using the null drivers safely

This example shows how the addition of the console command can recover from a situation where otherwise the physical jumper would have to be accessed.

>nvset boot.cmd "(hd0)/nosuchkernel ; console -a serial"
>nvset boot.auto on
>nvset console.write null
>nvset console.read null
verifying written data...
Autoboot attempt 2, Press any key to abort
Autobooting in   6

Even using this technique it is easy to get a system into an unbootable state, because of this setting the consoles to null is generally inadvisable if another approach can be found.

5.5.3. Displaying a logo and boot abort

This scenario the console is required if user input is given at a specific point in the boot sequence after a boot logo is displayed.

This is a slightly more complex situation and the developer may decide to place this in a shell script rather than try and cram it all into a single boot.cmd line. The general solution is:

  • Set the console logging level to 0 to inhibit any other ABLE output

  • Use the display command to plot the image

  • Use the echo command to display the user message

  • Use the read command to wait for user input with a two second timeout

  • If the user input is the correct key to abort the boot process set a variable to indicate this

  • If the abort variable is unset start the OS

  • Set the console log level to something reasonable and start a shell

Example 5.7. A method to display logo and boot abort

display -d s3c2410x-video (tftpboot)logo.bmp.Z
echo -n "press c to enter ABLE"
read -t 2 -n 1 -s RES && [ $RES = "c" ] && ABORT=yes 
[ $ABORT = "no" ] && (hd0)kernel root=/dev/hdc1 console=ttySAC0,115200
console -s 6
sh -i

This script would be stored somewhere accessible to ABLE(flash, hard disc or network) and boot.cmd set to that location. Once verified, consoles could be configured as required and console.level set to 0.