Fix ESP ROM header path for IDF >= 5.4

[5p4k]

Description

Starting from IDF 5.4 ROM includes should not use the target prefix in the include folder, see
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/migration-guides/release-5.x/5.4/system.html#esp-rom

I also removed commented out rom includes.

This should fix #8266.

Testing

I tested a build on ESP-IDF 5.4 using the managed version of wolfssl, from here: https://components.espressif.com/components/wolfssl/wolfssl/versions/5.7.4-preview1f
where I manually patched esp32-crypt.h with the one in this PR.

It seems that the repo cannot be used directly as an ESP-IDF component, and I could
not find the process to actually build the IDF component as it is released on the registry,
hence the testing is a bit unorthodox. However, I'd be willing to run more tests if someone
can point me to what would be a nominal way to test an ESP build of wolfSSL.

Checklist

This is a fix for an updated version of an external tool, it didn't seem like any of these
needed updating (but let me know if I missed something):

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[wolfSSL-Bot]

Can one of the admins verify this patch?

[gojimmypi]

Hi @5p4k

I saw your comment over at the open issue, thank you for submitting this PR!

I've been doing some testing this morning and all seems well.

In reviewing the code, it looks like the ESP32 flavor of the aes.h ROM file has been included for all chip types. This probably only works for wolfSSL since the only things used from that file are the ets_aes_enable and ets_aes_disable functions that coincidentally are the same for all chip types. Still, it is probably a good idea to have chip-specific includes.

Any chance you could add (and squash) this to your PR? I realize it is a tad beyond your fix. Otherwise I'll add this to a backlog of things to fix in my next update.

Thank you again for your contribution!

[5p4k]

Hi @gojimmypi ! I added a commit, is that what you meant? I used the same pattern as for sha.h further down.
Let me know if it's ok and I'll squash the two commits for merge.

[gojimmypi]

Hi @5p4k - yes, that's what I had in mind.

I have a few other changes that I'll be applying soon; it might be best to wrap your suggested changes into that.

There's a somewhat involved manual process of getting a new wolfSSL contributor approved (sorry, my bad, I didn't notice you had not done that). So unless you plan more contributions - it will be much easier for me to just add these changes to my upcoming PR. I'll reference this PR and credit you for the idea.

Thank you again for the suggestion and the specific code fix recommendation.

[5p4k]

I don't plan more contributions, it's fine if you apply the changes. I'll leave the PR to you then, feel free to close when appropriate.

You're welcome! If you can get a 5.7.4-preview1g released on the ESP component registry at some point in the future, it would be great :)

[gojimmypi]

it's fine if you apply the changes. I'll leave the PR to you

Awesome. thanks again, I'll try to get this wrapped up soon.

can get a 5.7.4-preview1g released on the ESP component registry

ya, I had quite a stumble testing on the staging site as noted in espressif/idf-component-manager#78 (comment)

[gojimmypi]

Hi @5p4k I've put together #8402 that improves the make & cmake for the Espressif devices.

cc: @AchimPieters re: #8266

[5p4k]

Thank you very much @gojimmypi !

[dgarske]

Thank you @5p4k. Closing this PR in favor of PR #8402.