Any existing bootloader implementation — regardless of its source or maturity — is a starting point. What follows the evaluation phase is the work that doesn't appear in any documentation: adapting the base to the actual requirements of the project.
These are the areas that consistently require custom development. None of them is optional in a device that will receive firmware updates in the field.
Communication Interface
An available base may support several interfaces, but not necessarily the one the project requires — or may implement it in a way that conflicts with the hardware design. At the bootloader level, there is no RTOS, no middleware, no abstraction layer. Whatever interface the project requires has to work bare metal: initialized correctly, reliable from first power-on, independent of the application stack.
Image Integrity
Before the bootloader jumps to a new application image, it must verify that the image is complete and uncorrupted. A CRC or hash computed over the image and validated against a stored reference is the standard approach. The specifics — where the checksum lives, when it's computed, what happens on a mismatch — are project decisions that have to be made deliberately.
Power can fail mid-transfer. Storage writes are not atomic. A half-written image that passes no integrity check must never be allowed to execute.
Transmission Security
Not every project requires encrypted or authenticated firmware updates — but the question has to be answered explicitly, not skipped by default. For connected devices, regulated applications, or any product where firmware authenticity matters, the bootloader needs to verify that the image came from a trusted source.
The right mechanism depends on the threat model and the hardware available. What doesn't change: this decision belongs in the design phase, not after the product ships.
Fail-Safe and Recovery
A device in the field that receives a corrupted update, loses power mid-flash, or encounters an unexpected failure must still be recoverable — without physical access, without a programmer. The approaches vary: dual-bank flash with automatic rollback, a protected recovery partition, a minimal fallback image. The right solution depends on available memory and what the product can tolerate.
Whatever the mechanism, it has to be tested under the actual failure conditions it's designed to survive. Not simulated. Tested.
Beyond the Four
Depending on the project, additional areas may require custom work: anti-rollback enforcement to prevent installing an older version, multi-image support when the product includes more than one programmable component, or explicit configuration of flash write-protection and memory access controls.
The common thread is that none of this is delivered by any existing base out of the box. It represents the gap between code that demonstrates a feature and firmware that can be trusted in the field — which is the only version that matters.