Add the esp-idf bootloader support crate

[bjoernQ]

Thank you for your contribution!

We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:

Submission Checklist 📝

• I have updated existing examples or added new ones (if applicable).
• I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
• My changes were added to the CHANGELOG.md in the proper section.
• I have added necessary changes to user code to the Migration Guide.
• My changes are in accordance to the esp-rs developer guidelines

Extra:

• I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖

Description

This adds the initial esp-bootloader-support-esp-idf - only supports the app-descriptor for now

See #3124 (review)

Next steps would be

• provide read access for the partition table
• provide an embedded-storage "view" of the partitions (see [esp-storage]: Add partitions support and allowed memory ranges #3259 (comment))
• provide a way to interact (read + modify) with the OTA partition

When we add MCUboot support we will have a similar crate for that

skip-changelog because of the change to the linker script

Testing

As said for now this offers limited functionality. To easily test that

• add a dependency in examples
• add esp_bootloader_support_esp_idf::esp_app_desc!(); to one of the examples
• run the example
• build a recent esp-idf bootloader (e.g. from 5.4)
• use espflash to flash the example with the bootloader built above
• hopefully see it boots fine

[bjoernQ]

to make sure the linker won't discard it when nothing else is referencing it

[Dominaezzz]

Should this be false?

I suppose you could just move the bytes.len() < C into the assert. 😄

[bjoernQ]

actually it's useless - the compiler will understand the overflow even before we can assert anything - so I removed this

(I admit, initially I pretty much just copied this code from somewhere)

[bugadani]

Just a wild idea that popped up, could we/should we store the partition table as metadata for this crate (even if optionally, through a feature/config)? It's technically not part of the application itself, but it's I think also rare to have a single application work with multiple partition tables.

[bjoernQ]

Just a wild idea that popped up, could we/should we store the partition table as metadata for this crate (even if optionally, through a feature/config)? It's technically not part of the application itself, but it's I think also rare to have a single application work with multiple partition tables.

You mean in .espressif.metadata? If there is any place where we want to do that, then it's this crate 😄

Not entirely sure what the use-case would be? espflash reading and using it? I see how this makes it easier to pass an ELF to someone to flash it but on the other hand should we remove the parition-table argument from espflash? If not how to resolve conflicting information

Maybe I just don't see the obvious 😆

But this sparked a different idea: Later I will add things like OTA and NVS support (which probably need to be features since they will change the available APIs) and we could encode that in the metadata to signal to the flashing tool (i.e. espflash) that an OTA / NVS partition is needed and refuse to flash if not 🤔