-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
ad1d13d
commit 0e142dc
Showing
1 changed file
with
58 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,58 @@ | ||
| # bgbootload | ||
| Secure OTA BLE bootloader for SiLabs EFR32BG chips and BGM111 modules | ||
| ## Overview | ||
| This project was created to provide an open-source alternative to the closed source OTA (Over The Air) bootloader provided by Silicon Labs | ||
| for their Blue Gecko chips and modules. This bootloader has been tested with the BGM111A BLE module, but should work with any of the | ||
| EFR32BG series chips. | ||
|
|
||
| ## Why an open source bootloader? | ||
| The SiLabs BLE stack is closed source - the rationale for this is understandable, but most of the OTA bootloader is built into the | ||
| stack, and uses a proprietary file format, and is thus quite opaque in its operation. It's not clear what encryption (if any) or end-to-end | ||
| data validation is used, and there are difficulties in using it with GCC rather than the expensive IAR compiler. An open-source | ||
| bootloader can be customised to individual requirements, uses a non-proprietary file format, and can use verifiable encryption methods. | ||
| ## Configuration | ||
| The BLE stack used is V2.1.1.0. The stack is provided by SiLabs as a pre-compiled BLOB (binstack.o) and a symbol file (stack.a.) | ||
| The stack must be loaded into flash at a fixed address (0x4000) and is used by the bootloader and any applications by making calls | ||
| using the addresses in stack.a. What this means is that binstack.o and stack.a are linked with the bootloader, but the application | ||
| program need only link with stack.a, since the stack BLOB is already loaded with the bootloader. | ||
|
|
||
| The SiLabs bootloader module is not used in this configuration. | ||
| ## Project layout | ||
| This repository includes 3 separate projects. | ||
| * bootload - this is the code for the the bootloader itself, which incorporates the BLE stack | ||
| * utils - one main utility which converts compiled applications into an encrypted firmware file | ||
| * app - a sample application which can be flashed to a device using the bootloader | ||
|
|
||
| ## Requirements | ||
| The projects all build using CMake, and are compatible with the CLion IDE, though this is not required. Testing has been done on | ||
| MacOS only, but there should be little difficulty in building on Linus or Windows using Cygwin. Required tools and libraries are: | ||
| * An ARM GCC compiler - the version used is the arm-none-eabi variant, version 4.9_2015q3. | ||
| * OpenSSL libraries - used for AES encryption and SHA-256 hashing on the build host. | ||
| * libuuid - for manipulating UUIDs on the build host. | ||
| * Host C compiler - for building the utilities | ||
| * A bootloader client - this is an app running on e.g. Android which can send firmware files to the bootloader for flashing into RAM. A usable | ||
| client is included in this repository as an APK - no source provided. | ||
|
|
||
| A set of configuration files provide the encryption key and BLE Service UUID used to define the bootload service. If you were to use | ||
| this bootloader for your own applications, you should customise the encryption key and service UUID to ensure that your application | ||
| can only be loaded onto a device running your bootloader. The bootloader sets the debug lock to prevent the decryption key being read from the chip. | ||
|
|
||
| ## Memory usage | ||
| The SiLabs BLE stack reserves some memory for its own purposes. The stack code loads into flash from 0x4000 to 0x20D00, and reserves RAM | ||
| from 20000000 to 20002FFF. The bootloader is linked with binstack.o to place the BLE stack in the correct location, and the bootloader code | ||
| itself is linked in the area from 0 to 4000, leaving flash memory from 21000 onwards available for the application. RAM from 20003000 is | ||
| used by the application and the bootloader, but only one of these will be running at any given time, so all the RAM not reserved | ||
| by the stack is available to the application. | ||
| ## Boot sequence | ||
| On reset, the bootloader gains control. It checks for the presence of an application program (by a magic number located at a known | ||
| address.) If an application is not present, or the reset was of a type other than power on and there is a special key in memory, it sets a flag | ||
| which will prevent the application program from being run. | ||
| This enables the bootloader to be loaded without an application program or allows the application | ||
| to programmatically invoke the bootloader. | ||
| The bootloader then initialises the BLE stack, following which it regains control, then either starts the application program, or | ||
| starts up its own BLE service. The bootloader service UUID is stored in a firmware file, so the bootloader client knows which service | ||
| to look for. There are two BLE characteristics, one for control and one for data which are used to transfer the application to | ||
| the bootloader. The bootloader decrypts the data using the CRYPTO hardware, and verifies a SHA-256 hash to confirm successful and | ||
| complete programming. If all this is successful it will enable the application program, which will run on the next reset. | ||
|
|
||
|
|