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) / 51K

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. 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 installer partition FS Figure 2: Flash map after FS resizing It is important to update the MCT in the proper sequence in order to aid in crash recovery (the sequence eliminates the window where a failure could be fatal). The proper sequence is as follows: 3.1) Create a backup of the current MCT. This step can be skipped if the current MCT is identical to the bootrom default. The location for this needs to be fixed (so the bootrom can find it). The end of the password sector is a good choice. Note that this location requires a password sector erase to clear the backup. Care must be taken to avoid a potential security hole. 3.2) Create a new MCT by copying the old one and adding the new MCT_INSTALLER, MCT_FS_FIXED and MCT_OS_FIXED entries and removing the old MCT_OS_FIXED/MCT_FS_FIXED/ MCT_OS_DYNAMIC/MCT_FS_DYNAMIC as needed. 3.3) Calculate the new MCT_CRC. 3.4) Replace the MCT in flash with the newly created one. 4) If OTAFU_CreateInstallerPartition() returns success, then the installer partition was created successfully. At this point the JVM may start downloading the Firmware Installer. The JVM should send the data to the following API: STATUS OTAFU_WriteInstaller( const WORD *data, DWORD size, DWORD offset ) where: data = pointer to a block of raw uncompressed binary installer data size = the size of the data block to be written offset = offset (in bytes from the start of the installer) where this block will be written. Repeated calls to this API will fill in the installer partition created in step 3 with the installer binary. A failure either means that there is not enough space left, or there was some flash write error. The end result of a successful operation will be the flash map shown in Figure 3. OS1 empty installer FS Figure 3: Flash map after downloading the installer 5) After the installer binary has been successfully downloaded the JVM must initiate the upgrade by calling an API. This API will: 5.1) set the installer "start bit" 5.2) initiate a reboot. 6) Upon Reset the bootrom will check if the MCT contains a MCT_INSTALLER record. If so, the bootrom will verify the cryptographic signature of the installer. If this test fails, then the normal bootrom procedure is followed: namely running a crypto check on the existing OS and booting it. This is the reboot path that is followed if the reset happened before the download was complete. Resuming the download should be possible in this case. If, on the other hand, the installer crypto check succeeds, and the installer "start bit" is set, then control passes to the installer program. 7) The installer program has one main purpose, to copy the new OS binary (which is contained in a compressed format in the installer) overtop of the the old OS. This simple task could have been performed directly by the bootrom, but this method allows new features such as LCD drivers for progress indicators and new compression algorithms to be added to the installation procedure. After the copy operation is complete, the flash map looks like that in Figure 4. OS2 installer FS Figure 4: OS copy operation completed 8) In order to clean up and finish the installation, the temporary MCT records are deleted and the installer code is erased, in that order (Figure 5). A final reset is all that is now required to complete the install. OS2 FS Figure 5: Post-Install flash map Failure Recovery The primary failure cause addressed here is a battery pull or other spurious reset. Coding bugs are beyond the scope of this document. 1) Failure prior to the MCT update in step 3.4 is irrelevent. Normal bootup procedures will succeed. Resuming is possible. 2) Failure at MCT update (step 3.4): In this event the Bootrom will boot and attempt to verify the MCT. The verification will fail, and the Bootrom must restore the default MCT. The backup MCT stored in a fixed location (in the password sector) will be verified and then restored to the MCT sector. If the backup failed or does not exist, then the factory default in the bootrom metrics is used in its place. Normal boot procedure is then followed. 3) Failure at step 4, 5, 6, or 7: On bootup, the flash will look like some variant of Figure 6 with the Installer or OS1 incomplete/invalid (note: at least one of OS1 and Installer will ALWAYS be valid). OS1 empty installer FS Figure 6: failure recovery If Installer is valid, then control passes to it, and it completes the installation (resuming at step 7). Otherwise control passes to OS1 and the JVM is responsible for picking up the upgrade where it was left off. This would probably entail completing the installer download (resuming at step 4). 4) Failure at step 8 after the MCT update will result in normal bootup procedures and the FS code will properly delete any left over installer that is found. Installer File Format The following is a sample installer file format: Installer metrics Installer code Firmware binaray (compressed diff) OSSignatureStruct Figure 7: Firmware Installer file format Installer metrics: typedef struct { DWORD InstallerCookie; // INSTALLER_COOKIE DWORD MetricsVersion; // INSTALLER_METRICS_VERSION DWORD MetricsSize; // sizeof(InstallerMetricsStruct) DWORD InstallerVersion; // INSTALLER_VERSION DWORD InstallerSize; // size of the installer package to be placed in flash DWORD InstallerScratch; // number of additional flash sectors allocated for the installer DWORD RevertSize; // size of a revert image DWORD HardwareID; char DeviceString[64]; char BuildUserName[16]; char BuildDate[16]; char BuildTime[12]; DWORD OldOSSize; MetricsDataStruct OldMetrics; DWORD NewOSSize; MetricsDataStruct NewMetrics; // Previous elements are valid in rev 1.0 // New elements added here. } InstallerMetricsStruct;

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