Can "test" partition be used instead of "factory" in production?

[jhnlmn]

Hi,
Typical 3 partition scheme includes factory, ota_1 and ota_2 partitions.
Then bootloader can be configured with CONFIG_BOOTLOADER_FACTORY_RESET option to erase OTA partitions if some button is pressed during reboot.
But this is too drastic - I do not want user to erase all OTA partitions by accidentally pressing a button during power cycle. I want a button press during boot to simply load FW from factory partition, which will then give user a choice whether to boot existing OTA image or install a new one - this is how many modern devices work, including smartphones.
I see that bootloader has similar option CONFIG_BOOTLOADER_APP_TEST, which loads FW from "test" partition, but "test" is not the same as "factory", is it?
I tried to replace "factory" by "test", essentially, I replaced
factory, app, factory, 0x010000, 0x120000,
ota_0, app, ota_0, 0x130000, 0x150000,
ota_1, app, ota_1, 0x280000, 0x150000,
by
test, app, test, 0x010000, 0x120000,
ota_0, app, ota_0, 0x130000, 0x150000,
ota_1, app, ota_1, 0x280000, 0x150000,
in partitions.csv. This appears to work: it boots into ota_x normally and to "test" if button is pressed.

Are there any drawbacks to this approach of using "test" instead of "factory"? In particlar from secure boot point of view?
What are the differences between "test" and "factory"?

Thank you

[phatpaul]

I was just asking myself a very similar question and found this post. It's a shame so many questions go unanswered for years on this forum. What did you end up doing?

Yes, the default behavior seems drastic and doesn't align with many devices on the market. The difference is this is a FACTORY_RESET feature, which immediately makes a change to nonvolatile memory. Many other devices instead have a "one-time load emergency bootloader" feature which does not make any nonvolatile changes (unless the user takes further action). I can see how each has a use-case.

BTW, I think your description is incorrect in one minor aspect. The FACTORY_RESET process does not (necessarily) erase the OTA app partitions. It only erases the ota_data partition. That ota_data is basically just a pointer that indicates which OTA app should boot. The app firmware in the OTA slots are typically untouched by the FACTORY_RESET process, but the bootloader doesn't jump there because the ota_data is erased. The factory app could change the boot order back to one of those OTA apps.

We have been using the 3 partition scheme for many years with a 16MB flash (ESP32-WROVER-N16R8), so factory, ota_1, and ota_2 each were 4MB. That gave plenty of room for future upgrades.
But we are in process of migrating to a module with less flash (8M on ESP32-PICO-MINI-02) which is still a lot, but not when you divide it up for 3 redundant app partitions (and a filesystem partition). Our firmware binary is currently about 1.8MB, so a 2MB OTA slot feels tight for the indefinite future of support.

My initial thought was to shrink our factory app partition as small as I can (~0.5MB), and put just a bare minimum firmware in it at our factory. That tiny factory firmware could only do an OTA upgrade, so we could call it a OTA-bootloader of sorts. It doesn't do any of our normal product stuff, except prompt the user to upgrade.

But this has potential issues:
1. If the user accidentally does a factory restore, the product will be inoperable until the user does the OTA process (our OTA process is not fully automatic). This is because the tiny factory app can't do the normal functions of our product.
2. Our development workflow expects to be able to write our entire app to the factory partition. If the factory app parition is tiny, then our main firmware will not fit and we can't do our normal `idf build flash monitor` for development. I'm sure the tooling can be adapted, but I rather not stray from the norm.

So, I was exploring using the BOOTLOADER_APP_TEST feature that you mentioned. In that case my tiny OTA-bootloader would be in a small partition high in the flash memory so it is not impacted by our development workflow. `idf build flash monitor` would actually write to the first of the 2 OTA app partitions at 0x10000 which can be made to be 3MB each since there is now no "factory app" partition.
Another benefit is that if the user accidentally triggers the FACTORY_RESET procedure, it is not permanent and a power cycle would restore the previous app running.

Any experience or thoughts are appreciated!

[phatpaul]

I did end up going with a partition of type "TEST" for a small recovery firmware. It is working quite well.

BTW, I just stumbled upon this component which allows for compressed OTA updates. It would have been very useful to know about it before:
https://components.espressif.com/compon ... pport_plus