Table of Contents
Advertisement
It is possible to modify envionment variables and start the pre-defined scripts form the bootloader shell. It is strongly dis-
couraged to modify the pre-defined script variables. However, definition and execution of user-defined script variables can
be done.
Note...
Meddling with the bootloader environment variables can affect significantly the
startup sequence of the system and may cause the system to be un-bootable.
Modification of bootloader environment variables is done using the 'setenv' and 'saveenv' bootloader CLI commands. With
the 'bootextensions' environment variable, user can setup his own bootcmd and bootargs variables and run his script auto-
matically by setting the 'bootsource' variable appropriately. In the following example, the new environment script variable
'bootcmdmyname' as well as 'bootargsmyname' are defined. After that, the 'bootsource' is set to <name> causing the
bootloader to setup <bootargsmyname> and execute <bootcmdmyname> upon next restart.
=> setenv bootextensions myname
=> setenv bootargsmyname 'setenv bootargs quiet mem=384M'
=> setenv bootcmdmyname 'bootp; tftpboot ${loadaddr} myimg.multi; bootm ${loadaddr}'
=> setenv bootsource myname
=> saveenv
Environment changes are stored in one of the redundant bootloader environment sectors. In case of failure (e.g. environ-
ment sector corruption), the settings of the redundant sector are still available. However, the fabric default setting is run-
ning with environment sectors erased. In this case the following startup message is displayed:
ENV: Using default environment
Any changes of the environment can be cleared using the 'clear_env' script (provided that 'clear_env' itself was not
changed):
=> run clear_env
4.3.3
Bootloader Pushbutton Reset
When the pushbutton is pressed, the CP6924-1 glue logic performs a SysReset to the CPU. After reset has been issued, the
board will restart with boot source 'Pushbutton' displayed on the serial console.
If the pushbutton has been pressed for more than 3s, bootloader will detect this and drop into the boot firmware shell
immediately. In addition, the watchdog will be stopped. This allows to get into the bootloader shell in case of severe errors,
e.g. if a boot monitor has been installed with valid checksum but un-bootable.
4.3.4
Bootloader Rollback Control
During board startup sequence, both boot monitor and linux system image checksums are checked before the respective
image is started. In case of a checksum error, automatic rollback mechanism is started, that overwrites corrupted flash sec-
tors with those located in the flash backup partition. After this has been finished, the board reboots and starts from recov-
ered image sectors now.
In case that the flash backup partition does not contain a valid backup image, checksum test will still fail after reboot
resulting in an endless flash recovery - reboot cycle. To avoid this, the rollback command sets a bit in non-volatile CPLD
scratchpad register 0x1 which keeps its contents over CPU reset as long as the board is not switched off. If the following CRC
check still detects flash corruption _and_ the scratchpad register bit is set, bootloader will switch off watchdog, drop into
CLI and wait.
58
CP6924-1 User Guide
www.kontron.com
Advertisement
Table of Contents
