KreaTV IP-STB Boot Procedure

The behavior of the booting process can be controlled by different options sent to the IP-STB from the DHCP server. These options are set in the DHCP server's configuration file. Most options can also be preconfigured from production.

Boot Procedure

The normal boot procedure can be divided into four communication steps:

DHCP

First the IP-STB broadcasts DHCP Discover and DHCP Request packets (according to RFC 951, RFC 2131 and RFC2132) in order to receive an IP address, gateway and the KreaTV specific BootCast address and other configuration parameters from the DHCP server.

See the DHCP options for detailed info on all supported DHCP options.

BootCast

In the second step the BootCast address is used to download the bootcast info file (multicasted by the Infocast server) used to receive information about where to find the splash image and the boot image.

Please also refer to the other supported boot methods.

Splash image

In the third step the splash image is downloaded. The information from the bootcast file is used to download the multicasted splash image.

Only one download attempt is made for the splash image per boot protocol. If the download of the splash image fails, the IP-STB will proceed and attempt to download the boot image instead.

Boot image

In the last step the boot image is downloaded. The information from the bootcast file is used to download the multicasted boot image.

If the boot image was not successfully downloaded the IP-STB will reboot and start a new downloading procedure. A DHCP Release message will first be sent to the DHCP server before the IP-STB reboots.

Two Stage Booting

With the introduction of the IP-STB models VIP2853, VIP11X3 and VIP43x2 comes a faster boot procedure called Two Stage Boot. The steps above are still valid but the new booting procedure introduces some caveats that needs to be taken into consideration.

In three stage boot, when the IP-STB is powered on, the resident boot loader (RBL) is executed which in turn starts the dynamic boot loader (DBL). The DBL manages all steps described above.

In two stage boot, the RBL decides if the DBL or the main software shall be started directly if available in local storage. The boot procedure can be explained as follows:

1. The RBL will execute the DBL if:
   • No valid boot image found.
   • Initial configuration, e.g. radio remote pairing, hasn't been made.
   • Forced execution of the DBL.
2. The DBL scans the network for new software and downloads it. Once the software is downloaded the DBL repackages the boot image, re-encrypts it and stores it on flash. The IP-STB is rebooted for the changes to take effect.

On subsequent boots the RBL will execute the repackaged boot image directly. No information will be sent to a listening bootloader_log_client.py

In two stage boot mode, KreaTV has the ability to detect any software updates when using the Bootcast or HTTP boot protocol and signal the software update to the boot loader and cause the DBL to run on next reboot. The possibility to force upgrades from an application is of course still possible through the following API:

To detect new software KreaTV matches the version of the system software against the version tags (see HTTP boot and Boot cast info). The system software version is derived from concatenation of information from two sources:

• The version field in the file build_data.xml. This file is supplied with each SDK.
• Version number (if any) supplied to the build script at build time.

This value must match the version tags in the boot server.

In some cases it may be necessary to force execution of the DBL. This is done by pressing the standby button when plugging in the power to the IP-STB and releasing the button when the blinking green LED turns solid red after around 10 seconds.

Troubleshooting

If you encounter a problem while trying to boot the STB, use the bootloader_log_client.py tool for debugging.