RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
Children Display |
---|
Table of Contents |
---|
...
...
This Page is under Development
< Describe the system design in broad terms . Consider benefits, costs and schedule and technical risks. Describe how the proposed solution aligns with the enterprise architecture. >
<Alternative designs considered and why one was chosen>
<Architecture Diagram>
<Describe the communication between the sub-systems. (Diagrams may be used to illustrate communications). >
< Identify input interfaces, function call protocol, and the nature of the data structures passed across the interface between the sub-modules>
< Identify output interfaces, function call protocol, and the nature of the data structures passed across the interface. >
<Provide a description of the data model>
< Describe the cases that are identified as problem but unable to report to it due to various factors. Describe the factors >
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.
draw.io Diagram | ||||
---|---|---|---|---|
|
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. < Describe how the current design is suitable for future enhancement without completely modifying existing design . >