CONFIG_PARTITION_TABLE_MD5=y is bricking devices

[william.ferguson.au]

Wait. Setting

Code: Select all

CONFIG_ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS=yCONFIG_ESP32_COMPATIBLE_PRE_V3_1_BOOTLOADERS=y

auto changed

Code: Select all

# CONFIG_PARTITION_TABLE_MD5 is not set

Ie unset the MD5 generation on the partition table

So when I build my partition table has no MD5.

Wasn't the whole point of this to roll forward so that we can generate partition_tables with MD5, check MD5 with current bootloader but allow the app to handle a partition table without an MD5 (so that OTA for 3.3 and earlier work)?

If I start generating and deploying a partition table with no MD5 then this problem is just kicked into the future and resolution has become harder.

[ESP_igrr]

I think this depends on whether you are building an application which will be sent over-the-air to the already deployed devices in the field or building an application for flashing newly produced devices.
For the devices in the field which don't have an MD5 in the partition table, the app should be built with the matching setting.
For new devices, you can enable MD5 in the partition table and keep this option enabled when building the OTA binaries.
(For an example of building multiple configurations of the same app, please take a look at examples/build_system/cmake/multi_config)

[william.ferguson.au]

Just like every other project, we will be be building the application to be sent OTA as well as flashed onto new devices.

We could build multiple configurations of the same app, one for OTA, one for new devices, but what would be the point?
The new devices would eventually received the OTAs, so they gain no benefit.

Surely the sensible approach is for

[ESP_igrr]

I think you can split the devices into two groups: one with old bootloaders, another with the new bootloaders. The OTA binaries would be built in two configurations, with MD5 check disabled for the old bootloader devices and enabled for the new bootloader devices. This way, the devices which have MD5 appended to the partition table will be actually verifying it; while the devices which don't won't be expecting the MD5.
In the approach you have suggested (separate options for generating and verifying MD5) you will end up with all devices not verifying MD5, which will probably not the best outcome.

[william.ferguson.au]

I don't think you are thinking this through. Or maybe I' not.

Suppose I have have 2 build configs.

• ConfigA no MD5 in partition tables and not requiring it in boot loader and app
• ConfigB generating MD5 in partition tables and requiring it in boot loader and app

They will each generate

• partition table
• boot loader
• app

I can deploy partitionTableB, bootLoaderB and appB to all new devices, which will check the partition table for an MD5 in the boot loader and app. This is great for the first version of an app deployed to any new devices.

But for the OTA update,

• if I send appB then all old devices (IDFv3.3 partition table & boot loader) will crash when it tries to open a partition (eg SPIFFS) because there is no MD5 on partition table. Hence we can't send appB as an OTA.
• So I can only send appA, which ignores whether the partition table has an MD5, which means that all devices will eventually have an app that ignores the partition table MD5.

[ESP_igrr]

Sorry i wasn't clear! I meant that the old devices should receive appA as an update binary, and the new devices should receive appB.

[william.ferguson.au]

Sure, that's an option.

But it means that we now also need to have a switch in the app to determine which OTA to download an apply (on top of maintaining the 2 configs). What happens when we get the next change that requires splitting OTAs. This gets unmanageable quickly. If you've been doing Android development over the last 13 years, you'll know what I mean.

Surely generating a single OTA that applies the new functionality when it can, and WARNs when it can't is preferable?