For more information, including FAQs and resources, please visit the link below:
RDKM-SSO
Any questions or comments please feel free to contact RDK Support team support@rdkcentral.com . Thank you. ***
This document covers the design of FirmwareControl plugin for RPI board.
Considering the current requirement, the design approach followed for FirmwareControl plugin is as follows.
FirmwareControl plugin is to be enabled from Metrological UI for firmware update else request is denied. Upon receiving firmware upgrade request, we initially validate the parameters. Execution is proceeded only if parameters are valid.
By default RPI is having only SD card support for flashing OS and boot and have only two partitions,one for Kernel(FAT32) and other for rootfs(ext3) (mmcblk0p1, mmcblk0p2), one new partitions is created as passive bank during run-time using fdisk and mkfs.ext3 command. Device is rebooted after creating partition to update device partition table. This happens only on the first request after image is flashed to device, further firmware update requests skip this step as device has three partitions.
Upon receiving firmware update request, package tar file mentioned in request, Pkg.tar.gz file from given HTTP server is copied to a file in /tmp of active memory bank. After download Hash values are compared with downloaded file and request to confirm Downloaded file and mentioned one are same.
During installation, new directory is created in active memory bank and is mounted to passive bank. the downloaded tar image is untarred to the mounted directory. From the untarred image, kernal and rootfs data is extracted and is loop mounted to temporary locations in passive memory bank. The extracted kernal data is copied to memory partition1 (mmcblk0p1) and the existing data is copied to a backup folder. rootfs is mounted to passive memory bank. cmdline.txt is modified for activating passive memory bank and active memory bank to passive. Device is then rebooted for activating the new image.
1. Validate requested firmware version with currently implemented firmware version. Firmware upgrade happens only if the versions are different.
2. Triggering firmwareUpgrade automatically without user intervention.