The Set-Top-Box Bootloader is a crucial piece of software (actually firmware that is generally burnt into (ROM) Read Only Memory, usually One Time Programmable (OTP)) that performs not only the vital job of the classic bootstrap (Power on, boot, launch application) for the device but also is fundamental to applying software updates to the system. Like in PCs, the bootstrap is the initial code that is loaded that generally performs a self-test to check if the device configuration is OK, and looks for an image to load that essentially boots the device into operation, ultimately loading the EPG application.
The Bootloader is generally implemented as very low-level code, with limited set of drivers to enact the basic hardware functionality, with the focus of occupying as small a footprint as possible. There are different types of Bootloaders implemented in STBs, generally known as "n-stage" Loaders. Typically you find a Singe-Stage Bootloader and Two-Stage Bootloaders. A Single-Stage Bootloader entails an all-encompassing loader, self-sufficient, not requiring the help of another bootstrap to continue the boot process. Whereas, a 2-Stage Bootloader, as the name suggests, includes a secondary stage, that kicks of a higher-level bootstrap to facilitate the loading of subsequent system components.
As a STB Project manager, there will be a occasions where the Bootloader requires special attention. This is especially true for projects involving brand-new hardware, different Middleware or Drivers. Generally though, the Bootloader is closely coupled with the Target Hardware: Change in Hardware implies Bootloader changes. However, if implemented correctly, the software architecture for a Bootloader can be effectively designed like any other software stack, with generic components as a Middleware would, leaving a HAL/Hardware Abstraction Layer open to port for different Hardware devices, thus making the job of supporting Bootloader code more efficient. In some cases, Bootloader is a product in its own right, and many companies and consultants have made a business out of it.
STB Bootloaders could be provided by the CA Vendor, Middleware Vendor, or traditionally the STB Manufacturer, because of the code being so low-level and tightly linked to the physical hardware. In the early days when the traditional medium of delivering software to the STB was through the physical tuner cable, the role of the Bootloader was relatively simple. It gets complicated when we move to hybrid STBs, especially with an IP connection, as this opens up another channel for distributing software updates. IP Bootloaders in STBs is relatively new, and hasn't reached a state of maturity as say, the traditional Satellite STB Bootloader. Bootloader testing is extremely technical and complicated, the security, reliability and resiliency testing is really thorough. For example, when testing a Satellite STB, the Bootloader must deal with all kinds of Signal Quality conditions: Removing the signal feed in the middle of the download process, recovering signal, time-outs and general reliability: pulling out the power during the final stages of the write process, etc.
In an IP Bootloader, the same scenarios are considered, but at the TCP/IP networking level. First and foremost, the STB IP Loader must implement a robust IP networking stack. We had a problem in one of our projects where the Bootloader had hard-coded MAC addresses to Zero! We only picked this up late in the project as we entered the final testing. Such basic scenarios should not get past the first stage. Once we fixed that problem, we then hit stability problems: network jitter, packet loss & general robustness w.r.t. IP-connectivity. The Bootloader software component must be ready and verified well in advance of formal production of the hardware. Remember this component is burnt into the STBs at the time of manufacture. It has to be defect-free, any rework post production is going to be next to near impossible, or severely time constraining, manual reworking that will cost the PayTV operator tons of money. You screw up the Bootloader, you fired!
The above experience thus triggered me to instigate a more formal, rigorous process in managing the Bootloader Workstream, which is presented below.
Template for STB Programme Manager: Bootloader Workstream
If your STB project involves a hardware element then it's most likely to impact the Bootloader. It is essential to highlight this dependency in your project plan, even though you might not be directly responsible for the development & delivery of the said platform. If the project was initiated well, or your organisation is quite mature and have been delivering STB projects for many years, then this workstream happens almost like clockwork, automatically in the background, most likely by your company's STB Hardware / Drivers Porting team.
Nonetheless, defining the key roles and assigning owners to the management of the Bootloader delivery will help clarify and add structure to the overall programme:
- Product Owner - If you're a broadcaster or PayTV Operator, you need a good understanding of the feature-set and requirements of this component that meets the needs of your business objectives & operations. If you're a component supplier, you still need someone to own the product specification for this component.
- Technical Owner - Is someone with technical responsibility, generally an architect, who will translate the Product Owner's requirements into detailed technical requirements specification, that Bootloader vendors must implement.
- Component Owner - The party responsible for implementing, testing & delivery of the Bootloader component.
- System Integrator: Low-Level & System High Level. The responsiblity of the assigned STB System Integrator to prove the integration of the said software component.
- Quality Assurance: Security & Customer. Generally CA Vendors provide certificate of approval of the Bootloader, as it has to pass strict security criteria, remember the CA is responsible for generating millions in revenue (this is generally known has Low-Level code testing). The Bootloader therefore has to be secure to prevent intrusion, compromising the integrity of the STB, leading to piracy. The PayTV operator also performs ATP as the Bootloader must adhere to various business scenarios for software download, upgrade, resiliency & recovery modes. Operator testing is generally referred to as High-Level Code or Customer Code testing.
- Project Team. There must be a Project Manager assigned to manage this Workstream. There are generally many dependencies at the System Integration level, so this is best assigned to an SI Project Manager.
 |
| Simple Template for Bootloader Workstream
Download the Template!
Some other useful references around Bootloaders S3's Whitepaper on STB Migration Tutorial on the inner workings of a STB |
No comments:
Post a Comment