OSAL Firmware update implementation for EFR32 Wi-SUN

[ismilak]

The PR is based on osal_fw_rw_api branch and it consist 3 well separated topics:

1. Fixed build issues for all platforms: linux, FeeRTOS, efr32_wisun

2. Refactor OSAL APIs and introduce new APIs.

• Slot header and related definitions are moved to OSAL

• osal_read_firmware() and osal_write_firmware() are refactored: The original APIs were designed to write and read the entire firmware image to the storage, on linux, into a file. For EFR32 platform we need to use gecko bootloader storage to store the images and the image cannot be stored in the RAM. The new osal_read_firmware_slothdr() and osal_write_firmware_slothdr() can be used to store the header only. For EFR32 NVM3 (non volatile memory section) is used to store the headers

• osal_write_storage() API is introduced as a portable interface to implement write storage operation for storing data chunks in the image block POST request. For linux it's a simple memcpy, for EFR32, Gecko bootloader write storage is used.

• osal_erase_storage() API is implemented to erase the particular storage slot. Gecko Bootloader requires erase operation before the write operations to store a new image to the "upload" slot.

• osal_deploy_and_reboot_firmware() API is implemented for having portable bootloader API calls. Gecko Bootloader requires "verify image", "set image to boatload" and "reboot and install" calls for EFR32. The bootable image slot should contain the GBL (Gecko Bootloader) file content.

• osal_copy_firmware_slot() API is introduced for having copy operation. For "backup" request, we need to copy "upload" storage slot to the "backup" storage slot, that is not a simple memcpy operation.

3. Implement APIs and TLVs for EFR32, refactor existing platform TLVs.

• Initialise 2 Gecko bootloader storage slot with 512KB size: Upload, Backup storage slots. Run image storage slot is the internal application flash in EFR32 SoCs, therefore it is not implemented as available storage slot.

• All the APIs are implemented for all platforms. If the platform doesn't support the particular API, an empty implementation is provided.

• Implemented EFR32 TLVs: in image block post request, we need to remove the Csmp header from the first chunk, because it can't be stored in the bootloader slot. In the TLV, the bootloader slot offset is calculated and managed separately from firmware image offset.

• Implemented OSAL APIs for EFR32: Gecko Bootloader and NVM3 API are integrated. NVM3 is used for storing storage header for all slots: Run, Upload, Backup.

• Csmp header structure is refactored: "image" allocation is removed from the structure definition (only for EFR32)

Improvement ideas

• emulate storage slot implementation for linux: creating a file per storage with 1MB size, that is filled with dummy data. Using fseek API, the chunks cane be stored directly in to the file, image allocations is not required. An other benefit is matching with other platforms

• remove tlvs port sources. If the OSAL API-s are well-defined, and can be used in the TLV handlers, portable TLV handlers are not required anymore (The same recommendation in osal_fw_rw_api PR)

• remove code duplications, move platform specific and common source to OSAL: csmp_info.h and csmpinfo.h are the same. In this PR the Csmp header definitions is moved into OSAL too. Library sources can use the OSAL API.

[ismilak]

Tested Linux and EFR32 version:

• With a fresh new deploy, downloading 'opencsmp-node-6.8-sample-image.bin':
• Set upload slot as backup image
• Perform scheduled reboot and install from FND (EFR32 is failed due to invalid images)
• Verify the downloaded images with getting slots from external flash (EFR32). I attached the slot hex files to compare.
  All the tests are succeeded.
  upload-slot
  backup-slot

[ismilak]

FYI Critical memory leak is solved in 3bba235

It's a general issue for all platforms, since it's in csmp_firmwareMgmt.c that is a not platform specific library source.

[ismilak]

EFR32 test result with real gbl file (lzma compression, ~389KB)

• Upload CsmpAgent_efr32_wisun_6.3.0.gbl.bin to Cisco FND succesfully
• Start and follow the firmware update on EFR32 Wi-SUN device.
• Schedule a reboot in FND
• Check the new firmware runtime as well: register to the FND

All the tests are passed. The sample log shows the output after rebooting the new firmware (it prints "!!!! NEW Csmp Agent Lib Sample Application). The device with the new firmware operates without any problem: it was registered successfully to Cisco FND.