Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP-IDFv5: Warning related to the uint32_t definition change #6029

Closed
llange opened this issue Jan 29, 2023 · 5 comments
Closed

ESP-IDFv5: Warning related to the uint32_t definition change #6029

llange opened this issue Jan 29, 2023 · 5 comments
Assignees

Comments

@llange
Copy link

llange commented Jan 29, 2023

Version

tag v5.5.4-stable or master

Description

Compiling OVMSv3 for ESP-IDF version 5+ (NOT using the component integration (https://github.com/espressif/esp-wolfssl/)) - like in #6024 , #6026

Also I'm targeting the ESP32 target (not ESP32-S3 etc...)

When building for ESP32, the compilation gives the following warning:

[2/148] Building C object esp-idf/wolfssl/CMakeFiles/__idf_wolfssl.dir/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c.objSRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c: In function 'wc_esp_digest_state':
SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c:553:9: warning: passing argument 1 of 'esp_dport_access_read_buffer' from incompatible pointer type [-Wincompatible-pointer-types]
  553 |         (word32*)(hash), /* the result will be found in hash upon exit     */
      |         ^~~~~~~~~~~~~~~
      |         |
      |         word32 * {aka unsigned int *}
In file included from SRCS/ESP-IDF/5.0/components/soc/esp32/include/soc/dport_reg.h:12,
                 from SRCS/ESP-IDF/5.0/components/hal/esp32/include/hal/clk_gate_ll.h:17,
                 from SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/Espressif/esp32_sha.c:41:
SRCS/ESP-IDF/5.0/components/soc/esp32/include/soc/dport_access.h:108:45: note: expected 'uint32_t *' {aka 'long unsigned int *'} but argument is of type 'word32 *' {aka 'unsigned int *'}
  108 | void esp_dport_access_read_buffer(uint32_t *buff_out, uint32_t address, uint32_t num_words);
      |                                   ~~~~~~~~~~^~~~~~~~

It's related to the change of definition of uint32_t type in the compiler (unsigned int -> unsigned long).
On those platforms, word32 is defined as unsigned int.
Even if those have the same byte-size, the compiler distinguish between the 2 definitions and warns them as not compatible.

The following trivial patch seems to please the compiler:

@ wolfcrypt/src/port/Espressif/esp32_sha.c:553 @ int wc_esp_digest_state(WC_ESP32SHA* ctx, byte* hash)
      *    DPORT_SEQUENCE_REG_READ(address + i * 4);
      */
     esp_dport_access_read_buffer(
-        (word32*)(hash), /* the result will be found in hash upon exit     */
+        (uint32_t*)(hash), /* the result will be found in hash upon exit     */
         SHA_TEXT_BASE,   /* there's a fixed reg addy for all SHA           */
         wc_esp_sha_digest_size(ctx->sha_type) / sizeof(word32) /* # 4-byte */
     );
@llange
Copy link
Author

llange commented Jan 29, 2023

+@gojimmypi FYI

@gojimmypi gojimmypi self-assigned this Jan 30, 2023
@gojimmypi
Copy link
Contributor

@llange thanks for the heads up. I've seen similar problems in the past.

Could you please kindly double check the exact installed version you are using? I think the code you are referring to has been recently changed to use uint32_t.

It appears there's a ESP_IDF_VERSION_MAJOR >= 4 check that should already be doing a (uint32_t*)(hash) type cast. Although from the link you included, it appears that should instead be for v5 or greater.

Note also there's reference to the gcc version. I've been testing wolfSSL for ESP-IDF v5 on both:

image

I'm not currently able to reproduce this problem but I'll take a closer look soon.

@llange
Copy link
Author

llange commented Jan 31, 2023

Hi @gojimmypi , you're right and I was mistaken when writing that it did occur in master - it's only in v5.5.4-stable that I encountered that.
I agree with you that the define should be targeting v5 for consistency.

@gojimmypi
Copy link
Contributor

Hi @llange thanks for confirming; looks like #5902 missed the release by just a day, being merged on Dec 22; the 5.5.4 release was a day earlier on Dec 21.

On the topic of ESP-IDF v5: although I have a v5 in my gcc 8.4 toolchain directory, and I thought it worked there, I believe I was mistaken. I am not able to get ESP-IDF v5 to work with gcc 8.4. I see this error:

ESP-IDF path changed from C:\SysGCC\esp32\esp-idf\v5.0 to C:\SysGCC\esp32-8.4\esp-idf\v5.0. Deleting C:\workspace-PR\wolfssl\IDE\Espressif\ESP-IDF\examples\wolfssl_benchmark\build\VisualGDB\Debug...
Running CMake: C:\Users\gojimmypi\AppData\Local\VisualGDB\CMake\bin\cmake.exe ../../.. -G "Ninja" -DCMAKE_BUILD_TYPE=DEBUG -DCMAKE_MAKE_PROGRAM=c:/sysgcc/esp32-8.4/tools/ninja/1.10.2/ninja.exe -DESP_PLATFORM=1 -DCCACHE_ENABLE=0 -DIDF_TARGET=esp32
-- Found Git: C:/Program Files/Git/cmd/git.exe (found version "2.38.1.windows.1") 
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: C:/SysGCC/esp32-8.4/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: C:/SysGCC/esp32-8.4/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc.exe - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: C:/SysGCC/esp32-8.4/tools/xtensa-esp32-elf/esp-2021r2-patch3/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++.exe - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Building ESP-IDF components for target esp32
-- Checking Python dependencies...
Python requirements are satisfied.
Constraint file: C:\Users\gojimmypi\.espressif\espidf.constraints.v5.0.txt
Requirement files:
 - C:\SysGCC\esp32-8.4\esp-idf\v5.0\tools\requirements\requirements.core.txt
Python being checked: C:\Users\gojimmypi\.espressif\python_env\idf5.0_py3.8_env\Scripts\python.exe
-- Configuring incomplete, errors occurred!
CMake Error at C:/SysGCC/esp32-8.4/esp-idf/v5.0/tools/cmake/build.cmake:519 (message):
  C:\SysGCC\esp32-8.4\esp-idf\v5.0\python-env\Scripts\python.exe: Error while
  finding module specification for 'idf_component_manager.prepare_components'
  (ModuleNotFoundError: No module named 'idf_component_manager')

Call Stack (most recent call first):
  C:/SysGCC/esp32-8.4/esp-idf/v5.0/tools/cmake/project.cmake:440 (idf_build_process)
  CMakeLists.txt:12 (project)


See also "C:/workspace-PR/wolfssl/IDE/Espressif/ESP-IDF/examples/wolfssl_benchmark/build/VisualGDB/Debug/CMakeFiles/CMakeOutput.log".
System.Exception: CMake exited with code 1
   at dg.b(d b, Object a)

========== Project Configuration Summary ==========
    VisualGDB_wolfssl_benchmark  configured in 00:16
========== Configuration: 1 Succeeded, 0 Failed, 0 Skipped ==========

It is probably best to use the recent gcc 11.2 toolchain anyhow. I cannot think of a reason to use the older one with ESP-IDF v5.

Shall we close this issue?

@llange
Copy link
Author

llange commented Feb 1, 2023

Hi @gojimmypi,
Thanks for the info. Yes, I've only used v5 with the recommended version of the toolkit (gcc 11) so cannot comment on the validity of compiling with an older toolchain.
Confirming that master works OK, we can now close the issue.

@llange llange closed this as completed Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants