Bootloader and Firmware Common Usage and Firmware Upgrade

Question

There are two case when working on an embedded system. Embedded system have limited resources like as ARM Cortex M0 Microcontroller with 12 K Flash.

Case 1 : Common function/module usage for Bootloader and Firmware : Bootloader and Firmware may need to use same module and function to prevent code duplication. Otherwise, same code will be included both Firmware and Bootloader twice. We can prevent this by specify the function address and call this function by calling functions by addresses. This is one of the solutions.

Is there any smart method to provide common function usage?

Case 2 : Sometimes, we need to upgrade firmware. One of the duties of bootloader is firmware upgrades. We can easily upgrade the firmware by overwrite the old one.

As we saw, two case can be implemented separately. But when we merge they, some problems are appeared.

Question : Bootloader's are generally static objects but firmware's are can be modified. Therefore, common functions are generally located at Bootloaders. But when we need update a common module/function, how can we do?

What are the general or smart approaches which bootloader, firmware structured embedded systems? In Addition, for limited resources.

To discrete common modules/functions, Can one or more additional areas solve this problems. Firmware, Bootloader and Library(New Area)?

I want to learn general approaches. Is there any paper, book and source about advanced Firmware management?

Thanks

Answer 1

If you share code between your bootloader and your mainline firmware application, then your bootloader will be using this code when it flashes the application space. In order to prevent this condition you must sacrifice the ability to update the common code, otherwise your bootloader will crash.

With only 12k of flash, it's pretty ambitious to expect a bootloader and mainline application to fit. You might consider writing the bootloader in assembly (gasp!). Some Cortex M0 parts (such as the NXP LPC11xx family) have an additional boot ROM which stores some useful functions and help alleviate some of the memory constraints.

Answer 2

Your question states the problem correctly - you cannot have your cake and eat it. Either:
1. You go for a small memory footprint and do not include firmware upgrade logic in the bootloader (i.e bootloader might just validate application image CRC etc but nothing more complicated). Here you could share functions to save space. OR
2. The bootloader has firmware upgrade functionality. Here you have to have shared functions compiled both into app and bootloader. The shared functions should be small - probably not a huge overhead but you need the space that this would take - if you dont have it then you need to go for more memory.
There is no way to share functionality and do firmware upgrade from bootloader reliably.

Answer 3

In lights of the current discussion about security in the firmware update process I would like to add the following for clarification: Sharing code between the bootloader and the app will open yet another door for the potential attack, so you really want to avoid that.

The bootloader part is the part you actually do not want to change ever, this should be as static as possible. If the bootloader is broken, in-the-field-updates become nearly impossible or at least insecure.

Having said that, you might want to use a different approach. You could create a maintenance mode for your device. This mode opens the JTAG interface and allows direct access to memory. Than the service technician could apply the update.

Now you "only" need to secure the activation of the maintenance mode. The following could work: Use a UART interface to communicate the activation.

1. Maintenance system sends its own id and requests maintenance mode via UART
2. The id of the maintenance system, a random number and a unique system id are sent back to the maintenance system.
3. The maintenance system sends this id-sequence to your certification server.
4. If the unique system id and the maintenance systems id is correct, the server will create a signature of the information received and send it back to the maintenance system.
5. Your system now will receive the signature via UART
6. Your system verifies the signature against the previously send id-string with a public key stored during production
7. On a successfull verification maintenance mode is entered

To add security, you definitely want to put some effort into the maintenance systems id following a similar scheme. The ID should basically depend on MAC-address or another unique hardware id and a signature of the same. The ID should be created in a secure environment during production process of the maintenance system. The unique hardware id should be something visible to the outside world, so the server could actually verify, whether the ID received matches with the maintenance system communicating with the server.

This whole setup would give you a secure firmware update without a bootloader. To have secure firmware updates, common understanding is, that you need a authentication system based on asymmetric encryption like RSA. If you need the verification code anyway, the above will exchange a bootloader capable of accepting updates with a simple UART interface, saving some resources in the process.

Is this something you were looking for?

A commercial bootloader in my experience uses between 4 and 8k of flash memory depending on flash algorithm and a couple of other things. I have been sticking with the same vendor throughout my carreer, so this might vary from your experience.

A digital signature system optimized for embedded systems uses approximately 4.5kByte in flash memory (for an example, see here: https://www.segger.com/emlib-emsecure.html ) and no more RAM than the stack.

You see, that 12k is really really low in terms of having a system which can be updated securely in the field. And even more so, if you want the system to be updated using a bootloader.