Page History

Introduction

      This document covers the design of FirmwareControl plugin  for RPI board. 

Limitations

...

1.   RPI box will reboot twice for Firmware upgrade only during first time, after booted for first time

...

Design Approach

       Initially firmware version is validated against the version mentioned in input and further actions are proceeded only if the versions mismatch

       URL and given parameters are validated

1. . First reboot creates two more partition if its not available and second reboot activates the new image. 
2.     User has to reboot the box manually after firmware update is completed. Auto reboot after image update is not handled currently.

Design Approach

       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         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. 

       The tar package is unzipped to find rootfs tarball.

        create new thread to handle rest of the operations.

         rootfs tar ball is copied to passive memory bankDuring 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.

• Sequence diagram

          Image Removed

Future Enhancements

   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.