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. Additionally, the reboot can be decoupled, allowing for a later or scheduled reboot after the firmware download. 

Architecture

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. 

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.

JSON Response from XConf server:

XConf returns firmware information as a JSON string, as shown in the following sample.

{
"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

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

1. XConf Admin UI
2. 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.