ARRIS Enterprises, Inc. Confidential Information

Configuring Two Stage Boot

The STB needs to be configured (usually via DHCP) to store bootimages in its flash memory. Typically, set the Kernel Protocol option to "313". As the STB performs a two stage booting from its flash memory, a valid boot image must already be in the STB flash memory before two stage boot can be used. This means that the STB will always perform at least one regular (three stage) boot when downloading and saving the boot image to flash. Subsequent boots may use the two stage boot mechanism.

Boot image version

Every boot image contains a string to identify the software version. The string itself is arbitrary.

The version string is supplied to the build_boot_image script or the various build_device.sh scripts when building the boot image. If no --version is provided to the build_device.sh script then the version is set automatically.

You can determine the version set in a particular boot image with the boot_image_version tool.

The Infocast Server broadcasts a version string alongside each boot image. The STB, on joining the Infocast channel, checks this version string against the version string stored in its flash memory to decide if downloading the image is necessary or not. See Bootcast Information for more.

Two stage boot process

There are two ways the STB can boot, depending on if its Two Stage Boot flag has been set or not. Fresh out of the box, following a factory reset or a TOI-initiated reboot, the Two Stage Boot flag is not set. The following steps will occur:

If the Two Stage Boot flag is not set...

Power on
Unconditionally download the offered bootimage
Save bootimage to flash
Set Two Stage Boot flag
Reboot (goes to next sequence)

If the Two Stage Boot Flag is set...

Power on
Two Stage boot from bootimage in flash memory
Join Infocast channel to receive version string
If different to the stored version, clear Two Stage Boot Flag

When up and running, the STB will periodically listen to the version string being broadcast from the boot server (broadcast by Infocast, or by the STB polling the HTTP server), to detect possible changes. If a change is noticed, the Two Stage Boot Flag will be cleared. This results in a new download during the next reboot.

Triggering a reboot by using the TOI API, ie calling toi.platformService.rebootNow() or issuing the command toish ps rebootnow will run the procedure for software update before rebooting the STB. If a change is noticed, the current boot image will be removed, STB will exit two stage boot mode and a new download will start after reboot. Just typing reboot into the STB's ssh shell, or pulling the power cable will not clear the flag.

The comparison of version strings has changed slightly with the introduction of the two stage boot mechanism. Previously, on the STBs that do not support two stage booting, the STB listens to the version string being broadcast by Infocast, and saves the string in its flash memory. On the next boot, this saved version is compared with the one being broadcast. If they are different, the bootimage being broadcast is downloaded. The version string baked into the boot image was not used.

For the two stage boot STB's, the process is a little different. The STB downloads the initial boot image, and extracts the version string from it. On subsequent boots, this extracted version string is compared to the one being broadcast from Infocast. This means that you should be particular about matching the version string in the boot image, with the version string being broadcast by Infocast.

If the STB is already in two stage boot mode, and you wish to revert to three stage boot mode or access the boot loader menu, then power it on and hold the power button until the LED turns red (approx 10 seconds).