Install Upgrade 112

Software Installation and Upgrade Guide
January 2014
Document no. AM-000501-TC v112
CONTENTS
INDEX
Amino Communications Ltd. 2014 CONFIDENTIAL
Copyright
Software Installation and Upgrade Guide
January 2014
Version 112
Amino Communications Ltd. 2014
Amino, AmiNET, and the Amino logo are trademarks of Amino Communications Ltd. All other trademarks are
the property of their respective owners.
This document contains information on a product under development. Amino Communications Ltd reserves
the right to change or discontinue this product without notice.
There may be visual deviations between graphics in the guide and the released software.
Comments about the documentation are welcome. Please submit feedback to docs@aminocom.com.
For further information about Amino or Amino products, please e-mail info@aminocom.com.
The generally available software versions at the time of issue are as follows:
Platform
Software version
Notes
0.18.11
Software version 0.18.5 is an upgrade

that runs on all set-top boxes listed
under x3x series STBs
x3x series STBs

A130/A130M
A130H
A132
M132
A530
A532
M532
x4x series STBs
A129
A140
M140
3.2.1
H140
Software version 3.2.1 is an upgrade

that runs on all set-top boxes listed
under x4x series STBs
A540PVR
M540
127(
This guide is to be used in conjunction with the Amino STBs and software
versions listed above. It does not refer to older STBs, unless required for
clarification of a particular instruction.
Similarly, Amino now only supports the Opera browser version 11. This guide
does not generally refer to older versions of Opera, unless required for
clarification of a particular instruction.
INDEX
CONTENTS
Operating System
The operating system required is a 32 bit x86 (ia32) Debian Lenny, or Debian Squeeze, with bash as the default
shell and Linux kernel 2.6.
It is possible to get the tools working on 64 bit Linux operating systems as long as the 32 bit compatibility
libraries are installed (ia32-libs), however this is not a configuration supported by Amino.
Likewise, it is possible to use variations of x86 Linux other than Debian and to use a virtual machine such as
VMWare or VirtualBox. Again, these configurations are not officially supported by Amino. Distributions other
than Debian may have different pre-requisites: they may require a certain cluster package or the addition of
optional packages. Amino is currently unable to advise further on this subject.
127(
This is not the embedded operating system in the set-top box.
CONTENTS
INDEX
Contents
Operating System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
About this guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Document conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Important: Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Document history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Chapter 1 The software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.1
Ax4x and Ax3x platforms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1.1
Ax4x platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2
Ax3x platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.3
Ax4x and Ax3x release directory contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4
Software images. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.5
Making new software images available . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.5.1 Upgrade image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.5.2 Bootstrap image (Ax3x platform only). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
16
19
20
20
20
1.2
What is the upgrade system? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3
Installation and upgrade prerequisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4
Downloading the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.5
Setting up a multicast system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Chapter 2 Installing the Ax4x software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1
Starting the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1.1
2.2
2.2.1
2.3
2.3.1
2.3.2
2.4
2.4.1
2.4.2
2.5
2.6
2.6.1
2.6.2
2.7
Configuring the DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Configuring the STB time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Setting the time zone over DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Configuring the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Example Filesystem sections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
DHCP and multicast server matching values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Software images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
Creating a signed upgrade image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
mc2 packet sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

DHCP options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Standard DHCP options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Amino vendor options in DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Software installation from a USB device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
INDEX
CONTENTS
2.7.1
2.7.2
2.7.3
Method of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
File systems supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Software image location on the USB storage device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Chapter 3 Installing the Ax3x software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1
Starting the installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.1
3.2
3.2.1
3.2.2
3.3
3.3.1
3.4
3.4.1
3.4.2
3.4.3
3.5
3.6
Configuring the DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Configuring the STB time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Setting the time zone over DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Setting the time zone in the netconf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Configuring the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

DHCP and multicast server matching values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Software images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Creating a signed bootstrap image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Creating a signed upgrade image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Bootstrap/mc2 packet sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

DHCP options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.6.1
Standard DHCP options supported . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.2
Amino vendor options in DHCP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3
Class IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3.2 IntActOS - multicast versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6.3.3 IntActOS - TFTP versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
60
63
63
63
63
3.7
Using symbolic links when adding new images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Chapter 4 Upgrading Ax4x STBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1
Upgrade mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.1
Using STBremoteconf to upgrade software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2
Using the Management pages to upgrade software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.3
Using the DHCP server to upgrade software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4
Summary of upgrade methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.4.1 Source Specific Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Upgrading the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.2.1
Creating a signed upgrade image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.2
Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3
Additional information for upgrading x4x STBs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3.1 Release Structure Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.3.2 Upgrading the STB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3
4.4
4.4.1
4.4.2
4.4.3
4.4.4
4.4.5
4.4.6
4.4.7
4.5
4.6
4.6.1
69
69
70
70
70
71
72
72
72
73
The STB operational state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

The Reflash/Reset button . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
The reflash sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The reset sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Static DHCP settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DHCP request and response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Download image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Assemble, verify and execute image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DI and external instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
78
78
79
79
80
80
STB configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Automatic upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Testing automatic upgrading. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
CONTENTS
INDEX
4.6.2
Static network and multicast upgrade settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2.1
Setting static multicast upgrade values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2.2 To set a static IP address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6.2.3 Example upgrade.sh script to set static multicast upgrade values . . . . . . . . . . . . . . . . . .
4.7
4.8
82
82
82
83
Automating multicast server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Using the DI for automatic upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.8.1
How it works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.2
DI and software versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.3
Migrating from pre-DI to DI-capable software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.4
Setting up automatic upgrade to minimum DI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.8.4.1 Resetting the DI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
85
85
85
86
4.9
Customising upgrade splashscreens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Chapter 5 Upgrading Ax3x STBs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.1
Upgrade mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.1.1
5.1.2
5.1.3
5.2
5.2.1
5.2.2
5.2.3
5.3
5.3.1
5.4
Using STBremoteconf to upgrade software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Using the Management pages to upgrade software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Using the DHCP server to upgrade software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Upgrading the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

Creating a signed bootstrap image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Create a signed upgrade image. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
About STB operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

Static DHCP settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Operational states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.4.1
Bootstrap (mboot) state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.4.1.1 Operation in the bootstrap (mboot) state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
5.4.1.2 Send DHCP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.1.3 DHCP response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.1.4 Download image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
5.4.1.5 Assemble, verify and execute image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.2
Upgrade (upgrd) state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.2.1 Operation in the upgrade (upgrd) state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.4.2.2 Send DHCP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4.2.3 DHCP response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4.2.4 Download image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.4.2.5 Assemble, verify and execute image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.3
Filesystem (fisys) state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.3.1 Operation in the filesystem (fisys) state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5.4.3.2 Send DHCP request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.3.3 DHCP response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.4.4
Initiate upgrade or normal use . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.5
5.6
STB configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Automatic upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.6.1
To test automatic upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.6.2
Static network and multicast upgrade settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.6.2.1 To set static multicast upgrade values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.6.2.2 To set a static IP address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.7
5.8
Automating multicast server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Using the DI for automatic upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
INDEX
CONTENTS
5.8.1
How it works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.8.2
DI and software versioning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.8.3
Migrating from pre-DI to DI-capable software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8.4
Setting up automatic upgrade to minimum DI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8.4.1 Resetting the DI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.8.5
To implement automatic upgrading . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Chapter 6 STB Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.1
Security keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .110
6.1.1
Hierarchy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1.1 Amino Master key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1.2 Customer key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.1.3 STBRC key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2
Consequences of key compromises . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.1 Amino Master key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.2 Customer key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1.2.3 STBRC key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2
6.3
6.3.1
6.3.2
6.4
6.4.1
6.4.2
6.4.3
110
111
111
111
112
112
112
112
Distributing software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Deployment Index (DI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
How it works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
How to use it. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .114
Changing STB passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Shadow file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Changing passwords in the shadow file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Chapter 7 Upgrading using HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

7.1
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
7.2
HTTP installation and upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
7.3
HTTP recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
7.4
JMACX API function ASTB.Upgrade() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Chapter 8 Postbuild packs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.1
Adding a postbuild pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .122
8.1.1
8.1.2
Using the customise script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Manually applying a postbuild pack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Appendix ALED flashing codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

A.1
Major error groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .124
A.1.1
List of LED flashing codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
A.2
Ethernet monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
Appendix BExample x4x DHCP configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .131
B.1
Ax4x DHCP configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .132
Appendix CExample x3x DHCP configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
C.1
Ax3x DHCP configuration file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .136
Appendix DThe mcastbootd.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .155
D.1
mcastbootd.conf file components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
D.1.1
D.1.2
D.1.3
D.1.4
D.1.5
File header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

[Server] section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Bootstrap and mc2 filesystem section commonalities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Bootstrap Section. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
mc2 Filesystem Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
CONTENTS
INDEX
D.2
D.3
Example mcastbootd.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

Troubleshooting and tips to measure and test bandwidth/MTU/TTL . . . . . . . . . . . . . 158
D.3.1 Common network monitoring/bandwidth measuring tools. . . . . . . . . . . . . . . . . . . . . . . . . . . 158

D.3.2 dhcpd interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
D.3.2.1 Common problems/mistakes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Appendix ESoftware builds: general information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

E.1
Software builds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .162
E.1.1
E.2
E.2.1
E.2.2
E.2.3
E.2.4
Build options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
What is a software release? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

Major core releases (0.X.0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Release candidates (0.X.0-rcZ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Minor core releases (0.X.Y) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Patch core releases (0.X.Ycp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
163
163
164
164
E.3
Software release designation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
INDEX
CONTENTS
10
CONTENTS
INDEX
Introduction
About this guide

This guide applies to all current Amino set-top boxes (STBs), but the installation and upgrade procedures are
different between the Ax4x STBs and the Ax3x STBs. Figure 1.1 shows the path you must take through the
guide depending on which STB you are installing:
/('IODVKLQJ
FRGHV
,QWURGXFWLRQ
$SSHQGL['
7KHPFDVWERRWG
ILOH
&KDSWHU
7KHVRIWZDUH
[[VHWWRSER[HV
$$0+
$3950
[[VHWWRSER[HV
$0+$0
$$0
$SSHQGL[
[['+&3
FRQILJXUDWLRQ
&KDSWHU
,QVWDOOLQJWKH
[[VRIWZDUH
&KDSWHU
,QVWDOOLQJWKH
[[VRIWZDUH
&KDSWHU
8SJUDGLQJ[[
VHWWRSER[HV
&KDSWHU
8SJUDGLQJ[[
VHWWRSER[HV
$SSHQGL[%
[['+&3
FRQILJXUDWLRQ
&KDSWHU
6HFXULW\IHDWXUHV
$SSHQGL[$
/('IODVKLQJ
FRGHV
$SSHQGL['
7KHPFDVWERRWG
ILOH
Figure 4.1 Plan of Installation and Upgrade Guide
Many of the control and customisation options described in this guide can also be implemented using
JavaScript Media Access Control Extensions (JMACX). For details refer to the Amino JMACX API specification .
127(
This guide describes the functionality available for the STBs listed on the
Copyright page. For information on functionality that is no longer supported,
refer to earlier versions of this guide.
INDEX
CONTENTS
11
Document conventions
The following document conventions are in use:
Formatting
Usage
< ...>
Indicates a value that you need to replace with a system specific value (except
where used in HTML or XML examples, where it is used in tags, as normal).
[ ...]
Indicates optional parameters - for example in commands or functions.
... | ...
Indicates choices - for example where an input can take one of a number of
values.
code font
Indicates input and output values (for example, at a command line), as well as
function, configuration, parameter and file names.
bold text
Used for emphasis and to indicate specific key presses. For example: Press the
Esc key.
grey text
Commands or settings which are not in general use (for example, configuration
settings that are reserved for Amino internal use).
blue text
Cross-reference to other sections and other documents (this is a clickable

hyperlink if you are viewing the document electronically).
Important: Audience
This guide is intended for computer-literate people, who have a working knowledge of computing and
networking principles. It assumes a prior knowledge of Linux commands and knowledge of how to configure
a DHCP server in the Linux environment.
12
CONTENTS
INDEX
Structure
Chapter
Outline
Introduction
General introduction.
The software
A description of software builds, and the

upgrade system.
Installing the Ax4x software
A step-by-step guide to installing the software

for Ax4x platforms.
Installing the Ax3x software
A step-by-step guide to installing the software

for Ax3x platforms.
Upgrading Ax4x STBs
Methods of upgrading and updating the

software for the Ax4x platform.
Upgrading Ax3x STBs
Methods of upgrading and updating the

software for the Ax3x platform.
STB Security Features
Describes the use of the Amino security keys.
Upgrading using HTTP
Describes how to upgrade using HTTP,

primarily for unmanaged networks.
Postbuild packs
How to add an Amino Postbuild pack to the

installation.
Appendix A, LED flashing codes
Describes the sequence of short and long

flashes of the STB LED which communicates
general information and error details.
Appendix B, Example x4x DHCP configuration

file
An example configuration of the complete

dhcp.conf file for the Ax4x platform.
Appendix C, Example x3x DHCP configuration

file
An example configuration of the complete

dhcp.conf file for the Ax3x platform.
Appendix D, The mcastbootd.conf file
Details of mcastbootd configuration.
Appendix E, Software builds: general

information
Supplementary information about Amino

software builds.
Document history
Version
Date issued
Changes
112
January 2014
Changes and updates for x4x series STB releases 2.8.0 to

3.2.1.
Changes and updates for x3x series STB release 0.18.11
111
December 2012
Changes and updates for x4x series STB releases 2.5.0 to

2.7.2
Changes and updates for x3x series STB releases 0.18.6 0.18.10
110
October 2011
Changes and updates for x4x series STB releases 2.2.0 2.2.6, 2.3.0 - 2.3.5, 2.4.2 - 2.4.3 and 2.5.0
Changes and updates for x3x series STB releases 0.18.3 0.18.6.
INDEX
CONTENTS
13
Version
Date issued
Changes
109
June 2011
Changes and updates for version 2.2.0 (for Ax4x STBs) and
version 0.18.0 (for Ax3x STBs) releases onwards. See
relevant Release Notes and Technical Memos for changes
made. Guide restructured to improve understanding for
readers.
108
December 2010
Changes and updates for version 0.17.5 and 0.17.6 (for

Ax3x STBs) and version 2.0.0 and 2.1.0 (for Ax4x STBs)
releases.
107
November 2010
DHCP config entries for Mood030 and Mood032 added
106
August 2010
Changes and updates for version 0.17.2 release.
105
March 2010
Minor corrections and updates. Troubleshooting section

removed.
104
August 2009
Appendix C on mcastbootd.conf added.

References to the AmiNET 120 and 124 removed.
Customers requiring information on these platforms
should consult previous versions of the guide.
Updates for Opera9 based platforms
103
June 2009
Removed confidentiality requirement. Password

protection warnings.
102
May 2009
Minor corrections.
101
February 2009
Document created. This document replaces parts of the

Amino Set-Top Box Operations Guide v0.14.x Revision 2
14
CONTENTS
INDEX
Chapter 1The software
In this Chapter:
1.1 Ax4x and Ax3x platforms
1.2 What is the upgrade system?
1.3 Installation and upgrade prerequisites
1.4 Downloading the software
1.5 Setting up a multicast system
INDEX
CONTENTS
15
THE SOFTWARE
AmiNET STB operation is controlled by software installed on the STB. The Amino multicast upgrade system
provides management, control and customisation for STBs. This guide describes how to install the software
on your system: it assumes you have an STB and can obtain a suitable software release. It also assumes a
basic understanding of the technologies involved, which includes Linux command line operation.
1.1
Ax4x and Ax3x platforms
1.1.1
Ax4x platform
Amino software builds of 1.x.x and higher are released as Ax4x combined images to run on A140 and A540
(Opera10, Minerva and Espial EVO). Builds 2.1.1 and higher include the A129 and H140 STBs.
Release 1.0.0 introduced a new primary boot loader and configuration options as well as new DHCP
configuration. There is no separate bootstrap multicast or TFTP image - the recovery image is stored on the
STB.
For information on configuring your DHCP server for the Ax4x platform, see Configuring the DHCP server on
page 25
1.1.2
Ax3x platform
Amino software builds of 0.17.2 and higher are released as Ax3x combined images to run on A130/A130M/
A130H/A132/A530/A532 (Opera9 and Minerva) or A130(M)/A130H (Opera-gogi and Fresco).
By using a combined image it is possible to rationalise the number of image streams being multicast by the
server, as you no longer need to have specific images for each product.
Depending on how you have your server configured, you could maintain different DHCP classes for the
different hardware types. These could then all return the same bootstrap/mc2 multicast addresses. However
you may find it easier to delete all the current class definitions and create a single set of Ax3x classes that can
handle all these boxes. For information on configuring your DHCP server for the Ax3x platform, see
Configuring the DHCP server on page 45.
1.1.3
Ax4x and Ax3x release directory contents
A compressed standard release file supplied by Amino unzips to the directory structure shown in the table
below. The actual contents of the directories depends upon the release for example, CA-specific files and
browser-specific files will be included with some releases, while other releases may not include keys or the
full set of management utilities. The table below shows the location of the main files described in the guide.
Bold text indicates a directory.
Ax3x
File / subdirectory
Description
bootstrap
Directory containing the components needed to create a

signed bootstrap image.
bootstrap.unsigned
The unsigned bootstrap image.
signbootstrap
The script to use to create a signed bootstrap image.
server
16
Directory containing files for setting up the multicast cd ../

upgrade system on the server.
CONTENTS
INDEX
THE SOFTWARE
Ax3x
File / subdirectory
Description
dhcpd.conf
Configuration file containing settings that you need to edit

and add to the your DHCP servers configuration file.
mcastbootd
Amino multicast server binary file.
mcastbootd.conf
Multicast server configuration file.
upgradeimage
Directory that contains the components needed to create a

signed upgrade image.
createtftpboot
Takes the contents of the imagecomponents directory

and creates a TFTP bootstrap in the same manner as
signupgradeimage.
flashcontents
File that lists the files to use to create the software

upgrade image (that is, the imagecomponents files).
signupgradeimage
The script to use to create a signed software upgrade

image.
mc2.mcfs
Multicast upgrade image. This is created after the

signupgradeimage script is run.
imagecomponents
Directory containing the files to be used as the contents of

a software upgrade image. A selection is shown below.
config.txt
Browser configuration file (For Fresco browsers only, not

required for Opera browsers).
fkeys.conf
Configuration file defining actions associated with IR

remote control and keyboard keys. You are not
recommended to edit this file directly.
loading.gif
Graphic shown on screen when the STB is loading a new

software upgrade image.
mcnfg.tar
Tar file containing HTML used to display the STB
Configuration pages.
netconf
Configuration file containing network settings
opera.ini
Browser configuration file for Opera.
settings
Configuration file containing general STB settings.
splash.gif
Graphic shown on screen when the STB is booting.
utils
Directory containing management utilities.

commands
File containing commands used by STBremoteconf.
customise
Script used to merge custom resources and postbuild packs

with your release.
imgcfg
A utility used by signupgradeimage to create signed

bootstraps or mc2 configuration files.
rsakey
RSA key generating utility.
STBremoteconf
Utility that enables remote configuration of STBs.
verifysignature
Validates additional customer keys.
keys
Directory containing the private keys used to sign and

verify software images and STBremoteconf commands.
INDEX
CONTENTS
17
THE SOFTWARE
Ax3x
File / subdirectory
Description
amino
The Amino engineering keys directory.

For Minerva builds, this folder is named minerva.
127(
KEY.private
The private customer key.
KEY.public
The public customer key.
Master.public The public master key.

STBrcKEY.private
The private configuration key.
STBrc-KEYpublic
The public configuration key.
Ax4x Opera 11 builds

File / subdirectory
Description
server
Directory containing files for setting up the multicast cd ../

upgrade system on the server.
dhcpd.conf
Configuration file containing settings that you need to edit

and add to the configuration file of your DHCP server.
mcastbootd
Amino multicast server binary file.
mcastbootd.conf
Multicast server configuration file.
upgradeimage
Directory that contains the components needed to create a

signed upgrade image.
flashcontents
File that lists the files to use to create the software

upgrade image (that is, the imagecomponents files).
signupgradeimage
The script to use to create a signed software upgrade

image.
mc2.mcfs
Multicast upgrade image. This is created after the

imagecomponents
Directory containing the files to be used as the contents of

a software upgrade image. A selection is shown below.
loading.gif
Graphic shown on screen when the STB is loading a new

software upgrade image.
mcnfg.tar
Tar file containing HTML used to display the STB
Configuration pages.
opera.ini
Browser configuration file (Opera)
opera_dir.tgz Tarball that extracts into /opera_dir. This tarball enables
further configuration of Opera such as extra skins.

opera_home.tgz Tarball that extracts into /opera_home. (This tarball was
named ./opera in previous versions). The opera.ini file is
in this tarball.
settings
18
CONTENTS
INDEX
Configuration file containing general STB settings.
THE SOFTWARE
Ax4x Opera 11 builds

File / subdirectory
splash.gif
Description
Graphic shown on screen when the STB is booting.
bin
recovery.image
The recovery image
pbl.image
The primary bootloader image
utils
Directory containing management utilities.

commands
File containing commands used by STBremoteconf.
customise
Script used to merge custom resources and postbuild packs

with your release.
imgcfg
A utility used by signupgradeimage to create signed

bootstraps or mc2 configuration files.
rsakey
RSA key generating utility.
STBremoteconf
Utility that enables remote configuration of STBs.
verifysignature
Validates additional customer keys.
keys
Directory containing the private keys used to sign and

verify software images and STBremoteconf commands.
amino
The Amino engineering keys directory.

For Minerva builds, this folder is named minerva.
127(
KEY.private
The private customer key.
KEY.public
The public customer key.
Master.public The public master key.
1.1.4
STBrcKEY.private
The private configuration key.
STBrc-KEYpublic
The public configuration key.
Software images
The STB NAND flash memory holds the signed software image:
Bootstrap image (Ax3x platform only)

The bootstrap image contains the software needed to manage the download of a multicast upgrade
image. It is a combined Linux kernel and RAM disk image with an RSA digital signature.
A signed bootstrap image is generated as a file called bootstrap.signed.
Recovery image (Ax4x platform only)

The recovery image is the software needed to recover the STB if it fails. This is already loaded on the STB
in a separate NAND partition.
INDEX
CONTENTS
19
THE SOFTWARE
Upgrade image
The upgrade image is a file that contains a complete software upgrade in the form of a file system image
with an RSA digital signature. A signed upgrade image is normally generated as a file called mc2.mcfs.
1.1.5
Making new software images available
When the STB is first connected, it inspects its NAND flash and if this contains no valid software, it connects
to the multicast server and downloads a software release: for the Ax3x platform it loads the bootstrap image
first, which enables the download of the upgrade image, whereas for the Ax4x platform the recovery image is
already loaded onto the STB.
If you have not been supplied with signed software images, you will need to create and sign your own. To do
this, you will need the /bootstrap and/or /upgradeimage directories of a software release, and the
customer key and its pass phrase. Keys are normally provided as part of a software release, but you can also
generate and use your own keys, as long as they are in the STB ROM.
1.1.5.1 Upgrade image

Upgrade images must be created whenever you need to upgrade STBs with a new software release. The
upgrade image is created from the contents of the imagecomponents directory specified in the
flashcontents file, using the signupgradeimage script and the customer key.
The upgrade image can be downloaded automatically by an STB (controlled by the deployment index
mechanism, see Deployment Index (DI) on page 113) or you can initiate multicasting (or unicasting) the image
manually from the DHCP server and Amino multicast server, for example, by using the STBremoteconf tool.
If you have not been supplied with signed bootstrap and upgrade images, you need to create them yourself
from the files supplied in the Amino software release.
1.1.5.2 Bootstrap image (Ax3x platform only)

You should normally only need to sign and load a bootstrap image when the STB is supplied with a blank NAND
flash (for example, units shipped direct from manufacture). The bootstrap image is created from the
bootstrap.unsigned file, using the signbootstrap script and the customer key.
1.2
What is the upgrade system?
The software can be specified and provided either by multicast streaming a new upgrade image to the STB, or
via HTTP where a new software image is placed on an available web server.
The Amino multicast upgrade system offers various means of instructing STBs to replace their software
images:
STBremoteconf
Management pages
DHCP server configuration
JMACX API
Reset button
Upgrading using HTTP
Information about these upgrade methods can be found in Chapter 4, Upgrading Ax4x STBs and Chapter 5,
Upgrading Ax3x STBs .
20
CONTENTS
INDEX
THE SOFTWARE
1.3
Installation and upgrade prerequisites
Before using this guide you should be familiar with the following Linux usage and administration skills:
Performing a SSH login.
Contrasting full and relative pathnames.
Understanding the file system hierarchy.
Handling files with cp and mv.
Making and navigating directories.
Listing attributes with ls.
Identifying multiple users and groups.
Interpreting file and directory modes.
Adjusting access permissions: chmod.
Raising privilege with su, sudo and setuid.
Extracting lines with GNU grep.
Saving command output into files.
Creating and modifying files with vi or emacs.
Exporting variables to the environment.
Calling scripts as a command.
Monitoring processes with ps.
Mounting storage devices.
Measuring free space.
Creating tar archives.
1.4
Downloading the software
Amino provides software updates to our corporate customers with a valid support account and the
appropriate software can be downloaded from the Amino support site at http://stbsupport.aminocom.com.
Sign in to the site and select Online support > Downloads. On the left hand side of the screen select Aminet
STBs > Software releases. From the available downloads select the type of STB and browser you require.
127(
Only the software to which you have access will be displayed.
A free 90 day sample account is available to all customers who have bought directly from Amino. After this
period there are different paid support options to choose from. If you have received your STB from a 3rd party,
you should contact them for software updates.
1.5
Setting up a multicast system
The instructions in the following chapters assume you have access to a compressed Amino release through
the Amino support site and a computer with Linux and a DHCP server installed. They also assume familiarity
with basic Linux command line functionality. If you intend to use STBremoteconf for remote control and
communication with STBs, then you will need Perl on the PC on which you are installing these components.
To complete the installation, you will also need to find out the settings for the network to which the STB is
connected.
INDEX
CONTENTS
21
THE SOFTWARE
22
CONTENTS
INDEX
Chapter 2Installing the Ax4x software
In this Chapter:
2.1 Starting the installation
2.2 Configuring the STB time zone
2.3 Configuring the multicast server
2.4 Software images
2.5 Starting the multicast server
2.6 DHCP options
2.7 Software installation from a USB device
INDEX
CONTENTS
23
INSTALLING THE AX4X SOFTWARE
The steps in this chapter describe how to set up a basic multicast system for Ax4x STBs. Although it is not
necessary to follow the installation methods exactly, Amino recommend that a similar directory structure is
used in your installation to simplify any subsequent support issues that may arise.
2.1
Starting the installation

In all the following instructions, <release_name> indicates the full name
of the software release image directory that contains your Amino software
release.For example, Ax4x-3.2.1-Opera11 installs in 3.2.1-Ax4xopera11, hence <release_name> is 3.2.1-Ax4x-opera11.
127(
1.
Open a terminal window and log on to your system as root, or change to root from a user using:
su
2.
Using mkdir, create directories to contain the software, for example:

mkdir /usr/local/amino
mkdir /usr/local/amino/images
this is where the multicast server will get the images to broadcast.
Also use mkdir to create the directory /usr/local/amino/releases , this is where the
downloaded files will be stored.
Ensure that you have the correct read/write permissions for each of these
directories using:
127(
chmod 777 <directory>
3.
Copy the required .tgz file to the /usr/local/amino/releases directory.

If you require builds for different AmiNET models, it may be useful to create
directories for each type, for example, /usr/local/amino/releases/
A140.
127(
4.
Navigate to the releases directory /usr/local/amino/releases and unpack the Amino software
release using:
tar zxvf <archive_name>
where
z
Filter the archive through gzip
Extract files from an archive
Verbosely list files processed
Use the specified archive file.
for example:
tar zxvf Ax4x-2.1.0-Opera10.tgz
unpacks 2.1.0-Ax4x-opera10.tgz to 2.1.0-Ax4x-opera10
24
CONTENTS
INDEX
This will then contain the following sub-directories:

UHOHDVHQDPH
XSJUDGHLPDJH
VHUYHU
XWLOLWLHV
upgradeimage
Contains the files needed for signing an upgrade image.
server
Contains the files needed for the mcastbootd server, including a sample DHCP
configuration file dhcpd.conf.
utils
Contains the generic Amino keys, the remote configuration utility (STBRemoteconf) and
binaries required for all the above processes.
5.
Copy the multicast server binary mcastbootd to a directory in the system path, using:
cp <release_name>/server/mcastbootd /usr/local/bin
6.
Copy the contents of the utils directory to the same location, using:
cp <release-name>/utils/* /usr/local/bin
127(
Amino recommends that you regularly copy the contents of the /utils
folder to /usr/local/bin, as STBremoteconf and build configurations
are occasionally updated.
You may see a warning message about cp omitting the /utils/keys
directory. This can be ignored safely.
For Minerva builds, the /utils/keys/amino directory is named
/utils/keys/minerva.
7.
Copy the multicast server configuration file to the /etc directory, using:
cp <release_name>/server/mcastbootd.conf /etc
8.
If you are using a dedicated DHCP server (only for this multicast system), then copy the sample
configuration file dhcpd.conf from the software release to the /etc directory, using:
cp <release_name>/server/dhcpd.conf /etc
If you are using a DHCP server that has already been set up with an existing installation, you will be
able to copy the configuration options settings from the sample file (dhcpd.conf) to your existing
DHCP configuration file when you set up your DHCP server for use with Amino products.
All the files needed to run the multicast system have now been copied to the locations where they are needed.
You will still need to access some of the other files in the software release directory.
2.1.1
Configuring the DHCP server
For a first configuration of a multicast system (for example, for trial purposes), you are recommended to
configure a DHCP server that will only be used for this multicast system, in order to keep configuration simple
while you are familiarising yourself with the system functionality.
In many deployments it is likely that there will be more than one type of STB installed, each needing different
software images. To implement this, you will need to change both the DHCP server and multicast server
configuration, and ensure that software images for different STB types are uniquely identifiable (either give
them different names or store them in separate directories).
INDEX
CONTENTS
25
A sample configuration file is supplied with the software release, and you can either edit that file or copy the
settings from that file to your existing DHCP servers configuration file.
1.
Open the sample DHCP server configuration file dhcpd.conf in a text editor.
127(
If you copied the file over when you copied the binaries (step 8. above), then
this is located in /etc. Otherwise, it is in the <release_name>/server/
directory and you should complete step 8. above before continuing.
If you are adding settings to an existing DHCP server configuration file (for
example for another STB, or an additional type of set top box), you will also
need to open the existing configuration file for your DHCP server, and modify
the settings in that file, as per the changes below. For an example of an
edited DHCP configuration file, see Appendix B, Example x4x DHCP
configuration file
2.
The following settings from the sample configuration file need to be copied to the DHCP server
configuration file that you wish to use.
##########################################################################
# Misc dhcp options
##########################################################################
allow bootp;
ddns-update-style ad-hoc;
filename="AMINET.txt";
The only items that may need changing are as follows:

option AMINO.software_uri "igmp://<mcast address>:<port>"
which are the multicast address and the port you are streaming the upgrade image on.
127(
If you change any of these options you must also make sure you make the
appropriate changes to /etc/mcastbootd.conf.
##########################################################################
# Extra Options for AMINO option space (used for multicast)
##########################################################################
option space AMINO;
option AMINO.address
code
1 = ip-address;
option AMINO.MBC_SAP
code 51 = text;
to
For further information, see Amino vendor options in DHCP
3.
The Ax4x platform does not have separate classes for the mboot, upgrd and fisys states. This is
because there are no longer multiple stages during boot and upgrade on these platforms.
##########################################################################
# AMINOx4x Configuration Section
##########################################################################
#
# class "AMINOx4x" - state when requesting an upgrade (main/recovery) image

#
26
CONTENTS
INDEX
# The only items that may need changing are as follows:
# option AMINO.software_uri "igmp://<mcast address>:<port>" the multicast #

# address you are streaming the upgrade image on
# option AMINO.port 11111; - the port you are streaming on.
# Note that on x4x, there is no longer separate classes for mboot, upgrd and
# fisys. This is primarily because there are no longer multiple stages during
# boot and upgrade on these platforms.
# If you change any of these options you must also make sure you make the
# appropriate changes to /etc/mcastbootd.conf
##########################################################################
##########################################################################
# class "AMINOx4x"
# AMINOx4x - response to x4x family STBs during Main and Recovery image boot
##########################################################################
class "AMINOx4x"
{
match if (substring( option vendor-class-identifier, 0, 8)="AMINOx4x");
#
vendor-option-space AMINO;
option AMINO.software_uri "igmp://<mcast address>:<port>";
4.
5.
Make a note of the multicast IP addresses and ports you have specified, as you will need to use the
same values when you set up the multicast server.
Edit the following declarations with the settings for your network. You may need to edit the following
lines:
#############################################################
#
Subnet Declaration
#
#############################################################
subnet 192.168.1.0 netmask 255.255.255.0 (
This is optional, but if required replace the existing value with:

subnet <IPaddress of the subnet of DHCP> netmask <sub-net netmask>
For example:
subnet 10.172.0.0 netmask 255.255.0.0 (
#############################################################
#
Default Gateway - This MUST be set!!
#
#############################################################
INDEX
CONTENTS
27
option routers 192.168.1.1;
Replace this with option routers <IPaddress of the default gateway the STB uses
to connect to the internet>;
For example:
#############################################################
#
Subnet Mask - This MUST be set!!
#
#############################################################
option
subnet-mask 255.255.255.0;
Replace this with options subnet-mask <IPaddress of the subnet mask>;

For example:
option subnet-mask 255.255.0.0;
#############################################################
#
Domain Name - Optional
#
#############################################################
option domain-name blahblah.com;
This should be replaced with your DNS name.

For example:
option domain-name aminocom.com.
#############################################################
#
DNS Servers - Optional
#
#############################################################
option domain-name-servers 192.168.1.1,192,168.1.2;
This is optional, but if required replace this with:

option domain-name-servers <IP address of the above DNS name>,<alternative
IP address of the above DNS name>;
6.
Edit the NTP server declarations to suit the time zone you are in (that is, uncomment the option
ntp-servers europe.pool.ntp.org; line if you require that option):
#####################################################################
# NTP Servers - Optional
#####################################################################
# option ntp-servers europe.pool.ntp.org; # example free NTP service
#####################################################################
# Time Offset - Optional
#
# This can be in one of three string formats e.g.
#
UNIX style Region/City - "Europe/London"
#
Commonly used alias - "GB-Eire"
#
Fully-specified Posix 1003.1 timezone string -
28
CONTENTS
INDEX
#
#
#
#
#
#
#
"GMT0BST-1,M3.5.0/01:00,M10.5.0/02:00"
#
# TZ info can be found in the following links:
#
http://www.twinsun.com/tz/tz-link.htm
# http://h71000.www7.hp.com/doc/73final/6497/6497pro_007.html
#
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
#
#
#####################################################################
option AMINO.timezone "Europe/London";
#
#
#
#
#############################################################
#
Time Offset - Optional
#
#############################################################
#option time-offset -5; # Eastern Standard Time
#option time-offset +8; # Eastern Standard Time
#option time-offset -5; # Pacific Standard Time
option time-offset 0; # Greenwich Mean Time
7.
Edit the address pool declarations so that the STB classes are given an address:
#############################################################
#
Address Pool - This MUST be set!!
#
#
#
#
In this address pool we list the classes which we wish #
#
to give addresses to, unless a device is in this list
#
#
it will not be given an address!
#
#############################################################
pool {
range dynamic_bootp 192.168.1.50 192.168.1.100
range 192.168.1.101 192.168.1.200
...
}
For a range of STBs:

Replace the pool section of the dhcpd.conf file with:
pool{
range 192.168.1.50 192.168.1.100;
}
where range is the range of the IP addresses for multicast booting and upgrades, in this case from
192.168.1.50 - 100.
For individual STBs:
In the case where you have a smaller number of STBs and wish to manage them individually, as in a
development network, the pool information should be replaced with STB specific information similar
to the following:
host aminet140_001 {
hardware ethernet 00:03:0A:0C:92:91;
INDEX
CONTENTS
29
fixed-address 10.172.227.64;
}
hardware ethernet 00:02:0A:13:AA:61;
}
8.
Make any further settings you require for your system.

127(
9.
From Ax4x version 1.0.0 onwards you can add User Class options to the
configuration file if required, and they will be passed to the STB in the DHCP
response.
When you have added classes for each STB type that you are supporting, save your changes, then
copy the edited dhcpd.conf file to the /etc/dhcp3 folder.
cp dhcpd.conf /etc/dhcp3/
10. Reboot the DHCP server with the following command:

/etc/init.d/dhcp3-server restart
The minimum DHCP server configuration for a multicast system is now complete.
2.2
Configuring the STB time zone
STBs support time zone handling through an NTP client, and the time zone can be set by using the DHCP
server.
Time zone strings can be in the following formats:
Unix-style definition in the format Region/City (for example, Europe/London)
Commonly used alias (for example, GB-Eire)
Fully specified Posix 1003.1 time zone string (for example, GMT0BST-1, M3.5.0/01, M10.5.0/02:00)
2.2.1
Setting the time zone over DHCP
If the STB retrieves its settings dynamically from the DHCP server, you can include the time zone in the settings
that it retrieves.
1.
Open the DHCP server configuration file (dhcpd.conf) in a text editor. This file should be found in
the following location:
/etc
2.
Add the following to the list of Amino vendor extensions (if it is not already there):
option AMINO.timezone code 16=text;
3.
In the subnet declaration in the configuration file, add a line that specifies the time zone you want
to set.
Example:
option AMINO.timezone Europe/Stockholm;
The subnet declaration will now look similar to the following:

subnet 10.172.0.0 netmask 255.255.0.0 {
30
CONTENTS
INDEX
option
option
option
option
subnet-mask 255.255.0.0;
domain-name "aminocom.com";
domain-name-servers 10.171.22.7,10.171.22.9;
AMINO.timezone Europe/Stockholm;
pool {
range 10.172.230.50 10.172.230.100;
}
}
4.
Add an NTP Server if one is not already configured on your network (see paragraph 6. in section 2.1.1
above).
5.
Save your changes and restart the DHCP server.
Next time the STB sends a DHCP request (for example, when it is rebooted), the time zone will be included in
the information that the DHCP server sends.
2.3
Configuring the multicast server
The following instructions describe the minimum steps that you need to complete to configure a working
multicast server that provides software images for a single type of STB (for example, as part of a trial system).
The instructions that follow assume that you have already installed, configured and started your DHCP server,
and that you have copied the files from your software release to the example locations given in Starting the
installation.
1.
Navigate to the /etc directory, and open the following file in a text editor:
mcastbootd.conf
2.
The [Image bootstrap.signed]does not have to be configured for Ax4x series boxes, so you
only need to add a [Filesystem mc2] section for each type of STB. Each section must be named
uniquely. The software image for each type of STB must be unique (they can either be stored in
separate directories or named uniquely by renaming the image files you have created).
3.
In the [Filesystem mc2] section, edit the following settings to specify the IP address and port for
multicasting the image.
MulticastIPAddress=<mcast address>
MulticastUDPPort=<port number>
For example:
MulticastIPAddress=239.255.200.2
MulticastUDPPort=11111
2.3.1
Example Filesystem sections

[Filesystem mc140]
ImageName=mc140
Description=upgrade filesystem
SerialNumber=8
DirsPerCycle=128
<-This is an example value.
INDEX
CONTENTS
31
DataRate=256
[Filesystem mc540]
ImageName=mc540
SerialNumber=5
DirsPerCycle=128
DataRate=256
Important: The multicast server configuration file must contain a Filesystem section called mc2. If this
section is removed, the signupgradeimage script cannot create new software upgrade images successfully
and will show an error "Filesystem 'mc2' is not configured".
If you want to name sections appropriately for each STB type, then you should leave this section in the file as
a dummy section, and add new sections for each of the STB types that you want to support. If there is no
software upgrade image at the location specified in this dummy section, the multicast server will generate
errors on start-up, but will still run.
Example [Filesystem mc2] section
(this can be a dummy section, as described above):

[Filesystem mc2]
ImageName=mc2
SerialNumber=73
DirsPerCycle=128
DataRate=256
1.
Check that the ImageName setting lists the directory that you will be copying signed software
upgrade images to and has the correct name for the image.
ImageName=mc2
This is the upgrade image that will be broadcast by the server.

2.
If you are setting up the multicast server to transmit software for multiple STB types, you will need
to add separate [Filesystem <imagename>] sections for each of the STB types. The
<filename> must be unique, and must match the name of the upgrade image for that type of STB.
(To set this up, you will also need to rename the software images you create, so that the image name
for each type of STB is unique.) This is not necessary if you have only configured the DHCP server for
a single type of STB.
The multicast server is now configured. Next, you should create software images and copy them to the
directory specified in the configuration file before you start the multicast server.
2.3.2
DHCP and multicast server matching values
For each STB type set up in the DHCP server, the multicast values that the configuration specifies must match
the values that the multicast server uses for transmitting software images. The following table shows the
32
CONTENTS
INDEX
equivalent settings for IP address and port in the example DHCP server and multicast server configuration
files.:
Multicast server configuration (example values)
class "AMINOx4x
option AMINO.software_uri
"igmp://<239.255.230.53>:<11111>";
AMINOx4x
MulticastUDPPort=<11111>
2.4
Software images
The Ax4x STB NAND flash memory holds two types of signed software image:
Recovery image
The recovery image is the software needed to recover the STB if it fails. This is already loaded on the STB
in a separate NAND partition.
Upgrade image
with an RSA digital signature.
A signed upgrade image is normally generated as a file called mc2.mcfs.
2.4.1
Creating a signed upgrade image

A video showing this installation procedure is available at:
http://video.aminocom.com/
Select:
How to edit and modify Amino software images
VIDEO
The following steps detail how to use the signupgradeimage script to create a signed software upgrade
image. This image is normally called mc2.mcfs.
Warning:
mcastbootd.conf must already exist, and be populated, before you use
signupgradeimage,otherwise the signupgradeimage script will fail
saying that the filesystem directory mc2 does not exist.
The steps outlined here assume that you have set up a multicast system and you have logged in as root. The
Amino software release contains the engineering customer key that you will need for creating the signed
software upgrade image. If you are using your own keys, then you will need to know the passphrase for your
customer key.
1.
Configure the files that will form the release (for example you may want to change the default
settings in the file settings or change the splash image) and add any extra files to the
flashcontents file. remember to set the appropriate permissions for the extra files if necessary.
If you are setting up a system to familiarise yourself with the components, then you will not need to
perform this extra configuration at this stage.
The flashcontents file lists the files that will be included in a software upgrade image, and defines
permissions for those files.
Example flashcontents file
This shows a small part of a typical flashcontents file.
INDEX
CONTENTS
33
# R == file must exist

#
must be read-only
#
must match the checksum in listfile.sig
# W == file may exist
#
must not be executable
#
we don't care about the checksum
# E == file may exist
#
if it does exist:
#
it must be read-only
#
R
R
R
R
R
R
R
R
R
R
R
R
R
R
W
W
W
W
2.
AMINET.img
libm223.so
libc223.so
xfresco
xfresco.amem
mkfs.ext2
fsck.ext2
tune2fs
mkfs.xfs
font_opt.bin
texttvd
ttsub
bbsdk.cfg
irb_keys.txt
noformat
!poweron
cookies.txt
history.txt
Set the CUSTOMER_KEY environment variable by entering a command in the following format:
export CUSTOMER_KEY=/usr/local/amino/releases/<release_name>/utils/
keys/amino/KEY.private
3.
Navigate to the upgradeimage directory:

cd /usr/local/amino/releases/<release_name>/upgradeimage
4.
Run the signupgradeimage script by entering a command in the following format:

./signupgradeimage [-hvz] [-s <pkt-size] [<DI>]
34
Argument
Usage
-h
Displays help text.
-v
Displays version.
-z
Compresses the image that is produced (this is only needed

for Opera releases, but can also be accepted by other
browsers).
-s
Sets the size of the multicast image packets to <pkt-size>

(bytes). This is useful for preventing packet fragmentation in
some networks. The default packet size is 4096 bytes.
CONTENTS
INDEX
Argument
Usage
<DI>
Sets the deployment index (DI) for the image that is created.
The default DI is 0 (zero). If you are not controlling upgrades
with a DI (for example, in trial installations), then you can omit
this argument. Otherwise, <DI> must be the same or greater
than the software currently on the STBs that you want to
upgrade with this upgrade image. The exception is for HTTP
upgrades where the DI must always be greater than the
previous DI (not the same). You are normally recommended to
increment the DI by 1 for each upgrade image.
-n <name>
Alternative mcfs file <name> without the mcfs extension

provided the mcfs file is matched within
mcastbootd.conf.
For example (recommended for a trial installation):

./signupgradeimage -h
or
./signupgradeimage -s 2048
or
./signupgradeimage
You will be prompted to enter the passphrase for the key. For the Amino engineering key, the
password is markskey.
5.
The script generates an upgrade image in the current directory. It is normally called mc2.mcfs. Copy
this file to the images directory specified by the ImageName setting in the [Filesystem mc2]
section of the multicast server configuration file (mcastbootd.conf).
For example:
cp mc2.mcfs /usr/local/amino/images/
If you have multiple [Filesystem <filename>] sections in the multicast server configuration file,
you will need to change the name of the file to the <filename> for the appropriate section, and
then copy the file, as above.
When the multicast server is started, the new image will be multicast automatically and the STB will download
the image next time it needs to upgrade its software. Alternatively, you can force the STB to upgrade to a
specified version. If the multicast server is already running, you will need to restart it to transmit the new
image.
2.4.2
mc2 packet sizes
When signing an mc2 image, for optimum performance the maximum transmission unit (MTUthe size in
bytes of the largest protocol data unit that it can pass onwards) of each image should be equal to the
maximum MTU size allowable on the network, allowing for ethernet, IP, UDP or any other overheads.
Mcastbootd also adds a 16-byte header to each packet, so this must be taken into account in any
calculations.
For example, a DSL PPPoE link might have a frame size of 1518 bytes (say). After headers are taken into
account, the maximum payload might be 1492 bytes.
Assuming mcastbootd adds a 16-byte header, the maximum allowable packet size is therefore 1476 byes.
INDEX
CONTENTS
35
For the mc2 image, the packet size is defined when signing the image with the signupgradeimage script.
The -s option defines the packet size. The default value is 4096 bytes, which will result in fragmentation on
this network.
signupgradeimage -s 1476
It is worth checking that no packet fragmentation is occurring when running mcastbootd on an end-to-end
connection. A packet capture tool such as Wireshark can be used for this (http://www.wireshark.org/).
2.5
Starting the multicast server
These instructions assume you have set up the DHCP and multicast servers, and that you have copied a signed
software upgrade image to the location specified in the multicast server configuration file.
1.
Navigate to the directory in which software images are located.

For example:
cd /usr/local/amino/images
2.
To start the multicast server in normal mode, enter the following command:
mcastbootd
To start the multicast server in debug mode, enter

mcastbootd -D.
In debug mode details of its operation are echoed to the terminal. This is useful to monitor its
operation in a trial installation.
The multicast server continuously transmits the software images as a carousel, and when an STB needs to
install an upgrade image, it joins the carousel then retrieves and installs the required files.
2.6
DHCP options
The DHCP options for configuration include both Standard DHCP options and Amino-specific DHCP options
(derived from Standard DHCP option 43 - Vendor specific)
2.6.1
Standard DHCP options
The supported options are defined in the following table (options not listed here are ignored by the STB). The
options shown in bold are requested by the STB in option 55 - Parameter List.
36
TAG
NAME
MEANING
Linux
support
Used by
STB
Subnet Mask
Subnet Mask Value
Time Offset
Time Offset in seconds from UTC
Router
Router addresses
Domain Server
DNS Server Addresses
12
Hostname
Hostname string
15
Domain Name
The DNS domain name of the client Y
17
Root Path
Path name for root disk
23
Default IP TTL
Default IP Time To Live
CONTENTS
INDEX
TAG
NAME
MEANING
Linux
support
Used by
STB
28
Broadcast Address
Broadcast Address
29
Mask Discovery
Perform Mask Discovery
31
Router Discovery
Perform Router Discovery
33
Static Route
Static Routing Table
40
NIS Domain
NIS Domain Name
41
NIS Servers
NIS Server Addresses
42
NTP Servers
NTP Server Addresses
43
Vendor Specific
Vendor Specific Information
51
Address Time
IP Address Lease Time
53
DHCP Msg Type
DHCP Message Type
54
DHCP Server ID
DHCP Server Identification
55
Parameter List
Parameter Request List
57
DHCP Max Msg Size
DHCP Maximum Message Size
58
Renewal Time
DHCP Renewal (T1) Time
59
Rebinding Time
DHCP Rebinding (T2) Time
60
Class Id *
Vendor Class Identifier
61
Client Id **
Vendor Client Identifier
77
User-Class
User Class Information
90
DHCP Authentication DHCP Authentication
125
TR-111 support
Vendor-specific information
*Standard option 60 Class ID is included by the STB in all requests it sends. The value is Aminox4x for all x4x
products.
**Standard option 61 Client ID is included by the STB in all requests it sends. The value sent is the Ethernet
MAC address of the STB.
2.6.2
Amino vendor options in DHCP
Using these options, a system integrator can customise the STB, for example, setting the browser to a home
page by adding option AMINO.homepage http://www.aminocom.com in the AMINOx4x class for the
particular STB, and similarly for other options.
Standard DHCP option 43 (Vendor Specific Information) is used to provide the following Amino specific
options. These are not Standard DHCP Options.
127(
Some of these options are specific to x4x boxes , for example code 25
software_di. Ensure you are using the correct code for the STBs you are
installing.
Amino specific options

TAG
NAME
TYPE
MEANING
address
ip-address
The multicast FS address, supplied as a 4-byte

value.
INDEX
CONTENTS
37

TAG
NAME
TYPE
MEANING
port
2 octet
integer
The port number for the group as a short.
product
string
The product identifier, sent from the client to the

server.
option
string
Option string, sent from the client to the server.
version
string
Version number sent from the client to the

server.
middleware
ip-address
The middleware multicast address, supplied as 4byte value.
mw_port
2 octet
integer
The middleware port to use on that group

(short).
homepage
string
The browser homepage (string).
dindex
integer
Deployment index (int).
10
dindex_min
integer
Deployment index minimum (int): Triggers an

automatic upgrade if the deployment index on
the box is less than this. If there is no minimum,
never automatically update. .
11
dindex_page
string
Deployment index upgrade page (string)

where to get the upgrade from.
12
STBrc_mcast_address
ip-address
STBremoteconf multicast group (4-byte value).
13
STBrc_mcast_port
2 octet
integer
STBremoteconf multicast port (short).
14
STBrc_ucast_port
2 octet
integer
STBremoteconf unicast port (short).
15
local_config
string
Local config URL (string) location of a config

tarball that should be downloaded at boot.
16
timezone
string
Timezone string
(Either fully specified, for example
"GMT0BST-1,M3.5.0/01:00,M10.5.0/
02:00"
or
zoneinfo-style e.g. "Europe/London").
17
middleware2
ip-address
The alternative middleware multicast address,

supplied as 4-byte value.
18
mw_args
string
CLI arguments string to be passed to the

middleware.
19
AMINO INTERNAL
TEST host machine IP-address.
20
AMINO INTERNAL
TEST directory path string.
22
mirimon_args
string
Mirimon CLI arguments string.
23
agama_args
string
Agama CLI arguments string.
24
reserved testing
text
Reserved for Amino internal use.
25
software_di
2 octet
integer
(Ax4x STBs only) As option 10.
38
CONTENTS
INDEX

TAG
NAME
TYPE
MEANING
26
recovery_ di
2 octet
integer
Not required.
27
pbl_ di
2 octet
integer
Not required.
28
software_uri
string
(Ax4x STBs only) The URI for an image when

recovering the STB if there is no DHCP response.
29
recovery_uri
string
Not required.
30
pbl_uri
string
Not required.
31
hw_options
string
(Ax4x STBs only) This is set to 4 spaces and can be

used to signal hardware variants if required.
32
extra_options
text
Allows customers or middleware suppliers to

pass arbitrary configuration to the STB from
DHCP.
If you need to pass more than one option, the
syntax is a space-separated list of tag=value pairs,
for example:
TESTSERVER=10.0.0.2_TESTVAL=5_
TESTURL=http://test.it/_
TESTNAME='Test 1'
Tag names may only contain A-Z, digits and

underscore. They will be converted to upper case
and prefixed with 'DHCP_EXTRA_OPTION_'.
Values will be quoted and any extra quotes
stripped, to avoid the possibility of this being
used as a method of executing arbitrary
commands.
33
debug_options
text
Used by Amino to define debug settings.
34
igmp_max_ver
integer
Sets the maximum IGMP version.
You will find the following code listing the Amino vendor options in the dhcpd.conf file.
option space AMINO;
code
1 = ip-address;
option AMINO.port
code
2 = integer 16;
option AMINO.product
code
3 = text;
option AMINO.option
code
4 = text;
option AMINO.version
code
5 = text;
option AMINO.middleware
code
6 = ip-address;
option AMINO.mw_port
code
7 = integer 16;
option AMINO.homepage
code
8 = text;
option AMINO.dindex
code
9 = integer 32;
option AMINO.dindex_min
code 10 = integer 32;
option AMINO.dindex_page
code 11 = text;
option AMINO.STBrc-mcast-address code 12 = ip-address;
INDEX
CONTENTS
39
2.7
option AMINO.STBrc-mcast-port
option AMINO.STBrc-unicast-port
option AMINO.local-config
code 15 = text;
option AMINO.timezone
code 16 = text;
option AMINO.middleware2
code 17 = ip-address;
option AMINO.mw_args
code 18 = text;
option AMINO.test_host
option AMINO.test_dir
code 20 = text;
option AMINO.recovery_mode
option AMINO.mirimon_args
code 22 = text;
option AMINO.agama_args
code 23 = text;
option AMINO.reserved_testing
code 24 = text;
option AMINO.software_di
option AMINO.recovery_di
option AMINO.pbl_di
code 28 = text;
option AMINO.recovery_uri
code 29 = text;
option AMINO.pbl_uri
code 30 = text;
option AMINO.hw_options
code 31 = text;
option AMINO.extra_options
code 32 = text;
option AMINO.debug_options
code 33 = text;
option AMINO.igmp_max_ver
Software installation from a USB device
A software image from a USB storage device can be installed onto an STB. This feature is available on Ax4x
STBs with an installed recovery image of version 2.8.1 or higher.
When you install a software image from a USB storage device, you can only reflash the STB: you cannot
upgrade it.
127(
Due to the extensive range of USB storage devices available, Amino cannot
guarantee satisfactory performance with every available device. Amino
suggests that to ensure correct operation, you use a branded USB storage
device from a major manufacturer.
2.7.1
Method of operation
To enable installation of a software image from a USB storage device, you must first run the recovery image
on the STB. You can run the recovery image by using the reflash button (see The reflash sequence) or by using
the Management pages (see the Amino Set-Top Box Configuration Guide).
When the recovery image runs, it will first check to see if restore to factory defaults has been requested. (For
details about resetting to factory defaults, see The reset sequence.) If not, the recovery image attempts to
install a new main image. It will check to see if a USB storage device is present, and if so, will try to mount it
40
CONTENTS
INDEX
and examine the filesystem. This process takes precedence over installing a new main image using the
network.
127(
The recovery image on the STB must be version 2.8.1 or higher. For older STBs
it may be necessary to upgrade them to version 2.8.1 or higher before
attempting installation from a USB storage device (You must perform an
upgrade as a reflash does not update the recovery image).
The recovery image will install the software image from the USB storage device if
the software image is correctly encrypted and signed
it is in the correct location
it is compatible with the STB platform.
If all these conditions are met, the recovery image does not need to check for a network upgrade and so
installs the software image from the USB storage device in the same manner as a downloaded image.
If any one of these conditions is not met then the recovery image will proceed to look for a software image on
the network in the usual manner.
2.7.2
File systems supported
The USB drive must be formatted as FAT32 or EXT.
2.7.3
Software image location on the USB storage device
The recovery image will first look for a directory /Amino at the top level of the file system on the USB storage
device. If this directory is not present then it will look in the root (top level) directory itself.
In the chosen directory, the recovery image will then look for an mcfs file using the following rules:
Product (as the /proc/hwident file on the STB) for example A540.mcfs
Family (as the /proc/hwfamily file on the STB) for example Ax4x.mcfs
Generic for example mc2.mcfs
If a matching file is found, the standard security checks are performed on it and if successful, the software
image is installed on the STB.
If a matching file is not found, or the file found is invalid, the system will revert to performing a network
installation in the usual manner.
INDEX
CONTENTS
41
42
CONTENTS
INDEX
Chapter 3Installing the Ax3x software
In this Chapter:
3.1 Starting the installation
3.2 Configuring the STB time zone
3.3 Configuring the multicast server
3.4 Software images
3.5 Starting the multicast server
3.6 DHCP options
3.7 Using symbolic links when adding new
images
INDEX
CONTENTS
43
The steps in this chapter describe how to set up a basic multicast system for Ax3x STBs. Although it is not
necessary to follow the installation methods exactly, Amino recommend that a similar directory structure is
used in your installation, in order to simplify any subsequent support issues that may arise.
3.1
Starting the installation

In all the following instructions, <release_name> indicates the full name
of the software release image directory that contains your Amino software
release.For example, Ax3x-0.17.6-opera9 installs in 0.17.6Ax3x-opera9, hence <release_name> is 0.17.6-Ax3x-opera9.
127(
1.
Open a terminal window and log on to your system as root, or change to root from a user using:
su
2.
Using mkdir, create directories to contain the software, for example:

mkdir /usr/local/amino
mkdir /usr/local/amino/images
this is where the multicast server will get the images to broadcast.
Also use mkdir to create the directory /usr/local/amino/releases , this is where the
downloaded files will be stored.
Ensure that you have the correct read/write permissions for each of these
directories using:
127(
chmod 777 <directory>
3.

If you require builds for different AmiNET models, it may be useful to create
directories for each type, for example, /usr/local/amino/releases/
A130.
127(
4.
release using:
where
z
Filter the archive through gzip
Extract files from an archive
Verbosely list files processed
Use the specified archive file.
for example:
tar zxvf Ax3x-0.18.0-opera10.tgz
unpacks Ax3x-0.18.0-opera10.tgz to 0.18.0-Ax3x-opera10
44
CONTENTS
INDEX
This will then contain the following sub-directories.

UHOHDVHQDPH
XSJUDGHLPDJH
ERRWVWUDS
VHUYHU
XWLOLWLHV
upgradeimage
Contains the files needed for signing an upgrade image for downloading to the STB.
bootstrap
Contains the files needed for signing a bootstrap image.
server
Contains the files needed for the mcastbootd server.
utils
Contains the generic Amino keys, STBRemoteconf and binaries required for all the above
processes.
5.
Copy the multicast server binary to a directory in the system path, using:
6.
127(
Amino recommends that you regularly copy the contents of the /utils
folder to /usr/local/bin, as STBremoteconf and build configurations
are occasionally updated.
You may see a warning message about cp omitting the /utils/keys
directory. This can be ignored safely.
For Minerva builds, the /utils/keys/amino directory is named
/utils/keys/minerva.
7.
8.
If you are using a dedicated DHCP server (that is, only for this multicast system), then copy the sample
configuration file dhcpd.conf from the software release to the /etc directory, using:
cp <release_name>/server/dhcpd.conf /etc
If you are using a DHCP server that has already been set up with an existing installation, you will be
able to copy the configuration options settings from the sample file (dhcpd.conf) to your existing
DHCP configuration file when you set up your DHCP server for use with Amino products
All the files needed to run the multicast system have now been copied to the locations where they are needed.
You will still need to access some of the other files in the software release directory.
3.1.1
Configuring the DHCP server
For a first set-up of a multicast system (for example, for trial purposes), you are recommended to set up a
DHCP server that will only be used for this multicast system, in order to keep configuration simple while you
are familiarising yourself with the system functionality.
In many deployments it is likely that there will be more than one type of STB installed, each needing different
software images. To implement this, you will need to change both the DHCP server and multicast server
configuration, and ensure that software images for different STB types are uniquely identifiable (either give
them different names or store them in separate directories).
INDEX
CONTENTS
45
A sample configuration file is supplied with the software release, and you can either edit that file or copy the
settings from that file to your existing DHCP servers configuration file.
1.
Open the sample DHCP server configuration file dhcpd.conf in a text editor.
127(
If you copied the file over when you copied the binaries (step 8. above), then
this is located in /etc. Otherwise, it is in the <release_name>/server/
directory and you should complete step 8. above, before continuing.
If you are adding settings to an existing DHCP server configuration file, for
example for another STB, or an additional type of set top box, you will also
need to open the existing configuration file for your DHCP server, and modify
the settings in that file, as per the changes below. For an example of an
edited DHCP configuration file, see Appendix C, Example x3x DHCP
configuration file
2.
The following settings from the sample configuration file need to be copied to the DHCP server
configuration file that you wish to use.
Misc options
allow bootp;
filename=AMINET.txt;
Extra Options for AMINO option space (used for multicast)

option space AMINO;
to..
For further information on this section, see Amino vendor options in DHCP on page 60
3.
For each STB type that you want to multicast to, you will need classes that specify how STBs can get
software images when they are in boot state (mboot class), upgrade state (upgrd class) and normal
boot state (fisys class).
The mboot, upgrd and fisys classes for the A130 are shown in the following extract from the
sample file:
#############################################################################
# AmiNET130 Configuration Section
#
#############################################################################
#
#
# class "AmiNET130 mboot" - boot state when requesting bootstrap image
#
# class "AmiNET130 upgrd" - boot state when requesting main upgrade image
#
# class "AmiNET130 fisys" - boot state when in normal state
#
#
#
#
#
#
# option AMINO.address 225.50.51.50; - the multicast address you are
#
# streaming on
#
# option AMINO.port 11111; - the port you are streaming on
#
#
#
#
#
#
#
# In the mboot class, the bootrom version (e.g. 1.32) must be given in the
#
# vendor-class-identifier. If multiple bootrom versions need to be
#
# supported multiple match cases may be used.
#
46
CONTENTS
INDEX
#
#
#############################################################################
4.
The following sections are available for each STB type:

class AmiNET<STBtype> mboot ...
class AmiNET<STBtype> upgrd ...
class AmiNET<STBtype> fisys ...
For the mboot and upgrd classes:

Use these classes exactly as they are shown in the sample file and edit just the multicast address and
port number to use a unique IP address for each class.
class "AmiNET130 mboot"
{
match if (option vendor-class-identifier="aminoAMINET130mboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2,
9)="AMINET130")
and (substring(option vendor-encapsulated-options, 13,
5)="mboot"));
#
#
#
}
127(
5.
option AMINO.address 225.50.50.52;
option AMINO.port 11111;
225.50.50.52 and 11111 are example values.
The last two lines of the mboot and upgrd classes are in the format:
#option AMINO.address <multicast_address>;
#option AMINO.port <port_number>;
Uncomment these lines.

The multicast address/port number pair must be unique per STB. For this reason either the
multicast_address or the port_number used for mboot and upgrd should be different.
For mboot replace <multicast_address> with the IP address of the multicast server you are
streaming on.
For upgrd replace <multicast_address> with the IP address of the multicast server you are
streaming on.
Replace <port_number> with the port number of the port you are streaming on.
6.
For the fisys class you will also see the following lines in the file:
option AMINO.middleware <mcast address>;
option AMINO.mw_port <port>;
127(
If you have Minerva middleware on the STB type, edit these lines with IP
address and port values for the middleware server. For all other middlewares,
and Ax3x STBs, comment out these lines by adding a # character to the start
of each line.
INDEX
CONTENTS
47
7.
8.
9.
Make a note of the multicast IP addresses and ports you have specified for each STB type, as you
will need to use the same values when you set up the multicast server.
The mboot and upgrd classes for each STB type should also have unique IP address and port pairs.
Edit the following declarations with the settings for your network. You may need to edit the following
lines:
#############################################################
#
Subnet Declaration
#
#############################################################
subnet 192.168.1.0 netmask 255.255.255.0 (
This is optional, but if required replace the existing value with:

subnet <IPaddress of the subnet of DHCP> netmask <sub-net netmask>
For example:
subnet 10.172.0.0 netmask 255.255.0.0 (
#############################################################
#
Default Gateway - This MUST be set!!
#
#############################################################
Replace this with option routers <IPaddress of the default gateway the STB uses
to connect to the internet>;
For example:
#############################################################
#
Subnet Mask - This MUST be set!!
#
#############################################################
option
subnet-mask 255.255.255.0;
Replace this with options subnet-mask <IPaddress of the subnet mask>;

For example:
#############################################################
#
Domain Name - Optional
#
#############################################################
option domain-name blahblah.com;
This should be replaced with your DNS name.

For example:
option domain-name aminocom.com.
#############################################################
#
DNS Servers - Optional
#
#############################################################
option domain-name-servers 192.168.1.1,192,168.1.2;
48
CONTENTS
INDEX
This is optional, but if required replace this with:

option domain-name-servers <IP address of the above DNS name>,<alternative
IP address of the above DNS name>;
10. Edit the NTP server declarations to suit the time zone you are in (that is, uncomment the option
ntp-servers europe.pool.ntp.org; line if you require that option):
#####################################################################
#####################################################################
#####################################################################
#
#
#
#
Fully-specified Posix 1003.1 timezone string #
"GMT0BST-1,M3.5.0/01:00,M10.5.0/02:00"
#
#
# http://h71000.www7.hp.com/doc/73final/6497/6497pro_007.html
#
# http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
#
#
#####################################################################
#############################################################
#
Time Offset - Optional
#
#############################################################
#option time-offset -5; # Eastern Standard Time
#option time-offset +8; # Eastern Standard Time
#option time-offset -5; # Pacific Standard Time
option time-offset 0; # Greenwich Mean Time
11. Edit the address pool declarations so that the STB classes are given an address:
#############################################################
#
Address Pool - This MUST be set!!
#
#
#
#
In this address pool we list the classes which we wish #
#
to give addresses to, unless a device is in this list
#
#
it will not be given an address!
#
#############################################################
pool {
range dynamic_bootp 192.168.1.50 192.168.1.100
range 192.168.1.101 192.168.1.200
...
INDEX
CONTENTS
49
#
#
#
#
#
#
#
#
#
#
For a range of STBs

Replace the pool section of the dhcpd.conf file with:
pool{
range 192.168.1.50 192.168.1.100;
}
where range is the range of the IP addresses for multicast booting and upgrades, in this case from
192.168.1.50 - 100.
For individual STBs

If you have a smaller number of STBs and wish to manage them individually, as in a development
network, the pool information should be replaced with STB specific information similar to the
following:
hardware ethernet 00:03:0A:0C:92:91;
}
hardware ethernet 00:02:0A:13:AA:61;
}
12. Make any further settings you require for your system.
127(
From the following software versions onwards you can add User Class options
to the configuration file if required, and they will be passed to the STB in the
DHCP response.
Platform
Software version
A130/A130M
0.18.0
A130H
0.18.0
A132
0.18.0
A530
0.18.0
A532
0.18.0
13. When you have added classes for each STB type that you are supporting, save your changes, then
copy the edited dhcpd.conf file to the dhcp3 directory (a Debian system directory)
cp dhcpd.conf /etc/dhcp3/
14. Reboot the DHCP server with the following command:

/etc/init.d/dhcp3-server restart
The minimum DHCP server set-up for a multicast system is now complete.
3.2
Configuring the STB time zone
STBs support time zone handling through an NTP client.
50
CONTENTS
INDEX
The time zone can be set in one of the following ways:
Dynamic configuration, using the DHCP server
Static configuration, in the netconf file
In both cases, time zone strings can be in the following formats:
Fully specified Posix 1003.1 time zone string (for example, GMT0BST-1, M3.5.0/01, M10.5.0/02:00
Unix-style definition in the format Region/City (for example, Europe/London)
Commonly used alias (for example, GB-Eire)
3.2.1
Setting the time zone over DHCP
If the STB retrieves its settings dynamically from the DHCP server, you can include the time zone in the settings
that it retrieves.
1.
Open the DHCP server configuration file (dhcpd.conf) in a text editor. This file should be found in
the following location:
/etc
2.
Add the following to the list of Amino vendor extensions (if it is not already there):
option AMINO.timezone code 16=text;
3.
In the subnet declaration in the configuration file, add a line that specifies the time zone you want
to set.
Example:
option AMINO.timezone Europe/Stockholm;
The subnet declaration will now look similar to the following:

subnet
option
option
option
option
option
10.172.0.0 netmask 255.255.0.0 {

routers 10.172.0.1;
subnet-mask 255.255.0.0;
domain-name "aminocom.com";
domain-name-servers 10.171.22.7,10.171.22.9;
AMINO.timezone Europe/Stockholm;
pool {
range 10.172.230.50 10.172.230.100;
}
}
4.
Add an NTP Server if one is not already configured on your network (see paragraph 10. in section
3.1.1 above).
5.
Save your changes and restart the DHCP server.
Next time the STB sends a DHCP request (for example, when it is rebooted), the time zone will be included in
the information that the DHCP server sends.
INDEX
CONTENTS
51
3.2.2
Setting the time zone in the netconf file
For further information on using the netconf settings, see the Amino Set-Top Box Configuration Guide.
If you want to set the time zone statically, you can do it with the following setting in the netconf file:
TIME_ZONE
127(
3.3
If the set-top box receives a time zone value from the DHCP server, it uses this
value in preference to the one in the netconf file.
Configuring the multicast server
The following instructions describe the minimum steps that you need to complete to configure a working
multicast server that provides software images for a single type of STB (for example, as part of a trial system).
The instructions that follow assume that you have already installed, configured and started your DHCP server,
and that you have copied the files from your software release to the example locations.
1.
Navigate to the /etc directory, and open the following file in a text editor:
mcastbootd.conf
2.
Add the Image and Filesystem sections for each type of STB. Each section must be named
uniquely. The software images for each STB type must be unique (they can either be stored in
separate directories or named uniquely by renaming the image files you have created).
3.
In the [Image bootstrap.signed] section, edit the following settings to specify the IP address
and port for multicasting the bootstrap image.
For example:
Here are two Image section examples that specify bootstrap images for two platforms. The images
are named uniquely - bootstrap.130 and bootstrap.530:
[Image bootstrap.130]
FileName=bootstrap.130
Description=Linux bootstrap image
ImageType=1
SerialNumber=1
PacketSize=1456
CycleTime=0
FileName=bootstrap.530
ImageType=1
52
CONTENTS
INDEX
SerialNumber=1
PacketSize=1456
CycleTime=0
These must be the same values as specified in the mboot class of the DHCP server configuration file.
4.
In the same section, check that the FileName setting lists the directory that you will be copying
signed bootstrap images to and has the correct file name.
Filename=bootstrap.signed
This is the bootstap file that will be broadcast by the server.

If you have used the Amino recommended settings, this is:
/usr/local/amino/images/bootstrap.signed
5.
In the [Filesystem mc2] section, edit the following settings to specify the IP address and port for
multicasting the bootstrap image.
For example:
These must be the same values as specified in the upgrd class of the DHCP server configuration file.
Here are two filesystem examples that specify software upgrade images for the same platforms
as in the Image section examples above. Again the upgrade images are named uniquely - mc130 and
mc530:
[Filesystem mc130]
ImageName=mc130
SerialNumber=8
DirsPerCycle=128
DataRate=256
[Filesystem mc530]
ImageName=mc530
SerialNumber=5
DirsPerCycle=128
DataRate=256
Important: The multicast server configuration file must contain a Filesystem section called mc2. If this
section is removed, the signupgradeimage script cannot create new software upgrade images successfully
and will show an error "Filesystem 'mc2' is not configured".
If you want to name sections appropriately for each STB type, then you should leave this section in the file as
a dummy section, and add new sections for each of the STB types that you want to support. If there is no
software upgrade image at the location specified in this dummy section, the multicast server will generate
errors on start-up, but will still run.
INDEX
CONTENTS
53
Example [Filesystem mc2] section

(this can be a dummy section, as described above):
[Filesystem mc2]
ImageName=mc2
SerialNumber=73
DirsPerCycle=128
DataRate=256
6.
Check that the ImageName setting lists the directory that you will be copying signed software
upgrade images to and has the correct name for the image.
ImageName=mc2
This is the upgrade image that will be broadcast by the server.

7.
If you are setting up the multicast server to transmit software for multiple STB types, you will need
to add separate [Image <filename>] and [Filesystem <imagename>] sections for each of
the types of STB. The <imagename> and <filename> must be unique, and must match the name
of the bootstrap and upgrade images for that type of STB. (To set this up, you will also need to
rename the software images you create, so that the image name for each type of STB is unique.) This
is not necessary if you have only configured the DHCP server for a single type of STB.
The multicast server is now set up. Next, you should create software images and copy them to the directory
specified in the configuration file before you start the multicast server.
3.3.1
DHCP and multicast server matching values
For each STB type set up in the DHCP server, the multicast values that the configuration specifies must match
the values that the multicast server uses for transmitting software images. The following table shows the
equivalent settings in the example DHCP server and multicast server configuration files.
Multicast server configuration (example values)

239.255.230.90;
class "AmiNET130 upgrd"

239.255.230.91;
[Filesystem mc130]

239.255.230.80;

239.255.230.81;
[Filesystem mc530]
54
CONTENTS
INDEX
3.4
Software images
The STB NAND flash memory holds two types of signed software image:
Bootstrap image
The bootstrap image contains the software needed to manage the download of a multicast upgrade
image. It is a combined Linux kernel and RAM disk image with an RSA digital signature.
A signed bootstrap image is generated as a file called bootstrap.signed.
Upgrade image
with an RSA digital signature.
A signed upgrade image is normally generated as a file called mc2.mcfs.
3.4.1
Creating a signed bootstrap image
The following steps detail how to create a signed bootstrap image. This is generated as a file called
bootstrap.signed.
The steps outlined here assume that you have set up a multicast server and you have logged in as root. The
Amino software release normally contains the engineering customer key that you will need for creating the
bootstrap image. If you are using your own keys, then you will need to know the pass phrase for your key.
1.
2.
Navigate to the bootstrap directory:

cd /usr/local/amino/releases/<release_name>/bootstrap
3.
Run the signbootstrap script by entering the following command:

./signbootstrap
You will be prompted to enter the password for the key. For the Amino engineering key, the
password is markskey
4.
The script generates a bootstrap.signed file in the bootstrap directory. Copy this file to the /
usr/local/amino/images directory specified by the FileName setting in the [Image
<image_name>] section of the multicast server configuration file (mcastbootd.conf).
For example:
cp bootstrap.signed /usr/local/amino/images/
it next time it needs to upgrade its software. If the multicast server is already running, you will need to restart
it in order for it to transmit the new image.
INDEX
CONTENTS
55
3.4.2
Warning:
mcastbootd.conf must already exist, and be populated, before you use
signupgradeimage, otherwise the signupgradeimage script will fail
saying that the filesystem directory mc2 does not exist.
The steps outlined here assume that you have set up a multicast system and you have logged in as root. The
Amino software release contains the engineering customer key that you will need for creating the signed
software upgrade image. If you are using your own keys, then you will need to know the pass phrase for your
customer key.
1.
Configure the files that will form the release, for example, by changing the default settings in the file
settings or changing the splash image, and add any extra files to the flashcontents file. If you are
setting up a system to familiarise yourself with the components, then you will not need to perform
any configuration at this stage.
The flashcontents file lists the files that will be included in a software upgrade image, and defines
permissions for the file.
Example flashcontents file
This shows a small part of a typical flashcontents file.
# R == file must exist
#
must be read-only
#
# W == file may exist
#
must not be executable
#
we don't care about the checksum
# E == file may exist
#
if it does exist:
#
it must be read-only
#
R
R
R
R
R
R
R
R
R
R
R
R
R
R
W
W
W
56
AMINET.img
libm223.so
libc223.so
xfresco
xfresco.amem
mkfs.ext2
fsck.ext2
tune2fs
mkfs.xfs
font_opt.bin
texttvd
ttsub
bbsdk.cfg
irb_keys.txt
noformat
!poweron
cookies.txt
CONTENTS
INDEX
W history.txt
2.
3.

4.
Run the signupgradeimage script by entering a command in the following format:

./signupgradeimage [-hvz] [-s <pkt-size] [<DI>]
Argument
Usage
-h
Displays help text.
-v
Displays version.
-z
Compresses the image that is produced (this is only needed for

Opera releases, but can also be accepted by other browsers).
-s
Sets the size of the multicast image packets to <pkt-size>

(bytes). This is useful for preventing packet fragmentation in
some networks. The default packet size is 4096 bytes.
<DI>
Sets the deployment index for the image that is created. The
default deployment index is 0 (zero). If you are not controlling
upgrades with a deployment index (from example, in trial
installations), then you can omit this argument. Otherwise,
<DI> must be the same or greater than the software currently
on the STBs that you want to upgrade with this upgrade image.
The exception is for HTTP upgrades where the deployment
index must always be greater than the previous deployment
index (not the same). You are normally recommended to
increment the deployment index by 1 for each upgrade image.
-n <name>
Alternative mcfs file <name> without the mcfs extension

provided the mcfs file is matched within
mcastbootd.conf.
For example (recommended for a trial installation):

./signupgradeimage -h
or
./signupgradeimage -s 2048
or
./signupgradeimage
You will be prompted to enter the pass phrase for the key. For the Amino engineering key, the
5.
The script generates an upgrade image in the current directory. It is normally called mc2.mcfs. Copy
this file to the images directory specified by the ImageName setting in the [Filesystem mc2]
section of the multicast server configuration file (mcastbootd.conf).
For example:
INDEX
CONTENTS
57
it next time it needs to upgrade its software. Alternatively, you can force the STB to upgrade to a specified
version. If the multicast server is already running, you will need to restart it in order for it to transmit the new
image.
3.4.3
Bootstrap/mc2 packet sizes
When signing a bootstrap/mc2 image, for optimum performance the maximum trasmission unit (MTUthe
size (in bytes) of the largest protocol data unit that it can pass onwards) of each image should be equal to the
maximum MTU size allowable on the network, allowing for ethernet, IP, UDP or any other overheads.
Mcastbootd also adds a 16-byte header to each packet, so this must be taken into account in any
calculations.
For example, a DSL PPPoE link might have a frame size of 1518 bytes (say). After headers are taken into
account, the maximum payload might be 1492 bytes.
Assuming mcastbootd adds a 16-byte header, the maximum allowable packet size is therefore 1476 byes.
For the bootstrap, this is configured in mcastbootd.conf with the setting:
PacketSize=1476
The default value is 1456 bytes, which would be acceptable on this network, but sub-optimal.
For the mc2 image, the packet size is defined when signing the image with the signupgradeimage script.
The -s option defines the packet size. The default value is 4096 bytes, which will result in fragmentation on
this network.
signupgradeimage -s 1476
It is worth checking with a packet capture tool such as wireshark when running mcastbootd on an end-toend connection that no packet fragmentation is occurring.
3.5
These instructions assume you have set up the DHCP and multicast servers, and that you have copied signed
bootstrap and software upgrade images to the location specified in the multicast server configuration file.
1.

For example:
2.
To start the multicast server in normal mode, enter the following command:
mcastbootd
To start the multicast server in debug mode, enter

mcastbootd -D.
In debug mode details of its operation are echoed to the terminal. This is useful to monitor its
operation in a trial installation.
The multicast server continuously transmits the software images as a carousel, and when an STB needs to
install a bootstrap or upgrade image, it joins the carousel then retrieves and installs the required files.
58
CONTENTS
INDEX
3.6
DHCP options
The DHCP options for configuration include both Standard DHCP options and Amino-specific DHCP options
(derived from Standard DHCP option 43 - Vendor specific)
3.6.1
Standard DHCP options supported
The supported options are defined in the following table (options not listed here are ignored by the STB). The
options shown in bold are requested by the STB in option 55 - Parameter List.
TAG
NAME
MEANING
IntActOS
support
Linux
support
Used by
STB
Subnet Mask
Subnet Mask Value
Time Offset
Time Offset in seconds from UTC
Router
Router addresses
Domain Server
DNS Server Addresses
12
Hostname
Hostname string
15
Domain Name
The DNS domain name of the client N
17
Root Path
Path name for root disk
23
Default IP TTL
Default IP Time To Live
28
Broadcast Address
Broadcast Address
29
Mask Discovery
Perform Mask Discovery
31
Router Discovery
Perform Router Discovery
33
Static Route
Static Routing Table
40
NIS Domain
NIS Domain Name
41
NIS Servers
NIS Server Addresses
42
NTP Servers
NTP Server Addresses
43
Vendor Specific
Vendor Specific Information
51
Address Time
IP Address Lease Time
53
DHCP Msg Type
DHCP Message Type
54
DHCP Server ID
DHCP Server Identification
55
Parameter List
Parameter Request List
57
DHCP Max Msg Size
DHCP Maximum Message Size
58
Renewal Time
DHCP Renewal (T1) Time
59
Rebinding Time
DHCP Rebinding (T2) Time
60
Class Id*
Vendor Class Identifier
61
Client Id**
Vendor Client Identifier
77
User-Class
User Class Information
90
DHCP Authentication DHCP Authentication
*Standard option 60 Class ID is included by the STB in all requests it sends. (See Class IDs)
**Standard option 61 Client ID is included by the STB in all requests it sends. The value sent is the Ethernet
MAC address of the STB.
INDEX
CONTENTS
59
3.6.2
Amino vendor options in DHCP
Using these options the system integrator can customise the STB, for example, setting the browser to a home
page, by adding option AMINO.homepage http://www.aminocom.com in the fisys class for the
particular STB, and similarly for other options.
Standard DHCP option 43 (Vendor Specific Information) is used to provide the following Amino specific
options. These are not Standard DHCP Options.
127(
Some of these options are specific to x4x boxes , for example codes 25 - 32.
Ensure you are using the correct code for the STB you are installing.

TAG
NAME
TYPE
MEANING
address
ip-address
The multicast FS address, supplied as a 4-byte

value.
port
2 octet
integer
The port number for the group as a short.
product
string
The product identifier, sent from the client to the

server.
option
string
Option string, sent from the client to the server.
version
string
Version number sent from the client to the

server.
middleware
ip-address
The middleware multicast address, supplied as 4byte value.
mw_port
2 octet
integer
The middleware port to use on that group

(short).
homepage
string
The browser homepage (string).
dindex
integer
Deployment index (int).
10
dindex_min
integer
Deployment index minimum (int): Triggers an

automatic upgrade if the deployment index on
the box is less than this. If there is no minimum,
never automatically update. .
11
dindex_page
string
Deployment index upgrade page (string)

where to get the upgrade from.
12
STBrc_mcast_address
ip-address
STBremoteconf multicast group (4-byte value).
13
STBrc_mcast_port
2 octet
integer
STBremoteconf multicast port (short).
14
STBrc_ucast_port
2 octet
integer
STBremoteconf unicast port (short)
15
local_config
string
Local config URL (string) location of a config

tarball that should be downloaded at boot
16
timezone
string
Timezone string
(Either fully specified e.g.
"GMT0BST-1,M3.5.0/01:00,M10.5.0/
02:00"
or
zoneinfo-style e.g. "Europe/London")
60
CONTENTS
INDEX

TAG
NAME
TYPE
MEANING
17
middleware2
ip-address
The alternative middleware multicast address,

supplied as 4-byte value.
18
mw_args
string
CLI arguments string to be passed to the

middleware.
19
AMINO INTERNAL
TEST host machine IP-address.
20
AMINO INTERNAL
TEST directory path string.
21
recovery-mode
1 octet
integer
Recovery mode. Used by IntActOS to instruct it to

store a bootstrap as a recovery image (see
saverecov and loadrecov in sm- filmod).
Used by bootstraps to determine how/whether
to start the recovery UI.
1.
Boot on-board recovery bootstrap if

present. If not present then run mboot
and store downloaded bootstrap as onboard recovery bootstrap.
2.
Ignore any on-board recovery bootstrap

and perform mboot. Do not store
downloaded bootstrap.
3.
Ignore any on-board recovery bootstrap

and perform mboot. Store newly
downloaded bootstrap as recovery
image. (WARNING: restrict use as it will
install recovery image on every reboot.)
22
mw_args
string
Mirimon CLI arguments string
23
agama_args
string
Agama CLI arguments string.
24
reserved testing
text
Reserved for Amino internal use.
25
software_di
2 octet
integer
26
recovery_di
2 octet
integer
27
pbl_di
2 octet
integer
28
software_uri
string
29
recovery_uri
string
30
pbl_uri
string
31
hw_options
string
32
extra_options
string
50
mbc bootorder
string
The boot method used for the STB: multicast,

unicast or recon. Note that combined boot
methods can be used (see the Mood Boot Server
Configuration Guide for further information).
51
mbc SAP
string
Multicast address for the SAP/SDP carousels.
52
mbc unicast
string
Public IP-address for MBS.
These options are used on Ax4x STBs only.
INDEX
CONTENTS
61

TAG
NAME
TYPE
MEANING
53
recon
string
Public IP-address for recon boot server (see the

Mood Boot Server Configuration Guide for
further information).
You will find the following code listing the Amino vendor options in the dhcpd.conf file.
option space AMINO;
code
1 = ip-address;
option AMINO.port
code
2 = integer 16;
code
3 = text;
option AMINO.option
code
4 = text;
code
5 = text;
code
6 = ip-address;
code
7 = integer 16;
code
8 = text;
option AMINO.dindex
code
9 = integer 32;
code 11 = text;
62
code 15 = text;
code 16 = text;
code 18 = text;
code 20 = text;
code 22 = text;
option AMINO.agama_args
code 23 = text;
option AMINO.reserved_testing
code 24 = text;
option AMINO.pbl_di
code 28 = text;
code 29 = text;
code 30 = text;
option AMINO.hw_options
code 31 = text;
code 32 = text;
option AMINO.mbc_bootorder
code 50 = text;
option AMINO.mbc_SAP
code 51 = text;
CONTENTS
INDEX
3.6.3
option AMINO.mbc_unicast
code 52 = text;
option AMINO.recon
code 53 = text;
Class IDs
Standard option 60 - Class ID is included by the STB in all requests it sends. The value that the STB includes for
this option depends on whether the request is from the Linux or IntActOS level.
3.6.3.1 Linux
For the Linux images, the value of the string sent is based on the following format:
Amino<product><type>
where <product> is the value of an internal "product" (for example, AMINET130) and <type> is upgrd for
the upgrade images and fisys for the main images.
3.6.3.2 IntActOS - multicast versions

For IntActOS multicast versions, the value of the string sent is based on the following format:
insecure<product>mboot<romver>
or
amino<product>mboot<romver>
where <product> is the value of an internal platform type environment variable, for example, AMINET130
and <romver> is the version number of the BootROM.
For example:
aminoAMINET130mboot1.34
3.6.3.3 IntActOS - TFTP versions

For IntActOS TFTP versions, the value of the string sent is:
amino
or
insecure
3.7
Using symbolic links when adding new images
If you are implementing a system in which you will be updating the software image that an STB needs to
download (for example, to provide images that use new software versions), it can be useful to put in place an
image directory structure that uses symbolic links, so that it becomes unnecessary to edit the multicast server
configuration file for every new software image. The following instructions tell you how to do this.
The steps that follow assume you have already set up the multicast server as detailed in TIME_ZONE on page
52.
1.
Create a directory structure with a separate directory for each type of STB that you are supporting,
each with a subdirectory for the current version.
For example, if you are supporting the AmiNET130 and AmiNET530, and you are currently using
software version 0.18.0 for both, create the following directories:
INDEX
CONTENTS
63
<images>/A130/0.18.0
<images>/A530/0.18.0
2.
Create the bootstrap and upgrade images for each software version, and copy them into the
appropriate directories. There is no need for the images for each STB type to have different names
from each other, as they are already uniquely identified by their directory location. The configuration
example below assumes both bootstrap images are called bootstrap.signed, and both upgrade
images are called mc2.
3.
Create symbolic links called current for each of these directories.

Example:
ln -s <images>/A130/0.18.0 <images>/A130/current
ln -s <images>/A530/0.18.0 <images>/A530/current
4.
Edit the multicast server configuration file to include sections for each image, using the same
multicast IP addresses and ports as specified in the DHCP server configuration. Instead of giving the
image location directory by version number, use the current symbolic links that you have just
created. You will also need to keep the original mc2 section with dummy settings.
Example configuration file:
127(
The multicast server values shown are example values.
# Configuration file: Wed Sept 19 10:25:51 2007

[Server]
LogLevel=4
MulticastTTL=5
ImageDir=/usr/local/amino/images
[Image A130Bootstrap]
FileName=130/current/bootstrap.signed
ImageType=1
SerialNumber=1
PacketSize=1456
CycleTime=0
[Image A530Bootstrap]
FileName=A530/current/bootstrap.signed
ImageType=1
SerialNumber=1
PacketSize=1456
CycleTime=0
[Filesystem mc2]
64
CONTENTS
INDEX
ImageName=mc2
Description=DUMMY upgrade filesystem
SerialNumber=149
DirsPerCycle=128
DataRate=512
[Filesystem A130Upgrade]
ImageName=A130/current/mc2
SerialNumber=6
DirsPerCycle=128
DataRate=512
[Filesystem A530Upgrade]
ImageName=A530/current/mc2
SerialNumber=6
DirsPerCycle=128
DataRate=512
5.
Save your changes and restart the multicast server.
Next time you need to add a new software image for the platforms you have set up:
1.
Create a subdirectory with the new version number.

For example, if youre adding images for version 0.18.3, for the AmiNET130, create the following
directory:
<images>/A130/0.18.3
2.
Change the current symbolic link to this new directory instead of the 0.18.0 one:
ln -s <images>/A130/0.18.2 <images>/bootstrap/A130/current
3.
The multicast server configuration sections already point to the current directory, so all you need
to do to start transmitting the new images is restart the multicast server. The images will
automatically come from the new directory.
INDEX
CONTENTS
65
66
CONTENTS
INDEX
Chapter 4Upgrading Ax4x STBs
In this Chapter:
4.1 Upgrade mechanisms
4.2 Upgrading the software
4.3 The STB operational state
4.4 The Reflash/Reset button
4.5 STB configuration
4.6 Automatic upgrading
4.7 Automating multicast server start-up
4.8 Using the DI for automatic upgrade
4.9 Customising upgrade splashscreens
INDEX
CONTENTS
67
UPGRADING AX4X STBS
images.
127(
4.1
There are changes in the upgrade procedure for x4x STBs: refer to Additional
information for upgrading x4x STBs.
Upgrade mechanisms
STBremoteconf remote configuration tool that enables you to send commands such as changing basic
configuration settings or initiating software upgrade.
Management pages local configuration pages, using an Amino IR keyboard and television display to
change configuration settings and simple commands such as rebooting and initiating software upgrades.
DHCP server configuration DHCP server configuration specifies where STBs go to retrieve software
images transmitted by the multicast server, it can also be configured to force upgrades by specifying
minimum deployment index numbers for software versions that the STB must be running. DHCP server
and Multicast server together also enable the STB to connect and retrieve new software images when
required (for example, if the software on the STB is corrupted).
The JMACX API offers functions for controlling a range of STB operational areas, including software
upgrades. This manual does not cover the use of the JMACX functions, please see the Amino JMACX API
Specification for more information.
The Reset button the software recovery image (Reset) button on the rear panel provides a method of
trying to recover unresponsive STBs in the field by running a basic boot image from which the STB can
boot and obtain the latest SW via normal upgrade processes. It can also be used to reset the STB to
factory defaults. See The Reflash/Reset button for further information.
Upgrading using HTTP allows remote upgrading of STBs over unmanaged networks. See Upgrading
using HTTP.
127(
Whilst HTTP itself is not an upgrade mechanism, in the context of Amino STBs
Upgrading using HTTP means upgrading the STB by a process that uses the
HTTP transport protocol.
As detailed in the table below, the various upgrade mechanisms are each suited to particular contexts. For
example, making images available by defining upgrade groups and ports in the DHCP server configuration
enables automatic upgrades when the STB requires them, but STBremoteconf can be used to force an
upgrade at a required time.
In the table below, Reflash refers to deleting all the contents of the NAND Flash and completely replacing the
main software image. All configuration options, except those stored in NOR Flash, will be replaced with the
configuration contained in the new software image. Upgrade refers to replacing just the main software image.
In this case, some of the configuration files, for example the user settings, may be preserved. This can be
controlled when the software image is built.
68
CONTENTS
INDEX
UPGRADING AX4X STBS
4.1.1
Using STBremoteconf to upgrade software
Contexts
STBremoteconf
Remote
Management DHCP server Upgrade over

pages
configuration HTTP
Local
Single STB
Large deployment
Test settings
Ya
Automatic
Manual
Y
Y
Y
Y
Yb
Operation
Upgrade software
Reflash
Upgrade to min. DI number

Upgrade to min. version number
Y
Y
a. Not recommended: requires all STBs to be powered.

b. Currently, the REFLASH command is not recommended as this will not upgrade the PBL or the recovery
image. The suggested method is to use the UPGRADE command via STBremoteconf, or by running
the pre/post-upgrade scripts from a working STB image. This will then upgrade the PBL and recovery
image and validate them before upgrading the main software image.
STBremoteconf provides a mechanism for remotely configuring and controlling a local network of AmiNET
STBs. It can be run on a Linux/Unix command line by sending commands individually to one or more STBs, or
commands can be collected into a script to save time. Commands are signed when they are created, so that
the STB can confirm that the commands have been sent by an authorised source.
Example functions include rebooting, modifying output modes or updating software, as well as viewing
information about the STB.
The UPGRADE command enables you to instruct an STB to upgrade. See the Set-top Box Configuration Guide
for further details about STBremoteconf.
4.1.2
Using the Management pages to upgrade software
STBs with built-in browsers include HTML configuration pages, displayed on the television screen, to enable
local access and editing of configuration areas. The pages are divided into an administrator area (Management
pages) and user area (Preferences pages).
The STB Management pages are a simple interface that enable administrators to change STB configuration
areas such as networking, channel list and browser set-up, as well as initiate basic operations such as
rebooting and updating software. Management pages allow access to advanced configuration functions and
are designed for use by administrators rather than end-users. The pages are password-protected and
accessed locally via an Amino IR keyboard. Limited functionality is also supported via the remote control.
You can instruct an STB to upgrade or reflash from the Update Software Management page. See the Set-top
Box Configuration Guide for further details.
The STB Preferences pages are a simple interface that enables users to change basic STB configuration areas
such as language, subtitle and keyboard set-up. The pages are accessed locally using an Amino or Ruwido
INDEX
CONTENTS
69
UPGRADING AX4X STBS
InfraRed (IR) remote control or keyboard. The Preferences pages are designed for use
by end-users.
4.1.3
Using the DHCP server to upgrade software
The DHCP server and multicast server enable the STB to retrieve software upgrades when it needs them. You
can also configure the DHCP server so that the STB automatically upgrades to a specific software version, even
if its current software is running normally. See Automatic upgrading for details of how to enable automatic
upgrades.
4.1.4
Summary of upgrade methods

Multicast
Unicast
Use mcastbootd to multicast the signed upgrade Use HTTP to direct the STB to the signed upgrade
image from the multicast server
image on a web server
The upgrade can be initiated by the STBremoteconf UPGRADE command
./STBremoteconf <host> UPGRADE
igmp:// <Multicast Upgrade address>:
<Upgrade port number> See also Source
./STBremoteconf <host> UPGRADE http:/

/<location>/mc2.mcfs
where <location> is the address and folder on
Specific Multicast.
the web server where the image is located.
......or initiated by the JMACX ASTB.Upgrade( ) command

number ASTB.Upgrade (igmp://
<Multicast Upgrade address>, <Upgrade
port number>)
number ASTB.Upgrade ("http://

<location>/mc2.mcfs")

......or by using DHCP configuration
Use option AMINO.software_uri
Use option AMINO.software_uri
"igmp://<mcast address>:<port>"
("http://<location>/mc2.mcfs")
where <mcast address>:<port> are the

address and port from which you are streaming
the upgrade image. See also Source Specific
Multicast.
......or by navigating to Upgrade in the Management pages

Navigate to the Upgrade page, enter the URI of
the multicast server then press the blue button
on the Remote Control Unit.
Navigate to the Upgrade page, enter the URI of

the web server where the image is located
"http://<location>/mc2.mcfs",then press
the blue button on the Remote Control Unit.
4.1.4.1 Source Specific Multicast

Source specific multicast (SSM) is supported for Ax4x STBs from software version 3.2.1. To use SSM, your
network must be configured to use IGMPv3 and STBs must be provisioned from Amino with IGMPv3 enabled.
Up to eight include and eight exclude multicast addresses can be specified.
70
CONTENTS
INDEX
UPGRADING AX4X STBS
In a normal multicast situation, the address of the upgrade image is specified by the
string:
"igmp://<mcast address>:<port>"
whereas for SSM, the string now has the additional addresses that should be included or excluded:
igmp://<mcast address>:<port>?incl=<address 1>,<address 2>,,,,,,<address 8>
or
igmp://<mcast address>:<port>?excl=<address 1>,<address 2>,,,,,,<address 8>
SSM can also be used via STBremoteconf. The libconfig setting REMOTECONF_URI indicates the address that
the STB listens on for SSM commands via STBremoteconf. For details of this setting refer to the Amino Settop box Configuration Guide.
4.2
Upgrading the software
This section describes a laboratory-based upgrade process and is a sub-set of the instructions found in Chapter
2, Installing the Ax4x software .
The following instructions assume the use of the Debian operating system.
127(
The commands in this section require you to be logged on as a superuser, or

to use the sudo command.
1.
2.
release using:
3.
4.
5.
4.2.1
1.
settings or changing the splash image, and add any extra files to the flashcontents file.
2.
3.

4.
Run the signupgradeimage script by using:

./signupgradeimage
INDEX
CONTENTS
71
UPGRADING AX4X STBS
You will be prompted to enter the pass phrase for the key. For the Amino
engineering key, the password is markskey.
5.
The script generates mc2.mcfs in the current directory. Copy this file to the images directory
specified by the ImageName setting in the [Filesystem mc2] section of the multicast server
configuration file (mcastbootd.conf).
For example:
it the next time the STB needs to upgrade its software. If the multicast server is already running, you will need
to restart it to transmit the new image.
4.2.2
1.

For example:
2.
Enter the following command:

mcastbootd to start the multicast server in normal mode.
mcastbootd -D starts the multicast server in debug mode, and details of its operation are echoed
to the terminal. This is useful to monitor its operation in a trial installation.

The multicast server continuously transmits the software images as a carousel, so when an STB needs to install
an upgrade image, it joins the carousel and retrieves and installs the required files.
4.2.3
Additional information for upgrading x4x STBs
4.2.3.1 Release Structure Changes

The customer release tarball for x.x.x-x4x now includes the following files for the Primary Boot Loader (PBL)
and recovery image:
/x.x.x-Ax4x-operaXX/upgradeimage/imagecomponents/bin
recovery.image
recovery.supported
recovery.version
pbl.branding
pbl.image
pbl.supported
pbl.version
Where the PBL image and/or the recovery image are known to be the same versions as on the STB, they can
be omitted from the bin folder to reduce the size of the upgrade image, then copied back later from their
respective folders.
72
CONTENTS
INDEX
UPGRADING AX4X STBS
The .image files are pre-signed images which will install on an STB containing any
Customer key.
The .supported files list the hardware component IDs that are supported by the software being installed (if
hardware components are detected that are not in this list, the upgrade will stop).
The .version file is a text file specifying the version number of the component and is used to populate the
new NORFLASH version values. These in turn are used to provide the version numbers on the new info
preferences page.
4.2.3.2 Upgrading the STB

The suggested method is to use the UPGRADEMCAST command via STBremoteconf, or by running the pre/
post-upgrade scripts from a working STB image. This will then upgrade the PBL and recovery image and
validate them before upgrading the main software image.
4.3
The STB operational state
The sections that follow provide detail about the STB operational state, including how STB operation is
affected if one of the actions that the STB executes is not successful.
The state an STB is in depends on the existence of a current software image in its NAND Flash, or whether it
can load that software successfully. Each time an STB enters a new state, it sends a DHCP request that includes
an appropriate string to identify its current state, as defined by Amino vendor extensions added to the DHCP
servers configuration file.
When an STB is powered, it attempts to execute software from its NAND Flash. If this is successful, the STB
enters its normal boot state. During the boot process the STB will display the following screen:
INDEX
CONTENTS
73
UPGRADING AX4X STBS
When the STB has booted successfully the following screen wil be shown:
127(
If there is a failure during this state, a sequence of flashes of the LED on the
STB indicates the reason. Refer to Appendix A, LED flashing codes for
details of these flashing codes.
4.4
The Reflash/Reset button
It is important to note the differences between Upgrade, Reflash and Reset.

Upgrade - means replacing the main software image, recovery image and bootloader. Some of the
configuration files, for example, the usersettings file, are preserved. To do this, the box downloads the
new software image, copies out the files to be preserved and copies them back once the upgrade is
completed.
Reflash - means deleting all the contents of the NAND Flash and completely replacing the main software
imagewith a new one. All configuration options, except those stored in NOR Flash, will be replaced with the
configuration contained in the new software image. After issuing a reflash command, the STB will reboot and
starts with no software. It will then attempt to download a new software image.
Reset - means resetting the NOR Flash settings to the factory default values without upgrading the software
image.
The STB can be reflashed or reset by using the reflash/reset button on the back of the STB.
This button can be used in two ways depending on the sequence in which it is pressed:
You can reflash the STB by following the procedure in The reflash sequence.
You can reset the STB by following the procedure in The reset sequence. The reset sequence triggers a
'factory reset', which resets each NOR configuration item to the 'default' value stored for it (if a default
value is available).
4.4.1
The reflash sequence
The reflash sequence must only be used if there is an AmiNET software image available on the network (either
via multicast or HTTP) and if the STB can reach the network and the DHCP server.
74
CONTENTS
INDEX
UPGRADING AX4X STBS
If the box is configured for static network addressing then, in addition to the address information, a
software_uri must also be configured so that the STB knows where to find the image.
If a box that is configured for static addressing was originally supplied for use
in a DHCP environment, the reset sequence can be used initially to return it
to a DHCP configuration before the reflash sequence is used to replace the
software image.
To reflash the STB:

1.
Ensure power is disconnected from the STB. Press the button then connect power while you are still
pressing the button. Release the button when the 'Amino' splash screen appears.
INDEX
CONTENTS
75
UPGRADING AX4X STBS
2.
The STB will then continue to boot as normal:
76
CONTENTS
INDEX
UPGRADING AX4X STBS
3.
If the STB cannot find a software image on the network (for example it is configured for static
addressing without a software URI, or it is unable to get a response from a DHCP server), then the
Connect network cable screen will be displayed for approximately one minute and the STB will
reboot and start with its existing software image.
4.
If a software image is now available the Upgrading. Do not unplug screen will be shown and the
STB will load the new upgrade image.
The time taken to upgrade will depend on your network configuration.
INDEX
CONTENTS
77
UPGRADING AX4X STBS
5.
When the upgrade is complete the Upgrade successful screen is shown and the STB will boot into
the new image.
4.4.2
The reset sequence
To reset the STB you will need to monitor the STB actions on a terminal while viewing the screen:
1.
Ensure power is disconnected from the STB. Press the button then connect power while you are still
pressing the button. Release the button when the 'Amino' splash screen appears. Follow the cosole
instructions as they appear (shown in full below):
************************************************
Checking for recovery image reset button options
************************************************
Allowing 5 seconds for user to let go of button
Button must not be pressed for 5 seconds
Button must be pressed in the next 10 seconds
Button detected.
Hold for 3 seconds to restore default configuration
Restoring default configuration in 10 seconds
4.4.3
Static DHCP settings
The descriptions that follow outline STB operation in cases where the STB relies on the DHCP server for its
network and other settings. Where these settings are defined statically in the STBs configuration, they can
either be used as a fall-back if communication with the DHCP server fails or they can be used in place of
DHCP communication. How these static settings are used depends on configuration.
Once the STB has found, downloaded and installed a valid upgrade image, it enters its operational state. The
STB will also enter this state in response to a manual upgrade request (for example, one initiated via
STBremoteconf). In this state, all non-essential applications are closed, and the STB can download and
78
CONTENTS
INDEX
UPGRADING AX4X STBS
execute a new software upgrade image.

The sequence of events is as follows:
,W^

EE&
s
D/EK
^d
,WZ
D^

:h'

^

Z

hZKD
Figure 4.2 Operational sequence
4.4.4
DHCP request and response
The STB sends a message to the DHCP server, including the vendor class identifier AMINOx4x, identifying the
hardware platform. The DHCP server compares the state and the platform string against classes defined in its
configuration file.
When the DHCP server identifies an appropriate class, it responds to the STB with network settings and the
vendor extensions defined in that class. These vendor extensions are an IP address and port for retrieving an
upgrade image that is being transmitted by the multicast server. If the DHCP server does not find a class, then
it cannot provide the information that the STB needs.
If the STB does not receive a response from the DHCP server after a number of attempts, it tries to move to
the next stage using the settings in its configuration (that is, using null values for the multicast IP address and
port if these have not been set in the configuration so the download will not succeed).
4.4.5
Download image
The STB connects to the multicast carousel with the IP address and port details it has received from the DHCP
server, and downloads the upgrade image. If it fails to download the image within a defined timeout, the STB
reboots, and returns to the initial powered state.
INDEX
CONTENTS
79
UPGRADING AX4X STBS
4.4.6
Assemble, verify and execute image
The STB verifies the new image by using the public customer key it holds to check the digital signature that
the image is signed with. It also compares the deployment index (DI) of the software against its current index.
If the software is successfully verified, the STB stores it in its NAND Flash and executes it.
If the software is not successfully verified and executed, the STB resets itself. How it behaves at this stage
depends on what stage of the verification process it failed at: it can either reboot or re-enter the upgrade
state.
127(
At this point the NAND Flash could potentially be corrupted by a power outage
or other failure. If this happens, the STB will detect it and return to the
bootstrap state.
Once the STB has found and executed a valid software image from the NAND Flash, it enters the operational
state. In this state, the STB is running and available for normal use. An administrator can initiate a software
upgrade using one of the management tools (for example, STBremoteconf).
When the STB first enters the operational state, it will show the page that has been set as the default home
page. For example, for a standard Amino build with the Opera browser, a screen similar to the following is
displayed:
4.4.7
DI and external instruction
If the minimum DI supplied is greater than the current index of the STB, the STB enters the upgrade state, to
download a new software version. The STB must have been supplied with a multicast IP address and port in
order for this upgrade to be successful. If the upgrade fails, then the STB returns to normal operation, using
its current software version. See also Automatic upgrading.
If the STB receives an upgrade instruction from an external application, the STB enters the upgrade state,
using the multicast IP address and port supplied in the upgrade instruction. Again, if the upgrade fails, the STB
returns to normal operation without upgrading its software.
Otherwise, the STB is available for normal operation.
80
CONTENTS
INDEX
UPGRADING AX4X STBS
4.5
STB configuration
The multicast system offers a range of tools for configuring STBs, depending on factors such as whether you
are testing new settings or rolling out configuration for a software upgrade, and whether you are configuring
the box remotely or locally. For an overview of configuration methods, see the Set-top box Configuration
Guide.
4.6
Automatic upgrading
Automatic upgrading to a specified minimum DI is set up in the DHCP server. The following steps outline how
to implement this system:
127(
These steps assume you have already set up a multicast upgrade system and
the software image is in the location specified in the multicast servers
configuration.
1.
Open the DHCP server configuration file (dhcpd.conf).
2.
Find the Amino options (under option space AMINO;) and ensure that the following line is
included (add it if it is not there already):
option AMINO.software_di code 25 = integer 16;
3.
Under the class AMINOx4x, and under vendor-option-space AMINO; add a line in the
following format:
option AMINO.software_di <minimum_DI>;
For example, if you want STBs to be running software with the minimum deployment index of 5, the
line should be as follows:
option AMINO.software_di_5;
4.
Again ensure that the following lines are present, and specify the correct multicast IP address and
port:
option AMINO.software_uri "igmp://<mcast address>:<port>"
5.
The AMINOx4x class you are editing should now look similar to the following:
class "AMINOx4x"
{
option AMINO.software_di <minimum_DI>;
option AMINO.software_uri "igmp://<239.255.225.100>:<11111>";
}
6.
Save your changes and restart the DHCP server. Also ensure the multicast server is running.
The system is now set up. Next time an STB of the configured type boots, it will compare its current DI with
the one you specified, and will upgrade to the specified software image if its current DI is lower than the one
in the DHCP server configuration.
4.6.1
Testing automatic upgrading
Once you have implemented automatic upgrading using a specified minimum DI to force upgrades, you can
test the system. The following steps assume that Telnet (or other remote log-in client) is enabled in the STB.
INDEX
CONTENTS
81
UPGRADING AX4X STBS
Check the DI number of the STB you are going to test with. You can do this from the command line
by Telnetting to the STB and entering the following command (the current DI number must be lower
than the one you want to upgrade to):
libconfig-get NORFLASH.DI
2.
Power up (or reboot) the STB.

The loading screen is displayed (the default image has Loading followed by Upgrading, do not
unplug!).
3.
When the upgrade is finished, you can check that the STB is running the new software version and
you can check the DI, as in step 1 (it should now have the DI specified in the DHCP server
configuration file).
4.6.2
Static network and multicast upgrade settings
Some DHCP servers do not support the addition of the vendor extensions that this multicast upgrade system
uses to tell STBs the IP address and port to use for retrieving software images (for example, AMINO.address
and AMINO.port). In these cases, the DHCP server can be used to assign an IP address to the STB, then you
configure the addresses and ports to use for software upgrades as static values in the STB configuration.
In other installations, it may be useful to set all network settings statically, rather than retrieving them from
the DHCP server.
In both cases, the static values are normally defined in the NOR Flash, which you can edit in the following
ways:
libconfig commands in the upgrade script (recommended method)
libconfig commands via a remote log-in tool (for example, Telnet)
via the Management pages (Network Configuration page)
JMACX calls in an HTML page (not recommended, for security reasons)
For details of how to use the tools available to change settings, see the JMACX API Specification and the SetTop Box Configuration Guide.
The recommended way to set static multicast upgrade and network values for multiple STBs is to add
libconfig commands to the upgrade script that is included as part of a software image. The script executes
automatically when the new software image is loaded to the STB, and is then deleted.
4.6.2.1 Setting static multicast upgrade values

127(
Valid multicast addresses must be set for multicast upgrades to work. If an

address is invalid, the STB tries to retrieve an IP address via DHCP. If this is not
successful or if the address that the STB retrieves via DHCP is also invalid
the STB reboots.
4.6.2.2 To set a static IP address

IPADDR
Other network settings

NETMASK
GATEWAY
DNS
82
CONTENTS
INDEX
UPGRADING AX4X STBS
TIME_SERVER
Required vs. optional settings

The list of values that must be defined statically depends on what functionality your DHCP server supports.
The following guidelines apply:
Required multicast upgrade settings

If the DHCP server is being used to provide network settings, but not the multicast upgrade settings (that
is, the DHCP server does not support the Amino vendor extensions), the upgrade settings are required.
The filesystem settings are normally optional, although this will depend on the functionality you want to
enable in the system.
Required network settings
If the DHCP server is not being used to provide network settings, then most of the values listed are
required, only DNS and TIME_SERVER are optional.
4.6.2.3 Example upgrade.sh script to set static multicast upgrade values

The recommended way to set static network and multicast upgrade values for multiple STBs is to add
libconfig commands to the upgrade script which is added to the image components used to create a
software upgrade image. When the new upgrade image is loaded to the STB, the script executes
automatically, and is then deleted.
127(
The software image containing this upgrade script must be installed on the
STBs before they are installed on a network that requires the static settings.
This is because the STB requires these network settings in order to retrieve the
new software image.
The following script uses libconfig commands to set values for some of the multicast upgrade settings
(upgrade ports and IP addresses) in the NOR Flash:
For example:
#!/bin/sh
libconfig-get NORFLASH.SOFTWARE_URI <http_URL>
For more information, see NOR Flash configuration in the Amino STB Configuration Guide.
4.7
Automating multicast server start-up
By default, the multicast server does not start when you start the server it is installed on. You can enable
automatic start-up by creating an mcastbootd script in /etc/init.d, and running the following command
to start the service:
chkconfig mcastbootd on.
The multicast server will be started automatically on the next reboot.

The following example start script works with Redhat Linux.
#!/bin/bash
#
# chkconfig: 2345 55 25
# description: Amino Multicast Daemon
# processname: mcastbootd
# config: /etc/mcastbootd.conf
INDEX
CONTENTS
83
UPGRADING AX4X STBS
# Source function library.

[ -f /etc/rc.d/init.d/functions ] || exit 0
. /etc/rc.d/init.d/functions
# getting the Mcastbootd options
. /etc/sysconfig/mcastbootd
RETVAL=0
start() {
echo -n $"Starting Mcastbootd server services: "
mcastbootd $MCASTBOOTD_ARGS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/mcastbootd
return $RETVAL
}
stop() {
echo -n $"Stopping Mcastbootd server services: "
killproc mcastbootd
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/mcastbootd echo
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start ;;
stop)
stop ;;
status)
status mcastbootd ;;
restart|reload)
stop start ;;
condrestart)
if [ -f /var/lock/subsys/mcastbootd ]; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
exit 1
esac
exit $RETVAL
84
CONTENTS
INDEX
UPGRADING AX4X STBS
4.8
Using the DI for automatic upgrade
In normal operation, the STB downloads new software from the multicast server when there is a problem with
its current software or when an upgrade command instructs it to do so (for example, from
STBremoteconf, the Management pages or a JMACX call). Using the DI, it is also possible to configure the
multicast upgrade system to force STBs to upgrade to a particular software version as identified by the
softwares DI.
4.8.1
How it works
The STB stores the DI of its current software version in the NOR Flash.
A new DI is specified when a new signed software upgrade image is created with the signupgradeimage
script. The DI is an integer between 0 and 65535.
When the STB receives the new software version, it checks the DI against the number in its NOR Flash, accepts
the software upgrade if the new number is the same or greater, and changes the DI in its NOR Flash
accordingly. Otherwise it rejects it.
For trial versions and for early stages of a project, we recommend you use a DI
of 0 (zero). This means that you do not need to specify the DI when you create
a new upgrade image. Once the deployment is live, the service provider
should increase the DI by 1 when asked to produce a new version by the
software provider (for example, the CA or middleware vendor).
4.8.2
DI and software versioning
The DI mechanism is completely separate from software version numbers. This means that if necessary a
service provider can downgrade from a current software version to an older one, as long as they create a
software upgrade image with a higher DI than the current software version.
VIDEO
4.8.3
A video showing how Deployment Index works is available at:

Select:
How Deployment Index works in Amino x4x STBs
Migrating from pre-DI to DI-capable software
All STBs are manufactured with an initial DI of 0 (zero) in their NOR Flash. To start using the DI mechanism in
a system that currently does not implement this control, just increase the DI to 1 in the next software upgrade
image that you create.
4.8.4
Setting up automatic upgrade to minimum DI
The DI mechanism can be used to force STBs to upgrade to a specified minimum DI, using Amino DHCP vendor
extensions. The minimum index number is added to the DHCP configuration. When the STB boots up and
contacts the DHCP server, the DHCP server includes this DI in its response, along with the multicast upgrade
address and port for the upgrade image. The STB checks this index against the DI in its NOR Flash, and
upgrades immediately if its index is lower than the specified value.
INDEX
CONTENTS
85
UPGRADING AX4X STBS
4.8.4.1 Resetting the DI

For security reasons Amino do not provide a method of resetting the DI remotely on an STB. However, it is
possible to retrieve the current DI through telnet.
Telnet to an STB, and run this command:
If, having obtained the DI, the software download is configured with a DI higher than the current value and
the STBs are all reflashed, they will all be on the same, new, DI.
4.9
Customising upgrade splashscreens
The upgrade splashscreens can be configured to display your corporate logo or choice of graphic, and the
status of the upgrade can be displayed in your corporate font and re-phrased if required. Furthermore the
error codes that are represented by the flashing LED can be displayed numerically on the screen.
Configuration of the splashscreen uses three "regions" on the screen. Region 1 is the top 2/3 and is used for
displaying the logo. The remaining 1/3 is split into two regions where region 2 displays the stage of the
upgrade (for example fetching data or Installing. Do not unplug ) and region 3 is used to display the two
digits of the error code.
Customising the upgrade display consists of simply replacing the graphics used for the display with your own
graphics to create a display in your preferred format, font, colour etc.
The supplied graphics are located in upgradeimage\imagecomponents\upgrade_branding.tgz.

Replace the graphics in the .tgz file with your own. When you use your own graphics, you must keep the same
filenames as those given in the release because the upgrade script will look for those filenames. For example,
your logo must be called logo.gif.
86
CONTENTS
INDEX
UPGRADING AX4X STBS
The following diagram shows how you can assemble your customised upgrade display by substituting the
graphics provided in the release image with your own:
z
ORJRJLI
^
ZLUHGFDEOHJLI

QXPJLI
QXPJLI
INDEX
CONTENTS
87
UPGRADING AX4X STBS
88
CONTENTS
INDEX
Chapter 5Upgrading Ax3x STBs
In this Chapter:
5.1 Upgrade mechanisms
5.2 Upgrading the software
5.3 About STB operation
5.4 Operational states
5.5 STB configuration
5.6 Automatic upgrading
5.7 Automating multicast server start-up
5.8 Using the DI for automatic upgrade
INDEX
CONTENTS
89
UPGRADING AX3X STBS
images.
5.1
Upgrade mechanisms
STBremoteconf remote configuration tool that enables you to send commands such as changing basic
configuration settings or initiating software upgrades.
Management pages local configuration pages, using an Amino IR keyboard and television display to
change configuration settings and simple commands such as rebooting and initiating software upgrades.
DHCP server configuration DHCP server configuration specifies where STBs go to retrieve software
images transmitted by the multicast server, it can also be configured to force upgrades by specifying
minimum deployment index numbers for software versions that the STB must be running. DHCP server
and Multicast server together also enable the STB to connect and retrieve new software images when
required (for example, if the software on the STB is corrupted)
The JMACX API offers functions for controlling a range of STB operational areas, including software
upgrades. This manual does not cover the use of the JMACX functions, please see the Amino JMACX API
Specification for more information.
Upgrading using HTTP allows remote upgrading of STBs over unmanaged networks. See Upgrading
using HTTP
127(
Whilst HTTP itself is not an upgrade mechanism, in the context of Amino STBs
Upgrading using HTTP means upgrading the STB by a process that uses the
HTTP transport protocol.
As detailed in the table below, the various upgrade mechanisms are each suited to particular circumstances
and contexts. For example, making images available by defining upgrade groups and ports in the DHCP server
configuration enables automatic upgrades when the STB requires them, but STBremoteconf can be used to
force an upgrade at a required time.
In the table below, Reflash refers to deleting all the contents of the NAND Flash and completely replacing the
main software image using the bootstrap process. All configuration options, except those stored in NOR Flash,
will be replaced with the configuration contained in the new software image. Upgrade refers to replacing just
the main software image. In this case, some of the configuration files, for example, the user settings, may be
preserved. This can be controlled when the software image is built.
Contexts
STBremoteconf
Remote

pages
configuration HTTP
Local
Y
Y
Single STB
Large deployment
Test settings
Ya
Automatic
Y
Y
Y
Manual
Yb
Operation
Upgrade software
Reflash
90
CONTENTS
INDEX
Y
Y
UPGRADING AX3X STBS
Contexts
STBremoteconf

pages
configuration HTTP
Upgrade to min. DI number

Upgrade to min. version number
Y
Y
a. Not recommended: requires all STBs to be powered.

b. Currently, the REFLASH command is not recommended as this will not upgrade the PBL or the recovery
image. The suggested method is to use the UPGRADE command via STBremoteconf, or by running
the pre/post-upgrade scripts from a working STB image. This will then upgrade the PBL and recovery
image and validate them before upgrading the main software image.
5.1.1
Using STBremoteconf to upgrade software
STBremoteconf provides a mechanism for remotely configuring and controlling a local network of AmiNET
STBs. It can be run on a Linux/Unix command line by sending commands individually to one or more STBs, or
commands can be collected into a script to save time. Commands are signed when they are created, so that
the STB can confirm that the commands have been sent by an authorised source.
Example functions include rebooting, modifying output modes or updating software, as well as viewing
information about the STB.
The UPGRADE command enables you to instruct an STB to upgrade. See the Set-top Box Configuration Guide
for further details.
5.1.2
Using the Management pages to upgrade software
STBs with built-in browsers include HTML configuration pages, displayed on the television screen, to enable
local access and editing of configuration areas. The pages are divided into an administrator area (Management
pages) and user area (Preferences pages).
The STB Management pages are a simple interface that enable administrators to change STB configuration
areas such as networking, channel list and browser set-up, as well as initiate basic operations such as
rebooting and updating software. Management pages allow access to advanced configuration functions and
are designed for use by administrators rather than end-users. The pages are password-protected and
accessed locally via an Amino IR keyboard. Limited functionality is also supported via the remote control.
You can instruct an STB to upgrade or reflash from the Update Software Management page. See the Set-top
Box Configuration Guide for further details.
The STB Preferences pages are a simple interface that enables users to change basic STB configuration areas
such as language, subtitle and keyboard set-up. The pages are accessed locally via an Amino or Ruwido
InfraRed (IR) remote control (or keyboard). The Preferences pages are designed for use by end-users.
5.1.3
Using the DHCP server to upgrade software
The DHCP server and multicast server enable the STB to retrieve software upgrades when it needs them. You
can also configure the DHCP server so that the STB automatically upgrades to a specific software version, even
if its current software is running normally. See Automatic upgrading on page 101 for details of how to enable
automatic upgrades.
INDEX
CONTENTS
91
UPGRADING AX3X STBS
5.2
Upgrading the software
This section describes a laboratory-based upgrade process and is a sub-set of the instructions found in Chapter
3, Installing the Ax3x software .
The following instructions assume the use of the Debian operating system.
127(
The commands in this section require you to be logged on as a superuser, or

to use the sudo command.
1.
2.
release using:
3.
4.
5.
5.2.1
1.
Creating a signed bootstrap image

2.
Navigate to the bootstrap directory:

cd /usr/local/amino/releases/<release_name>/bootstrap
3.
Run the signbootstrap script by entering the following command:

./signbootstrap
You will be prompted to enter the password for the key. For the Amino engineering key, the
password is markskey
4.
The script generates a bootstrap.signed file in the bootstrap directory. Copy this file to the /
usr/local/amino/images directory specified by the FileName setting in the [Image
<image_name>] section of the multicast server configuration file (mcastbootd.conf).
For example:
cp bootstrap.signed /usr/local/amino/images/
it next time it needs to upgrade its software. If the multicast server is already running, you will need to restart
it in order for it to transmit the new image.
5.2.2
Create a signed upgrade image
92
CONTENTS
INDEX
UPGRADING AX3X STBS
1.
settings or changing the splash image, and add any extra files to the flashcontents file.
2.
3.

4.
Run the signupgradeimage script by using:

./signupgradeimage
You will be prompted to enter the pass phrase for the key. For the Amino engineering key, the
5.
The script generates mc2.mcfs in the current directory. Copy this file to the images directory
specified by the ImageName setting in the [Filesystem mc2] section of the multicast server
configuration file (mcastbootd.conf).
For example:
it the next time the STB needs to upgrade its software. If the multicast server is already running, you will need
to restart it to transmit the new image.
5.2.3
1.

For example:
2.
Enter the following command:

mcastbootd to start the multicast server in normal mode.
mcastbootd -D starts the multicast server in debug mode, and details of its operation are echoed
to the terminal. This is useful to monitor its operation in a trial installation.

The multicast server continuously transmits the software images as a carousel, so when an STB needs to install
a bootstrap or upgrade image, it joins the carousel and retrieves and installs the required files.
5.3
About STB operation
The sections that follow provide detail about the STB operation states, including how STB operation is
affected if one of the actions that the STB executes is not successful. Information about operational errors is
indicated by flashing codes via the LED on the STB.
STB operation is driven by a defined set of states, and how the STB operates depends on its current state. The
state an STB is in depends on the existence of a current software image in its NAND Flash, or whether it can
load that software successfully. Each time an STB enters a new state, it sends a DHCP request that includes an
INDEX
CONTENTS
93
UPGRADING AX3X STBS
appropriate string to identify its current state, as defined by Amino vendor extensions added to the DHCP
servers configuration file.
Figure 5.1 Splash screen for version 0.18.0. Earlier builds will display a different screen.
When an STB is powered, it attempts to execute software from its NAND Flash. If this is successful, the STB
enters its normal running state (see Filesystem (fisys) state), otherwise, the STB enters its bootstrap state.
The operation is summarised in Figure 5.2.
5.3.1
Static DHCP settings
The descriptions that follow outline operation in cases where the STB relies on the DHCP server for its network
and other settings. Where these are defined statically in the STBs configuration, they can either be used as a
fall-back if communication with the DHCP server fails or they can be used in place of DHCP communication.
How these static settings are used depends on configuration.
127(
When the NAND Flash does not contain valid software, operation is enabled
by the Bootloader stored permanently in the NOR Flash.
Figure 5.2 Dataflow diagram
94
CONTENTS
INDEX
UPGRADING AX3X STBS
5.4
Operational states
The following operational states are defined
Bootstrap state
Recovery state
Upgrade state
5.4.1
Bootstrap (mboot) state
When the STB is first turned on (not from standby), it inspects its NAND Flash for valid software. If no valid
software is found, the STB enters the multicast bootstrap (mboot) state. In this state, it can securely download
a bootstrap image from the multicast server.
When an STB is in bootstrap state, it includes mboot state in the message it uses to communicate with a DHCP
server.
5.4.1.1 Operation in the bootstrap (mboot) state

During bootstrap state, the default boot logo is displayed on the screen. If the logo has not been customised,
it will be similar to Figure 5.3:
Figure 5.3 Boot logo splash screen for version 0.18.0. Earlier builds will display a different screen.
INDEX
CONTENTS
95
UPGRADING AX3X STBS
The operational sequence on entering this state is as follows:

W
D
,QLWLDOSRZHURQQR
ILUPZDUHLQVWDOOHG

EE&
>
/K^ZKD
,W^

D/Ed
K^
,WZ
D^
$[[ERRWVWUDS

D/EK
:

Figure 5.4 Operational sequence (bootstrap state)
If there is a failure during this state, a sequence of flashes of the LED on the STB indicates the reason.
5.4.1.2 Send DHCP request

The STB sends a message to the DHCP server, including the current mboot state and a string identifying the
hardware platform. The DHCP server compares the state and the platform string against classes defined in its
configuration file. If it cannot find such a class, then it will be unable to provide the mulitcast information that
the STB needs, but will supply the IP address.
5.4.1.3 DHCP response

vendor extensions defined in that class. These vendor extensions are normally an IP address and port for
retrieving a bootstrap image that is being transmitted by the multicast server.
If the STB does not receive a response from the DHCP server, it tries to resend the DHCP request a number of
times (the number of times is specified in the code). If this is still not successful, it either uses values from its
configuration (if these have been set) or reboots itself, returning to the initial powered state.
5.4.1.4 Download image

The STB connects to the multicast carousel with the details it has received and downloads the packets for a
bootstrap image. If the STB does not manage to download an image from the multicast server within a defined
timeout, it reboots itself, returning to the initial powered state.
96
CONTENTS
INDEX
UPGRADING AX3X STBS
5.4.1.5 Assemble, verify and execute image

The STB verifies the new bootstrap image by using the public customer key it holds to check the digital
signature that the image is signed with. If the software is successfully verified, the STB executes it and stores
it in its NAND Flash.
If the STB is unable to verify or execute the software it has downloaded, the software is reset and the STB
either reboots itself or re-enters the bootstrap state, depending on what stage the process fails at. The debug
output will contains details of why the failure occurred.
5.4.2
Upgrade (upgrd) state
Once the STB has found, downloaded and installed a valid bootstrap image, it enters the upgrade (upgrd)
state. The STB will also enter this state in response to a manual upgrade request (for example, one initiated
via STBremoteconf). In this state, all non-essential applications are closed, and the STB can download and
execute a new software upgrade image.
When an STB is in the upgrade state, it includes upgrd state in the message it uses to communicate with a
DHCP server.
5.4.2.1 Operation in the upgrade (upgrd) state

In the upgrade state, the upgrading screen is displayed.
Figure 5.5 Upgrading logo screen for version 0.18.0. Earlier builds will display a different screen.
INDEX
CONTENTS
97
UPGRADING AX3X STBS
The operational sequence on entering this state is as follows:

,W^
h^

EE&

D/EK
^d
,WZ
D^
:h'
^

D/EK

Z

hZKD
Z
Figure 5.6 Operational sequence (upgrade state)
If there is a failure during this state, a sequence of flashes of the LED on the STB indicates the reason.

Once the STB has successfully loaded a bootstrap image, it enters the upgrade state.The STB also enters this
state if a manual upgrade request is initiated (for example, via STBremoteconf). The STB sends a message
to the DHCP server, including upgrd state and a string identifying the hardware platform.

The DHCP server compares the state and the platform string against classes defined in its configuration file.
vendor extensions defined in that class. These vendor extensions are normally an IP address and port for
retrieving an upgrade image that is being transmitted by the multicast server. If it does not find a class, then
it cannot provide the information that the STB needs.
If the STB does not receive a response from the DHCP server after a number of retries, it tries to move to the
next stage using the settings in its configuration (that is, using null values for the multicast IP address and port
if these have not been set in the configuration so the download will not succeed).
5.4.2.4 Download image

The STB connects to the multicast carousel with the details it has received and downloads the packets for an
upgrade image. If it fails to download the image within a defined timeout, the STB reboots, and returns to the
initial powered state.
98
CONTENTS
INDEX
UPGRADING AX3X STBS
5.4.2.5 Assemble, verify and execute image

The STB verifies the new image by using the public customer key it holds to check the digital signature that
the image is signed with. It also compares the deployment index (DI) of the software against its current index.
If the software is successfully verified, the STB stores it in its NAND Flash and executes it.
If the software is not successfully verified and executed, the STB resets itself. How it behaves at this stage
depends on what stage of the verification process it failed at: it can either reboot or re-enter the upgrade
state.
127(
5.4.3
At this point the NAND Flash could potentially be corrupted by a power outage
or other failure. If this happens, the STB will detect it and return to the
bootstrap state.
Filesystem (fisys) state
Once the STB has found and executed a valid software image from the NAND Flash, it enters the filesystem
(fisys) state. In this state, the STB is running and available for normal use. An administrator can initiate a
software upgrade using one of the management tools (for example, STBremoteconf).
5.4.3.1 Operation in the filesystem (fisys) state

EE&
&^
1RUPDOERRW
ILOHV\VWHPLQVWDOOHG
,WZ
,W^

D/EK
([HFXWHVWDUWXS
VFULSWV
D^
D
([HFXWH
0LGGOHZDUH
D/EK
-RLQ0LGGOHZDUH
JURXS
^dZ

-RLQ67%5&JURXS
5XQ%URZVHU
0LGGOHZDUH
E
K
Figure 5.7 Operational sequence (fisys state)
INDEX
CONTENTS
99
UPGRADING AX3X STBS
In the filesystem state, normal operation is enabled. When the STB first enters this state, it shows the page
set as the default home page. For example, for a standard Amino build with the Opera browser, a screen
similar to the following is displayed:
Figure 5.8 typical Opera screen
The operational sequence on entering this state is as follows. If there is a failure during this state, a sequence
of flashes of the LED on the STB indicates the reason. Refer to Appendix A, LED flashing codes for details of
these flashing codes.

When the STB successfully loads both a bootstrap and software upgrade image, it enters the filesystem state.
The STB sends a message to the DHCP server, including fisys state and a string identifying the hardware
platform. The DHCP server compares the state and the platform string against classes defined in its
configuration file. If it does not find a class, then it is unable to supply the information that the STB needs.

When the DHCP server identifies an appropriate class, it responds to the STB, with network settings and any
vendor extensions defined in that class. For the filesystem state, vendor extensions are optional, but they can
include an IP address and port for retrieving an upgrade image that is being transmitted by the Multicast
server as well as other options such as middleware server details and minimum software deployment index
(DI) that the STB must be running.
If the STB does not receive a response from the DHCP server after a number of attempts, it reboots, returning
to its initial powered state.
5.4.4
Initiate upgrade or normal use
If the minimum DI supplied is greater than the current index of the STB, the STB enters the upgrade state, to
download a new software version. The STB must have been supplied with a multicast IP address and port in
order for this upgrade to be successful. If the upgrade fails, then the STB returns to normal operation, using
its current software version.
If the STB receives an upgrade instruction from an external application, the STB enters the upgrade state,
using the multicast IP address and port supplied in the upgrade instruction. Again, if the upgrade fails, the STB
returns to normal operation without upgrading its software.
100
CONTENTS
INDEX
UPGRADING AX3X STBS
Otherwise, the STB is available for normal operation.

When an STB is in filesystem state, it includes fisys state in the message it uses to communicate with a DHCP
server.
5.5
STB configuration
The multicast system offers a range of tools for configuring STBs, depending on factors such as whether you
are testing new settings or rolling out configuration for a software upgrade, and whether you are configuring
the box remotely or locally. For an overview of configuration methods, see the Set-top box Configuration
Guide.
5.6
Automatic upgrading
to implement this system:
127(
configuration.
2.
option AMINO.dindex_min code 10=integer 32;
3.
Find the fisys class for the STB type that you want to force to upgrade, and under vendoroption-space AMINO; add a line in the following format:
option AMINO.dindex_min <minimum_DI>;
option AMINO.dindex_min 5;
4.
Also ensure that the following lines are present, and specify the correct multicast IP address and port:
option AMINO.address <IPaddress>;
option AMINO.port <port_number>;
The fisys class you are editing should now look similar to the following:
class 130 normal
{
match if (substring( option vendor-encapsulated-options, 2,
9)=aminet130) and (substring( option vendor-encapsulatedoptions,13, 5)=fisys);
}
5.
INDEX
CONTENTS
101
UPGRADING AX3X STBS
The system is now set up. Next time an STB of the configured type boots, it will compare its current
deployment index with the one you specified, and will upgrade to the specified software image if its current
deployment index is lower than the one in the DHCP server configuration.
5.6.1
To test automatic upgrading
Once you have implemented automatic upgrading using a specified minimum DI to force upgrades, you can
test the system. The following steps assume that Telnet (or other remote log-in client) is enabled in the STB.
1
Check the DI number of the STB you are going to test with. You can do this from the command line
by Telnetting to the STB and entering the following command (the current DI number must be lower
than the one you want to upgrade to):
2.
Power up (or reboot) the STB.

The loading screen is displayed (the default image has Loading followed by Upgrading, do not
unplug!).
3.
When the upgrade is finished, you can check that the STB is now running the new software version
and you can check the DI, as in step 1 (it should now have the DI specified in the DHCP server
configuration file).
5.6.2
Static network and multicast upgrade settings
Some DHCP servers do not support the addition of the vendor extensions that this multicast upgrade system
uses to tell STBs the IP address and port to use for booting and retrieving software images (for example,
AMINO.address and AMINO.port). In these cases, the DHCP server can be used just to assign an IP address
to the STB, then you configure the addresses and ports to use for software upgrades as static values in the
STBs configuration.
In other installations, it may be useful to set all network settings statically, rather than retrieving them from
the DHCP server.
In both cases, the static values are normally defined in the NOR Flash, which you can edit in the following
ways:
127(
In some cases, these settings may be defined in the netconf file. See the
Amino Set-Top Box Configuration Guide for more information.
libconfig commands in upgrade script (recommended method)
libconfig commands via remote log-in tool (for example, Telnet)
via the Management pages (Network Configuration page)
JMACX calls in HTML page (not generally recommended, for security reasons)
For details of how to use the tools available to change settings, see the JMACX API Specification and the SetTop Box Configuration Guide.
The recommended way to set static multicast upgrade and network values for multiple STBs is to add
libconfig commands to the upgrade script that is included as part of a software image. The script executes
automatically when the new software image is loaded to the STB, and is then deleted.
102
CONTENTS
INDEX
UPGRADING AX3X STBS
5.6.2.1 To set static multicast upgrade values

MULTICAST_BOOTSTRAP_GROUP
MULTICAST_BOOTSTRAP_PORT
MULTICAST_UPGRADE_GROUP
MULTICAST_UPGRADE_PORT
MULTICAST_FILESYSTEM_GROUP
MULTICAST_FILESYSTEM_PORT
127(
The bootstrap, upgrade and filesystem groups must be set with a valid
multicast addresses in order for multicast upgrades to work. If an address is
invalid, the STB tries to retrieve an IP address via DHCP. If this is not successful
or if the address that the STB retrieves via DHCP is also invalid the STB
reboots.
5.6.2.2 To set a static IP address

IPADDR
Other network settings

NETMASK
GATEWAY
DNS
TIME_SERVER
Required vs. optional settings

The list of values that must be defined statically depends on what functionality your DHCP server supports.
The following guidelines apply:
Required multicast upgrade settings

If the DHCP server is being used to provide network settings, but not the multicast upgrade settings (that
is, the DHCP server does not support the Amino vendor extensions), the bootstrap and upgrade settings
are required. The filesystem settings are normally optional, although this will depend on the
functionality you want to enable in the system.
Required network settings
If the DHCP server is not being used to provide network settings, then most of the values listed are
required, only DNS and TIME_SERVER are optional.
Example upgrade.sh script to set static multicast upgrade values

The recommended way to set static network and multicast upgrade values for multiple STBs is to add
libconfig commands to the upgrade script that is added to the image components used to create a
software upgrade image. When the new upgrade image is loaded to the STB, the script executes
automatically, and is then deleted.
127(
The software image containing this upgrade script must be installed on the
STBs before they are installed on a network that requires the static settings.
This is because the STB requires these network settings in order to retrieve the
new software image.
The following script uses libconfig commands to set values for some of the multicast upgrade settings
(bootstrap and upgrade ports and IP addresses) in the NOR Flash:
#!/bin/sh
INDEX
CONTENTS
103
UPGRADING AX3X STBS
libconfig-set
libconfig-set
libconfig-set
libconfig-set
5.7
NORFLASH.MULTICAST_BOOTSTRAP_GROUP 239.255.1.1
NORFLASH.MULTICAST_BOOTSTRAP_PORT 11111
NORFLASH.MULTICAST_UPGRADE_GROUP 239.255.1.2
NORFLASH.MULTICAST_UPGRADE_PORT 11111
Automating multicast server start-up
By default, the multicast server does not start when you start the server it is installed on. You can enable
automatic start-up by creating an mcastbootd script in /etc/init.d, and running the following command
to start the service:
chkconfig mcastbootd on.
The multicast server will be started automatically on the next reboot.

The following example start script works with Redhat Linux.
#!/bin/bash
#
# chkconfig: 2345 55 25
# description: Amino Multicast Daemon
# processname: mcastbootd
# config: /etc/mcastbootd.conf
# Source function library.
[ -f /etc/rc.d/init.d/functions ] || exit 0
. /etc/rc.d/init.d/functions
# getting the Mcastbootd options
. /etc/sysconfig/mcastbootd
RETVAL=0
start() {
echo -n $"Starting Mcastbootd server services: "
mcastbootd $MCASTBOOTD_ARGS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/mcastbootd
return $RETVAL
}
stop() {
echo -n $"Stopping Mcastbootd server services: "
killproc mcastbootd
RETVAL=$?
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/mcastbootd echo
return $RETVAL
}
# See how we were called.
case "$1" in
start)
start ;;
stop)
104
CONTENTS
INDEX
UPGRADING AX3X STBS
stop ;;
status)
status mcastbootd ;;
restart|reload)
stop start ;;
condrestart)
if [ -f /var/lock/subsys/mcastbootd ]; then
stop
start
fi
;;
*)
echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
exit 1
esac
exit $RETVAL
5.8
Using the DI for automatic upgrade
In normal operation, the STB downloads new software from the multicast server when there is a problem with
its current software or when an upgrade command instructs it to (for example, from
STBremoteconf, the Management pages or a JMACX call). Using the DI, it is also possible to configure the
multicast upgrade system to force STBs to upgrade to a particular software version as identified by the
softwares DI.
5.8.1
How it works
The STB stores the DI of its current software version in the NOR Flash.
A new DI is specified when a new signed software upgrade image is created with the signupgradeimage
script. The DI is an integer between 0 and 65535.
When the STB receives the new software version, it checks the DI against the number in its NOR Flash, accepts
the software upgrade if the new number is the same or greater, and changes the DI in its NOR Flash
accordingly. Otherwise it rejects it.
127(
5.8.2
For trial versions and for early stages of a project, we recommend you use a DI
of 0 (zero). This means that you do not need to specify the DI when you create
a new upgrade image. Once the deployment is live, the service provider
should increase the DI by 1 when asked to produce a new version by the
software provider (for example, the CA or middleware vendor).
DI and software versioning
The DI mechanism is completely separate from software version numbers. This means that if necessary a
service provider can downgrade from a current software version to an older one, as long as they create a
software upgrade image with a higher DI than the current software version.
INDEX
CONTENTS
105
UPGRADING AX3X STBS
5.8.3
Migrating from pre-DI to DI-capable software
All STBs are manufactured with an initial DI of 0 (zero) in their NOR Flash. To start using the DI mechanism in
a system that currently does not implement this control, just increase the DI to 1 in the next software upgrade
image that you create.
5.8.4
Setting up automatic upgrade to minimum DI
The DI mechanism can be used to force STBs to upgrade to a specified minimum DI, using Amino DHCP vendor
extensions. The minimum index number is added to the DHCP configuration. When the STB boots up and
contacts the DHCP server, the DHCP server includes this DI in its response, along with the multicast upgrade
address and port for the upgrade image. The STB checks this index against the DI in its NOR Flash, and
upgrades immediately if its index is lower than the specified value.
5.8.4.1 Resetting the DI

For security reasons Amino do not provide a method of resetting the DI remotely on an STB. However, it is
possible to retrieve the current DI through Telnet.
Telnet to an STB, and run this command:
If, having obtained the DI, the software download is configured with a DI higher than the current value and
the STBs all reflashed, they will all be on the same, new, DI.
5.8.5
To implement automatic upgrading
to implement this system.
127(
configuration.
1.
2.
option AMINO.dindex_min code 10=integer 32;
3.
Find the fisys class for the STB type that you want to force to upgrade, and under vendoroption-space AMINO; add a line in the following format:
option AMINO.dindex_min <minimum_DI>;
4.
Also ensure that the following lines are present, and specify the correct multicast IP address and port:
option AMINO.address <IPaddress>;
option AMINO.port <port_number>;
The fisys class you are editing should now look similar to the following:
class 130 normal
106
CONTENTS
INDEX
UPGRADING AX3X STBS
{
match if (substring( option vendor-encapsulated-options, 2,
9)=aminet130) and (substring( option vendor-encapsulatedoptions,13, 5)=fisys);
}
5.
The system is now set up. Next time an STB of the configured type boots, it will compare its current DI with
the one you specified, and will upgrade to the specified software image if its current DI is lower than the one
in the DHCP server configuration.
INDEX
CONTENTS
107
UPGRADING AX3X STBS
108
CONTENTS
INDEX
Chapter 6STB Security Features
In this Chapter:
6.1 Security keys
6.2 Distributing software
6.3 Deployment Index (DI)
6.4 Passwords
INDEX
CONTENTS
109
STB SECURITY FEATURES
The software on an STB is protected by a combination of security measures:
Security keys
Deployment Index (DI)
Password-protected access to management tools
6.1
Security keys
Software is protected by cryptographic public-private keys and digital signatures. This protection extends
from initial booting through to uploading of new software images. Images and commands are digitally signed
before they are sent to an STB, and the STB verfies this signature before it loads the new software or
completes the operation requested.
Amino STBs use 2048-bit and 1024-bit RSA signing to verify code and commands. Each STB has three keys in
a heirarchy: a Master key, a Customer key and a configuration or STBRC key. For each key in a software
distribution there are in fact two keys - a public key (used by the STB to verify images and commands) which
is stored on the STB, and a private key that is kept secret, either at Amino, at the customer (that is, the
telephone or broadband service provider), or at a CA partner. The keys used can be either the Amino
engineering keys used for trial purposes or customer specific keys, depending on customer requirements.
6.1.1
Hierarchy
The use of a series of different keys allows us to achieve the above aims. The hierarchy used is shown below.
Amino Master
Key
Can sign Customer Keys
Can also sign BootROMs and Boot
Loaders
Customer Key
Can authorise specific commands

Can sign software
Can change STBRC key
STBRC Key
Can authorise commands
The final implementation makes use of three 1024-bit RSA keys. The private part of each is encrypted using
the Blowfish cipher using a secret passphrase. The individual keys are described in more detail below.
110
CONTENTS
INDEX
The public part of each key is stored in the NOR Flash.
6.1.1.1 Amino Master key

This key is the most secure. It is used to sign Customer keys. On Ax3x STBs it is used to sign the BootROM and
on Ax4x STBs it is used to sign the Boot Loader.
The Amino Master private key is kept in a secure environment and only two senior, long-term, employees
know the passphrase.
The public part of the key is programmed into each individual STB at time of manufacture and is not intended
to be changed.
The Master key is used exclusively by Amino to sign the Customer key. It is held securely and is only available
to Amino.
The Master public key is stored in the lockable (OTP) region of the NOR Flash ROM. It is only used infrequently.
For Ax3x STBs, at startup it is used to verify that the Customer public key has been signed with the Master
private key and that the IntActOS code has been signed with the Master private key. It is also sometimes used
to verify bootstraps and software downloads before executing them. On Ax4x STBs it is used to verify the Boot
Loader before it runs (or before it runs very far).
6.1.1.2 Customer key

This key is used to sign software images and specific remote commands.
A different Customer key is generated for each customer by Amino and the private part is kept off-line,
generally by the customer.
For generic Amino STBs, a default Customer key is stored on the STB at time of manufacture. This key is
included with all Amino SDKs and is used in-house for development. It is also used for all demonstration and
evaluation STBs. In the event of a particular site moving to a full deployment the Customer key in all of their
STBs must be replaced with a customer specific one. For larger deployments, Amino manufacture STBs with
Customer public keys installed.
The use of a single default key for new boxes ensures that the Amino Master key is kept secure, as it is not
needed for non-customer specific STBs (for example, demonstration and evaluation units). This also minimises
the number of times that the Master key is used, which always improves security. In addition, only customers
at the point of deployment will need to be concerned with key security.
Once verified by the Master key, the Customer key is used to verify the STBRC key at startup time. It is also
used to verify bootstraps and software downloads before executing them. The Customer key is used for this
verification and if it should fail then the Master key is tried - only when that also fails is the software rejected.
The Customer key is used to verify that bootstrap and upgrade images have been signed by a trusted source.
The Amino engineering Customer key (KEY.private) is normally provided with a release.
The password for this Amino engineering Customer key is markskey.
6.1.1.3 STBRC key

The STBRC key is verified by the Customer key at startup and is only used to verify remote commands set to
the STB by the STBremoteconf utility. Again, there is a heirarchy of keys so if a remote command does not
verify with the STBRC key, then the Customer and Master keys are tried in that order.
This key is used for remote control of the STB. This is the key that is normally used when signing
STBremoteconf messages and as such it may be scripted and will need to be stored on-line (on servers and
given to field engineers).
INDEX
CONTENTS
111
As a result this is the key that is most likely to be compromised. Therefore it is not used to sign software which
may run on the STB.
In the event of this key becoming compromised a customer can change it by generating a new key and then
using STBremoteconf to upload it (in a message signed with their Customer key). This should be the only key
that is vulnerable to loss since it is the only key which is kept online.
The STBRC key is used to verify the validity of remote management commands sent to the STB.
The Amino engineering configuration key (STBrc-KEY.private) is normally provided with a release. The
password for this Amino engineering configuration key is stbrckey.
6.1.2
Consequences of key compromises
This section discusses the consequences of any particular key becoming lost or compromised.
6.1.2.1 Amino Master key

The consequences of losing this key are serious Amino would be unable to sign new Customer keys. The key
would immediately need to change and all newly manufactured boxes would need to be modified to use new
keys.
Software could be written and signed with each customer's key that modifies the Amino Master Key stored in
their STBs. This can only be done if customers have their keys available and the theft of the Amino Master Key
is discovered before boxes are maliciously attacked.
This key clearly needs protecting at all costs and as such is never stored on-line. A duplicate of the key is stored
offsite in a high-security environment.
6.1.2.2 Customer key

If this key is compromised then an attacker can run arbitrary software on any of the customer's STBs. They
cannot run the software on other sites unless they also managed to steal the Customer key changing message
that was signed by Amino.
Clearly all customers need to be aware of the serious consequences of the loss of this key and must be fully
aware of their responsibility to keep it securely. Provided that they act quickly, loss of this key can normally
be recovered without material loss but this cannot be guaranteed.
6.1.2.3 STBRC key

If this key is compromised then an attacker can issue commands to STBs. This could cause, amongst other
things:
Reboots.
Displaying particular web pages.
Transfer of files to the STB which will allow arbitrary code to be run (although this is a complex
procedure).
6.2
Distributing software
This key hierarchy influences the method for distribution of software from Amino. The standard procedure is:
1.
Amino create and test a new software build in-house.
2.
Amino securely encrypts the software and transfers it to a customer.
112
CONTENTS
INDEX
3.
The customer decrypts and modifies the software as required by their site. This might involve
changing default addresses, for example.
4.
The customer signs the image offline with their customer key.
5.
The software image is multicasted to the customer's STBs.
6.
The STBs verify the signature on the image and accept it if they are satisfied.
Some smaller customers may choose not to maintain responsibility for their own keys. In that event Amino
will generate and store the customer's key for them:
1.
Amino creates and test a new software build in-house.
2.
Amino signs the image offline with the customer key.
3.
Amino transfers the image to the customer (since this image is already signed it cannot be tampered
with en route).
4.
The software image is multicasted to the STBs.
5.
The STBs verify the signature on the image and accept it if they are satisfied.
6.3
Deployment Index (DI)
The Amino multicast upgrade system uses a facility called "Deployment Index". This was added at the request
of Conditional Access vendors as a mechanism to prevent older software releases being loaded onto an Amino
STB.
6.3.1
How it works
A DI number (starting at 0) is stored in the NOR Flash. When the STB downloads a new software image it
compares the DI number in NOR Flash with the DI number in the software image. If the DI number in the
software image is the same or greater than the DI number in NOR Flash, it accepts the upgrade. Otherwise, it
rejects it.
So, when a customer receives a software update from Amino with a security fix they should increase the DI
number by 1 to prevent anyone from loading older (lower DI numbered) images back onto the box.
The DI number is completely separate from software version numbers. Indeed, should a service provider wish
to downgrade from, for example, software version 0.15.6 to 0.15.4 they can do this. All they have to do is
generate the multicast download image of 0.15.4 again, but with a new (higher) DI number. The STBs will then
accept this software and downgrade from 0.15.6 to 0.15.4.
127(
6.3.2
Once you have started using DI you cannot load a normal image with no DI set.
How to use it
The signupgradeimage script within the release takes a parameter that is the DI number to put into that
image. This is a number in the range 0 to 65535 (maximum).
For example:
./signupgradeimage 1
For development work we recommend just using a DI of 1 all the time. In customer deployments, the service
provider must increase the DI by 1 for a new release when advised by the service provider (that is, CA or
middleware vendor) due to a security issue being fixed in the new release.
INDEX
CONTENTS
113
6.4
Passwords
Access to management functionality is assigned to password-controlled users.

The following table outlines the main password-controlled user levels:
Default
password
User name Description

root
Used for Telnet or serial terminal access on development builds.
root2root
mngread
Used for access to the STB management pages.
leaves
mngwrite Used to write back changes from the STB management pages.
snake
Warning:
Amino strongly recommends that you change the default passwords when
deploying our STBs.
See below for information on changing these default passwords.
6.4.1
Changing STB passwords
It is possible to customise the passwords used to access an STB by editing the shadow file supplied with a
software release, and then generating a new software upgrade image that includes the updated shadow file.
In some builds it is also possible to customise passwords once software is installed on an STB, using
STBremoteconf.
6.4.2
Shadow file
The shadow file defines the passwords for STB management users. Each line in the file specifies password
information for a user, beginning with the user name.
6.4.3
Changing passwords in the shadow file
127(
1.
The following steps assume you have already set up a multicast upgrade
system and the software release is in the location specified in the set-up
instructions.
At a Linux command line, generate a new password hash with a command in the following format:
perl -e print crypt(<password>, <salt>)
(where <password> is the new password you want to set, and <salt> is any two alphabetical
characters.)
For example:
perl -e print crypt(admin, Ap)
The command returns a hash for the password admin. In general, a hash function takes a string of
any length as input and produces a fixed length string as output.
Result:
ApC4fVgseQ63w
114
CONTENTS
INDEX
2.
Open the shadow file. If you used the recommended settings when you set up the multicast upgrade
system, you will find the file in the following location:
/usr/local/amino/releases/<release_name>/upgradeimage/imagecomponents
3.
The shadow file has a line for each password that can be changed. Find the line for the password
you want to change, and replace the current password hash with your new one. The password hash
is the string between colons after the user name.
For example, if you want to change the password for root, find the line that looks similar to the
following:
root:kUCfiRdXdzJSM:10596:0:99999:7:-1:-1:0
Replace the password hash string, so that the line now looks similar to this:
root:ApC4fVgseQ63w:10596:0:99999:7:-1:-1:0
Repeat these steps for any other passwords you want to change, then save your changes.
Once you have changed the passwords as required, you will need to create a new software upgrade image
that includes the edited shadow file, and save it to your STBs.
INDEX
CONTENTS
115
116
CONTENTS
INDEX
Chapter 7Upgrading using HTTP
In this Chapter:
7.1 Introduction
7.2 HTTP installation and upgrade
7.3 HTTP recovery
7.4 JMACX API function ASTB.Upgrade()
INDEX
CONTENTS
117
UPGRADING USING HTTP
7.1
Introduction
It is now possible to deliver content with unlimited duration and quality that adapts to available network
bandwidth.
So unmanaged networks can now be utilised by operators to extend their services and also by content
providers to make their content available. It follows that STBs used in unmanaged networks must be
configured so they can be upgraded or recovered over these networks. To provide upgrade and recovery,
HTTP is used for control and download because it adapts to the available bandwidth and does not require
complex configurations of gateways and firewalls, therefore making set up easier.
An advantage of HTTP upgrade and recovery is that the STB can always be upgraded and recovered as long as
it is connected to the internet.
HTTP upgrade and recovery are available from AmiNET releases 0.18.0 and 2.3.0 onwards.
,ddW>
/&t
,ddW
h
^d
7.2
HTTP installation and upgrade
A software upgrade can be performed by:

the end user:
by selecting middleware pages using the JMACX function ASTB.Upgrade( )
or
the operator:
via the middleware using ASTB.Upgrade( ) to download the firmware
by using a portal designed to check the software version against the desired version and trigger an
update if necessary, again using the JMACX function ASTB.Upgrade( ) to provide the correct URL
(http://<host>/<firmwarename>)
by using the STBremoteconf upgrade command:

./STBremoteconf <host> UPGRADE http://<host>/mc2.mcfs
127(
STBremoteconf is a Linux client used to control and manage AmiNET STBs.

For installation and set up information, plus details of the commands
available, refer to the Amino STB Configuration Guide.
It is only necessary to supply the correct HTTP address for a unicast upgrade, however you must know whether
there is a new software image available or not. For AmiNET we assume that the middleware client on the STB
118
CONTENTS
INDEX
is always able to find the middleware server, can query its own software version (that is, the latest version on
the server) and so determine if an update is needed. As the middleware client has the best knowledge of what
the STB is doing at any particular time, it is able to schedule an upgrade that results in minimum disruption to
the end user.
http:// is used for unicast upgrade. igmp:// is used for a multicast upgrade.
A video showing this installation procedure is available at:

Select:
Upgrading your x4x using the http upgrade method
VIDEO
7.3
HTTP recovery
For open networks where there is no control over the DHCP server and the STB is located behind a NAT
gateway, the STB needs to be provisioned with the correct recovery address in the factory. The recovery
address can be the HTTP address for a normal mc2.mcfs install image: if there is a problem preventing the
main image from running, then a recovery image will trigger the download of the software from that address.
For HTTP recovery, you must supply a URI to be set during the STB manufacture if Amino DHCP vendor
extensions are not available.
127(
Amino can provide a mechanism to change the recovery URI if necessary. If

you require this mechanism please contact Amino Customer Support.
7.4
JMACX API function ASTB.Upgrade()
The ASTB.Upgrade()command is the JMACX function used to upgrade the STB using HTTP. In this case the
mc2.mcfs file must be on a web server, and the prototype used for HTTP is shown below:
Prototype
number ASTB.Upgrade ("http://<host>/mc2.mcfs")
Parameters
Parameters
Allowed values
<host>
Description
IP address of host.
Returns
nothing if there is an error parsing the parameters entered. The function returns -1 if the address
entered is null and returns 0 on other error. Otherwise, the upgrade process has started.
INDEX
CONTENTS
119
120
CONTENTS
INDEX
Chapter 8Postbuild packs
In this Chapter:
8.1 Adding a postbuild pack
INDEX
CONTENTS
121
POSTBUILD PACKS
8.1
Adding a postbuild pack
Postbuild packs are optional components that can be merged into any build with which they are compatible
(usually based on platform and version). They are provided as individual tarballs and are available on the
support-release server.
Postbuild packs are added to the upgrade image automatically by using the customise script, or manually by
copying files from the postbuild pack into the release. To automatically apply a postbuild pack
Use the customise script in <release>/utils/customise. This will automatically apply a postbuild pack
to the release.
8.1.1
Using the customise script
For example, to apply the 2.5.2-Ax4x-ffmpeg postbuild pack to the 2.5.2-Ax4x-opera11 release:
1.
Unzip the postbuild pack and release to /usr/local/amino/releases
2.
Issue the command:

2.5.2-Ax4x-opera11/utils/customise -R 2.5.0-Ax4x-ffmpeg
2.5.2-Ax4x-opera11 2.5.2-Ax4x-opera11-ffmpeg
(any trailing / should be removed from the folder paths)

This command will create a new directory, 2.5.2-Ax4x-opera11-ffmpeg, containing the release
with the postbuild pack applied to it.
3.
Sign and use this customised release.
8.1.2
Manually applying a postbuild pack
Amino strongly recommends that you use the customise script to

automatically add a postbuild pack. This avoids errors that may occur when
manually copying files.
Copy the files from the required postbuild pack to the equivalent location in the release, taking care to merge
any configuration files provided by the postbuild pack.
Then modify flashcontents according to any additional or modified entries in flashcontents.in in the
postbuild pack.
122
CONTENTS
INDEX
Appendix ALED flashing codes
In this Chapter:
A.1 Major error groups
A.2 Ethernet monitoring
INDEX
CONTENTS
123
The LED on the front of AmiNET STBs indicates operational information such as errors during booting. A
sequence of short and long flashes communicates the general type of information and the detail of the error.
Each LED flashing code is constructed from a sequence of flashes and pauses in the following order:
<major number of flashes>
<short pause>
<minor number of flashes>
<long pause>
<repeat>
127(
For the A540 that has two front panel LEDs, the left hand LED (power) will flash
the error code.
A.1
Major error groups
The flashing codes indicate two main groups of errors information and fatal errors.
Information errors: Information errors are indicated by shorter flashes. These errors generally require a
reboot of the STB, but there are exceptions - for example if the STB cannot execute a command sent by
STBremoteconf, it continues normal operation rather than rebooting.
Fatal errors: Fatal errors are indicated by longer flashes. When the STB detects these errors, it flashes the LED
error in an endless loop. Rebooting the STB in these cases may cause it to stop responding permanently,
particularly after a NOR flash write failure. For this reason, the STB should not be rebooted until all diagnostics
have been completed.
The following table shows the number of flashes that indicates the major groups of information errors.
124
Major no.
of flashes
Error type
Not full functionality but the box will start-up fully.
Code upgrade failure.
Security/cryptographic issue (boot loader).
Security/cryptographic issue (OS).
Miscellaneous errors.
Reserved for future use.
Reserved for future use.
Cryptographic failure (fatal).
Hardware failure (fatal).
CONTENTS
INDEX
A.1.1
List of LED flashing codes

Major Minor Error
STB behaviour
Reboot
Not full functionality but the box will start-up
No network connection.
Repeats three times. STB

continues booting.
No
DHCP look-up failure.

continues booting.
No
I2C communication failure.

continues booting.
No
Code upgrade failure (Ax3x)
poweron file is not saved.
Yes
TFTP download failure.
Reboots.
2
BOOTP server not found.
poweron file is not saved. STB Yes
reboots.
2
Multicast group not found.
Retries three times. If still

unsuccessful, STB reboots.
Yes
Multicast download timeout.
Retries three times. If still

Yes
product file missing from

running software.
Upgrade system is broken,

Yes
uses reflash and then reboots.
bin/products file missing

from downloaded software
upgrade image.
STB reboots.
Yes
bin/products file does not STB reboots.

match STB product (that is, the
software upgrade image is not
suitable for this platform).
Yes
Failed to load new NOR flash

driver.
STB reboots.
Yes
An EXT2SEC upgrade did not

find an EXT ROM.
No ROM upgrade takes place.

STB reboots.
Yes
Code upgrade failure (Ax4x)
Multicast group not found /

Upgrade URI invalid
Retries 3 times and if still

Yes
Multicast download timeout
Retries 3 times and if still

Yes
Product file missing from

running software
STB reboots.
Yes
bin/products file missing from STB reboots.

downloaded software upgrade
Yes
INDEX
CONTENTS
125
Major Minor Error
STB behaviour
Reboot
bin/products file does not

match STB product
STB reboots.
Yes
HTTP download failed
STB reboots.
Yes
Local image download failure STB reboots.

(for example, from USB sticks)
Yes
11
bin/st_chip_types file missing

from downloaded software
upgrade
STB reboots.
Yes
12
bin/st_chip_types file does not STB reboots.

match STB ST chip
Yes
13
Recovery image invalid, cannot STB reboots.

upgrade Main image
Yes
14
Failed to upgrade recovery

image
STB reboots.
Yes
15
PBL incompatible with

hardware
STB reboots.
Yes
16
Recovery image incompatible

with hardware
STB reboots.
Yes
17
Main upgrade image

incompatible with hardware
STB reboots.
Yes
18
Attempt to install old SW onto STB reboots.

new HW
Yes
Security/cryptographic issue (boot loader)
Verification of download
image failed.
Deletes the image if saved in

the flash. Retries three times.
If still unsuccessful, STB
reboots.
Yes
Signature check of

If still unsuccessful, STB
reboots.
Yes
listfile.sig failed.
listfile.sig is missing.
Erases the flash (which must

Yes
be assumed to be unsafe) and
reboots.
Missing file in the NAND flash

(according to
listfile.sig).

Yes
reboots.
File check against

Yes
reboots.
126
CONTENTS
Yes
File found in the NAND flash is Erases the flash (which must
not in listfile.sig.
reboots.
INDEX
Major Minor Error
STB behaviour
Reboot
STB reboots.
Yes
Security/cryptographic issue (Primary Boot Loader)
Primary Boot Loader selfverification fails
Keeps flashing code in endless No

loop.
Main Image and recovery

image missing or corrupt .

loop.
Security/cryptographic issue (OS)
Verification of the download

image failed.

If still unsuccessful, reboots.
Signature check of
Deletes the image if saved in Yes

the flash. Retries 3 times. If still
unsuccessful, reboots.
listfile.sig is missing or
Erases the flash (assumed to

be unsafe) and reboots.
Unable to decode the

customer public key on the
STB.
corrupted.
Yes
Yes
Software upgrade image DI

(deployment index) is less than the flash. Retries three times.
STB DI.
If still unsuccessful, the STB
reboots.
Yes
Set DI failed.
Deletes the code contents of

the flash, then reboots.
Yes
STBremoteconf key not
Ignores command.
No
STBremoteconf key failed to Ignores command.
No
found.
4
verify.
4
MD5 sum failure.
Rejects software upgrade

image.
No
Number of entries in
Rejects software upgrade

image.
No
STB reboots.
Yes
Reformat the NAND flash and

reboot.
Yes
listfile.sig does not
match files downloaded.

4
10
No DI found.
Miscellaneous errors
NAND flash corruption.
PID mismatch when upgrading Reboots.

the ROM.
Yes
Failed to remove files on

upgrade.
Reboots and retries.
Yes
Failed to set execute/start

address in the NAND flash.
Clears the NAND flash.
Yes
INDEX
CONTENTS
127
Major Minor Error
STB behaviour
Reboot
Kernel crash / no root FS.
Reboots (cannot clear the

NAND flash).
Yes
Invalid type of GIF file saved on Deletes the file.

NAND flash.
Yes
Failed to write files to NAND

flash.
Yes
Failed to gunzip the boot ROM Rejects image and reboots.

image.
Reserved for future use
Reserved for future use
Cryptographic failure (fatal)
No master key found.
Flashes in endless loop
No
No customer key found.
No
Signature check of customer

key failed.
No
Verification of IntactOS code

failed.
No
Key update during bootstrap

failed.
Flashes and then continues the

bootstrap.
Hardware failure (fatal)
Page write to ROM failed.
NAND flash hardware / format Keeps flashing code in endless No

failure.
loop.
SDRAM access failure.

loop.
Communication to Ethernet
chip failed.

loop.
STB has overheated.
Keeps flashing code in endless

loop.
A.2
Clears the NAND flash
Yes

loop.
Ethernet monitoring
The physical network connection at the back of the STB contains two LEDs. The Ethernet LEDs are set up as
follows:
128
CONTENTS
INDEX
Green on = 100Mbit or 10Mbit link detected

127(
On x4x series STBs only 100Mbit Ethernet is supported.
Green off = no link
Amber on - Tx or Rx packet. Data activity.
The speed at which the Amber LED flashes depends on the configuration of the ethernet chip and the network
activity.
INDEX
CONTENTS
129
130
CONTENTS
INDEX
Appendix BExample x4x DHCP configuration file
In this Chapter:
B.1 Ax4x DHCP configuration file
INDEX
CONTENTS
131
B.1
Ax4x DHCP configuration file
This Appendix contains a full copy of the unmodified DHCP file. This example configuration assumes that you
are creating a DHCP file for an AmiNET x4x STB.
127(
This is not a complete dhcpd.conf file. It just covers the various settings required
for AmiNet STB multicast bootstrapping, therefore it may require some changes
for deployment on your network, including modifying lines that are commented
out.
###############################################################################
# Extra Options for AMINO option space
###############################################################################
option space AMINO;
# These options are defined for communication between STB and the DHCP
# server for the class match (see below). These just need to exist
code
3 = text;
option AMINO.option
code
4 = text;
code
5 = text;
# Key values needed for booting the Amino STB, configuring network
# based applications and managing upgrades
code
8 = text;

code 16 = text;
code 18 = text;
code 22 = text;
code 28 = text;
# This extra options value is a general option for 3rd party or SDK
# customers to easily add their own DHCP options
code 32 = text;
# Optional different way of providing Minerva middleware argments

# instead of using AMINO.mw_args
code
6 = ip-address;
###############################################################################
# class "AMINOx4x"
132
CONTENTS
INDEX
# AMINOx4x - response to x4x family STBs during Main and Recovery image boot
###############################################################################
class "AMINOx4x"
{
#
option AMINO.software_uri "igmp://<mcast address>:<port>";
# OR an HTTP address
#
option AMINO.software_uri "http://server/image.mcfs";
}
###############################################################################
# Subnet Declaration
###############################################################################
subnet 192.168.1.0 netmask 255.255.255.0 {
###############################################################################
# Default Gateway - This MUST be set!!
###############################################################################
###############################################################################
# Subnet Mask - This MUST be set!!
###############################################################################
###############################################################################
# Domain Name - Optional
###############################################################################
option domain-name "mydomain.com";
###############################################################################
# DNS Servers - Optional
###############################################################################
option domain-name-servers 192.168.1.1,192.168.1.2;
###############################################################################
###############################################################################
###############################################################################
# Time Zone - Optional
INDEX
CONTENTS
133
Fully-specified Posix 1003.1 timezone string -
"GMT0BST-1,M3.5.0/01:00,M10.5.0/02:00"
http://h71000.www7.hp.com/doc/73final/6497/6497pro_007.html
http://en.wikipedia.org/wiki/List_of_tz_zones_by_name
###############################################################################
###############################################################################
# Address Pool - This MUST be set!!
# In this address pool we list the classes which we wish to give addresses to,#
# unless a device is in this list it will not be given a address!
###############################################################################
pool {
range dynamic-bootp 192.168.1.50 192.168.1.100;
range 192.168.1.101 192.168.1.200;
}
}
###############################################################################
# End dhcpd.conf
###############################################################################
134
CONTENTS
INDEX
Appendix CExample x3x DHCP configuration file
In this Chapter:
C.1 Ax3x DHCP configuration file
INDEX
CONTENTS
135
C.1
Ax3x DHCP configuration file
This Appendix contains a full copy of the unmodified DHCP file. This example configuration assumes that you
are creating a DHCP file for an AmiNET 130 and that the IP address of the multicast server is
239.255.225.100.
Should you wish to add a different model of STB, simply add the configuration details for that STB type.
127(
Some of the line lengths in this file have been shortened for the sake of
appearance.
Bold text indicates where the file contents have been edited.
Grey text indicates where the contents of the DHCP file are not strictly
necessary for the file to function correctly. If you are editing the file for one
particular type of STB, it may be worth removing the unnecessary grey text to
make the file less unwieldy.
This is not a complete dhcpd.conf file. It just covers the various settings required
for AmiNet STB multicast bootstrapping, therefore it may require some changes
for deployment on your network, including modifying lines that are commented
out.
#############################################################################
# Misc dhcp options
#
#############################################################################
allow bootp;
filename="AMINET.txt";
#############################################################################
# Extra Options for AMINO option space (used for multicast)
#
#############################################################################
option space AMINO;
option AMINO.port
code 3 = text;
option AMINO.option
code 4 = text;
code 5 = text;
code 8 = text;
option AMINO.dindex
code 11 = text;
option AMINO.STBrc-unicast-port code 14 = integer 16;
code 15 = text;
code 16 = text;
code 18 = text;
code 20 = text;
code 22 = text;
136
CONTENTS
INDEX
################################################################################
# AmiNET / Mood x4x config options
################################################################################
option AMINO.pbl_di
code 28 = text;
code 29 = text;
code 30 = text;
option AMINO.options
code 31 = text;
################################################################################
# Some MBS / Mood config options
################################################################################
option AMINO.mbc_bootorder
code 50 = text;
option AMINO.mbc_sap
code 51 = text;
option AMINO.mbc_unicast
code 52 = text;
option AMINO.recon
code 53 = text;
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
# Class "AmiNET103 mboot"
#
# AmiNET103 - response to bootrom request for a bootstrap image
#
#############################################################################
INDEX
CONTENTS
137

{
version>") or
((substring( option vendor-encapsulated-options, 2, 9)="AMINET103")
and (substring(option vendor-encapsulated-options, 13, 5)="mboot"));
}
#############################################################################
#############################################################################
# Class "AmiNET103 upgrd"
#
# AmiNET103 - response to bootstrap request for a main upgrade image
#
#############################################################################
{
match if (option vendor-class-identifier="Aminoaminet103upgrd") or
((substring( option vendor-encapsulated-options,2,9)="aminet103")
and (substring( option vendor-encapsulated-options,13,5)="upgrd"));
}
#############################################################################
#############################################################################
# Class "AmiNET103 fisys"
#
# AmiNET103 - response when booting in normal boot state
#
#############################################################################
class "AmiNET103 fisys"
{
match if (option vendor-class-identifier="Aminoaminet103fisys") or
((substring( option vendor-encapsulated-options, 2, 9)="aminet103")
and (substring(option vendor-encapsulated-options, 13, 5)="fisys"));
}
#############################################################################
AmiNET110 Configuration Section
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
138
CONTENTS
INDEX
#
#
#
#
#
#
#
#############################################################################
#############################################################################
#
#
#############################################################################
{
match if (option vendor-class-identifier="aminoAMINET11xmboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2, 9)="AMINET11x")
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
}
INDEX
CONTENTS
139
#############################################################################
# AmiNET110H Configuration Section
#
#############################################################################
#
#
# class "AmiNET110H mboot" - boot state when requesting bootstrap image
#
# class "AmiNET110H upgrd" - boot state when requesting main upgrade image
#
# class "AmiNET110H fisys" - boot state when in normal state
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
# Class "AmiNET110H mboot"
#
# AmiNET110H - response to bootrom request for a bootstrap image
#
#############################################################################
class "AmiNET110H mboot"
{
match if (option vendor-class-identifier="aminoAMINET110Hmboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2, 10)="AMINET110H")
}
#############################################################################
# Class "AmiNET110H upgrd"
#
# AmiNET110H - response to bootstrap request for a main upgrade image
#
#############################################################################
class "AmiNET110H upgrd"
{
match if (option vendor-class-identifier="Aminoaminet110hupgrd") or
((substring( option vendor-encapsulated-options,2,10)="aminet110h")
}
#############################################################################
# Class "AmiNET110h fisys"
#
140
CONTENTS
INDEX

#
#############################################################################
class "AmiNET110H fisys"
{
match if (option vendor-class-identifier="Aminoaminet110hfisys") or
((substring( option vendor-encapsulated-options, 2, 10)="aminet110h")
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
#
#
#############################################################################
{
match if (option vendor-class-identifier="aminoAMINET5xxmboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2, 9)="AMINET5xx")
}
#############################################################################
INDEX
CONTENTS
141

#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
#
#
142
CONTENTS
INDEX
#############################################################################
{
version>") or
((substring(option vendor-encapsulated-options, 2, 9)="AMINET124")
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
INDEX
CONTENTS
143
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
#
#
#############################################################################
{
version>") or
option AMINO.address <mcast address>;
option AMINO.port <port>;
}
#############################################################################
#
#
#############################################################################
{
option AMINO.address <mcast address>;
option AMINO.port <port>;
}
#############################################################################
#
#
#############################################################################
{
}
144
CONTENTS
INDEX
#############################################################################
#
# AmiNET120 - response when bootstrapping
#
#############################################################################
class "AMINET120 mboot"
{
match if (option vendor-class-identifier="aminoAMINET120mboot") or
#
option log-servers10.172.2.20;
}
#############################################################################
#
# AmiNET120 - response when upgrading
#
#############################################################################
class "aminet120 upgrd"
{
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
INDEX
CONTENTS
145
#############################################################################
#
#
#############################################################################
{
version>") or
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
#option AMINO.middleware <mcast address>;
#option AMINO.mw_port <port>;
}
#############################################################################
# AmiNET130M Configuration Section
#
#############################################################################
#
#
# class "AmiNET130M mboot" - boot state when requesting bootstrap image
#
# class "AmiNET130M upgrd" - boot state when requesting main upgrade image# #
# class "AmiNET130M fisys" - boot state when in normal state
#
#
#
#
146
CONTENTS
INDEX
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
# Class "AmiNET130M mboot"
#
# AmiNET130M - response to bootrom request for a bootstrap image
#
#############################################################################
class "AmiNET130M mboot"
{
match if (option vendor-class-identifier="aminoAMINET130Mmboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2, 10)="AMINET130M")
}
#############################################################################
# Class "AmiNET130M upgrd"
#
# AmiNET130M - response to bootstrap request for a main upgrade image
#
#############################################################################
class "AmiNET130M upgrd"
{
match if (option vendor-class-identifier="Aminoaminet130mupgrd") or
((substring( option vendor-encapsulated-options,2,10)="aminet130m")
}
#############################################################################
# Class "AmiNET130m fisys"
#
#
#############################################################################
class "AmiNET130M fisys"
{
match if (option vendor-class-identifier="Aminoaminet130mfisys") or
((substring( option vendor-encapsulated-options, 2, 10)="aminet130m")
INDEX
CONTENTS
147

}
#############################################################################
# AmiNET130H Configuration Section
#
#############################################################################
#
#
# class "AmiNET130H mboot" - boot state when requesting bootstrap image
#
# class "AmiNET130H upgrd" - boot state when requesting main upgrade image
#
# class "AmiNET130H fisys" - boot state when in normal state
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
# Class "AmiNET130H mboot"
#
# AmiNET130H - response to bootrom request for a bootstrap image
#
#############################################################################
class "AmiNET130H mboot"
{
match if (option vendor-class-identifier="aminoAMINET130Hmboot<bootrom
version>") or
((substring(option vendor-encapsulated-options, 2, 10)="AMINET130H")
}
#############################################################################
# Class "AmiNET130H upgrd"
#
# AmiNET130H - response to bootstrap request for a main upgrade image
#
#############################################################################
class "AmiNET130H upgrd"
{
match if (option vendor-class-identifier="Aminoaminet130hupgrd") or
((substring( option vendor-encapsulated-options,2,10)="aminet130h")
148
CONTENTS
INDEX

}
#############################################################################
# Class "AmiNET130h fisys"
#
#
#############################################################################
class "AmiNET130H fisys"
{
match if (option vendor-class-identifier="Aminoaminet130hfisys") or
((substring( option vendor-encapsulated-options, 2, 10)="aminet130h")
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
#############################################################################
#############################################################################
#
#
#############################################################################
{
version>") or
INDEX
CONTENTS
149

}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#############################################################################
#
#
#
#
#
#
#
#
#
#
#
# streaming on
#
#
#
#
#
#
#
#
#
#
#
#
#
150
CONTENTS
INDEX
#############################################################################
#############################################################################
#
#
#############################################################################
{
version>") or
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
#
#
#############################################################################
{
}
#############################################################################
# Class "M030mboot"
#
# Mood400-03x - response to bootrom request for a bootstrap image
#
# Bootrom sends different options for 030 and 032 h/w that we handle as the #
# same class here.
#
#############################################################################
#
class "M030 mboot"
{
INDEX
CONTENTS
151
match if (((substring(option vendor-encapsulated-options, 2,

11)="MOOD400-030") or
(substring(option vendor-encapsulated-options, 2,
11)="MOOD400-032")) and
(substring(option vendor-encapsulated-options, 15, 5)="mboot"));
}
#############################################################################
# Class "M030upgrd"
#
# Mood400-03x - response to bootstrap request for a main upgradeimage
#
#############################################################################
class "M030 upgrd"
{
match if ((substring(option vendor-encapsulated-options, 2, 4)="M030") and
(substring(option vendor-encapsulated-options, 8, 5)="upgrd"));
}
#############################################################################
# Class "M030upgrd"
#
# Mood400-03x - response when booting in normal bootstate
#
#############################################################################
class "M030 fisys"
{
match if ((substring(option vendor-encapsulated-options, 2, 4)="M030") and
(substring(option vendor-encapsulated-options, 8, 5)="fisys"));
}
#############################################################################
# Class "AmiNETx3x mboot"
#
# AmiNETx3x - response to bootrom request for a bootstrap image
#
#############################################################################
class "AmiNETx3x mboot"
{
match if (
or
(substring(option vendor-encapsulated-options, 2, 9)="aminet130")
or
(substring(option vendor-encapsulated-options, 2, 9)="AMINET530"))
and ((substring(option vendor-encapsulated-options, 13, 5)="mboot")
or
(substring(option vendor-encapsulated-options, 14, 5)="mboot"))
);
}
152
CONTENTS
INDEX
#############################################################################
# Class "AmiNETx3x upgrd"
#
# AmiNETx3x - response to bootstrap request for a main upgrade image
#
#############################################################################
class "AmiNETx3x upgrd"
{
match if (
or
(substring( option vendor-encapsulated-options,2,9)="aminet530"))
and (( substring( option vendor-encapsulated-options,13,5)="upgrd")
or
(substring( option vendor-encapsulated-options,14,5)="upgrd"))
);
}
#############################################################################
# Class "AmiNETx3x fisys"
#
# AmiNETx3x - response when booting in normal boot state
#
#############################################################################
class "AmiNETx3x fisys"
{
match if (
or
(substring( option vendor-encapsulated-options,2,9)="aminet530"))
and (( substring( option vendor-encapsulated-options,13,5)="fisys")
or
(substring( option vendor-encapsulated-options,14,5)="fisys"))
);
option AMINO.homepage "http://192.168.0.1/test.html";
}
#############################################################################
# class "AmiNETx4x"
#
# AmiNETx4x -
#############################################################################
class "AmiNETx4x"
{
match if (substring( option vendor-class-identifier, 0, 8)="AMINOx4x") or
(substring( option vendor-class-identifier, 0, 8)="Aminox4x");
option AMINO.software_uri "igmp://239.255.243.25:11111";
}
INDEX
CONTENTS
153
#############################################################################
# Subnet Declaration
#
#############################################################################
subnet 192.168.1.0 netmask 255.255.255.0 {
#############################################################################
# Default Gateway - This MUST be set!!
#
#############################################################################
#############################################################################
# Subnet Mask - This MUST be set!!
#
#############################################################################
#############################################################################
# Domain Name - Optional
#
#############################################################################
option domain-name "blahblah.com";
#############################################################################
# DNS Servers - Optional
#
#############################################################################
option domain-name-servers 192.168.1.1,192.168.1.2;
#############################################################################
#
#############################################################################
option time-offset -5; # Eastern Standard Time
#############################################################################
# Address Pool - This MUST be set!!
#
#
#
# In this address pool we list the classes which we wish to give
#
# addresses to, unless a device is in this list it will not be given an
#
# address!
#
#
#
#############################################################################
pool {
range dynamic-bootp 192.168.1.50 192.168.1.100;
range 192.168.1.101 192.168.1.200;
}
}
#############################################################################
# End dhcpd.conf
#
#############################################################################
}
154
CONTENTS
INDEX
Appendix DThe mcastbootd.conf file
In this Chapter:
D.1 mcastbootd.conf file components
D.2 Example mcastbootd.conf file
D.3 Troubleshooting and tips to measure and
test bandwidth/MTU/TTL
INDEX
CONTENTS
155
The mcastbootd.conf file (located in the /etc file folder) configures parameters for the mcastbootd
application. The mcastbootd application supplies a bootstrap and filesystem to Amino STBs via IP multicast
over the network. The mcastbootd.conf file also works in conjunction with information supplied to Amino
STBs via dhcpd/dhcpd.conf, the STBremoteconf application or the management pages/configuration
files within the STB.
D.1
mcastbootd.conf file components
This section describes the main parts of the mcastbootd.conf file.
D.1.1
File header
# Configuration file: <weekday> <month> <day> <hr>:<min>:<sec> <year>
Each time the signupgradeimage script is run it updates the timestamp in the Configuration file line.
D.1.2
[Server] section
This is the part of the mcastbootd.conf file where global parameters are set.
Global Server Parameters

LogLevel=<number>
Sets the debug log level from 0 to 10 for the mcastbootd -D parameter. The default value
is 4.
ImageDir=<file path>
Sets the common file path location where mc2 images and bootstraps are stored.
MulticastTTL=<number>
Sets the number of router hops to allow the multicast packets to traverse in order to contain
the scope of the multicast image. The default value is 1.
MulticastInterface=<interface>
On a system with multiple interfaces this option specifies which interface to use for the
Multicast traffic.
This is specified as the name of the interface:
MulticastInterface=eth0
D.1.3
Bootstrap and mc2 filesystem section commonalities
MulticastIPAddress=<Multicast IP Address>
Sets the Multicast IP Address that an Amino STB will join to download the bootstrap and the
mc2 filesystem. This must match the corresponding section of the dhcpd.conf file. The
Multicast IP Address and port combination should be unique and unused by other
applications on the network.
MulticastUDPPort=<Port Number>
Sets the Multicast Port Number
Description
156
CONTENTS
<any text can go here>
INDEX
SerialNumber
<integer> originally designated to control filesystem upgrades, but not fully

implemented. Number should not be altered or removed as it may cause mcastbootd not
to function properly. SerialNumber is incremented each time the
CycleTime
<integer> Repeat cycle every n seconds or 0 for repeat continuously. Defaults are set at
5 seconds and repeat continuously for bootstrap and filesystem respectively.
DataRate
<integer> Data rate in kb/s. The default for the bootstrap is 128kb/s = 1 Mb/s. The
default for the mc2.mcfs is also 128kb/s = 1 Mb/s. An image using these two settings
would output a multicast stream of roughly 2 Mb/s aggregately.
A quick way to convert the DataRate from kb/s to Mb/s is do simply divide the kb/s by 128.
For example, 128kb/s = 1 Mb/s, 256kb/s = 2 Mb/s, 512kb/s = 4 Mb/s.
The bootstrap and mc2 filesystem multicast are delivered simultaneously. Therefore the
bandwidth set for the bootstrap image must be added to the bandwidth set for the mc2
filesystem when considering the total network bandwidth requireded by the mcastbootd
application.
D.1.4
Bootstrap Section
PacketSize
<integer> Sets the size in Bytes of bootstrap packets to conform to network MTU size
requirements and prevent packet fragmentation. Default is set at 1456.
FileName
<absolute or relative filepath><bootstrap filename> The default is set

to <relative path of the present working folder>/
bootstrap.signed>
ImageType
D.1.5
mc2 Filesystem Section
DirsPerCycle
<integer> The number of times to multicast a filesystem from beginning to end before
moving to the next filesystem (assuming there is more than one). The default is set to 128.
PacketSize
not used in the mc2 filesystem section. The PacketSize for the mc2 filesystem section is
instead controlled by the 'signupgradeimage -s<PacketSizeInBytes
<integer>>' process.
D.2
Example mcastbootd.conf file
# Configuration file: Fri Apr 11 12:39:40 2003

[Server]
LogLevel=4
MulticastTTL=1
[Image bootstrap.signed]
FileName=bootstrap.signed
ImageType=1
SerialNumber=1
PacketSize=1456
INDEX
CONTENTS
157
CycleTime=0
[Filesystem mc2]
ImageName=mc2
SerialNumber=2
DirsPerCycle=128
DataRate=256
CycleTime=0
[Filesystem mc2]
ImageName=mc2
SerialNumber=2
DirsPerCycle=128
DataRate=256
CycleTime=0
D.3
Troubleshooting and tips to measure and test bandwidth/

MTU/TTL
The following sections describe troubleshooting tools and common problems.
D.3.1
Common network monitoring/bandwidth measuring tools
Ethereal/Tethereal/Wireshark/Tcpdump: These are common pcap/winpcap file generating sniffing

applications that can capture or display network traffic.
Bwm/bwm-ng: Useful network interface bandwidth monitoring tool that can display bandwidth usage on
an ethernet interface.
Ping/Traceroute/Tracert: Common ICMP protocol tools that can help understand basic connectivity, mtu
and topological information.
Helpful Linux Commands may require sudo prefix:
ps -ef | grep mcastbootd | grep -v grep - A command to show details of how many instances
of mcastbootd may be running (only one can run at one time).
pgrep mcastbootd - Returns on the Program ID's (PIDs) of the running mcastbootd processes.
kill <pid1> <pid2> - Stops running the instances by PID number.
killall mcastbootd - Stops running all instances of mcastbootd
netstat -rn - Shows all of the routes on the system.
Ifconfig - Shows all interface information on a system.
route add -net 224.0.0.0 netmask 240.0.0.0 eth0 - A command that routes all multicast
traffic out the eth0 interface.
158
CONTENTS
INDEX
D.3.2
dhcpd interaction
The dhcpd.conf file interacts with the mcastbootd.conf file by providing the STB with the multicast IP
addresses and ports used to get the bootstrap and mc2 filesystem in order to upgrade the STB.
For x3x platform STBs:
The multicast IP address and port for each STB model mboot section corresponds to the
mcastbootd.conf bootstrap multicast IP/Port combination for that STB model.
Similarly, the multicast IP address and port for each STB model upgrade section corresponds
with the mcastbootd.conf mc2 file multicast IP/Port combination for that STB model.
The fisys section can contain a multicast IP address and port when used for auto-upgrading
STBs. (see the Set-Top Box Configuration Guide)
D.3.2.1 Common problems/mistakes

1.
mcastbootd not running - The STB will usually provide an LED flashcode of 2:3 or 2:4.
2.
Too many instances of mcastbootd running. The STB will usually provide a flashcode of 2:3.
3.
No route for multicast. - Check routes/add multicast route
4.
Firewall blocking route. - Check firewall permissions.
5.
Wrong mc2 file STB type. Means that either DHCP is pointing STBs to the wrong mc2 file or the mc2
file is misnamed/incorrect. This usually results in a flashcode of 2:7.
6.
File not found - Incorrect file path set for image/file. The mcastbootd.conf file can provide path
information three ways:
using the global setting of ImageDir
specifying the absolute or relative path in the ImageName and/or
FileName lines or running mcastbootd from the folder containing all of the images.
Only one strategy should be used for consistent results. Secondly, make sure that the actual files for
the mc2.mcfs files contain the .mcfs file extension. However, the reference in the
mcastbootd.conf file will not contain the extension.
7.
8.
The signupgradeimage script fails. There are three main reason why this script can fail:
There is no dummy mc2 filesystem entry in the mcastbootd.conf. The sign upgrade
image script checks for a dummy mc2 filesystem like the last entry in the sample above.
The CUSTOMER_KEY is not properly exported
Utilities have not been copied into the /us/local/bin folder from the proper location in the
build.
Multicast not making it to the STB through the routed network. The multicast TTL needs to be
increased. Usually indicated by an LED flashcode of 2:3 or 2:4, but it can be verified that a single
instance of mcastbootd is multicasting and is able to exit the server.
INDEX
CONTENTS
159
160
CONTENTS
INDEX
Appendix ESoftware builds: general

information
In this Chapter:
E.1 Software builds
E.2 What is a software release?
E.3 Software release designation
INDEX
CONTENTS
161
E.1
Software builds
AmiNET STBs support a wide range of functions. The software enables as much user customisation as possible,
but in order to minimise the size of the software image loaded onto an STB, it is built to support a particular
set of functions. Once a build has been created, it is possible to customise it with customer specific security
keys, additional files and configuration settings. However, it is not possible to enable functionality that has not
been compiled into the software build. For this reason, it is useful to understand what is included in a software
build, and what can be added later.
127(
The build stage shown in this diagram is internal to Amino.
%XLOG
'HYHORSPHQW
4XDOLW\$VVXUDQFH
6RIWZDUHEXLOG
&XVWRPLVH
&XVWRPLVDWLRQ
&UHDWH,PDJH
6LJQHGVRIWZDUHLPDJH
&RQILJXUH
,QVWDOODWLRQ
&RQILJXUDWLRQ
2SHUDWLRQ
Figure E.9 Software build and customisation stages
162
CONTENTS
INDEX
The following table shows the stages at which some of the key functionality can generally be added or
changed:
E.1.1
Stage
Options
Build
Browser and middleware support

Hardware platform
Subtitles
BitBand support
Some CA system support
Some language support
Customise
RSA security keys

Enable/disable Telnet/SSH
Graphic shown during upgrade
Some CA system support
Some language support
Packet size and file format for multicast software images
Configure
Configuration settings e.g. browser display, language choice,

output format
Build options
Various STB functions are locked or disabled during a hardware build, to protect the STB from interference.
This includes identity settings such as MAC address and serial number. STBs with these functions enabled are
referred to in this guide as development builds (these are sometimes also called production). STBs with
the functionality locked are known as live builds.
127(
E.2
Software releases designed to support functions only available during

development include production in the name of the release version.
What is a software release?
Software releases are planned to primarily provide a major core release and then interim point releases for
urgent customer fixes.
E.2.1
Major core releases (0.X.0)
These are planned by date and driven by new features, such as core improvements or support for new
platforms.
E.2.2
Release candidates (0.X.0-rcZ)
Released as part of the major core development, release candidates allow the new features and
improvements to be tested before customer builds use the core.
INDEX
CONTENTS
163
E.2.3
Minor core releases (0.X.Y)
Minor point releases are driven by bug fixes and are not planned to a specific date as closely as major releases.
Point releases will typically occur once all the scheduled bugs against them are fixed, but may be pulled
forwards if required for specific customer releases.
E.2.4
Patch core releases (0.X.Ycp)
It is assumed that whenever a new major core is released, it contains all the features found in the previous
major core including those in point releases for that major core. Not all customers are able to move to the
latest core version so they may subsequently require patches to older core versions. In the past these have
been considered as point releases for the older core but this leads to confusion.
Consider the following hypothetical example:
Development of 0.13 stops at 0.13.7 because 0.14.0 (which contains fixes up to and including 0.13.7) is
released. Point releases of 0.14 begin.
Customer A requires a fix to their 0.13 release but cannot move to the 0.14 baseline for some reason. Instead
of a 0.13.8 point release being created, which may lead to confusion as to whether that fix was included in
0.14.0 or not, 0.13.7 gets patched to create a 0.13.7a1 release.
Subsequent patches for customer A will increase the final number - 0.13.7a2, 0.13.7a3, etc. If other customers
require different patched versions, the letter is changed. For example, 0.13.7b1 or 0.13.7c1
E.3
Software release designation
The following diagram explains the component parts of a software release designation:
dD
D
^W,W
d
d
Zs,t
^tZ
,t^
d^d
D,
,
164
CONTENTS
INDEX
Index
A
Ax3x platform
automatic upgrading 101
configuring the DHCP server 45
installing the software 43
introduction 16
starting the installation 44
upgrading the software 89
Ax4x platform
automatic upgrading 81
configuring the DHCP server 25
installing the software 23
introduction 16
starting the installation 24
upgrading the software 67
B
Bootstrap
directory 16
See also software images 19, 55
Bootstrap image 19, 55
distributing 20
Bootstrap state
DHCP request
Ax3x 96
DHCP response
Ax3x 96
Bootstrap.unsigned 16
Build options 163
D
Deployment index
software versioning
Ax3x 105
Ax4x 85
using for automatic upgrade
Ax3x 105
Ax4x 85
DHCP options supported
Amino Ax3x 60
Amino Ax4x 37
Standard Ax3x 59
Standard Ax4x 36
DHCP request
Ax3x Bootstrap state 96
Ax3x Filesystem state 100
Ax3x Upgrade state 98
Ax4x 79
DHCP response
Ax3x Bootstrap state 96
Ax3x Filesystem state 100
Ax3x Upgrade state 98
Upgrade state
Ax4x 79
Ax3x 45
Ax4x 25
dhcpd.conf 17, 18
Distributing software 112
Document plan 11
E
C
Class IDs
Ax3x 63
Client IDs
Ax3x 63
Ax4x 37, 59
Commands file 17, 19
config.txt 17
Configuration pages
mcnfg.tar 17, 18
Configuring the multicast server 31
customise script 17, 19
Customising splashscreens 86
Example DHCP configuration file

Ax3x 136
Ax4x 132
F
Filesystem state
Ax3x
DHCP request 100
DHCP response 100
Operation
Ax3x 99
Ax4x 80
fkeys.conf 17
INDEX
CONTENTS
165
flashcontents file 33, 56, 71, 93
Ax3x 102
Ax4x 82
G
O
Getting the software 21
Graphics
loading.gif 17, 18
splash.gif 17, 19, 95
opera.ini 17, 18
H
Passwords
shadow file 114
Private configuration key 18, 19
Private customer key 18, 19
Public configuration key 18, 19
Public customer key 18, 19
Public master key 18, 19
HTTP upgrade 68, 90, 117
I
imagecomponents directory 18
imgcfg file 17, 19
Installation prerequisites 21
IntActOS 63
K
Keys
Amino engineering keys
keys directory 17, 19
Key.private customer 18, 19
key.public 18, 19
master.public 18, 19
security keys 110
STBrc-key.private 18, 19
STBrc-key-public 18, 19
keys directory 17, 19
LED flashing codes 125

loading.gif 17, 18
M
Matching values
Ax3x 54
Ax4x 32
mc2 packet sizes
Ax3x 58
Ax4x 35
mc2.mcfs 17, 18
mcastbootd binary file 17, 18
mcastbootd.conf 17, 18, 156
mcnfg.tar 17, 18
Migrating (Deployment Index) 85
Multicast server
automatic starting
Ax3x 104
Ax4x 83
starting
Ax3x 58
Ax4x 36
Multicast server configuration
Ax3x 52
Ax4x 31
Multicast upgrade settings
CONTENTS
S
Security
Amino Master key 110
customer key 111
hierarchy 110
STBRC key 111
server directory 16, 18
Setting up a multicast system 21
settings file 17, 18
Set-top box operation
Filesystem state
Ax3x 99
Ax4x 80
Upgrade state
Ax3x 97
shadow file 114
signbootstrap script 16
signupgradeimage script 17, 18
Software builds 162
Software images
Bootstrap 19, 55
Distributing 20
Installing from USB device 40
Signing a bootstrap image
Ax3x 55
Signing an upgrade image
Ax3x 56
Ax4x 33
Upgrade 20
Ax3x 55
Ax4x 33
Software release designation 164
software uri 39, 61
166
Recovery
See also software images 19
Recovery image
Ax4x 19, 33
Reflash
Ax3x 90
Ax4x 68
Reflash/Reset button (x4x) 68, 74
Release directory contents 16
rsakeys 17, 19
INDEX
Source Specific Multicast 70

splash.gif 17, 19, 95
Static DHCP serttings
Ax3x 94
Ax4x 78
Static network settings
Ax3x 102
Ax4x 82
Symbolic links
Ax3x 63
verifysignature script
Ax3x 17
Ax4x Opera 11 19
T
time zone
Ax3x 50
Ax4x 30
U
Unsigned bootstrap image 16
Upgrade image 20, 33, 55
See also Software images
Upgrade mechanisms
DHCP server
Ax3x 90
Ax4x 68
HTTP upgrade 117
JMACX API
Ax3x 90
Ax4x 68
Management pages
Ax3x 90
Ax4x 68
Reset button
Ax4x 68
STBremoteconf
Ax3x 90
Ax4x 68
upgrade methods summary Ax4x 70
Upgrade state
DHCP request
Ax3x 98
DHCP response
Ax3x 98
Ax4x 79
Operation
Ax3x 97
Upgrade system types 20
upgradeimage directory
Ax3x 17
Ax4x Opera 11 18
Upgrading software
Ax3x 92
Ax4x 68
USB device
installation from 40
utils directory
Ax3x 17
Ax4x Opera 11 19
V
Vendor options in DHCP
Amino Ax3x 60
Ax4x 37
INDEX
CONTENTS
167
168
CONTENTS
INDEX

Install Upgrade 112

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Install Upgrade 112

Uploaded by

Copyright:

Available Formats

Software Installation and Upgrade Guide

Amino Communications Ltd. 2014 CONFIDENTIAL

Software version 0.18.5 is an upgrade

x3x series STBs

Software version 3.2.1 is an upgrade

Amino Communications Ltd. 2014 CONFIDENTIAL

This is not the embedded operating system in the set-top box.

Amino Communications Ltd. 2014 CONFIDENTIAL

Configuring the DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

Configuring the STB time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Configuring the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Software installation from a USB device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Amino Communications Ltd. 2014 CONFIDENTIAL

Chapter 3 Installing the Ax3x software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Configuring the DHCP server. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Configuring the STB time zone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Configuring the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Starting the multicast server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Upgrading the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

The STB operational state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

Amino Communications Ltd. 2014 CONFIDENTIAL

Automating multicast server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

Using STBremoteconf to upgrade software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Upgrading the software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

About STB operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

STB configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .101

Automating multicast server start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .104

Amino Communications Ltd. 2014 CONFIDENTIAL

Chapter 6 STB Security Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

Distributing software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .112

Chapter 7 Upgrading using HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

Using the customise script. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Appendix ALED flashing codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .123

List of LED flashing codes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

File header . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156

Amino Communications Ltd. 2014 CONFIDENTIAL

Example mcastbootd.conf file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .157

D.3.1 Common network monitoring/bandwidth measuring tools. . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Appendix ESoftware builds: general information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

Build options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

What is a software release? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163

Amino Communications Ltd. 2014 CONFIDENTIAL

Amino Communications Ltd. 2014 CONFIDENTIAL

About this guide

Figure 4.1 Plan of Installation and Upgrade Guide

Amino Communications Ltd. 2014 CONFIDENTIAL

Indicates optional parameters - for example in commands or functions.

Cross-reference to other sections and other documents (this is a clickable

Amino Communications Ltd. 2014 CONFIDENTIAL

A description of software builds, and the

Installing the Ax4x software

A step-by-step guide to installing the software

Installing the Ax3x software

A step-by-step guide to installing the software

Upgrading Ax4x STBs

Methods of upgrading and updating the

Upgrading Ax3x STBs

Methods of upgrading and updating the

STB Security Features

Describes the use of the Amino security keys.

Upgrading using HTTP

Describes how to upgrade using HTTP,

How to add an Amino Postbuild pack to the