Support for Espressif ESP-IDF v5

[AchimPieters]

Contact Details

info@studiopieters.nl

Version

5.5.3

Description

Got the message: Please report this bug, all information can be found here: https://github.com/AchimPieters/esp32-homekit-demo.git

/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S: Assembler messages:
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:104: Error: unknown opcode or format name 'pushl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:105: Error: unknown opcode or format name 'pushl'
.....

.....
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Error: bad register name: (%esp
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Error: junk at end of line, first unrecognized character is `('
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Internal error in demand_empty_rest_of_line at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/binutils/gas/read.c:3788.
Please report this bug.

Reproduction steps

1. Install docker
2. Install IDF V5.0 - docker pull espressif/idf:v5.0
3. Clone repository - git clone --recursive https://github.com/AchimPieters/esp32-homekit-demo.git
4. start IDF - docker run -it -v ~/ESP32-HOMEKIT-DEMO:/project -w /project espressif/idf:v5.0
5. cd examples - cd led
6. idf.py build

Relevant log output

No response

[embhorn]

Hello @AchimPieters

Thanks for sharing this issue. I have requested a review by the team.

Kind regards,
@embhorn - wolfSSL Support

[gojimmypi]

Hi @AchimPieters and thank you for your interest in using wolfSSL on the Espressif ESP32.

I've tried your steps to reproduce this error and confirmed there's a problem. Thank you for reporting this.

I noticed from the error message that you are trying to use ESP-IDF v5.0. At this time the wolfSSL Espressif examples are only for ESP-IDF v4.x. We have an open PR #5902 that may fix some of the breaking changes of the recent Espressif upgrade to v5. Do you have the option to use ESP-IDF 4.x?

More work is needed to have full support for wolfSSL on the Espressif ESP-IDF v5. I've renamed this issue to reflect that objective.

There's also a reference in the error message regarding x86 assembly. This is typically used for code performance optimization, but is not available on the Espressif Xtensa architecture at this time. The x86 asm should be disabled automatically when using #define WOLFSSL_ESPIDF. There are several key ESP32 settings missing from your user_settings.h; see the example user_settings.h

It looks like you may have cloned (a rather old) wolfSSL into your project components/common/wolfssl/ as a submodule? Having just a repo clone work as an Espressif component is definitely something I'd like to have supported, but I don't yet quite have that finished. For now the best way to use wolfSSL is to use the setup.sh as described in the README and install a more recent version of wolfSSL to either the ESP-IDF or your local project ./components/ directory. Not both.

Let me know if these suggestions are helpful and what else we can do to help you get wolfSSL working in your project.

[AchimPieters]

@gojimmypi thank you for your reply! Tried to use ESP-IDF 4.x, unfortunately this gives a whole new scale of problems. Looking into the future, and the development of Home and Matter, the IDF 5 and up will become mainstream. Hope that you will support it soon.

Al your provided information is really helpful, thank you for that!

[gojimmypi]

@AchimPieters let's see what we can do with the ESP-IDF v5 using a wolfSSL component install via the script and a known-good user_settings.h file mentioned above.

Please give that a try and we'll address any incompatibilities that may be encountered.

[AchimPieters]

@gojimmypi that would really be appreciated! I updated my repository with all your instructions and got this result:

/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S: Assembler messages:

/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:104: Error: unknown opcode or format name 'pushl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:105: Error: unknown opcode or format name 'pushl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:106: Error: unknown opcode or format name 'pushl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:107: Error: unknown opcode or format name 'pushl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:108: Error: unknown opcode or format name 'subl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:109: Error: unknown opcode or format name 'movl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:110: Error: unknown opcode or format name 'movl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:111: Error: unknown opcode or format name 'movl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:112: Error: unknown opcode or format name 'pxor'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:113: Error: unknown opcode or format name 'pxor'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:114: Error: unknown opcode or format name 'cmpl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:115: Error: unknown opcode or format name 'jne'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:118: Error: unknown opcode or format name 'movl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:119: Error: unknown opcode or format name 'pinsrd'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:120: Error: unknown opcode or format name 'pinsrd'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:121: Error: unknown opcode or format name 'pinsrd'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:122: Error: unknown opcode or format name 'pinsrd'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:124: Error: unknown opcode or format name 'movdqa'
......

......
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1342: Error: unknown opcode or format name 'aesenc'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1343: Error: unknown opcode or format name 'aesenc'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1344: Error: unknown opcode or format name 'movdqa'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1346: Error: unknown opcode or format name 'aesenclast'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1347: Error: unknown opcode or format name 'subl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1348: Error: unknown opcode or format name 'xorl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1349: Error: unknown opcode or format name 'movdqu'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1351: Error: unknown opcode or format name 'movzbl'
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Error: bad register name: (%esp
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Error: junk at end of line, first unrecognized character is `('
/project/components/common/wolfssl/wolfssl-5.5.3/wolfcrypt/src/aes_gcm_x86_asm.S:1352: Internal error in demand_empty_rest_of_line at /builds/idf/crosstool-NG/.build/xtensa-esp32-elf/src/binutils/gas/read.c:3788.
Please report this bug.

The strange thing is that you said: The x86 asm should be disabled automatically when using #define WOLFSSL_ESPIDF. But it still gives this error.

Reproduction steps

Install docker
Install IDF V5.0 - docker pull espressif/idf:v5.0
Clone repository - git clone --recursive https://github.com/AchimPieters/esp32-homekit-demo.git
start IDF - docker run -it -v ~/ESP32-HOMEKIT-DEMO:/project -w /project espressif/idf:v5.0
cd examples - cd led
idf.py build

[gojimmypi]

It looks like your project is still trying to use wolfSSL in common/wolfssl/wolfssl-5.5.3 and it is not seeing the user_settings.h file. Can that wolfSSL directory be removed?

Upon install with the setup script, wolfSSL should end up in a directory called components/wolfssl which by default should be in the ESP-IDF directory. There should be no other instances of wolfSSL source code anywhere else in the build path.

Also, I noticed that you included the same reproduction text steps that actually didn't work for me as-is, but might be problematic. Your ~/ESP32-HOMEKIT-DEMO:/project there is all upper case. The clone goes to a lower case directory. Perhaps you have a non-empty upper case directory that inadvertently gets used?

[AchimPieters]

I changed the file structure as you recommended.

Reproduction steps

Install docker
Install IDF V5.0 - docker pull espressif/idf:v5.0
Clone repository - git clone --recursive https://github.com/AchimPieters/esp32-homekit-demo.git
start IDF - docker run -it -v ~/ESP32-HOMEKIT-DEMO:/project -w /project espressif/idf:v5.0
cd components - wolfssl-5.5.3 -ide -espressif - esp-idf - bash setup.sh
cd .. 5x
cd examples - cd led
idf.py menuconfig - component config - freertos- kernel and enable configENABLE_BACKWARD_COMPATIBILITY
idf.py build

[gojimmypi]

Hi @AchimPieters

I have an interim update for you. There's an open PR by @bandi13 that fixes some of the ESP-IDF v5 problems, but may need just a bit of fine tuning for the default ESP32 user_settings.h.

First: remove the existing wolfSSL:

Remove ~/esp32-homekit-demo/components/common/wolfssl (and ~/ESP32-HOMEKIT-DEMO if present)

(edit: I removed the above ! that I intended as "important" but could otherwise be interpreted as "not")

Fetch the @bandi13 ESP-IDF_fixes branch into bandi13-wolfssl-install

cd ~/esp32-homekit-demo
git clone https://github.com/bandi13/wolfssl.git bandi13-wolfssl-install --branch ESP-IDF_fixes --depth 1

docker run -it -v ~/esp32-homekit-demo:/project -w /project espressif/idf:v5.0

from within docker, run the wolfSSL setup:

cd /project/bandi13-wolfssl-install/IDE/Espressif/ESP-IDF
./setup.sh

cd /project/examples/led
idf.py build

This gets us close to compiling. I saw a bunch of warnings about things being redefined (ok to ignore for now):

<command-line>: note: this is the location of the previous definition
[95/145] Building C object esp-idf/wolfssl/CMa.../wolfcrypt/src/port/Espressif/esp32_util.c.objIn file included from /opt/esp/idf/components/wolfssl/wolfssl/wolfcrypt/settings.h:269,
                 from /opt/esp/idf/components/wolfssl/wolfcrypt/src/port/Espressif/esp32_util.c:21:
/opt/esp/idf/components/wolfssl/include/user_settings.h:48: warning: "HAVE_HKDF" redefined
   48 | #define HAVE_HKDF

but then encountered some more serious errors in homekit/src/json.c and homekit/src/port.c:

/project/components/common/homekit/src/json.c: In function 'json_uint32':
/project/components/common/homekit/src/json.c:238:53: error: format '%u' expects argument of type 'unsigned int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
  238 |     size_t len = snprintf(buffer, sizeof(buffer), "%u", x);
      |                                                    ~^   ~
      |                                                     |   |
      |                                                     |   uint32_t {aka long unsigned int}
      |                                                     unsigned int
      |                                                    %lu

/project/components/common/homekit/src/port.c: In function 'homekit_random':
/project/components/common/homekit/src/port.c:162:12: error: implicit declaration of function 'esp_random'; did you mean 'srandom'? [-Werror=implicit-function-declaration]
  162 |     return esp_random();
      |            ^~~~~~~~~~
      |            srandom
/project/components/common/homekit/src/port.c: In function 'homekit_system_restart':
/project/components/common/homekit/src/port.c:174:5: error: implicit declaration of function 'esp_restart' [-Werror=implicit-function-declaration]
  174 |     esp_restart();
      |     ^~~~~~~~~~~

Let's see if we can get your build to this state and address the errors and I'll look more at the warnings.

[PaulMartinsen]

FWIW, I was able to build for ESP32 using v5 of ESP-IDF, VisualGDB and @bandi13 's changes in #5902 . Thanks for all your hard work on this!

[gojimmypi]

@PaulMartinsen that's great news! I saw over on the VisualGDB forum that you also had some challenges with their update in VisualGDB. Glad to see you got everything working!

There are more wolfSSL examples for the ESP32 that I want to test with ESP-IDF v5 before claiming this issue is fully resolved, so I will go ahead and leave it open for now.

Let me know how things go with wolfSSL and if I can help in any way.