Over the air (OTA) bootloading update tutorial?
-
Yes, MYSBootloader overwrites firmware directly in place and node has no way of recovering if things fail (more that retry the firmware update over and over).
The DualOptiboot + flash is a bit safer as it can always boot from the old firmware if checksum fails for the new firmware.
-
I have made a french tuto for jeedom. it is about Dualoptiboot OTA (with external eeprom). I will try to translate it in english when I will have time (maybe this week-end I will see). or maybe if someone does it in the mean time...
-
I have a small nit-picky request - could we say "OTA Bootloading" when we mean "Over the Air Bootloading"?
We have also discussed things like the OTA payload format, which means the bytes actually sent over the air (versus over a serial link, for example). We can also talk about the OTA speed vs the SPI speed.
OTA just means "Over the Air", which can apply to several things, not just bootloading. If we keep this clear now, it won't be a perpetual confusion, when a newbie comes across discussion about OTA protocols and assumes it MUST mean bootloading protocols because OTA==bootloading.
And if this is too much trouble to keep clear, never mind. Not a deal breaker.
-
I have a small nit-picky request - could we say "OTA Bootloading" when we mean "Over the Air Bootloading"?
We have also discussed things like the OTA payload format, which means the bytes actually sent over the air (versus over a serial link, for example). We can also talk about the OTA speed vs the SPI speed.
OTA just means "Over the Air", which can apply to several things, not just bootloading. If we keep this clear now, it won't be a perpetual confusion, when a newbie comes across discussion about OTA protocols and assumes it MUST mean bootloading protocols because OTA==bootloading.
And if this is too much trouble to keep clear, never mind. Not a deal breaker.
-
OK, here's some background, for some eventual Wiki article or such.
So there are 4 main ways to get a program into the uC:
- In System Programming (ISP) - uses SPI pins + reset, can program entire flash as well as fuses. This is how we get bootloaders into protected section of Flash. (There are also parallel programmers, and sometimes even additional methods like DebugWire or JTAG).
Using these methods is more cumbersome, so the Arduino folks chose to use "bootloaders" - a small program programmed (via ISP) into a protected section of on-chip Flash, and which can in turn communicate with the outside world and write (program) a compiled sketch into the rest of on-chip flash. The bootloaders are invoked by rebooting (or upon powerup) the uC.
-
Serial bootloader using Arduino bootloader protocol (subset of Atmel's STK500 protocol). A program in a protected section of uC onboard flash that can write compiled sketches into the rest of flash. Optiboot is the name of a particular serial bootloader used in many ATMega328p Arduino derivatives. (Not always used in APM (Arduino Pro Micros) but can be).
-
MysBootloader - similar to the serial bootloader, is a small program in a protected section of on-chip flash which can write compiled sketches into the rest of the flash, but it gets the data to write from special Over The Air (OTA) bootloader packets rather than via the serial port.
-
DualOptiboot - this is another OTA bootloader, but the idea is that you write the new compiled sketch (in binary) into an external flash chip, and then only after you have received and validated the entire new binary do you reboot and let the bootloader copy from external flash to on-chip flash. Called DualOptiboot because it's derived from OptiBoot and still supports serial bootloading as well.
With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into a sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the OTA bootloader. The DualOptiboot approach is perhaps in some ways a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast. Also, if all else fails, you can still open up the node and user serial bootloading. However, DualOptiboot only works when you have an appropriate off-chip flash memory connected, which limits your hardware.
I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would involve using a subset of the RFM69 library in the bootloader, and had not yet been done when this was written.
If OTA bootloading fails, you can try again (you may need to power cycle the node). You can reduce the distance between source and destination. You can open the node and fall back to normal serial bootloading (at least with DualOptiboot, maybe with future versions of MysBootloader). And of course there is the fallback of using ISP (assuming the PCB doesn't do something to the reset & SPI lines that breaks that option).
Since MysBootloader keeps requesting replacements for missing or corrupted OTA bootloading packets, it usually won't fail unless the node is really out of range or there is terrible interference.
Tekka points out below a different failure mode - suppose the bootloading was successful, but the sketch itself is faulty (bugs). A serial bootloader like OptiBoot takes control upon reset (which in modern Arduinos can usually be triggered via the serial connection using an additional wire), and goes into bootloading mode if it receives proper data on the serial port - or if not, starts the currently loaded sketch. This may also happen on power up. For an OTA bootloader there's no additional wire to trigger reset on the target uC. Tekka says that MysBootloader can recover and load another sketch OTA while for some bugs in a sketch, DualOptiboot cannot recover (without a manual reset).
-
OK, here's some background, for some eventual Wiki article or such.
So there are 4 main ways to get a program into the uC:
- In System Programming (ISP) - uses SPI pins + reset, can program entire flash as well as fuses. This is how we get bootloaders into protected section of Flash. (There are also parallel programmers, and sometimes even additional methods like DebugWire or JTAG).
Using these methods is more cumbersome, so the Arduino folks chose to use "bootloaders" - a small program programmed (via ISP) into a protected section of on-chip Flash, and which can in turn communicate with the outside world and write (program) a compiled sketch into the rest of on-chip flash. The bootloaders are invoked by rebooting (or upon powerup) the uC.
-
Serial bootloader using Arduino bootloader protocol (subset of Atmel's STK500 protocol). A program in a protected section of uC onboard flash that can write compiled sketches into the rest of flash. Optiboot is the name of a particular serial bootloader used in many ATMega328p Arduino derivatives. (Not always used in APM (Arduino Pro Micros) but can be).
-
MysBootloader - similar to the serial bootloader, is a small program in a protected section of on-chip flash which can write compiled sketches into the rest of the flash, but it gets the data to write from special Over The Air (OTA) bootloader packets rather than via the serial port.
-
DualOptiboot - this is another OTA bootloader, but the idea is that you write the new compiled sketch (in binary) into an external flash chip, and then only after you have received and validated the entire new binary do you reboot and let the bootloader copy from external flash to on-chip flash. Called DualOptiboot because it's derived from OptiBoot and still supports serial bootloading as well.
With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into a sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the OTA bootloader. The DualOptiboot approach is perhaps in some ways a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast. Also, if all else fails, you can still open up the node and user serial bootloading. However, DualOptiboot only works when you have an appropriate off-chip flash memory connected, which limits your hardware.
I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would involve using a subset of the RFM69 library in the bootloader, and had not yet been done when this was written.
If OTA bootloading fails, you can try again (you may need to power cycle the node). You can reduce the distance between source and destination. You can open the node and fall back to normal serial bootloading (at least with DualOptiboot, maybe with future versions of MysBootloader). And of course there is the fallback of using ISP (assuming the PCB doesn't do something to the reset & SPI lines that breaks that option).
Since MysBootloader keeps requesting replacements for missing or corrupted OTA bootloading packets, it usually won't fail unless the node is really out of range or there is terrible interference.
Tekka points out below a different failure mode - suppose the bootloading was successful, but the sketch itself is faulty (bugs). A serial bootloader like OptiBoot takes control upon reset (which in modern Arduinos can usually be triggered via the serial connection using an additional wire), and goes into bootloading mode if it receives proper data on the serial port - or if not, starts the currently loaded sketch. This may also happen on power up. For an OTA bootloader there's no additional wire to trigger reset on the target uC. Tekka says that MysBootloader can recover and load another sketch OTA while for some bugs in a sketch, DualOptiboot cannot recover (without a manual reset).
@Zeph said:
With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into the sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the bootloader itself. The DualOptiboot approach is perhaps a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast.
Maybe it's worthwhile noting here: if you upload a faulty sketch (e.g. failing to call gw.process() in regular intervals or hanging after startup) there is no way to recover OTA using dualoptiboot. This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.
Usually I get pretty stable and non-faulty transmissions, about 40secs to upload an average-sized sketch - besides that, MYSBootloader re-requests corrupt or incomplete FW blocks.
I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would be a substantial rewrite I suspect.
Yep, and including RFM69 compatibility should be relatively straightforward.
-
So the MYSBootloader doesn't support RFM69 radios right now. Does the DualOptiboot support RFM69?
-
** I think it can also accept serial protocol - or not?**
I believe it doesn't. It would be nice if it can accept serial upload. I would then be called Dual MysBootloader :)
-
@Zeph said:
With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into the sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the bootloader itself. The DualOptiboot approach is perhaps a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast.
Maybe it's worthwhile noting here: if you upload a faulty sketch (e.g. failing to call gw.process() in regular intervals or hanging after startup) there is no way to recover OTA using dualoptiboot. This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.
Usually I get pretty stable and non-faulty transmissions, about 40secs to upload an average-sized sketch - besides that, MYSBootloader re-requests corrupt or incomplete FW blocks.
I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would be a substantial rewrite I suspect.
Yep, and including RFM69 compatibility should be relatively straightforward.
@tekka said:
Maybe it's worthwhile noting here: if you upload a faulty sketch (e.g. failing to call gw.process() in regular intervals or hanging after startup) there is no way to recover OTA using dualoptiboot.
Ah. In theory, a DualOptiboot system would have a checksum of the new firmware written to external flash, and would not copy from external flash to internal flash until that was valid. I gather from what you say that this is not currently implemented?
This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.
Usually I get pretty stable and non-faulty transmissions, about 40secs to upload an average-sized sketch - besides that, MYSBootloader re-requests corrupt or incomplete FW blocks.
Cool. If MYSBootloader is reliable in loading new firmware OTA, I'm not sure what point there would be to the external flash method (DualOptiboot), at least within the MySensors ecosystem. Perhaps bootloader size?
If there was some way to embed a full library (ie: all functions needed by our sketches) for the nRF into the bootloader for OTA flashing, but also make it accessible it from sketches rather than loading a second copy of a nRF library, that could be a low cost variant (in terms of overall uC Flash).
-
@Zeph said:
With the bootloaders, once they begin to program the rest of flash, they wipe out the old compiled sketch - the chip can't in general boot into the sketch again until all of the new sketch has been successfully programmed. With a serial bootloader, this is usually pretty straightforward and reliable. But flashing a page at a time via an OTA bootloader like MysBootloader is a little more dicey in that it's easy to miss packets and leave the chip in a "broken" state - with no workable sketch, only the bootloader itself. The DualOptiboot approach is perhaps a little safer, in that the current sketch in on-chip flash is not overwritten until there is a validated copy of the new code in an external flash; then copying from external to internal flash by DualOptiboot is again pretty reliable and fast.
Maybe it's worthwhile noting here: if you upload a faulty sketch (e.g. failing to call gw.process() in regular intervals or hanging after startup) there is no way to recover OTA using dualoptiboot. This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.
Usually I get pretty stable and non-faulty transmissions, about 40secs to upload an average-sized sketch - besides that, MYSBootloader re-requests corrupt or incomplete FW blocks.
I believe that at this time, MysBootloader only works with the nRF24L01+. It basically needs a subset of the nRF's library in the bootloader section (which grows the bootloader from 1/2 KiB to 2KiB I think). Porting it to use the RFM69 would be a substantial rewrite I suspect.
Yep, and including RFM69 compatibility should be relatively straightforward.
@tekka said:
This is the strength of MYSBootloader; you can basically develop sketches, transmit OTA and test - if they fail, power-cycle (or take advantage of the watchdog) and upload a new/updated sketch.
MysBootloader sounds very promising! In relation to the OP, who asked for a tutorial, is there a tutorial for it?
-
A thing to remember is that while MYSBootloader does not require an external flash to intermediately store the new firmware, this means it cannot support authenticating new firmwares as well (at least not currently from what I gather).
DualOptiboot on the other hand can support this since the checksumming of the updated firmware can be signed and verified before rebooting (and overwriting the existing firmware from external flash).
If signing is enabled and required and the checksum is not properly signed, it will be rejected and the bootloader won't be "informed" to do the update. This is at least in theory. I have not yet had the time to look into OTA security. But from the little I have learned, I would recommend DualOptiboot for the paranoid for this reason. Using MYSBootloader is easy, but it is also easy for an attacker to knock out security by remotely replacing the node firmwares. -
another little difference between the two otas is with Dualoptiboot you can still use ftdi to upload sketch (dual!), could be useful sometimes. with MYSbootloader you can't upload with ftdi. but of course if there is ota, it should not be a problem!
-
A thing to remember is that while MYSBootloader does not require an external flash to intermediately store the new firmware, this means it cannot support authenticating new firmwares as well (at least not currently from what I gather).
DualOptiboot on the other hand can support this since the checksumming of the updated firmware can be signed and verified before rebooting (and overwriting the existing firmware from external flash).
If signing is enabled and required and the checksum is not properly signed, it will be rejected and the bootloader won't be "informed" to do the update. This is at least in theory. I have not yet had the time to look into OTA security. But from the little I have learned, I would recommend DualOptiboot for the paranoid for this reason. Using MYSBootloader is easy, but it is also easy for an attacker to knock out security by remotely replacing the node firmwares.@Anticimex said:
A thing to remember is that while MYSBootloader does not require an external flash to intermediately store the new firmware, this means it cannot support authenticating new firmwares as well (at least not currently from what I gather).
DualOptiboot on the other hand can support this since the checksumming of the updated firmware can be signed and verified before rebooting (and overwriting the existing firmware from external flash).
If signing is enabled and required and the checksum is not properly signed, it will be rejected and the bootloader won't be "informed" to do the update. This is at least in theory. I have not yet had the time to look into OTA security. But from the little I have learned, I would recommend DualOptiboot for the paranoid for this reason. Using MYSBootloader is easy, but it is also easy for an attacker to knock out security by remotely replacing the node firmwares.That's correct for the 1.1 release.
However, 1.5 (various improvements) and 2.0 (signing) are under development. Stay tuned :) -
@Anticimex said:
A thing to remember is that while MYSBootloader does not require an external flash to intermediately store the new firmware, this means it cannot support authenticating new firmwares as well (at least not currently from what I gather).
DualOptiboot on the other hand can support this since the checksumming of the updated firmware can be signed and verified before rebooting (and overwriting the existing firmware from external flash).
If signing is enabled and required and the checksum is not properly signed, it will be rejected and the bootloader won't be "informed" to do the update. This is at least in theory. I have not yet had the time to look into OTA security. But from the little I have learned, I would recommend DualOptiboot for the paranoid for this reason. Using MYSBootloader is easy, but it is also easy for an attacker to knock out security by remotely replacing the node firmwares.That's correct for the 1.1 release.
However, 1.5 (various improvements) and 2.0 (signing) are under development. Stay tuned :) -
@Anticimex I'm testing different scenarios, one using a signed checksum to initiate the OTA - this would be compatible with the current framework. The challenges are obviously size limitations and the lack of a RNG...
-
@Anticimex I'm testing different scenarios, one using a signed checksum to initiate the OTA - this would be compatible with the current framework. The challenges are obviously size limitations and the lack of a RNG...
-
@Anticimex I'm testing different scenarios, one using a signed checksum to initiate the OTA - this would be compatible with the current framework. The challenges are obviously size limitations and the lack of a RNG...
@tekka a signed initiation I believe would come for free unless the initiation message is explicitly ignored when deciding to sign a message in the library. It is if/when the bootloader has to do signing or verification things get tricky. A signed initiation could be hacked though. An attacker could detect am initiated OTA transfer (target reboots in bootloader/OTA mode) and then (if the bootloader is unable to process signed messages) anyone could feed anything to it. If the bootloader could verify messages though, there would be no issue of course. The payload could be sent unsigned (for efficiency) and last a checksum is sent signed (which is validated both for signature and checksum on received payload) before bootloader marks flashed software as valid.
Do you feel secure today? No? Start requiring some signatures and feel better tomorrow ;)
