Browse Prior Art Database

Method of Over-the-Air Firmware Update

IP.com Disclosure Number: IPCOM000130442D
Publication Date: 2005-Nov-11
Document File: 4 page(s) / 18K

Publishing Venue

The IP.com Prior Art Database

Abstract

Updating the firmware on a mobile device to upgrade the device wirelessly Over-the-Air (OTA) is difficult. It must be completely fault tolerant (i.e. assuming that the battery could fail at any moment) and it must be secure.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 31% of the total text.

OVER-THE-AIR FIRMWARE UPGRADE

Method of Over-the-Air Firmware Update

Disclosed Anonymously

Updating the firmware on a mobile device to upgrade the device wirelessly Over-the-Air (OTA) is difficult.  It must be completely fault tolerant (i.e. assuming that the battery could fail at any moment) and it must be secure.

Certain devices have implemented security restrictions that make it more difficult to perform this upgrade. Devices must not be possible to update the firmware with code that is not approved and accepted by both the device manufacturer, network carrier or approved partners.

Furthermore, the device must not be possible to get into a state where the device does not start and/or requires connection to a desktop to repair.  Some of these problems to be considered include:

·        Limited space on boot ROM for storing new features.

·        Boot ROM refusing to execute unsigned code.

·        A desirable user feedback mechanism to capture user feedback.

·        A carrier requirement that the update agent itself be updateable.

OTA Firmware Upgrade Steps

One proposed method for performing an Over-The-Air firmware upgrade on a mobile device is as follows:

1)   The initial state of a normal operating device will look like that in Figure 1.  The Operating System (OS) will occupy the first ~2MB and the file system (FS) will fill in the remainder.

           

OS1

 

FS

             Figure 1:

Normal

device flash map

2)   Before initiating an OTA firmware upgrade, the device must acquire the metrics information of the binary to be downloaded.  This information must be communicated down to the OS for verification.  The OS will return either TRUE (the chosen download is acceptable for this device) or FALSE (the chosen download is invalid for this device).  In the latter case, the device should not proceed.

3)   In order to allocate space for the downloaded firmware installer binary, the device should clear enough total space in the FS.  Once this is done, the device should make a request to the OS to resize the FS and create a partition for the upgrade installer.  This request is made Via a call to the API:

        OTAFU_CreateInstallerPartition(data, size, allowRevert )

        where:

            data = a pointer to the installer metrics that has been downloaded

            size = the size of installer metrics that has been downloaded

            allowRevert = allocate extra flash to allow the install to be reverted later (Boolean)

    The task of this function is to verify the installer metrics, and to locate a suitable place in flash where the installer partition should be created.  It will then create the installer partition (relocating FS data if required).  This involves updating the device MCT to resize existing partitions and add a new MCT_INSTALLER partition.

    The end result of this step is a memory map like that in Figure 2.

           

OS1

 

empty

empty

insta...