Can partitions table be replaced by application?

[jsam589]

I would like to have the flexibility to change my partition definitions as part of an OTA update.
I haven't seen this discussed, but might the following work?

1. A deployed device has partition table "version 1" and the corresponding partitions are in place.
2. OTA new firmware is then programmed and begins to run.
3. This new firmware expects partition table "version 2" and, seeing that the partition table does not match, it updates the partition table at 0x8000 (erase, then program flash).

What would the implications and risks be of doing this? I guess the actual partitions in SPI flash might need to be updated now to match the new table. What else?

Thanks.

[WiFive]

Risk is a failed update could brick the device unless you have some way of recovering from that.

viewtopic.php?t=11482

[ESP_Angus]

Hi jsam589,

WiFive is right. ESP-IDF doesn't support OTA updating of the partition table because a power failure or crash during the update could brick the device.

If you're confident this won't happen then you can disable the config flag that the prevents SPI flash APIs from erasing or writing "sensitive" areas, then erase and rewrite the contents of the partition table. But you should be aware of the risks.

Why exactly do you want to change the partition table in an existing device? We might be able to suggest some other way to achieve the same result.

Angus

[jsam589]

>> Why exactly do you want to change the partition table in an existing device? We might be able to suggest some other way to achieve the same result.

Please bear with the answer below. I will explain what I have found in some existing code (not yet released anywhere) and then what I might want to do with it differently.

1. EXISTING CODE, STILL IN PRERELEASE STATE:

The project I am working on was started by another developer. It is still some way from being released and I am refactoring a lot of it. I found in the original developer's code something that reprograms the partition table under certain conditions. I was trying to understand it and see if he had taken this from one of the example apps provided in the IDF. But the more I looked and read the online ESP documentation, it seemed like no one else was doing this.

This code actually embeds the binary version of the partition table into the application using this line in a component.mk file:
COMPONENT_EMBED_TXTFILES := ../../build/partitions.bin

He then uses this in a source file and compares partition table in flash against this embedded table, via:
extern const uint8_t partitions_bin_start[] asm("_binary_partitions_bin_start");
extern const uint8_t partitions_bin_end[] asm("_binary_partitions_bin_end");

The purpose for this seems to be to correct a missing, corrupt or changed partition table. I notice that he also did modify two IDF files to bypass the safety checks. He actually named the functions "unsafe", so he understood this was bypassing standard behavior.

The files modified are:
components/spi_flash/flash_ops.c
components/spi_flash/include/esp_spi_flash.h

2. GOING FORWARD:

The only reason I can think of at this time, based on my own experience creating embedded systems, for rewriting the partitions table in the field would be because a new firmware release has some new functionality and wants additional partitions. I have modified the original developer's partitions table and currently have it as shown below. But as you can see, I don't need the full 16 MByte today. But in the future, could the unused area be activated as additional partitions? And if so, how would the partitions table be updated to match? If this is not possible, then I have to get my partitions table exactly right for all times when a product ships. And then if we change it at some point for future production, the firmware will need to be backward-compatible with the earlier tables that might be found in the field. I don't mind doing it this way, but it would allow a little more flexibility if the table could be updated on the unit.

So, what do you think about at least being able to append new partitions to the end of the used space?

"Version 1" partitions table:
# Name, Type, SubType, Offset, Size, Flags
nvs, data, nvs, 0x9000, 16K,
otadata, data, ota, 0xd000, 8K,
phy_init, data, phy, 0xf000, 4K,
factory, app, factory, 0x10000, 2M,
ota_0, app, ota_0, 0x210000, 2M,
ota_1, app, ota_1, 0x410000, 2M,
log_0, data, spiffs, 0x610000, 1516K,
log_1, data, spiffs, 0x78B000, 1556K,
dump, data, coredump, 0x910000, 512K,
cert, 0x45, , 0x990000, 8K,
key, 0x45, , 0x992000, 4K,
storage, 0x44, , 0x993000, 2M,
# 0xB93000 - 0xFFFFFF (4532K): Remainder of 16 MByte is reserved for future use