enabling a partition in front of partition table (IDFGH-11338)

[kohait00]

In real world project one finds himself with the need to place partitions before the partition table..
Reasons for that could be:

• Enlarged Bootloader demands for moving the partition table anyway, a good fix adress is probably far away from 0,
• 0x10000 (64k) as offset for the partition table for the lifetime of the application is probably a good idea..
• according to https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/bootloader.html
  for Secure Boot V2 capailities (if desired to be used later), the max size for the bootloader is 0xC000 anyway
• this leaves significant space, that cant be used due to various checks in the code base and the idf py domain, preventing any partition being declared north of the partition table..
• the remaining hole of 0x4000 bye (16k) is just enough for the bare minimum nvs, which, should the bootloader indeed need to grow for some reason, can move back south of the partition table.
• the provided changes enable a real world partition table like this one..

bootloader, 0xB0, 0x0B, 0x01000, 0xc000,
nvs, data, nvs, 0x0d000, 0x3000,
#part_table, data, 0xEE, 0x10000, 0x1000,
phy_init, data, phy, 0x11000, 0x1000,
otadata, data, ota, 0x12000, 0x2000,

emul_efuse, data, efuse, 0x14000, 0x2000,
nvs_keys, data, nvs_keys, 0x16000, 0x1000,
nvs_sys, data, nvs, 0x17000, 0x9000,

ota_0, app, ota_0, 0x20000, 0x140000,
ota_1, app, ota_1, 0x160000, 0x140000,
usr, data, nvs, 0x2a0000, 0x20000,
www, data, spiffs, 0x2c0000, 0x140000,

rfc

[github-actions]

	Messages
📖	Good Job! All checks are passing!

---

👋 Welcome kohait00, thank you for your first contribution to espressif/esp-idf project!

📘 Please check Contributions Guide for the contribution checklist, information regarding code and documentation style, testing and other topics.

🖊️ Please also make sure you have read and signed the Contributor License Agreement for espressif/esp-idf project.

Pull request review and merge process you can expect

Espressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.

1. An internal issue has been created for the PR, we assign it to the relevant engineer
2. They review the PR and either approve it or ask you for changes or clarifications
3. Once the Github PR is approved, we synchronize it into our internal git repository
4. In the internal git repository we do the final review, collect approvals from core owners and make sure all the automated tests are passing
   • At this point we may do some adjustments to the proposed change, or extend it by adding tests or documentation.
5. If the change is approved and passes the tests it is merged into the master branch
6. On next sync from the internal git repository merged change will appear in this public Github repository

---

Generated by 🚫 dangerJS against d2a34e9

[kohait00]

I also got a change to the python code to be able to have entries for bootloader and partition table..
AFAI am concerned, this would prepare the possibility to in field update the bootloader and partition table (albeit very dangerously)
is this a thing?

[adokitkat]

Hi @kohait00, thank you very much for the contribution.

Unfortunately we would like to ask you if you could keep this just as your local patch, since this is something we do not recommend doing (it is theoretically possible to have a minimal NVS there but our recommended size is 0x6000).

[kohait00]

Hi @kohait00, thank you very much for the contribution.

Unfortunately we would like to ask you if you could keep this just as your local patch, since this is something we do not recommend doing (it is theoretically possible to have a minimal NVS there but our recommended size is 0x6000).

No problem. Just wanted to share in case it is of interest..
It is fun to poke around in the code :)