[WIP] Add ota_update module (second attempt)#7398
Closed
kYc0o wants to merge 14 commits intoRIOT-OS:masterfrom
Closed
[WIP] Add ota_update module (second attempt)#7398kYc0o wants to merge 14 commits intoRIOT-OS:masterfrom
kYc0o wants to merge 14 commits intoRIOT-OS:masterfrom
Conversation
kYc0o
added
Type: new feature
Contributor
Author
|
@emmanuelsearch You can try the instructions from #7396 in this branch. I tested it in samr21-xpro successfully, by updating incrementally on both slots. |
kYc0o
changed the title
Member
|
when I |
Member
Contributor
Author
Sorry, a leftover from a previous rebase. Should be good now |
Contributor
Author
|
I found another bug which I fixed. Should be working now in OS X and Vagrant. |
Contributor
Author
Yes it depends on that PR. I did it that way to ease the review process, so I wouldn't like to close it. |
Member
|
@kYc0o thanks for the update. |
Contributor
Author
|
Oh yes, for the vagrant image bc needs to be installed |
Member
Wouldn't it be better to update the vagrant bootstrap script instead? |
Member
|
installed bc. Now I get: |
Contributor
Author
|
Hmm that starts to be strange... can you try again with |
Contributor
Author
That would only work for new downloads of the vagrant image or? |
Contributor
Author
|
Added support for iotlab-m3 board. |
kYc0o
added
the
CI: ready for build
kYc0o
force-pushed
the
ota_updates
branch
5 times, most recently
from
affff4f to
2ce0d0e
Compare
aabadie
requested changes
Aug 18, 2017
| uint32_t appid_slot1 = 0, appid_slot2 = 0; | ||
| firmware_metadata_t metadata; | ||
|
|
||
| puts("[bootlaoder] Checking for slots metadata..."); |
| memcpy(&metadata, firmware_get_metadata(1), sizeof(firmware_metadata_t)); | ||
| if (firmware_validate_metadata_checksum(&metadata) != -1) { | ||
| appid_slot1 = metadata.appid; | ||
| printf("[bootlaoder] Found slot 1 with APPID: 0x%lx \n", appid_slot1); |
| memcpy(&metadata, firmware_get_metadata(2), sizeof(firmware_metadata_t)); | ||
| if (firmware_validate_metadata_checksum(&metadata) != -1) { | ||
| appid_slot2 = metadata.appid; | ||
| printf("[bootlaoder] Found slot 2 with APPID: 0x%lx \n", appid_slot2); |
| static int validate_and_boot(uint8_t slot) | ||
| { | ||
| if (firmware_validate_int_slot(slot) != -1) { | ||
| printf("[bootlaoder] slot %d validated! Booting...\n", slot); |
| puts("[bootloader] Booting failed!"); | ||
| } | ||
| else { | ||
| puts("[bootlaoder] Slot 1 inconsistent, no image to boot..."); |
| */ | ||
|
|
||
| /** | ||
| * @file |
| * | ||
| * @return 0 on success or error code | ||
| */ | ||
| uint32_t fw_slots_get_slot_address(uint8_t slot); |
Contributor
There was a problem hiding this comment.
should be renamed to firmware_slots_... for consistency
| int firmware_sign_metadata(firmware_metadata_t *metadata, unsigned char *sk); | ||
|
|
||
| /** | ||
| * @brief Validate FW metadata signature |
Contributor
There was a problem hiding this comment.
FW => firmware
and in other places above
| uint8_t sig[FIRMWARE_SIG_LEN]; /**< Firmware signature */ | ||
| uint8_t pad[FIRMWARE_PADDING]; /**< padding to total of FIRMWARE_METADATA_SIZE bytes */ | ||
| } firmware_metadata_t; | ||
| /** @} */ |
Contributor
There was a problem hiding this comment.
no need for this @{..@} block in doxygen
| */ | ||
|
|
||
| /** | ||
| * @ingroup sys_firmware |
Contributor
There was a problem hiding this comment.
Should be @defgoup sys_firmware and add @ingroup sys
rfuentess
reviewed
Sep 1, 2017
| #include "checksum/fletcher32.h" | ||
| #include "tweetnacl.h" | ||
|
|
||
| void firmware_metadata_print(firmware_metadata_t *metadata) |
Contributor
There was a problem hiding this comment.
If this is only for debugging, I think this modification could improve a little the readability of the messages :
void firmware_metadata_print(firmware_metadata_t *metadata, uint8_t slot_id)
Or moving the line 45 (metadata->start_addr) at the beginning of this function.
rfuentess
reviewed
Sep 1, 2017
| result = firmware_validate_metadata_signature(&metadata, ed25519_pub); | ||
|
|
||
| if (result == -1) { | ||
| printf("[firmware] Signature check failed!\n"); |
Contributor
There was a problem hiding this comment.
I suggest to modify to
printf("[firmware] Signature check failed! (slot %u)\n",slot );This can help to identify the wrong slot if the node already rebooted.
Contributor
|
Nice work! I have been able to testing this code for iotlab-m3 nodes, and also iotlab-a8-m3 nodes running in the FIT IoT-Lab (although, I need to run manually openocd for the latest). |
|
Hi
No fw found seem to be logical I ve only flashed the bootloader.
Slot1 & 2 are invalid. Regards, |
Contributor
Author
|
Hi @LalunePierr0t ! Thanks for testing this PR. I must say that recently I was working in a more robust solution for OTA, thus this PR got a bit outdated. Please test this other branch (you can just fetch it from my repo). It will be PRed soon anyways. Regarding this branch, apparently your images are being flashed in a wrong place, I suggest you delete the directory RIOT/bootloader/bin, if any, and launch the command Hope this works and don't hesitate to publish here your results. Thanks again! |
Contributor
Additionally @LalunePierr0t , If you want to be extra paranoid, you can run the following between testings: The only problem is that you need to save the tweetncl keys, otherwise a new couple of keys will be generated between each testing.
I already tested that branch and is working nicely. However, I think is relevant to mention that some variables had their names changed: Also, one of the new make rules has a new syntax: |
|
Hi @kYc0o , I can build and flash
Req :
Definitions :
Regards, |
Contributor
Author
Currently the build system (or rather the way I manage the dependencies) doesn't detect when there's a change in the bootloader code, thus is not rebuilt. You need to clean the bootloader to take into account the modifications. The bootloader is systematically flashed (actually appended to the application binary). Currently the development is in an early stage, we provide a bootloader which can explore the internal ROM for valid images for a maximum of two slots (the current one and the update), check for a valid and consistent header (metadata) and then boot the newest version. On the other hand, the OTA update module fetches information about the upstream images, downloads the newest if present and then flashes it into the available slot (can be 1 or 2 depending on where are you running the application), verifies the cryptographic signature and if valid writes the metadata to the beginning of the slot, then reboots. All of this is done from the current running image, thus flashing and verification capabilities are not embedded in the bootloader. Next steps:
Thanks again for looking at this! |
Contributor
Author
|
I think this PR got unrelated to the ongoing OTA work. Thus, will close. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR is based on #7396 which is also based on @kaspar030 work.
It basically adds the capability of retrieving updates from a TFTP server.
To do so, you need to setup an ota-server following the steps in this repo.
Then you can run the server with the following parameters:
./ota-server --static-path=../otaserver/static --upload-path=../otaserver/static/uploadsThis ensures the server looks for the firmware binaries in the right directory.
The ota-server application will start at CoAP server listening on the default port 5683, which will answer the requests from this ota_update module. As in #7167, the module requests periodically the latest version from the server, and if it finds a newer one it starts to download it using TFTP.
For the TFTP server, you need to install the tftpd-hpa server (
sudo apt-get install tftpd-hpaon ubuntu). Afterwards, to manually setup the server folder, you need first to stop the daemon:$ sudo /etc/init.d/tftpd-hpa stopThen, start the server on the uploads folder:
$ sudo in.tftpd -vvv -L -6 -c -s -u ${USER} otaserver/static/uploads/This will start to listen for TFTP request from this OTA module.