@Esp_alisitsyn,
Do you have a plan to push your MR to github? This bug remains in v4.3-beta

The reason for my initial fail must have been a failed write in step 2. Secure boot key is known and burnt in BLK2 resulting in an unknown key.

When taking an encrypted device and reflashing everything nvs partitions must be re-initialized: All encrypted nvs partitions needs to be initialized so that they read 0xff after decryption. This is done by creating a file with all 0xff of the proper length, encode it using the key and address and t...

The above process works, at least when flashed on an un-encrypted device, letting it self-encrypt, and doing sub-sequent writes with encrypted files to the bootloader, partition table, ota and app.

Thats a great step-by-step! Could you please also add what your launch.jso looks like? I think I've messed mine up.

I'm having a commercial product out based on ESP32 where I have secure flash and OTA updates enabled. As volumes now grows I would like to enable the secure boot for a new generation based on idf 4.2. I would like to be able to be able regularly reflash my internal boards but keep them as close to t...

@ESP_alisitsyn, I think I've found an issue with the the code. I have a multi-region setup where I also have a mix of 16 and 32 bit registers. This means that one memory region can be followed by another without an "empty" address in between but with different read/write sizes. The current check to ...

Looks good, and I can have multiple areas defined. Would be great to have each area defined with a memory pointer to one "read area" and one "write area" in the call. And using them accordingly in the read and write functions. Then you can avoid overwriting results if not wanted. Setting the memory ...

I'm definitely interested to help out verifying your code

I had to extend the current implementation of mbc_serial_slave.c and mbc_tcp_slave.c by using a linked list of memory areas. It's a hack for now.