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.
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
(u16550_serial0,9600,8n1)
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) >nvsave verifying written data... >
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:
null
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 >nvsave verifying written data... >reset 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.
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(1) 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
#!sh display -d s3c2410x-video (tftpboot)logo.bmp.Z echo -n "press c to enter ABLE" ABORT=no 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.