RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Page History
| Table of Contents | ||
|---|---|---|
|
Introduction
The Firmware upgrade component will upgrade the device firmware depending upon the configurations given against the device in XConf server. This process involves determining which version to download, where to download it from (including support for FQDN and secure endpoints), the protocol for downloading (with HTTPS as the preferred method and fallback to HTTP or TFTP), and the ability to schedule firmware checks based on timezones and quiet times. Additionally, the reboot can be decoupled, allowing for a later or scheduled reboot after the firmware download.
Architecture
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
On the server side, the business logic determines which version of the firmware code needs to be provided for download. The firmware upgrade process is initiated by the device, which sends information such as its current firmware version and capabilities to the server. Based on this information, the server identifies the appropriate firmware version and provides the download location. The firmware upgrade mechanism uses the CPE to download the code from the server.
On the device side, the firmware upgrade process is managed by the System rdkservices plugin(org.rdk.System), which handles user-initiated upgrades through the updateFirmware method. This plugin invokes the deviceInitiatedFWDnld.sh script to communicate with the XConf server and fetch the required firmware information. Once the server responds with the firmware version and download instructions, the script initiates the download. After the download is complete, a device-specific script executes to handle platform-specific tasks and verify the integrity of the downloaded firmware. Following this verification, the script invokes the OEM Flash Utility to apply the new firmware.
Configuration Details
CPE makes an HTTPS request to XConf to get firmware information. The request may be an HTTPS POST or GET. The response is a JSON string. An example GET for the production XConf instance would look like this.
| Code Block |
|---|
https://xconf.rdkcentral.com:19092/xconf/swu/stb?eStbMac=AA:BB:CC:DD:EE:FF |
The following table lists some of the parameters which may be sent.
| Name | Example value | Description |
|---|---|---|
| capabilities | rebootDecoupled, RCDL, supportsFullHttpUrl etc. | Specifies capabilities of the CPE that XConf needs to know about. This is a multi-valued parameter. More than one capability may be sent. Separate the values using url?capabilities=value1&capabilities=value2&capabilities=value3. These capabilities should not live forever. Once all CPEs are known to support a given capability, XConf should deprecate/delete code that handles CPEs that don't support the capability and CPE should stop sending the capability value. |
| env | PROD | VBN | QA | DEV | environment of the CPE. |
| eStbMac | AA:BB:CC:DD:EE:FF | MAC address of the CPE. |
| firmwareVersion | abc123 | CPE's current firmware version. |
| ipAddress | 192.0.2.146 | IP address of the device. |
| model | abcd | CPE model. |
| rebootImmediately | true|false | immediate reboot flag. |
JSON Response from XConf server:
XConf returns firmware information as a JSON string, as shown in the following sample.
| Code Block |
|---|
{
"firmwareDownloadProtocol":"tftp",
"firmwareFilename":"rdkb-generic-broadband-image_rdkb-2024q1-dunfell_20240609064020.rootfs.wic",
"firmwareLocation":"192.168.161.216",
"firmwareVersion":"rdkb-generic-broadband-image_rdkb-2024q1-dunfell_20240609064020",
"ipv6FirmwareLocation":"fe80::da3a:ddff:fe0a:aad2/64",
"rebootImmediately":false,
"mandatoryUpdate":false
} |
XConf should be able to add new values, and the CPE should still be able to process the JSON string by ignoring any values it doesn't understand.
Error Handling
| Error | Description |
|---|---|
| 500 Internal Server Error | On server error, CPE may implement retry logic or not. Most 500 errors will be caused by bad requests, but some may be temporary conditions. |
| Timeout | If the request to XConf times out, CPE should implement retry logic. |
| 404 / Empty JSON | There are times when XConf does not wish to respond to the CPE. In these cases, it will send an HTTP 404 (not found) response and a prose text reason for why the response was not handled. The CPE should ignore these responses (and not retry the request to XConf). |
Firmware Upgrade using RDK Community XConf Server
RDKM offers a reference XConf server that is publicly accessible at the URL xconf.rdkcentral.com. Users have the option to either use this XConf server or create their own.
In RDKM XConf server- xconf.rdkcentral.com, user would be able to see two options in the landing page
- XConf Admin UI
- XConf Data service
Users can configure firmware rules, configurations, telemetry settings, RFC settings, etc., in the admin UI. The data service currently provides the XConf version information, including which version is used, when it was last updated, and the commit information.
To know more about the process of firmware upgrade using the RDKM XConf server at xconf.rdkcentral.com, please click here. If you are interested in setting up a custom XConf server, please visit the XConf server user guide for configuration and feature validation for detailed instructions on installation and usage.
Overview
Community Forums
Content Tools
Tasks