app_update: Add esp_ota_write_raw function to write pre-encrypted data (IDFGH-5583)

[AxelLin]

Use esp_ota_write_raw instead esp_ota_write to write pre-encrypted data.

Signed-off-by: Axel Lin [email protected]

[AxelLin]

Hi @mahavirj
I understand you comments in #6172 (comment).
Before introducing new "pre-encrypted" OTA image format, this function allows
existing users to implement updating pre-encrypted ota data.(#6172 (comment))
Please review if this PR is acceptable.

[mahavirj]

@AxelLin I am not quite clear on this change. So you think that application needs to take care about correct "pre-encrypted" image per flash offset of passive OTA update slot?

[AxelLin]

Hi @mahavirj
Yes, for the use case for some customers using device in closed netowrk.
I have no choice but to implement supporting "pre-encrypted" image by taking
care the correct logic in our application side.
Actually when we do OTA in an independent partition (e.g. test partition), we
can always update image to ota1 partition and set boot from ota1. (so no choose image issue).

[mahavirj]

@AxelLin Thanks for explaining. It will be difficult to accept this PR, unless we add lot of explanation in documentation (and probably application as well) to clarify usage scenario here. I would request that we wait for official approach as I had highlighted in #6172 (comment). Of course, if someone find this change useful they can always refer to PR here.

[AxelLin]

And honestly, such requirement (ota with pre-encrypted image) has been asked so many times.
Waiting for a new "pre-encrypted" OTA image format could take too much time.
(It maybe not available this year)

If this PR is not acceptable, I have no choice but to maintain my on fork of esp-idf.
Thanks for your time anyway.

[AxelLin]

@AxelLin Thanks for explaining. It will be difficult to accept this PR, unless we add lot of explanation in documentation (and probably application as well) to clarify usage scenario here. I would request that we wait for official approach as I had highlighted in #6172 (comment). Of course, if someone find this change useful they can always refer to PR here.

On the second thought, by calling esp_ota_get_next_update_partition() the
firmware can easily know which encrypted ota image to download.

The only thing needs to comment or document is the feteched encrypted ota image needs
to be generated for the target partition address.

BTW, this is probably off-topic.
But I had bad experience about waitting new features ready.
e.g. regarding 802.11r support:
21 Jun 2019: we may prioritise 11r though. #3671 (comment)
18 Dec 2020: 11r support will be added in future. #3671 (comment)
25 Jan 2021: We are targeting 2nd quarter of 2021. #3671 (comment)
Now, 11r is still not yet available. (It's more than 2 years since initial reply)

[sagb2015]

@AxelLin - We have to keep changing priorities of the deliverables based on constantly changing demands/requirements. For example, #3671 (comment) says that 11r will be prioritised over 11k, 11v, however, we had to make 11k and 11v ready before 11r for other prerequisites. Our intention of providing the tentative timeline is to give visibility to everyone based on the current inputs. This may or may not translate into hard deadlines for us. Hope you understand!

[AxelLin]

@AxelLin - Our intention of providing the tentative timeline is to give visibility to everyone based on the current inputs. This may or may not translate into hard deadlines for us. Hope you understand!

Take a look at #3671
What make me feel uncomfortable is the fact you don't response to my questions at all.