[closed] updating the bootloader via OTA -- is it possible?

[hassan789]

Hello,
Is it possible to update the bootloader via OTA?

[ESP_Angus]

No. At least, it's not supported and it's not possible to do so safely.

It is technically possible to erase the bootloader sectors and rewrite them from an app (you may need to disable this option first), but if there's a power failure or a crash before the process completes then the device will need physical reflashing to unbrick.

[hassan789]

No. At least, it's not supported and it's not possible to do so safely.

It is technically possible to erase the bootloader sectors and rewrite them from an app (you may need to disable this option first), but if there's a power failure or a crash before the process completes then the device will need physical reflashing to unbrick.

I see. Looks like, rom bootloader always jumps to 0x1000... so it seems that it basically impossible to have a safe-upgrade of stage 2 bootloader.

[p-rimes]

This is interesting, and maybe it calls for refactoring the current ESP-IDF bootloader such that there could be a fallback bootloader. So there would have to be another level of initial bootloader. At least, it seems like whatever the initial bootloader stage should fit in a single flash sector at 0x1000. In that initial bootloader sector, enough code to verify integrity of that sector (If it is good, then jump to a more complicated bootloader. In the case of corruption, select the fallback bootloader which may or may not be updatable.)

It does seem slightly risky to have a bootloader which cannot be updated, and/or a multi-sector bootloader that could be corrupted during update.

[ESP_Angus]

I'd like to hear bit about what the use cases are for OTA bootloader updating.

From the ESP-IDF side, we try to keep as much functionality out of the bootloader as possible - for this reason. And we keep IDF backwards compatible with older bootloaders (you should be able to boot an app built from current master branch on an ESP-IDF V1.0 bootloader, if necessary.)

For ESP32, we can't really change this as the Mask ROM is what boots from 0x1000 (I guess technically we could make an additional bootloader stage so it goes ROM->second stage at 0x1000->third stage at ???->app, but this seems a little overly complex and brittle) However we can consider our options for future chips.

So, what situations are you looking to accommodate via bootloader OTA?

[p-rimes]

Hi ESP_Angus, thanks for replying.

Well, looking backwards in time, if I understand correctly MD5 checksumming was not always present in the bootloader. So there may be bootloaders out there which do not support checksummed boots, and will never be able to gain that feature. While that doesn't actually affect any of my products, that's an example of when I would want to upgrade my bootloader.

And, this extra (2nd? 3rd?) stage bootloader process is what I am suggesting. I believe a first stage bootloader that fits within a single flash sector (and contains enough code to verify its own sector), would be optimal.

This is not super high on my priority list tbh, but I just thought it should be noted that a single-sector bootloader has some benefits.

[hassan789]

I'd like to hear bit about what the use cases are for OTA bootloader updating.

Hi Angus,
For devices that don't have any human interaction (eg street lamps), the bootloader can contain logic to auto-fallback to factory OR auto-rollback to previous good running image, OR auto-validate new image as running good. These features are critical in large scale deployments. A lot of this logic is not present early into the project, so waiting to perfect the bootloader causes a large delay to market. Also, the logic is highly dependent on the role of the partition (ie. factory, test, safe-mode, previous stable running build, etc). If a role of any of those partitions is added/changed, then a bootloader update may be required.

In short, from the software developers perspective, a safely-upgradeable bootloader allows for faster launch to market with a simpler bootloader, as well as increases flexibility to allow the dev team to change anything and everything later down the project.

[User_416]

No. At least, it's not supported and it's not possible to do so safely.

It is technically possible to erase the bootloader sectors and rewrite them from an app (you may need to disable this option first), but if there's a power failure or a crash before the process completes then the device will need physical reflashing to unbrick.

Hi,
since we are interested in updating the bootloader even if it's not possible to do it safely, I would like to ask what should be the option, mentioned above, to disable first.

[DrMickeyLauer]

Let me chime in here and ask about the same. Our situation is that that we forgot to enable the OTA ROLLBACK support in the bootloader we released for manufacturing. Now I would really love to retrofit this by updating the bootloader in the field, even if it‘s a theoretically risky situation.

[chegewara]

Hi,
it is possible if you have enabled option in menuconfig, which is mentioned few posts earlier
https://docs.espressif.com/projects/esp ... rous-write

I didnt test it, so im not sure if it is enabled in bootloader or firmware tho.