ESP-IDF v4 / v5 - baby steps
Hi list, I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc... In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ). I'm now trying to revive this effort, and after some work managed to have: * OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/ The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic) You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations) I'm now reaching out here mostly for : * gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files My next steps could be (of course, subject to feedback) : 1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same. (Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.) # The guidelines I tried to follow: * Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... # Missing features: In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon: * I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment. Let me know your comments and questions. Best regards,
Ludovic, really great & appreciated you're going ahead on this. I second skipping idf 4 and going directly for version 5. I'll try to get my idf 5 build environment up ASAP. I need to get into cmake myself as well. Needing to hard code dependencies doesn't sound good though, I thought cmake is supposed to be smart about this. I'll have a look at porting the custom crash handler to idf 5. There were some other additions that haven't been accepted by Espressif, IIRC. I'll see if I can check them as well. Regards, Michael Am 23.01.23 um 11:04 schrieb Ludovic LANGE:
Hi list,
I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc...
In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ).
I'm now trying to revive this effort, and after some work managed to have:
* OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing)
(/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/
The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic)
You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations)
I'm now reaching out here mostly for :
* gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files
My next steps could be (of course, subject to feedback) :
1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same.
(Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.)
# The guidelines I tried to follow:
* Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides...
# Missing features:
In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon:
* I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment.
Let me know your comments and questions.
Best regards,
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Thanks for your help. FYI I've just pushed the last touches to the vehicle components which are now all converted to cmake and "should work". Still compiles under 3.3.x. A new things that need to be checked : in https://github.com/llange/Open-Vehicle-Monitoring-System-3/commit/f31117a48d... i had to replace `INT` with another type. This time I choose `int32_t` but I'm not really sure because I could not find a way to see where and how INT was defined. I could only verify (by compilation tricks) that sizeof(INT) == sizeof(int32_t). Regarding cmake, I understand your concern with dependencies, and I did have the same reaction. There certainly is a way - I did not spend too much time on it. We will however have some "bugs" in the current state of things when disabling components in menuconfig where a dependency was implied and is now exposed. I'll let the cmake experts guide us :-) I'll now work on the compilation warnings. Btw, another thing that I need to mention is that from 3.3 to 5.x, many constants (used in sdkconfig) have been renamed etc... So our sdkconfig is upgraded by the build toolchain when we compile with 4.x or 5.x. I recommend doing a backup if it has been customized - in case of. Regards, Ludovic Le 23/01/2023 à 21:11, Michael Balzer a écrit :
Ludovic,
really great & appreciated you're going ahead on this. I second skipping idf 4 and going directly for version 5. I'll try to get my idf 5 build environment up ASAP.
I need to get into cmake myself as well. Needing to hard code dependencies doesn't sound good though, I thought cmake is supposed to be smart about this.
I'll have a look at porting the custom crash handler to idf 5. There were some other additions that haven't been accepted by Espressif, IIRC. I'll see if I can check them as well.
Regards, Michael
Am 23.01.23 um 11:04 schrieb Ludovic LANGE:
Hi list,
I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc...
In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ).
I'm now trying to revive this effort, and after some work managed to have:
* OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing)
(/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/
The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic)
You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations)
I'm now reaching out here mostly for :
* gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files
My next steps could be (of course, subject to feedback) :
1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same.
(Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.)
# The guidelines I tried to follow:
* Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides...
# Missing features:
In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon:
* I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment.
Let me know your comments and questions.
Best regards,
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi, A quick note to share with you the progress on the ESP-IDFv4 + cmake endeavour: * The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for greater review. Most of the warnings are gone, and I'll need some help for the last ones. * I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/806 . Not that I want to merge it as-is nor soon, but it may help the review process to have some central discussion point. * I'll now switch to ESP-IDFv5 porting - on a new branch (based on the v4) : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (empty at the moment). Regards, Le 23/01/2023 à 22:19, Ludovic LANGE a écrit :
Michael,
Thanks for your help. FYI I've just pushed the last touches to the vehicle components which are now all converted to cmake and "should work". Still compiles under 3.3.x.
A new things that need to be checked : in https://github.com/llange/Open-Vehicle-Monitoring-System-3/commit/f31117a48d... i had to replace `INT` with another type. This time I choose `int32_t` but I'm not really sure because I could not find a way to see where and how INT was defined. I could only verify (by compilation tricks) that sizeof(INT) == sizeof(int32_t).
Regarding cmake, I understand your concern with dependencies, and I did have the same reaction. There certainly is a way - I did not spend too much time on it. We will however have some "bugs" in the current state of things when disabling components in menuconfig where a dependency was implied and is now exposed. I'll let the cmake experts guide us :-)
I'll now work on the compilation warnings.
Btw, another thing that I need to mention is that from 3.3 to 5.x, many constants (used in sdkconfig) have been renamed etc... So our sdkconfig is upgraded by the build toolchain when we compile with 4.x or 5.x. I recommend doing a backup if it has been customized - in case of.
Regards,
Ludovic
Le 23/01/2023 à 21:11, Michael Balzer a écrit :
Ludovic,
really great & appreciated you're going ahead on this. I second skipping idf 4 and going directly for version 5. I'll try to get my idf 5 build environment up ASAP.
I need to get into cmake myself as well. Needing to hard code dependencies doesn't sound good though, I thought cmake is supposed to be smart about this.
I'll have a look at porting the custom crash handler to idf 5. There were some other additions that haven't been accepted by Espressif, IIRC. I'll see if I can check them as well.
Regards, Michael
Am 23.01.23 um 11:04 schrieb Ludovic LANGE:
Hi list,
I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc...
In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ).
I'm now trying to revive this effort, and after some work managed to have:
* OVMS codebase building under v4.x using Makefile * OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing)
(/*WARNING*: some important features of OVMS have been deactivated for the moment, see end of post)/
The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic)
You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations)
I'm now reaching out here mostly for :
* gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) * having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs * guidance and fixes regarding the CMakeLists.txt files
My next steps could be (of course, subject to feedback) :
1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same.
(Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.)
# The guidelines I tried to follow:
* Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality * Keep Makefiles running for 3.3.x (and 4.x if possible) * When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. * Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... * https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... * https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides...
# Missing features:
In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon:
* I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it * There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. * I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. * A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. * I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! * Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. * etc... * Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: o Our own fork does not seem to include this build system o It was experimental, the component API changed and I did not want to have edge case for something not used at the moment.
Let me know your comments and questions.
Best regards,
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Progress looks good on this. Thanks for stepping up to try to tackle it. Pain points for me with our current approach are: RAM usage (in particular IRAM) IDF bugs that may be improved in newer versions Support for newer hardware (including ESP32-S3) #3 would give us a welcome 12 more GPIOs with minimal hardware changes, but possibly worse RAM situation (520KB->512KB, see #1). My preference would be v5 IDF (for the newer hardware support). I think it would be fine to have this as a new branch. Not particularly important to make it work in the master one. Regards, Mark.
On 26 Jan 2023, at 8:56 AM, Ludovic LANGE <ll-ovmsdev@lange.nom.fr> wrote:
Hi,
A quick note to share with you the progress on the ESP-IDFv4 + cmake endeavour: The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for greater review. Most of the warnings are gone, and I'll need some help for the last ones.
I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/806 . Not that I want to merge it as-is nor soon, but it may help the review process to have some central discussion point.
I'll now switch to ESP-IDFv5 porting - on a new branch (based on the v4) : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (empty at the moment).
Regards,
Le 23/01/2023 à 22:19, Ludovic LANGE a écrit :
Michael,
Thanks for your help. FYI I've just pushed the last touches to the vehicle components which are now all converted to cmake and "should work". Still compiles under 3.3.x.
A new things that need to be checked : in https://github.com/llange/Open-Vehicle-Monitoring-System-3/commit/f31117a48d... i had to replace `INT` with another type. This time I choose `int32_t` but I'm not really sure because I could not find a way to see where and how INT was defined. I could only verify (by compilation tricks) that sizeof(INT) == sizeof(int32_t).
Regarding cmake, I understand your concern with dependencies, and I did have the same reaction. There certainly is a way - I did not spend too much time on it. We will however have some "bugs" in the current state of things when disabling components in menuconfig where a dependency was implied and is now exposed. I'll let the cmake experts guide us :-)
I'll now work on the compilation warnings.
Btw, another thing that I need to mention is that from 3.3 to 5.x, many constants (used in sdkconfig) have been renamed etc... So our sdkconfig is upgraded by the build toolchain when we compile with 4.x or 5.x. I recommend doing a backup if it has been customized - in case of.
Regards,
Ludovic
Le 23/01/2023 à 21:11, Michael Balzer a écrit :
Ludovic,
really great & appreciated you're going ahead on this. I second skipping idf 4 and going directly for version 5. I'll try to get my idf 5 build environment up ASAP.
I need to get into cmake myself as well. Needing to hard code dependencies doesn't sound good though, I thought cmake is supposed to be smart about this.
I'll have a look at porting the custom crash handler to idf 5. There were some other additions that haven't been accepted by Espressif, IIRC. I'll see if I can check them as well.
Regards, Michael
Am 23.01.23 um 11:04 schrieb Ludovic LANGE:
Hi list,
I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc...
In the past it seems that some endeavours already set the basis to make this happen (https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ).
I'm now trying to revive this effort, and after some work managed to have:
OVMS codebase building under v4.x using Makefile OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing) (WARNING: some important features of OVMS have been deactivated for the moment, see end of post)
The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic)
You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations)
I'm now reaching out here mostly for :
gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs guidance and fixes regarding the CMakeLists.txt files
My next steps could be (of course, subject to feedback) :
Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) Work on the warnings (currently disabled in the builds) and try to fix as much as possible Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) then work on the v5 and do the same.
(Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.)
# The guidelines I tried to follow:
Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality Keep Makefiles running for 3.3.x (and 4.x if possible) When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides...
# Missing features:
In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon:
I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. etc... Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: Our own fork does not seem to include this build system It was experimental, the component API changed and I did not want to have edge case for something not used at the moment.
Let me know your comments and questions.
Best regards,
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
I may try this on my spare board as a start! (The Aux 12v switch didn't work... But otherwise it's mostly OK) Michael. On Thu, 26 Jan 2023, 4:41 pm Mark Webb-Johnson, <mark@webb-johnson.net> wrote:
Progress looks good on this. Thanks for stepping up to try to tackle it.
Pain points for me with our current approach are:
1. RAM usage (in particular IRAM) 2. IDF bugs that may be improved in newer versions 3. Support for newer hardware (including ESP32-S3)
#3 would give us a welcome 12 more GPIOs with minimal hardware changes, but possibly worse RAM situation (520KB->512KB, see #1).
My preference would be v5 IDF (for the newer hardware support).
I think it would be fine to have this as a new branch. Not particularly important to make it work in the master one.
Regards, Mark.
On 26 Jan 2023, at 8:56 AM, Ludovic LANGE <ll-ovmsdev@lange.nom.fr> wrote:
Hi,
A quick note to share with you the progress on the ESP-IDFv4 + cmake endeavour:
- The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for greater review. Most of the warnings are gone, and I'll need some help for the last ones.
- I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/806 . Not that I want to merge it as-is nor soon, but it may help the review process to have some central discussion point.
- I'll now switch to ESP-IDFv5 porting - on a new branch (based on the v4) : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (empty at the moment).
Regards,
Le 23/01/2023 à 22:19, Ludovic LANGE a écrit :
Michael,
Thanks for your help. FYI I've just pushed the last touches to the vehicle components which are now all converted to cmake and "should work". Still compiles under 3.3.x.
A new things that need to be checked : in https://github.com/llange/Open-Vehicle-Monitoring-System-3/commit/f31117a48d... i had to replace `INT` with another type. This time I choose `int32_t` but I'm not really sure because I could not find a way to see where and how INT was defined. I could only verify (by compilation tricks) that sizeof(INT) == sizeof(int32_t).
Regarding cmake, I understand your concern with dependencies, and I did have the same reaction. There certainly is a way - I did not spend too much time on it. We will however have some "bugs" in the current state of things when disabling components in menuconfig where a dependency was implied and is now exposed. I'll let the cmake experts guide us :-)
I'll now work on the compilation warnings.
Btw, another thing that I need to mention is that from 3.3 to 5.x, many constants (used in sdkconfig) have been renamed etc... So our sdkconfig is upgraded by the build toolchain when we compile with 4.x or 5.x. I recommend doing a backup if it has been customized - in case of.
Regards,
Ludovic
Le 23/01/2023 à 21:11, Michael Balzer a écrit :
Ludovic,
really great & appreciated you're going ahead on this. I second skipping idf 4 and going directly for version 5. I'll try to get my idf 5 build environment up ASAP.
I need to get into cmake myself as well. Needing to hard code dependencies doesn't sound good though, I thought cmake is supposed to be smart about this.
I'll have a look at porting the custom crash handler to idf 5. There were some other additions that haven't been accepted by Espressif, IIRC. I'll see if I can check them as well.
Regards, Michael
Am 23.01.23 um 11:04 schrieb Ludovic LANGE:
Hi list,
I am interested in upgrading our codebase to a latest ESP-IDF version (preferentially v5 which has just happened end of 2022 - Happy New Year ! :-)) - mostly to be able to use some components for which a backport seems difficult (for example : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ), and as a matter of balance between stability vs latest bugfixes, security fixes, new features etc...
In the past it seems that some endeavours already set the basis to make this happen ( https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/263, https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/360 ).
I'm now trying to revive this effort, and after some work managed to have:
- OVMS codebase building under v4.x using Makefile - OVMS codebase building under v4.x using cmake / idf.py (not 100% finished, multiple vehicle_* components are missing)
(*WARNING: some important features of OVMS have been deactivated for the moment, see end of post)*
The produced binaries seem to "work on my machine board", as they end with a "OVMS#" prompt and a few (very) basic tests look OK (to be honest, unfortunately no real tests have been done except to check that the binary does not crash during boot and a few seconds of run, checking that WiFi / web Interface is OK, sdcard is OK - but very basic)
You'll find the changes here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (In the README.md, there is a short notice at the top with a few useful informations)
I'm now reaching out here mostly for :
- gathering feedback both around the effort (is it worth pursuing this goal ?) and the implementation (do my CMakeLists.txt look weird ? yes they do.) - having volunteers using those builds on real-world workload (which I cannot do at the moment) and finding bugs - guidance and fixes regarding the CMakeLists.txt files
My next steps could be (of course, subject to feedback) :
1. Have 100% of the cmake implementation finished (all the missing vehicle_* components) -> easy (only missing time) 2. Work on the warnings (currently disabled in the builds) and try to fix as much as possible 3. Iron out all the bugs, improve the dev documentation -> need help on finding them with real-world use 4. 1st goal is to propose this result as a merge request (either as a whole, or split depending on feedback - ideally I would like to have a first (big) MR accepted quickly so that people can play with it, and deliver incremental updates as expected) 5. then work on the v5 and do the same.
(Please note that my cmake skills are inexistent - so be careful when opening those files to not hurt yourself.)
# The guidelines I tried to follow:
- Stay compatible with our 3.3.x branch which should still compile without any issue nor loss of functionality - Keep Makefiles running for 3.3.x (and 4.x if possible) - When possible, isolate differences (between 3.x, 4.x, 5.x) by testing the versions of ESP-IDF. - Focus on 5.x (if there are impossibilities, let's make it easier to build v5.x than v4.x) - https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-refere... - https://docs.espressif.com/projects/esp-idf/en/release-v4.4/esp32/api-guides... - https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides... - https://docs.espressif.com/projects/esp-idf/en/latest/esp32/migration-guides...
# Missing features:
In the course of this work I had to make some decisions to speed up the work - that will need to be acted upon:
- I disabled the crash handler (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`) for the moment, we need to decide whether we "fork" ESP-IDF again to port it ; or if the new APIs are enough to (partially ?) reimplement it - There is a crash in `OvmsConsole::Poll` which I did not analyse (yet) and which I worked around by declaring a variable static. - I decided to transform our local copies of `wolfssh` and `wolfssl` in submodules (and move them one level below in terms of directories) - mainly to be able to have a CMakeLists.txt different from the upstream one. In the process, I "lost" one of our patches : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/commit/5144... and we need to decide how to handle this. - A lot of dependencies are now explicitly (hard-)coded in the CMakeLists.txt - which may, or may not be a good thing. Let's discuss it. - I had to change a set of defines into a header generation (in ovms_webserver) because I was unable to implement those in a satisfying manner in cmake. If you manage to do it, it's a win ! - Build warnings were disabled to keep the output clean and focus on the build issues - but now they need to be re-activated. - etc... - Even if there is experimental support for cmake / idf.py in ESP-IDF 3.3.x, I did not make any effort to be compatible with it: - Our own fork does not seem to include this build system - It was experimental, the component API changed and I did not want to have edge case for something not used at the moment.
Let me know your comments and questions.
Best regards,
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing listOvmsDev@lists.openvehicles.comhttp://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi list, Another quick post to share with you the progress on the ESP-IDFv5 + cmake endeavour: * ESP-IDF v5 version of OVMSv3 is now officially booting and seems to work fine (then again, I'm not doing any real-world testing for lack of time / car at the moment - it's here that you can help me) with a few caveats detailed in the PR or the README.md <https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md>. * The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for testing, sharing, studying, ... * I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/810 (just like for ESP-IDFv4), in order to show the diff and gather feedback. Not to be merged as-is. * I'll try to break it into smaller low-impact / easy-to-review PR's that could be merged as-is in current master (warning corrections, header definitions, xxprintf type impact, etc...), so that the big pieces could be more easily reviewed. Please note that those branches / PRs are still Work-In-Progress, and that I may certainly (and wrongly) `push --force` some changes as I rebase, update or split the big PR into smaller, easy to study PRs. I'll try not to but can't promise :-) So if you checkout the branch, please be warned and know your git commands to either reset or rebase your working copy... Next on my list are, in no particular order: * Have a few patches/bugs fixed in upstream wolfSSL (in progress) in order to enable * Check to see if we could upgrade mongoose (not absolutely necessary because it works / compile OK with a small patch) * Fix the remaining warnings o And change the ADC implementation that is deprecated now o deprecation of esp_vfs_fat_spiflash_mount / esp_vfs_fat_spiflash_unmount * Fix the WIP WIP WIP commits * Resume work on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 Boot time warnings to study and check if OK: * W (1091) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped * W (2132) ADC: legacy driver is deprecated, please migrate to `esp_adc/adc_oneshot.h` (<- this one is easy to understand...) Additional instructions: When first building, your sdkconfig will be converted as some config options did change betwen ESP-IDF v3.x and v5.x. Run `menuconfig` and : * *Select FREERTOS_ENABLE_BACKWARD_COMPATIBILITY*(=y) "configENABLE_BACKWARD_COMPATIBILITY" * *Unselect MG_ENABLE_SSL*(=n) "Enable MONGOOSE SSL/TLS support" If any of you with some free time could be nice enough to try to reproduce such a build and share the experience here. Let me know how the instructions could be updated and what issues you are facing. Best regards, Le 27/01/2023 à 03:17, Michael Geddes a écrit :
I may try this on my spare board as a start! (The Aux 12v switch didn't work... But otherwise it's mostly OK)
Michael.
On Thu, 26 Jan 2023, 4:41 pm Mark Webb-Johnson, <mark@webb-johnson.net> wrote:
Progress looks good on this. Thanks for stepping up to try to tackle it.
Pain points for me with our current approach are:
1. RAM usage (in particular IRAM) 2. IDF bugs that may be improved in newer versions 3. Support for newer hardware (including ESP32-S3)
#3 would give us a welcome 12 more GPIOs with minimal hardware changes, but possibly worse RAM situation (520KB->512KB, see #1).
My preference would be v5 IDF (for the newer hardware support).
I think it would be fine to have this as a new branch. Not particularly important to make it work in the master one.
Regards, Mark.
On 26 Jan 2023, at 8:56 AM, Ludovic LANGE <ll-ovmsdev@lange.nom.fr> wrote:
Hi,
A quick note to share with you the progress on the ESP-IDFv4 + cmake endeavour:
* The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for greater review. Most of the warnings are gone, and I'll need some help for the last ones.
* I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/806 . Not that I want to merge it as-is nor soon, but it may help the review process to have some central discussion point.
* I'll now switch to ESP-IDFv5 porting - on a new branch (based on the v4) : https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... (empty at the moment).
Regards,
Hi list, I started to split my big list of patches into smaller, more manageable, easier to review PRs: * missing headers <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/825> #825 * ESP-IDF v5+: dependency on ovms_webserver.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/824> #824 * ESP-IDF v5+: change type of TaskHandle_t <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/823>#823 * changes to (long deprecated) ADC constants <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/822> #822 * ESP-IDF v5+: static assertion failed: std::vector must have the same value_type as its allocator <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/821> #821 * ESP-IDF v5+: static assertion failed: comparison object must be invocable as const <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/820> #820 * ESP-IDF v4+ : remove deprecated and unused esp_event_loop.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/819> #819 * remove warning by replacing rom/queue.h with sys/queue.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/818> #818 * remove warning : '_GNU_SOURCE' redefined <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/817> #817 * ESP-IDF v4+ : esp_intr.h is deprecated, replaced by esp_intr_alloc.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/816> #816 * Add header and fix function signature <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/815> #815 * replace some constants with their more adapted counterpart <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/813> #813 Let me know if it's the proper approach ; and if some of you can review those changes and comment on them, it'll help merging those - and progress in reaching ESP-IDFv5 compatibility. Best regards, Le 31/01/2023 à 01:49, Ludovic LANGE a écrit :
Hi list,
Another quick post to share with you the progress on the ESP-IDFv5 + cmake endeavour:
* ESP-IDF v5 version of OVMSv3 is now officially booting and seems to work fine (then again, I'm not doing any real-world testing for lack of time / car at the moment - it's here that you can help me) with a few caveats detailed in the PR or the README.md <https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md>.
* The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for testing, sharing, studying, ...
* I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/810 (just like for ESP-IDFv4), in order to show the diff and gather feedback. Not to be merged as-is.
* I'll try to break it into smaller low-impact / easy-to-review PR's that could be merged as-is in current master (warning corrections, header definitions, xxprintf type impact, etc...), so that the big pieces could be more easily reviewed.
Please note that those branches / PRs are still Work-In-Progress, and that I may certainly (and wrongly) `push --force` some changes as I rebase, update or split the big PR into smaller, easy to study PRs. I'll try not to but can't promise :-) So if you checkout the branch, please be warned and know your git commands to either reset or rebase your working copy...
Next on my list are, in no particular order:
* Have a few patches/bugs fixed in upstream wolfSSL (in progress) in order to enable * Check to see if we could upgrade mongoose (not absolutely necessary because it works / compile OK with a small patch) * Fix the remaining warnings o And change the ADC implementation that is deprecated now o deprecation of esp_vfs_fat_spiflash_mount / esp_vfs_fat_spiflash_unmount * Fix the WIP WIP WIP commits * Resume work on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
Boot time warnings to study and check if OK:
* W (1091) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped * W (2132) ADC: legacy driver is deprecated, please migrate to `esp_adc/adc_oneshot.h` (<- this one is easy to understand...)
Additional instructions:
When first building, your sdkconfig will be converted as some config options did change betwen ESP-IDF v3.x and v5.x.
Run `menuconfig` and :
* *Select FREERTOS_ENABLE_BACKWARD_COMPATIBILITY*(=y) "configENABLE_BACKWARD_COMPATIBILITY" * *Unselect MG_ENABLE_SSL*(=n) "Enable MONGOOSE SSL/TLS support"
If any of you with some free time could be nice enough to try to reproduce such a build and share the experience here. Let me know how the instructions could be updated and what issues you are facing.
Best regards,
Ludovic, I'm having trouble getting the experimental-esp-idf-v5 branch to even configure. Configuring and building the "hello_world" example with idf5.0 works without any issues, so it's related to our sources. I've tried removing the build directory, doing "idf.py python-clean", doing "idf.py clean" "idf.py fullclean", but I always get this, already when doing set-target: balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> idf.py set-target esp32 Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Build directory '/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build' not found. Nothing to clean. Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it. -- Found Git: /usr/bin/git (found version "2.35.3") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "3.0.4") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp CMake Error at /home/balzer/esp/esp-idf/tools/cmake/component.cmake:224 (message): CMake Warning (dev) at build_properties.temp.cmake:8: Syntax Warning in cmake code at column 51 Argument not separated from preceding token by whitespace. Call Stack (most recent call first): /home/balzer/esp/esp-idf/tools/cmake/scripts/component_get_requirements.cmake:3 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_FIND_LIBRARY_PREFIXES CMake Error: Error required internal CMake variable not set, cmake may not be built correctly. Missing variable is: CMAKE_FIND_LIBRARY_SUFFIXES Call Stack (most recent call first): /home/balzer/esp/esp-idf/tools/cmake/build.cmake:553 (__component_get_requirements) /home/balzer/esp/esp-idf/tools/cmake/project.cmake:440 (idf_build_process) CMakeLists.txt:18 (project) -- Configuring incomplete, errors occurred! See also "/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/CMakeFiles/CMakeOutput.log". cmake failed with exit code 1, output of the command is in the /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stderr_output_8211 and /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stdout_output_8211 Any idea about this? Regards, Michael Am 02.02.23 um 22:38 schrieb Ludovic LANGE:
Hi list,
I started to split my big list of patches into smaller, more manageable, easier to review PRs:
* missing headers <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/825> #825 * ESP-IDF v5+: dependency on ovms_webserver.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/824> #824 * ESP-IDF v5+: change type of TaskHandle_t <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/823>#823 * changes to (long deprecated) ADC constants <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/822> #822 * ESP-IDF v5+: static assertion failed: std::vector must have the same value_type as its allocator <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/821> #821 * ESP-IDF v5+: static assertion failed: comparison object must be invocable as const <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/820> #820 * ESP-IDF v4+ : remove deprecated and unused esp_event_loop.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/819> #819 * remove warning by replacing rom/queue.h with sys/queue.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/818> #818 * remove warning : '_GNU_SOURCE' redefined <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/817> #817 * ESP-IDF v4+ : esp_intr.h is deprecated, replaced by esp_intr_alloc.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/816> #816 * Add header and fix function signature <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/815> #815 * replace some constants with their more adapted counterpart <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/813> #813
Let me know if it's the proper approach ; and if some of you can review those changes and comment on them, it'll help merging those - and progress in reaching ESP-IDFv5 compatibility.
Best regards,
Le 31/01/2023 à 01:49, Ludovic LANGE a écrit :
Hi list,
Another quick post to share with you the progress on the ESP-IDFv5 + cmake endeavour:
* ESP-IDF v5 version of OVMSv3 is now officially booting and seems to work fine (then again, I'm not doing any real-world testing for lack of time / car at the moment - it's here that you can help me) with a few caveats detailed in the PR or the README.md <https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md>.
* The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for testing, sharing, studying, ...
* I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/810 (just like for ESP-IDFv4), in order to show the diff and gather feedback. Not to be merged as-is.
* I'll try to break it into smaller low-impact / easy-to-review PR's that could be merged as-is in current master (warning corrections, header definitions, xxprintf type impact, etc...), so that the big pieces could be more easily reviewed.
Please note that those branches / PRs are still Work-In-Progress, and that I may certainly (and wrongly) `push --force` some changes as I rebase, update or split the big PR into smaller, easy to study PRs. I'll try not to but can't promise :-) So if you checkout the branch, please be warned and know your git commands to either reset or rebase your working copy...
Next on my list are, in no particular order:
* Have a few patches/bugs fixed in upstream wolfSSL (in progress) in order to enable * Check to see if we could upgrade mongoose (not absolutely necessary because it works / compile OK with a small patch) * Fix the remaining warnings o And change the ADC implementation that is deprecated now o deprecation of esp_vfs_fat_spiflash_mount / esp_vfs_fat_spiflash_unmount * Fix the WIP WIP WIP commits * Resume work on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
Boot time warnings to study and check if OK:
* W (1091) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped * W (2132) ADC: legacy driver is deprecated, please migrate to `esp_adc/adc_oneshot.h` (<- this one is easy to understand...)
Additional instructions:
When first building, your sdkconfig will be converted as some config options did change betwen ESP-IDF v3.x and v5.x.
Run `menuconfig` and :
* *Select FREERTOS_ENABLE_BACKWARD_COMPATIBILITY*(=y) "configENABLE_BACKWARD_COMPATIBILITY" * *Unselect MG_ENABLE_SSL*(=n) "Enable MONGOOSE SSL/TLS support"
If any of you with some free time could be nice enough to try to reproduce such a build and share the experience here. Let me know how the instructions could be updated and what issues you are facing.
Best regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, Sorry to hear you have issues but very happy that you're trying to compile it ! We're going to solve those :-) I don't use this command `idf.py set-target esp32` myself - but after trying it, it works as expected. (By the look of it, it says "Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old." so I would be careful not to use it too much as you loose your sdkconfig) The only commands I'm using are: * menuconfig (once in a while) * fullclean (while switching ESP-IDF version ; also doing `rm -rf build/`) * clean (if some changes have been made and not caught by cmake) * build (90% of the time) * app-flash * monitor My versions of git / bison / flex are (for the record): -- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 ... -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") (I also had success with bison 3.8.2 so not an issue) and my cmake is : cmake version 3.25.2 and ninja is at version 1.11.1 I set a required version of cmake 3.16 in the main CMakeLists.txt, as recommended by ESP-IDF v5 instructions, but if it's the issue we can modify this. Could you please check your version and see if there is something to try here ? During the `set-target esp32` run, my output is similar to yours but continues:
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory SRCS/OVMS-wt2/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 SRCS/OVMS-wt2/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of time_t -- Check size of time_t - done -- Found Python3: SRCS/ESP-IDF-TOOLS/5.0/python_env/idf5.0_py3.10_env/bin/python (found version "3.10.9") found components: Interpreter -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success -- App "ovms3" version: 3.3.003-316-gcb90ef8c-dirty -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/build/esp-idf/esp_system/ld/memory.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_system/ld/esp32/sections.ld.in -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.api.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/soc/esp32/ld/esp32.peripherals.ld -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/main/ovms_boot.ld -- wolfssl : EXCLUDE_ASM = SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_x86_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/chacha_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/fe_x25519_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/poly1305_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-aes-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha256-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha3-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha256_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha3_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha512_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sp_x86_64_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/wc_kyber_asm.S -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- Found Perl: /usr/local/bin/perl (found version "5.36.0") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Component idf::main will be linked with -Wl,--whole-archive -- Component idf::pcp will be linked with -Wl,--whole-archive -- Component idf::ovms_buffer will be linked with -Wl,--whole-archive -- Component idf::can will be linked with -Wl,--whole-archive -- Component idf::canopen will be linked with -Wl,--whole-archive -- Component idf::wolfssl will be linked with -Wl,--whole-archive -- Component idf::console_ssh will be linked with -Wl,--whole-archive -- Component idf::console_telnet will be linked with -Wl,--whole-archive -- Component idf::crypto will be linked with -Wl,--whole-archive -- Component idf::dbc will be linked with -Wl,--whole-archive -- Component idf::esp32adc will be linked with -Wl,--whole-archive -- Component idf::esp32bluetooth will be linked with -Wl,--whole-archive -- Component idf::esp32can will be linked with -Wl,--whole-archive -- Component idf::esp32system will be linked with -Wl,--whole-archive -- Component idf::esp32wifi will be linked with -Wl,--whole-archive -- Component idf::ext12v will be linked with -Wl,--whole-archive -- Component idf::max7317 will be linked with -Wl,--whole-archive -- Component idf::mcp2515 will be linked with -Wl,--whole-archive -- Component idf::microrl will be linked with -Wl,--whole-archive -- Component idf::obd2ecu will be linked with -Wl,--whole-archive -- Component idf::ovms_http will be linked with -Wl,--whole-archive -- Component idf::ovms_location will be linked with -Wl,--whole-archive -- Component idf::ovms_mdns will be linked with -Wl,--whole-archive -- Component idf::ovms_netlib will be linked with -Wl,--whole-archive -- Component idf::ovms_ota will be linked with -Wl,--whole-archive -- Component idf::pushover will be linked with -Wl,--whole-archive -- Component idf::ovms_webserver will be linked with -Wl,--whole-archive -- Component idf::ovms_plugins will be linked with -Wl,--whole-archive -- Component idf::ovms_tls will be linked with -Wl,--whole-archive -- Component idf::ovms_script will be linked with -Wl,--whole-archive -- Component idf::ovms_server will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v2 will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v3 will be linked with -Wl,--whole-archive -- Component idf::ovms_tpms will be linked with -Wl,--whole-archive -- Component idf::powermgmt will be linked with -Wl,--whole-archive -- Component idf::retools will be linked with -Wl,--whole-archive -- Component idf::retools_pidscan will be linked with -Wl,--whole-archive -- Component idf::retools_testerpresent will be linked with -Wl,--whole-archive -- Component idf::sdcard will be linked with -Wl,--whole-archive -- Component idf::simcom will be linked with -Wl,--whole-archive -- Component idf::spi will be linked with -Wl,--whole-archive -- Component idf::strverscmp will be linked with -Wl,--whole-archive -- Component idf::swcan will be linked with -Wl,--whole-archive -- Component idf::vehicle will be linked with -Wl,--whole-archive -- Component idf::vehicle_bmwi3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_boltev will be linked with -Wl,--whole-archive -- Component idf::vehicle_cadillac_c2_cts will be linked with -Wl,--whole-archive -- Component idf::vehicle_chevrolet_c6_corvette will be linked with -Wl,--whole-archive -- Component idf::vehicle_dbc will be linked with -Wl,--whole-archive -- Component idf::vehicle_demo will be linked with -Wl,--whole-archive -- Component idf::vehicle_fiat500 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniq5 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniqvfl will be linked with -Wl,--whole-archive -- Component idf::vehicle_jaguaripace will be linked with -Wl,--whole-archive -- Component idf::vehicle_kianiroev will be linked with -Wl,--whole-archive -- Component idf::vehicle_kiasoulev will be linked with -Wl,--whole-archive -- Component idf::vehicle_maxus_edeliver3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_mercedesb250e will be linked with -Wl,--whole-archive -- Component idf::vehicle_mgev will be linked with -Wl,--whole-archive -- Component idf::vehicle_minise will be linked with -Wl,--whole-archive -- Component idf::vehicle_mitsubishi will be linked with -Wl,--whole-archive -- Component idf::vehicle_nissanleaf will be linked with -Wl,--whole-archive -- Component idf::vehicle_none will be linked with -Wl,--whole-archive -- Component idf::vehicle_obdii will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaulttwizy will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe_ph2_obd will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarted will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarteq will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodel3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodels will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslaroadster will be linked with -Wl,--whole-archive -- Component idf::vehicle_thinkcity will be linked with -Wl,--whole-archive -- Component idf::vehicle_toyotarav4ev will be linked with -Wl,--whole-archive -- Component idf::vehicle_track will be linked with -Wl,--whole-archive -- Component idf::vehicle_voltampera will be linked with -Wl,--whole-archive -- Component idf::vehicle_vweup will be linked with -Wl,--whole-archive -- Component idf::vehicle_zeva will be linked with -Wl,--whole-archive -- Component idf::vfsedit will be linked with -Wl,--whole-archive -- Component idf::zip will be linked with -Wl,--whole-archive -- Components: app_trace app_update bootloader bootloader_support bt can canopen cmock console console_ssh console_telnet crypto cxx dbc driver duktape efuse esp-tls esp32adc esp32bluetooth esp32can esp32system esp32wifi esp_adc esp_app_format esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_netif esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump espressif__mdns esptool_py ext12v fatfs freertos hal heap http_parser idf_test ieee802154 json libtelnet log lwip main max7317 mbedtls mcp2515 microrl mongoose mqtt newlib nvs_flash obd2ecu openthread ovms_buffer ovms_cellular ovms_http ovms_location ovms_mdns ovms_netlib ovms_ota ovms_plugins ovms_script ovms_server ovms_server_v2 ovms_server_v3 ovms_tls ovms_tpms ovms_webserver partition_table pcp perfmon powermgmt protobuf-c protocomm pthread pushover retools retools_pidscan retools_testerpresent sdcard sdmmc simcom soc spi spi_flash spiffs strverscmp swcan tcp_transport ulp unity usb vehicle vehicle_bmwi3 vehicle_boltev vehicle_cadillac_c2_cts vehicle_chevrolet_c6_corvette vehicle_dbc vehicle_demo vehicle_fiat500 vehicle_hyundai_ioniq5 vehicle_hyundai_ioniqvfl vehicle_jaguaripace vehicle_kianiroev vehicle_kiasoulev vehicle_maxus_edeliver3 vehicle_mercedesb250e vehicle_mgev vehicle_minise vehicle_mitsubishi vehicle_nissanleaf vehicle_none vehicle_obdii vehicle_renaulttwizy vehicle_renaultzoe vehicle_renaultzoe_ph2_obd vehicle_smarted vehicle_smarteq vehicle_teslamodel3 vehicle_teslamodels vehicle_teslaroadster vehicle_thinkcity vehicle_toyotarav4ev vehicle_track vehicle_voltampera vehicle_vweup vehicle_zeva vfs vfsedit wear_levelling wifi_provisioning wolfssh wolfssl wpa_supplicant xtensa zip -- Component paths: SRCS/ESP-IDF/5.0/components/app_trace SRCS/ESP-IDF/5.0/components/app_update SRCS/ESP-IDF/5.0/components/bootloader SRCS/ESP-IDF/5.0/components/bootloader_support SRCS/ESP-IDF/5.0/components/bt SRCS/OVMS-wt2/vehicle/OVMS.V3/components/can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/canopen SRCS/ESP-IDF/5.0/components/cmock SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_ssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_telnet SRCS/OVMS-wt2/vehicle/OVMS.V3/components/crypto SRCS/ESP-IDF/5.0/components/cxx SRCS/OVMS-wt2/vehicle/OVMS.V3/components/dbc SRCS/ESP-IDF/5.0/components/driver SRCS/OVMS-wt2/vehicle/OVMS.V3/components/duktape SRCS/ESP-IDF/5.0/components/efuse SRCS/ESP-IDF/5.0/components/esp-tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32adc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32bluetooth SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32system SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32wifi SRCS/ESP-IDF/5.0/components/esp_adc SRCS/ESP-IDF/5.0/components/esp_app_format SRCS/ESP-IDF/5.0/components/esp_common SRCS/ESP-IDF/5.0/components/esp_eth SRCS/ESP-IDF/5.0/components/esp_event SRCS/ESP-IDF/5.0/components/esp_gdbstub SRCS/ESP-IDF/5.0/components/esp_hid SRCS/ESP-IDF/5.0/components/esp_http_client SRCS/ESP-IDF/5.0/components/esp_http_server SRCS/ESP-IDF/5.0/components/esp_https_ota SRCS/ESP-IDF/5.0/components/esp_https_server SRCS/ESP-IDF/5.0/components/esp_hw_support SRCS/ESP-IDF/5.0/components/esp_lcd SRCS/ESP-IDF/5.0/components/esp_local_ctrl SRCS/ESP-IDF/5.0/components/esp_netif SRCS/ESP-IDF/5.0/components/esp_partition SRCS/ESP-IDF/5.0/components/esp_phy SRCS/ESP-IDF/5.0/components/esp_pm SRCS/ESP-IDF/5.0/components/esp_psram SRCS/ESP-IDF/5.0/components/esp_ringbuf SRCS/ESP-IDF/5.0/components/esp_rom SRCS/ESP-IDF/5.0/components/esp_system SRCS/ESP-IDF/5.0/components/esp_timer SRCS/ESP-IDF/5.0/components/esp_wifi SRCS/ESP-IDF/5.0/components/espcoredump SRCS/OVMS-wt2/vehicle/OVMS.V3/managed_components/espressif__mdns SRCS/ESP-IDF/5.0/components/esptool_py SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ext12v SRCS/ESP-IDF/5.0/components/fatfs SRCS/ESP-IDF/5.0/components/freertos SRCS/ESP-IDF/5.0/components/hal SRCS/ESP-IDF/5.0/components/heap SRCS/ESP-IDF/5.0/components/http_parser SRCS/ESP-IDF/5.0/components/idf_test SRCS/ESP-IDF/5.0/components/ieee802154 SRCS/ESP-IDF/5.0/components/json SRCS/OVMS-wt2/vehicle/OVMS.V3/components/libtelnet SRCS/ESP-IDF/5.0/components/log SRCS/ESP-IDF/5.0/components/lwip SRCS/OVMS-wt2/vehicle/OVMS.V3/main SRCS/OVMS-wt2/vehicle/OVMS.V3/components/max7317 SRCS/ESP-IDF/5.0/components/mbedtls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mcp2515 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/microrl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mongoose SRCS/ESP-IDF/5.0/components/mqtt SRCS/ESP-IDF/5.0/components/newlib SRCS/ESP-IDF/5.0/components/nvs_flash SRCS/OVMS-wt2/vehicle/OVMS.V3/components/obd2ecu SRCS/ESP-IDF/5.0/components/openthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_buffer SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_cellular SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_http SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_location SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_mdns SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_netlib SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_ota SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_plugins SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_script SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v2 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tpms SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_webserver SRCS/ESP-IDF/5.0/components/partition_table SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pcp SRCS/ESP-IDF/5.0/components/perfmon SRCS/OVMS-wt2/vehicle/OVMS.V3/components/powermgmt SRCS/ESP-IDF/5.0/components/protobuf-c SRCS/ESP-IDF/5.0/components/protocomm SRCS/ESP-IDF/5.0/components/pthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pushover SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_pidscan SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_testerpresent SRCS/OVMS-wt2/vehicle/OVMS.V3/components/sdcard SRCS/ESP-IDF/5.0/components/sdmmc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/simcom SRCS/ESP-IDF/5.0/components/soc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/spi SRCS/ESP-IDF/5.0/components/spi_flash SRCS/ESP-IDF/5.0/components/spiffs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/strverscmp SRCS/OVMS-wt2/vehicle/OVMS.V3/components/swcan SRCS/ESP-IDF/5.0/components/tcp_transport SRCS/ESP-IDF/5.0/components/ulp SRCS/ESP-IDF/5.0/components/unity SRCS/ESP-IDF/5.0/components/usb SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_bmwi3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_boltev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_cadillac_c2_cts SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_chevrolet_c6_corvette SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_dbc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_demo SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_fiat500 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniq5 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniqvfl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_jaguaripace SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kianiroev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kiasoulev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mercedesb250e SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mgev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_minise SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mitsubishi SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_nissanleaf SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_none SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_obdii SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaulttwizy SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe_ph2_obd SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarted SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarteq SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodel3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodels SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslaroadster SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_thinkcity SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_toyotarav4ev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_track SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_voltampera SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_vweup SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_zeva SRCS/ESP-IDF/5.0/components/vfs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vfsedit SRCS/ESP-IDF/5.0/components/wear_levelling SRCS/ESP-IDF/5.0/components/wifi_provisioning SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl SRCS/ESP-IDF/5.0/components/wpa_supplicant SRCS/ESP-IDF/5.0/components/xtensa SRCS/OVMS-wt2/vehicle/OVMS.V3/components/zip -- Configuring done -- Generating done -- Build files have been written to: SRCS/OVMS-wt2/vehicle/OVMS.V3/build
So the next line that should have been printed, instead of the error, would have been:
-- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig
Could you check that your env variable `IDF_PATH` is pointing to the proper copy of ESP-IDF (v5 then) ? It's currently set to `/home/balzer/esp/esp-idf`. (The main CMakeLists.txt includes `$ENV{IDF_PATH}/tools/cmake/project.cmake`) The important env variables for ESP-IDF would be: * CMAKE_COLOR_DIAGNOSTICS set to 1 to have beautiful error messages * ESPBAUD set to 921600 * ESPPORT set to your usb device (mine is /dev/cu.usbserial-0001) * ESP_IDF_VERSION (5.0 here) * IDF_PATH should be set to the proper 5.0 root * IDF_TOOLS_EXPORT_CMD on my installation is equivalent to $IDF_PATH/export.sh * IDF_TOOLS_INSTALL_CMD on my installation is equivalent to $IDF_PATH/install.sh * IDF_TOOLS_PATH should be set to proper 5.0 tools root * IDF_PYTHON_ENV_PATH on my installation is equivalent to $IDF_TOOLS_PATH/python_env/idf5.0_py3.10_env * OPENOCD_SCRIPTS on my installation is equivalent to $IDF_TOOLS_PATH/tools/openocd-esp32/v0.11.0-esp32-20221026/openocd-esp32/share/openocd/scripts and * PATH which should include a few occurrences of $IDF_PATH and $IDF_TOOLS_PATH All of them should be automatically set it you have installed per the docs, and the fact that "hello_world" compiles is a good indicator that it was OK on your install , but double-checking is always interesting. Let me know the result of your checks. Regards, Le 05/02/2023 à 11:48, Michael Balzer a écrit :
Ludovic,
I'm having trouble getting the experimental-esp-idf-v5 branch to even configure.
Configuring and building the "hello_world" example with idf5.0 works without any issues, so it's related to our sources.
I've tried removing the build directory, doing "idf.py python-clean", doing "idf.py clean" "idf.py fullclean", but I always get this, already when doing set-target:
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> idf.py set-target esp32 Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Build directory '/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build' not found. Nothing to clean. Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/bin/git (found version "2.35.3") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "3.0.4") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp CMake Error at /home/balzer/esp/esp-idf/tools/cmake/component.cmake:224 (message): CMake Warning (dev) at build_properties.temp.cmake:8:
Syntax Warning in cmake code at column 51
Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
/home/balzer/esp/esp-idf/tools/cmake/scripts/component_get_requirements.cmake:3 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_PREFIXES
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_SUFFIXES
Call Stack (most recent call first): /home/balzer/esp/esp-idf/tools/cmake/build.cmake:553 (__component_get_requirements) /home/balzer/esp/esp-idf/tools/cmake/project.cmake:440 (idf_build_process) CMakeLists.txt:18 (project)
-- Configuring incomplete, errors occurred! See also "/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/CMakeFiles/CMakeOutput.log". cmake failed with exit code 1, output of the command is in the /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stderr_output_8211 and /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stdout_output_8211
Any idea about this?
Regards, Michael
Am 02.02.23 um 22:38 schrieb Ludovic LANGE:
Hi list,
I started to split my big list of patches into smaller, more manageable, easier to review PRs:
* missing headers <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/825> #825 * ESP-IDF v5+: dependency on ovms_webserver.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/824> #824 * ESP-IDF v5+: change type of TaskHandle_t <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/823>#823 * changes to (long deprecated) ADC constants <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/822> #822 * ESP-IDF v5+: static assertion failed: std::vector must have the same value_type as its allocator <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/821> #821 * ESP-IDF v5+: static assertion failed: comparison object must be invocable as const <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/820> #820 * ESP-IDF v4+ : remove deprecated and unused esp_event_loop.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/819> #819 * remove warning by replacing rom/queue.h with sys/queue.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/818> #818 * remove warning : '_GNU_SOURCE' redefined <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/817> #817 * ESP-IDF v4+ : esp_intr.h is deprecated, replaced by esp_intr_alloc.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/816> #816 * Add header and fix function signature <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/815> #815 * replace some constants with their more adapted counterpart <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/813> #813
Let me know if it's the proper approach ; and if some of you can review those changes and comment on them, it'll help merging those - and progress in reaching ESP-IDFv5 compatibility.
Best regards,
Le 31/01/2023 à 01:49, Ludovic LANGE a écrit :
Hi list,
Another quick post to share with you the progress on the ESP-IDFv5 + cmake endeavour:
* ESP-IDF v5 version of OVMSv3 is now officially booting and seems to work fine (then again, I'm not doing any real-world testing for lack of time / car at the moment - it's here that you can help me) with a few caveats detailed in the PR or the README.md <https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md>.
* The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for testing, sharing, studying, ...
* I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/810 (just like for ESP-IDFv4), in order to show the diff and gather feedback. Not to be merged as-is.
* I'll try to break it into smaller low-impact / easy-to-review PR's that could be merged as-is in current master (warning corrections, header definitions, xxprintf type impact, etc...), so that the big pieces could be more easily reviewed.
Please note that those branches / PRs are still Work-In-Progress, and that I may certainly (and wrongly) `push --force` some changes as I rebase, update or split the big PR into smaller, easy to study PRs. I'll try not to but can't promise :-) So if you checkout the branch, please be warned and know your git commands to either reset or rebase your working copy...
Next on my list are, in no particular order:
* Have a few patches/bugs fixed in upstream wolfSSL (in progress) in order to enable * Check to see if we could upgrade mongoose (not absolutely necessary because it works / compile OK with a small patch) * Fix the remaining warnings o And change the ADC implementation that is deprecated now o deprecation of esp_vfs_fat_spiflash_mount / esp_vfs_fat_spiflash_unmount * Fix the WIP WIP WIP commits * Resume work on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
Boot time warnings to study and check if OK:
* W (1091) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped * W (2132) ADC: legacy driver is deprecated, please migrate to `esp_adc/adc_oneshot.h` (<- this one is easy to understand...)
Additional instructions:
When first building, your sdkconfig will be converted as some config options did change betwen ESP-IDF v3.x and v5.x.
Run `menuconfig` and :
* *Select FREERTOS_ENABLE_BACKWARD_COMPATIBILITY*(=y) "configENABLE_BACKWARD_COMPATIBILITY" * *Unselect MG_ENABLE_SSL*(=n) "Enable MONGOOSE SSL/TLS support"
If any of you with some free time could be nice enough to try to reproduce such a build and share the experience here. Let me know how the instructions could be updated and what issues you are facing.
Best regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
It's cmake version 3.20.4. As I wrote, everything works with the example project "hello_world". Apparently the error occurs while the builder checks the dependencies, specifically the "idf" dependency. Where does that originate from? "hello_world" does not need this. The checked out version is your branch llange/experimental-esp-idf-v5. Regards, Michael Am 05.02.23 um 15:45 schrieb Ludovic LANGE:
Hi Michael,
Sorry to hear you have issues but very happy that you're trying to compile it ! We're going to solve those :-)
I don't use this command `idf.py set-target esp32` myself - but after trying it, it works as expected. (By the look of it, it says "Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old." so I would be careful not to use it too much as you loose your sdkconfig)
The only commands I'm using are:
* menuconfig (once in a while) * fullclean (while switching ESP-IDF version ; also doing `rm -rf build/`) * clean (if some changes have been made and not caught by cmake) * build (90% of the time) * app-flash * monitor
My versions of git / bison / flex are (for the record):
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0
...
-- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4")
(I also had success with bison 3.8.2 so not an issue)
and my cmake is : cmake version 3.25.2 and ninja is at version 1.11.1
I set a required version of cmake 3.16 in the main CMakeLists.txt, as recommended by ESP-IDF v5 instructions, but if it's the issue we can modify this. Could you please check your version and see if there is something to try here ?
During the `set-target esp32` run, my output is similar to yours but continues:
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory SRCS/OVMS-wt2/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 SRCS/OVMS-wt2/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of time_t -- Check size of time_t - done -- Found Python3: SRCS/ESP-IDF-TOOLS/5.0/python_env/idf5.0_py3.10_env/bin/python (found version "3.10.9") found components: Interpreter -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success -- App "ovms3" version: 3.3.003-316-gcb90ef8c-dirty -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/build/esp-idf/esp_system/ld/memory.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_system/ld/esp32/sections.ld.in -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.api.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/soc/esp32/ld/esp32.peripherals.ld -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/main/ovms_boot.ld -- wolfssl : EXCLUDE_ASM = SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_x86_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/chacha_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/fe_x25519_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/poly1305_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-aes-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha256-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha3-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha256_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha3_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha512_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sp_x86_64_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/wc_kyber_asm.S -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- Found Perl: /usr/local/bin/perl (found version "5.36.0") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Component idf::main will be linked with -Wl,--whole-archive -- Component idf::pcp will be linked with -Wl,--whole-archive -- Component idf::ovms_buffer will be linked with -Wl,--whole-archive -- Component idf::can will be linked with -Wl,--whole-archive -- Component idf::canopen will be linked with -Wl,--whole-archive -- Component idf::wolfssl will be linked with -Wl,--whole-archive -- Component idf::console_ssh will be linked with -Wl,--whole-archive -- Component idf::console_telnet will be linked with -Wl,--whole-archive -- Component idf::crypto will be linked with -Wl,--whole-archive -- Component idf::dbc will be linked with -Wl,--whole-archive -- Component idf::esp32adc will be linked with -Wl,--whole-archive -- Component idf::esp32bluetooth will be linked with -Wl,--whole-archive -- Component idf::esp32can will be linked with -Wl,--whole-archive -- Component idf::esp32system will be linked with -Wl,--whole-archive -- Component idf::esp32wifi will be linked with -Wl,--whole-archive -- Component idf::ext12v will be linked with -Wl,--whole-archive -- Component idf::max7317 will be linked with -Wl,--whole-archive -- Component idf::mcp2515 will be linked with -Wl,--whole-archive -- Component idf::microrl will be linked with -Wl,--whole-archive -- Component idf::obd2ecu will be linked with -Wl,--whole-archive -- Component idf::ovms_http will be linked with -Wl,--whole-archive -- Component idf::ovms_location will be linked with -Wl,--whole-archive -- Component idf::ovms_mdns will be linked with -Wl,--whole-archive -- Component idf::ovms_netlib will be linked with -Wl,--whole-archive -- Component idf::ovms_ota will be linked with -Wl,--whole-archive -- Component idf::pushover will be linked with -Wl,--whole-archive -- Component idf::ovms_webserver will be linked with -Wl,--whole-archive -- Component idf::ovms_plugins will be linked with -Wl,--whole-archive -- Component idf::ovms_tls will be linked with -Wl,--whole-archive -- Component idf::ovms_script will be linked with -Wl,--whole-archive -- Component idf::ovms_server will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v2 will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v3 will be linked with -Wl,--whole-archive -- Component idf::ovms_tpms will be linked with -Wl,--whole-archive -- Component idf::powermgmt will be linked with -Wl,--whole-archive -- Component idf::retools will be linked with -Wl,--whole-archive -- Component idf::retools_pidscan will be linked with -Wl,--whole-archive -- Component idf::retools_testerpresent will be linked with -Wl,--whole-archive -- Component idf::sdcard will be linked with -Wl,--whole-archive -- Component idf::simcom will be linked with -Wl,--whole-archive -- Component idf::spi will be linked with -Wl,--whole-archive -- Component idf::strverscmp will be linked with -Wl,--whole-archive -- Component idf::swcan will be linked with -Wl,--whole-archive -- Component idf::vehicle will be linked with -Wl,--whole-archive -- Component idf::vehicle_bmwi3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_boltev will be linked with -Wl,--whole-archive -- Component idf::vehicle_cadillac_c2_cts will be linked with -Wl,--whole-archive -- Component idf::vehicle_chevrolet_c6_corvette will be linked with -Wl,--whole-archive -- Component idf::vehicle_dbc will be linked with -Wl,--whole-archive -- Component idf::vehicle_demo will be linked with -Wl,--whole-archive -- Component idf::vehicle_fiat500 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniq5 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniqvfl will be linked with -Wl,--whole-archive -- Component idf::vehicle_jaguaripace will be linked with -Wl,--whole-archive -- Component idf::vehicle_kianiroev will be linked with -Wl,--whole-archive -- Component idf::vehicle_kiasoulev will be linked with -Wl,--whole-archive -- Component idf::vehicle_maxus_edeliver3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_mercedesb250e will be linked with -Wl,--whole-archive -- Component idf::vehicle_mgev will be linked with -Wl,--whole-archive -- Component idf::vehicle_minise will be linked with -Wl,--whole-archive -- Component idf::vehicle_mitsubishi will be linked with -Wl,--whole-archive -- Component idf::vehicle_nissanleaf will be linked with -Wl,--whole-archive -- Component idf::vehicle_none will be linked with -Wl,--whole-archive -- Component idf::vehicle_obdii will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaulttwizy will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe_ph2_obd will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarted will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarteq will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodel3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodels will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslaroadster will be linked with -Wl,--whole-archive -- Component idf::vehicle_thinkcity will be linked with -Wl,--whole-archive -- Component idf::vehicle_toyotarav4ev will be linked with -Wl,--whole-archive -- Component idf::vehicle_track will be linked with -Wl,--whole-archive -- Component idf::vehicle_voltampera will be linked with -Wl,--whole-archive -- Component idf::vehicle_vweup will be linked with -Wl,--whole-archive -- Component idf::vehicle_zeva will be linked with -Wl,--whole-archive -- Component idf::vfsedit will be linked with -Wl,--whole-archive -- Component idf::zip will be linked with -Wl,--whole-archive -- Components: app_trace app_update bootloader bootloader_support bt can canopen cmock console console_ssh console_telnet crypto cxx dbc driver duktape efuse esp-tls esp32adc esp32bluetooth esp32can esp32system esp32wifi esp_adc esp_app_format esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_netif esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump espressif__mdns esptool_py ext12v fatfs freertos hal heap http_parser idf_test ieee802154 json libtelnet log lwip main max7317 mbedtls mcp2515 microrl mongoose mqtt newlib nvs_flash obd2ecu openthread ovms_buffer ovms_cellular ovms_http ovms_location ovms_mdns ovms_netlib ovms_ota ovms_plugins ovms_script ovms_server ovms_server_v2 ovms_server_v3 ovms_tls ovms_tpms ovms_webserver partition_table pcp perfmon powermgmt protobuf-c protocomm pthread pushover retools retools_pidscan retools_testerpresent sdcard sdmmc simcom soc spi spi_flash spiffs strverscmp swcan tcp_transport ulp unity usb vehicle vehicle_bmwi3 vehicle_boltev vehicle_cadillac_c2_cts vehicle_chevrolet_c6_corvette vehicle_dbc vehicle_demo vehicle_fiat500 vehicle_hyundai_ioniq5 vehicle_hyundai_ioniqvfl vehicle_jaguaripace vehicle_kianiroev vehicle_kiasoulev vehicle_maxus_edeliver3 vehicle_mercedesb250e vehicle_mgev vehicle_minise vehicle_mitsubishi vehicle_nissanleaf vehicle_none vehicle_obdii vehicle_renaulttwizy vehicle_renaultzoe vehicle_renaultzoe_ph2_obd vehicle_smarted vehicle_smarteq vehicle_teslamodel3 vehicle_teslamodels vehicle_teslaroadster vehicle_thinkcity vehicle_toyotarav4ev vehicle_track vehicle_voltampera vehicle_vweup vehicle_zeva vfs vfsedit wear_levelling wifi_provisioning wolfssh wolfssl wpa_supplicant xtensa zip -- Component paths: SRCS/ESP-IDF/5.0/components/app_trace SRCS/ESP-IDF/5.0/components/app_update SRCS/ESP-IDF/5.0/components/bootloader SRCS/ESP-IDF/5.0/components/bootloader_support SRCS/ESP-IDF/5.0/components/bt SRCS/OVMS-wt2/vehicle/OVMS.V3/components/can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/canopen SRCS/ESP-IDF/5.0/components/cmock SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_ssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_telnet SRCS/OVMS-wt2/vehicle/OVMS.V3/components/crypto SRCS/ESP-IDF/5.0/components/cxx SRCS/OVMS-wt2/vehicle/OVMS.V3/components/dbc SRCS/ESP-IDF/5.0/components/driver SRCS/OVMS-wt2/vehicle/OVMS.V3/components/duktape SRCS/ESP-IDF/5.0/components/efuse SRCS/ESP-IDF/5.0/components/esp-tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32adc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32bluetooth SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32system SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32wifi SRCS/ESP-IDF/5.0/components/esp_adc SRCS/ESP-IDF/5.0/components/esp_app_format SRCS/ESP-IDF/5.0/components/esp_common SRCS/ESP-IDF/5.0/components/esp_eth SRCS/ESP-IDF/5.0/components/esp_event SRCS/ESP-IDF/5.0/components/esp_gdbstub SRCS/ESP-IDF/5.0/components/esp_hid SRCS/ESP-IDF/5.0/components/esp_http_client SRCS/ESP-IDF/5.0/components/esp_http_server SRCS/ESP-IDF/5.0/components/esp_https_ota SRCS/ESP-IDF/5.0/components/esp_https_server SRCS/ESP-IDF/5.0/components/esp_hw_support SRCS/ESP-IDF/5.0/components/esp_lcd SRCS/ESP-IDF/5.0/components/esp_local_ctrl SRCS/ESP-IDF/5.0/components/esp_netif SRCS/ESP-IDF/5.0/components/esp_partition SRCS/ESP-IDF/5.0/components/esp_phy SRCS/ESP-IDF/5.0/components/esp_pm SRCS/ESP-IDF/5.0/components/esp_psram SRCS/ESP-IDF/5.0/components/esp_ringbuf SRCS/ESP-IDF/5.0/components/esp_rom SRCS/ESP-IDF/5.0/components/esp_system SRCS/ESP-IDF/5.0/components/esp_timer SRCS/ESP-IDF/5.0/components/esp_wifi SRCS/ESP-IDF/5.0/components/espcoredump SRCS/OVMS-wt2/vehicle/OVMS.V3/managed_components/espressif__mdns SRCS/ESP-IDF/5.0/components/esptool_py SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ext12v SRCS/ESP-IDF/5.0/components/fatfs SRCS/ESP-IDF/5.0/components/freertos SRCS/ESP-IDF/5.0/components/hal SRCS/ESP-IDF/5.0/components/heap SRCS/ESP-IDF/5.0/components/http_parser SRCS/ESP-IDF/5.0/components/idf_test SRCS/ESP-IDF/5.0/components/ieee802154 SRCS/ESP-IDF/5.0/components/json SRCS/OVMS-wt2/vehicle/OVMS.V3/components/libtelnet SRCS/ESP-IDF/5.0/components/log SRCS/ESP-IDF/5.0/components/lwip SRCS/OVMS-wt2/vehicle/OVMS.V3/main SRCS/OVMS-wt2/vehicle/OVMS.V3/components/max7317 SRCS/ESP-IDF/5.0/components/mbedtls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mcp2515 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/microrl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mongoose SRCS/ESP-IDF/5.0/components/mqtt SRCS/ESP-IDF/5.0/components/newlib SRCS/ESP-IDF/5.0/components/nvs_flash SRCS/OVMS-wt2/vehicle/OVMS.V3/components/obd2ecu SRCS/ESP-IDF/5.0/components/openthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_buffer SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_cellular SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_http SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_location SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_mdns SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_netlib SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_ota SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_plugins SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_script SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v2 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tpms SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_webserver SRCS/ESP-IDF/5.0/components/partition_table SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pcp SRCS/ESP-IDF/5.0/components/perfmon SRCS/OVMS-wt2/vehicle/OVMS.V3/components/powermgmt SRCS/ESP-IDF/5.0/components/protobuf-c SRCS/ESP-IDF/5.0/components/protocomm SRCS/ESP-IDF/5.0/components/pthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pushover SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_pidscan SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_testerpresent SRCS/OVMS-wt2/vehicle/OVMS.V3/components/sdcard SRCS/ESP-IDF/5.0/components/sdmmc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/simcom SRCS/ESP-IDF/5.0/components/soc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/spi SRCS/ESP-IDF/5.0/components/spi_flash SRCS/ESP-IDF/5.0/components/spiffs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/strverscmp SRCS/OVMS-wt2/vehicle/OVMS.V3/components/swcan SRCS/ESP-IDF/5.0/components/tcp_transport SRCS/ESP-IDF/5.0/components/ulp SRCS/ESP-IDF/5.0/components/unity SRCS/ESP-IDF/5.0/components/usb SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_bmwi3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_boltev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_cadillac_c2_cts SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_chevrolet_c6_corvette SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_dbc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_demo SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_fiat500 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniq5 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniqvfl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_jaguaripace SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kianiroev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kiasoulev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mercedesb250e SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mgev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_minise SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mitsubishi SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_nissanleaf SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_none SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_obdii SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaulttwizy SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe_ph2_obd SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarted SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarteq SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodel3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodels SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslaroadster SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_thinkcity SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_toyotarav4ev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_track SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_voltampera SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_vweup SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_zeva SRCS/ESP-IDF/5.0/components/vfs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vfsedit SRCS/ESP-IDF/5.0/components/wear_levelling SRCS/ESP-IDF/5.0/components/wifi_provisioning SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl SRCS/ESP-IDF/5.0/components/wpa_supplicant SRCS/ESP-IDF/5.0/components/xtensa SRCS/OVMS-wt2/vehicle/OVMS.V3/components/zip -- Configuring done -- Generating done -- Build files have been written to: SRCS/OVMS-wt2/vehicle/OVMS.V3/build
So the next line that should have been printed, instead of the error, would have been:
-- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig
Could you check that your env variable `IDF_PATH` is pointing to the proper copy of ESP-IDF (v5 then) ? It's currently set to `/home/balzer/esp/esp-idf`.
(The main CMakeLists.txt includes `$ENV{IDF_PATH}/tools/cmake/project.cmake`)
The important env variables for ESP-IDF would be:
* CMAKE_COLOR_DIAGNOSTICS set to 1 to have beautiful error messages * ESPBAUD set to 921600 * ESPPORT set to your usb device (mine is /dev/cu.usbserial-0001) * ESP_IDF_VERSION (5.0 here) * IDF_PATH should be set to the proper 5.0 root * IDF_TOOLS_EXPORT_CMD on my installation is equivalent to $IDF_PATH/export.sh * IDF_TOOLS_INSTALL_CMD on my installation is equivalent to $IDF_PATH/install.sh * IDF_TOOLS_PATH should be set to proper 5.0 tools root * IDF_PYTHON_ENV_PATH on my installation is equivalent to $IDF_TOOLS_PATH/python_env/idf5.0_py3.10_env * OPENOCD_SCRIPTS on my installation is equivalent to $IDF_TOOLS_PATH/tools/openocd-esp32/v0.11.0-esp32-20221026/openocd-esp32/share/openocd/scripts and * PATH which should include a few occurrences of $IDF_PATH and $IDF_TOOLS_PATH
All of them should be automatically set it you have installed per the docs, and the fact that "hello_world" compiles is a good indicator that it was OK on your install , but double-checking is always interesting.
Let me know the result of your checks.
Regards,
Le 05/02/2023 à 11:48, Michael Balzer a écrit :
Ludovic,
I'm having trouble getting the experimental-esp-idf-v5 branch to even configure.
Configuring and building the "hello_world" example with idf5.0 works without any issues, so it's related to our sources.
I've tried removing the build directory, doing "idf.py python-clean", doing "idf.py clean" "idf.py fullclean", but I always get this, already when doing set-target:
balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> idf.py set-target esp32 Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Build directory '/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build' not found. Nothing to clean. Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/bin/git (found version "2.35.3") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: /home/balzer/.espressif/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "3.0.4") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp CMake Error at /home/balzer/esp/esp-idf/tools/cmake/component.cmake:224 (message): CMake Warning (dev) at build_properties.temp.cmake:8:
Syntax Warning in cmake code at column 51
Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
/home/balzer/esp/esp-idf/tools/cmake/scripts/component_get_requirements.cmake:3 (include)
This warning is for project developers. Use -Wno-dev to suppress it.
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_PREFIXES
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_FIND_LIBRARY_SUFFIXES
Call Stack (most recent call first): /home/balzer/esp/esp-idf/tools/cmake/build.cmake:553 (__component_get_requirements) /home/balzer/esp/esp-idf/tools/cmake/project.cmake:440 (idf_build_process) CMakeLists.txt:18 (project)
-- Configuring incomplete, errors occurred! See also "/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/CMakeFiles/CMakeOutput.log". cmake failed with exit code 1, output of the command is in the /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stderr_output_8211 and /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stdout_output_8211
Any idea about this?
Regards, Michael
Am 02.02.23 um 22:38 schrieb Ludovic LANGE:
Hi list,
I started to split my big list of patches into smaller, more manageable, easier to review PRs:
* missing headers <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/825> #825 * ESP-IDF v5+: dependency on ovms_webserver.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/824> #824 * ESP-IDF v5+: change type of TaskHandle_t <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/823>#823 * changes to (long deprecated) ADC constants <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/822> #822 * ESP-IDF v5+: static assertion failed: std::vector must have the same value_type as its allocator <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/821> #821 * ESP-IDF v5+: static assertion failed: comparison object must be invocable as const <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/820> #820 * ESP-IDF v4+ : remove deprecated and unused esp_event_loop.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/819> #819 * remove warning by replacing rom/queue.h with sys/queue.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/818> #818 * remove warning : '_GNU_SOURCE' redefined <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/817> #817 * ESP-IDF v4+ : esp_intr.h is deprecated, replaced by esp_intr_alloc.h <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/816> #816 * Add header and fix function signature <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/815> #815 * replace some constants with their more adapted counterpart <https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/813> #813
Let me know if it's the proper approach ; and if some of you can review those changes and comment on them, it'll help merging those - and progress in reaching ESP-IDFv5 compatibility.
Best regards,
Le 31/01/2023 à 01:49, Ludovic LANGE a écrit :
Hi list,
Another quick post to share with you the progress on the ESP-IDFv5 + cmake endeavour:
* ESP-IDF v5 version of OVMSv3 is now officially booting and seems to work fine (then again, I'm not doing any real-world testing for lack of time / car at the moment - it's here that you can help me) with a few caveats detailed in the PR or the README.md <https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental-esp-idf-v5/README.md>.
* The branch https://github.com/llange/Open-Vehicle-Monitoring-System-3/tree/experimental... is now ready for testing, sharing, studying, ...
* I created a draft PR https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/810 (just like for ESP-IDFv4), in order to show the diff and gather feedback. Not to be merged as-is.
* I'll try to break it into smaller low-impact / easy-to-review PR's that could be merged as-is in current master (warning corrections, header definitions, xxprintf type impact, etc...), so that the big pieces could be more easily reviewed.
Please note that those branches / PRs are still Work-In-Progress, and that I may certainly (and wrongly) `push --force` some changes as I rebase, update or split the big PR into smaller, easy to study PRs. I'll try not to but can't promise :-) So if you checkout the branch, please be warned and know your git commands to either reset or rebase your working copy...
Next on my list are, in no particular order:
* Have a few patches/bugs fixed in upstream wolfSSL (in progress) in order to enable * Check to see if we could upgrade mongoose (not absolutely necessary because it works / compile OK with a small patch) * Fix the remaining warnings o And change the ADC implementation that is deprecated now o deprecation of esp_vfs_fat_spiflash_mount / esp_vfs_fat_spiflash_unmount * Fix the WIP WIP WIP commits * Resume work on https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752
Boot time warnings to study and check if OK:
* W (1091) esp_psram: Virtual address not enough for PSRAM, map as much as we can. 4MB is mapped * W (2132) ADC: legacy driver is deprecated, please migrate to `esp_adc/adc_oneshot.h` (<- this one is easy to understand...)
Additional instructions:
When first building, your sdkconfig will be converted as some config options did change betwen ESP-IDF v3.x and v5.x.
Run `menuconfig` and :
* *Select FREERTOS_ENABLE_BACKWARD_COMPATIBILITY*(=y) "configENABLE_BACKWARD_COMPATIBILITY" * *Unselect MG_ENABLE_SSL*(=n) "Enable MONGOOSE SSL/TLS support"
If any of you with some free time could be nice enough to try to reproduce such a build and share the experience here. Let me know how the instructions could be updated and what issues you are facing.
Best regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
"idf" dependency, as expressed in (new file) `main/idf_component.yml`, is just ESP-IDF - this just checks that ESP-IDF is at minimum at version 5.0 This new file expresses the dependencies with new components (like a `requirements.txt` in Python, `Gemfile` in Ruby, `package.json` in JS, etc...), and they started to remove components from ESP-IDF and make them available as external components. `mdns` is such a component : https://components.espressif.com/components/espressif/mdns So I'm not 100% convinced it's related - but in any case you could remove this file completely and see if it changes something (you wouldn't be able to compile `mdns`-related components, but still make some progress) Could you share the 3 log files please ?
See also "/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/CMakeFiles/CMakeOutput.log". cmake failed with exit code 1, output of the command is in the /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stderr_output_8211 and /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stdout_output_8211 Regards,
Le 05/02/2023 à 16:43, Michael Balzer a écrit :
It's cmake version 3.20.4.
As I wrote, everything works with the example project "hello_world".
Apparently the error occurs while the builder checks the dependencies, specifically the "idf" dependency. Where does that originate from? "hello_world" does not need this.
The checked out version is your branch llange/experimental-esp-idf-v5.
Regards, Michael
Am 05.02.23 um 15:45 schrieb Ludovic LANGE:
Hi Michael,
Sorry to hear you have issues but very happy that you're trying to compile it ! We're going to solve those :-)
I don't use this command `idf.py set-target esp32` myself - but after trying it, it works as expected. (By the look of it, it says "Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old." so I would be careful not to use it too much as you loose your sdkconfig)
The only commands I'm using are:
* menuconfig (once in a while) * fullclean (while switching ESP-IDF version ; also doing `rm -rf build/`) * clean (if some changes have been made and not caught by cmake) * build (90% of the time) * app-flash * monitor
My versions of git / bison / flex are (for the record):
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0
...
-- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4")
(I also had success with bison 3.8.2 so not an issue)
and my cmake is : cmake version 3.25.2 and ninja is at version 1.11.1
I set a required version of cmake 3.16 in the main CMakeLists.txt, as recommended by ESP-IDF v5 instructions, but if it's the issue we can modify this. Could you please check your version and see if there is something to try here ?
During the `set-target esp32` run, my output is similar to yours but continues:
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory SRCS/OVMS-wt2/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 SRCS/OVMS-wt2/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of time_t -- Check size of time_t - done -- Found Python3: SRCS/ESP-IDF-TOOLS/5.0/python_env/idf5.0_py3.10_env/bin/python (found version "3.10.9") found components: Interpreter -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success -- App "ovms3" version: 3.3.003-316-gcb90ef8c-dirty -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/build/esp-idf/esp_system/ld/memory.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_system/ld/esp32/sections.ld.in -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.api.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/soc/esp32/ld/esp32.peripherals.ld -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/main/ovms_boot.ld -- wolfssl : EXCLUDE_ASM = SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_x86_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/chacha_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/fe_x25519_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/poly1305_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-aes-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha256-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha3-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha256_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha3_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha512_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sp_x86_64_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/wc_kyber_asm.S -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- Found Perl: /usr/local/bin/perl (found version "5.36.0") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Component idf::main will be linked with -Wl,--whole-archive -- Component idf::pcp will be linked with -Wl,--whole-archive -- Component idf::ovms_buffer will be linked with -Wl,--whole-archive -- Component idf::can will be linked with -Wl,--whole-archive -- Component idf::canopen will be linked with -Wl,--whole-archive -- Component idf::wolfssl will be linked with -Wl,--whole-archive -- Component idf::console_ssh will be linked with -Wl,--whole-archive -- Component idf::console_telnet will be linked with -Wl,--whole-archive -- Component idf::crypto will be linked with -Wl,--whole-archive -- Component idf::dbc will be linked with -Wl,--whole-archive -- Component idf::esp32adc will be linked with -Wl,--whole-archive -- Component idf::esp32bluetooth will be linked with -Wl,--whole-archive -- Component idf::esp32can will be linked with -Wl,--whole-archive -- Component idf::esp32system will be linked with -Wl,--whole-archive -- Component idf::esp32wifi will be linked with -Wl,--whole-archive -- Component idf::ext12v will be linked with -Wl,--whole-archive -- Component idf::max7317 will be linked with -Wl,--whole-archive -- Component idf::mcp2515 will be linked with -Wl,--whole-archive -- Component idf::microrl will be linked with -Wl,--whole-archive -- Component idf::obd2ecu will be linked with -Wl,--whole-archive -- Component idf::ovms_http will be linked with -Wl,--whole-archive -- Component idf::ovms_location will be linked with -Wl,--whole-archive -- Component idf::ovms_mdns will be linked with -Wl,--whole-archive -- Component idf::ovms_netlib will be linked with -Wl,--whole-archive -- Component idf::ovms_ota will be linked with -Wl,--whole-archive -- Component idf::pushover will be linked with -Wl,--whole-archive -- Component idf::ovms_webserver will be linked with -Wl,--whole-archive -- Component idf::ovms_plugins will be linked with -Wl,--whole-archive -- Component idf::ovms_tls will be linked with -Wl,--whole-archive -- Component idf::ovms_script will be linked with -Wl,--whole-archive -- Component idf::ovms_server will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v2 will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v3 will be linked with -Wl,--whole-archive -- Component idf::ovms_tpms will be linked with -Wl,--whole-archive -- Component idf::powermgmt will be linked with -Wl,--whole-archive -- Component idf::retools will be linked with -Wl,--whole-archive -- Component idf::retools_pidscan will be linked with -Wl,--whole-archive -- Component idf::retools_testerpresent will be linked with -Wl,--whole-archive -- Component idf::sdcard will be linked with -Wl,--whole-archive -- Component idf::simcom will be linked with -Wl,--whole-archive -- Component idf::spi will be linked with -Wl,--whole-archive -- Component idf::strverscmp will be linked with -Wl,--whole-archive -- Component idf::swcan will be linked with -Wl,--whole-archive -- Component idf::vehicle will be linked with -Wl,--whole-archive -- Component idf::vehicle_bmwi3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_boltev will be linked with -Wl,--whole-archive -- Component idf::vehicle_cadillac_c2_cts will be linked with -Wl,--whole-archive -- Component idf::vehicle_chevrolet_c6_corvette will be linked with -Wl,--whole-archive -- Component idf::vehicle_dbc will be linked with -Wl,--whole-archive -- Component idf::vehicle_demo will be linked with -Wl,--whole-archive -- Component idf::vehicle_fiat500 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniq5 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniqvfl will be linked with -Wl,--whole-archive -- Component idf::vehicle_jaguaripace will be linked with -Wl,--whole-archive -- Component idf::vehicle_kianiroev will be linked with -Wl,--whole-archive -- Component idf::vehicle_kiasoulev will be linked with -Wl,--whole-archive -- Component idf::vehicle_maxus_edeliver3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_mercedesb250e will be linked with -Wl,--whole-archive -- Component idf::vehicle_mgev will be linked with -Wl,--whole-archive -- Component idf::vehicle_minise will be linked with -Wl,--whole-archive -- Component idf::vehicle_mitsubishi will be linked with -Wl,--whole-archive -- Component idf::vehicle_nissanleaf will be linked with -Wl,--whole-archive -- Component idf::vehicle_none will be linked with -Wl,--whole-archive -- Component idf::vehicle_obdii will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaulttwizy will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe_ph2_obd will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarted will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarteq will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodel3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodels will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslaroadster will be linked with -Wl,--whole-archive -- Component idf::vehicle_thinkcity will be linked with -Wl,--whole-archive -- Component idf::vehicle_toyotarav4ev will be linked with -Wl,--whole-archive -- Component idf::vehicle_track will be linked with -Wl,--whole-archive -- Component idf::vehicle_voltampera will be linked with -Wl,--whole-archive -- Component idf::vehicle_vweup will be linked with -Wl,--whole-archive -- Component idf::vehicle_zeva will be linked with -Wl,--whole-archive -- Component idf::vfsedit will be linked with -Wl,--whole-archive -- Component idf::zip will be linked with -Wl,--whole-archive -- Components: app_trace app_update bootloader bootloader_support bt can canopen cmock console console_ssh console_telnet crypto cxx dbc driver duktape efuse esp-tls esp32adc esp32bluetooth esp32can esp32system esp32wifi esp_adc esp_app_format esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_netif esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump espressif__mdns esptool_py ext12v fatfs freertos hal heap http_parser idf_test ieee802154 json libtelnet log lwip main max7317 mbedtls mcp2515 microrl mongoose mqtt newlib nvs_flash obd2ecu openthread ovms_buffer ovms_cellular ovms_http ovms_location ovms_mdns ovms_netlib ovms_ota ovms_plugins ovms_script ovms_server ovms_server_v2 ovms_server_v3 ovms_tls ovms_tpms ovms_webserver partition_table pcp perfmon powermgmt protobuf-c protocomm pthread pushover retools retools_pidscan retools_testerpresent sdcard sdmmc simcom soc spi spi_flash spiffs strverscmp swcan tcp_transport ulp unity usb vehicle vehicle_bmwi3 vehicle_boltev vehicle_cadillac_c2_cts vehicle_chevrolet_c6_corvette vehicle_dbc vehicle_demo vehicle_fiat500 vehicle_hyundai_ioniq5 vehicle_hyundai_ioniqvfl vehicle_jaguaripace vehicle_kianiroev vehicle_kiasoulev vehicle_maxus_edeliver3 vehicle_mercedesb250e vehicle_mgev vehicle_minise vehicle_mitsubishi vehicle_nissanleaf vehicle_none vehicle_obdii vehicle_renaulttwizy vehicle_renaultzoe vehicle_renaultzoe_ph2_obd vehicle_smarted vehicle_smarteq vehicle_teslamodel3 vehicle_teslamodels vehicle_teslaroadster vehicle_thinkcity vehicle_toyotarav4ev vehicle_track vehicle_voltampera vehicle_vweup vehicle_zeva vfs vfsedit wear_levelling wifi_provisioning wolfssh wolfssl wpa_supplicant xtensa zip -- Component paths: SRCS/ESP-IDF/5.0/components/app_trace SRCS/ESP-IDF/5.0/components/app_update SRCS/ESP-IDF/5.0/components/bootloader SRCS/ESP-IDF/5.0/components/bootloader_support SRCS/ESP-IDF/5.0/components/bt SRCS/OVMS-wt2/vehicle/OVMS.V3/components/can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/canopen SRCS/ESP-IDF/5.0/components/cmock SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_ssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_telnet SRCS/OVMS-wt2/vehicle/OVMS.V3/components/crypto SRCS/ESP-IDF/5.0/components/cxx SRCS/OVMS-wt2/vehicle/OVMS.V3/components/dbc SRCS/ESP-IDF/5.0/components/driver SRCS/OVMS-wt2/vehicle/OVMS.V3/components/duktape SRCS/ESP-IDF/5.0/components/efuse SRCS/ESP-IDF/5.0/components/esp-tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32adc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32bluetooth SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32system SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32wifi SRCS/ESP-IDF/5.0/components/esp_adc SRCS/ESP-IDF/5.0/components/esp_app_format SRCS/ESP-IDF/5.0/components/esp_common SRCS/ESP-IDF/5.0/components/esp_eth SRCS/ESP-IDF/5.0/components/esp_event SRCS/ESP-IDF/5.0/components/esp_gdbstub SRCS/ESP-IDF/5.0/components/esp_hid SRCS/ESP-IDF/5.0/components/esp_http_client SRCS/ESP-IDF/5.0/components/esp_http_server SRCS/ESP-IDF/5.0/components/esp_https_ota SRCS/ESP-IDF/5.0/components/esp_https_server SRCS/ESP-IDF/5.0/components/esp_hw_support SRCS/ESP-IDF/5.0/components/esp_lcd SRCS/ESP-IDF/5.0/components/esp_local_ctrl SRCS/ESP-IDF/5.0/components/esp_netif SRCS/ESP-IDF/5.0/components/esp_partition SRCS/ESP-IDF/5.0/components/esp_phy SRCS/ESP-IDF/5.0/components/esp_pm SRCS/ESP-IDF/5.0/components/esp_psram SRCS/ESP-IDF/5.0/components/esp_ringbuf SRCS/ESP-IDF/5.0/components/esp_rom SRCS/ESP-IDF/5.0/components/esp_system SRCS/ESP-IDF/5.0/components/esp_timer SRCS/ESP-IDF/5.0/components/esp_wifi SRCS/ESP-IDF/5.0/components/espcoredump SRCS/OVMS-wt2/vehicle/OVMS.V3/managed_components/espressif__mdns SRCS/ESP-IDF/5.0/components/esptool_py SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ext12v SRCS/ESP-IDF/5.0/components/fatfs SRCS/ESP-IDF/5.0/components/freertos SRCS/ESP-IDF/5.0/components/hal SRCS/ESP-IDF/5.0/components/heap SRCS/ESP-IDF/5.0/components/http_parser SRCS/ESP-IDF/5.0/components/idf_test SRCS/ESP-IDF/5.0/components/ieee802154 SRCS/ESP-IDF/5.0/components/json SRCS/OVMS-wt2/vehicle/OVMS.V3/components/libtelnet SRCS/ESP-IDF/5.0/components/log SRCS/ESP-IDF/5.0/components/lwip SRCS/OVMS-wt2/vehicle/OVMS.V3/main SRCS/OVMS-wt2/vehicle/OVMS.V3/components/max7317 SRCS/ESP-IDF/5.0/components/mbedtls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mcp2515 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/microrl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mongoose SRCS/ESP-IDF/5.0/components/mqtt SRCS/ESP-IDF/5.0/components/newlib SRCS/ESP-IDF/5.0/components/nvs_flash SRCS/OVMS-wt2/vehicle/OVMS.V3/components/obd2ecu SRCS/ESP-IDF/5.0/components/openthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_buffer SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_cellular SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_http SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_location SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_mdns SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_netlib SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_ota SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_plugins SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_script SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v2 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tpms SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_webserver SRCS/ESP-IDF/5.0/components/partition_table SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pcp SRCS/ESP-IDF/5.0/components/perfmon SRCS/OVMS-wt2/vehicle/OVMS.V3/components/powermgmt SRCS/ESP-IDF/5.0/components/protobuf-c SRCS/ESP-IDF/5.0/components/protocomm SRCS/ESP-IDF/5.0/components/pthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pushover SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_pidscan SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_testerpresent SRCS/OVMS-wt2/vehicle/OVMS.V3/components/sdcard SRCS/ESP-IDF/5.0/components/sdmmc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/simcom SRCS/ESP-IDF/5.0/components/soc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/spi SRCS/ESP-IDF/5.0/components/spi_flash SRCS/ESP-IDF/5.0/components/spiffs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/strverscmp SRCS/OVMS-wt2/vehicle/OVMS.V3/components/swcan SRCS/ESP-IDF/5.0/components/tcp_transport SRCS/ESP-IDF/5.0/components/ulp SRCS/ESP-IDF/5.0/components/unity SRCS/ESP-IDF/5.0/components/usb SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_bmwi3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_boltev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_cadillac_c2_cts SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_chevrolet_c6_corvette SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_dbc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_demo SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_fiat500 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniq5 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniqvfl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_jaguaripace SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kianiroev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kiasoulev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mercedesb250e SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mgev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_minise SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mitsubishi SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_nissanleaf SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_none SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_obdii SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaulttwizy SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe_ph2_obd SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarted SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarteq SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodel3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodels SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslaroadster SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_thinkcity SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_toyotarav4ev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_track SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_voltampera SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_vweup SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_zeva SRCS/ESP-IDF/5.0/components/vfs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vfsedit SRCS/ESP-IDF/5.0/components/wear_levelling SRCS/ESP-IDF/5.0/components/wifi_provisioning SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl SRCS/ESP-IDF/5.0/components/wpa_supplicant SRCS/ESP-IDF/5.0/components/xtensa SRCS/OVMS-wt2/vehicle/OVMS.V3/components/zip -- Configuring done -- Generating done -- Build files have been written to: SRCS/OVMS-wt2/vehicle/OVMS.V3/build
So the next line that should have been printed, instead of the error, would have been:
-- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig
Could you check that your env variable `IDF_PATH` is pointing to the proper copy of ESP-IDF (v5 then) ? It's currently set to `/home/balzer/esp/esp-idf`.
(The main CMakeLists.txt includes `$ENV{IDF_PATH}/tools/cmake/project.cmake`)
The important env variables for ESP-IDF would be:
* CMAKE_COLOR_DIAGNOSTICS set to 1 to have beautiful error messages * ESPBAUD set to 921600 * ESPPORT set to your usb device (mine is /dev/cu.usbserial-0001) * ESP_IDF_VERSION (5.0 here) * IDF_PATH should be set to the proper 5.0 root * IDF_TOOLS_EXPORT_CMD on my installation is equivalent to $IDF_PATH/export.sh * IDF_TOOLS_INSTALL_CMD on my installation is equivalent to $IDF_PATH/install.sh * IDF_TOOLS_PATH should be set to proper 5.0 tools root * IDF_PYTHON_ENV_PATH on my installation is equivalent to $IDF_TOOLS_PATH/python_env/idf5.0_py3.10_env * OPENOCD_SCRIPTS on my installation is equivalent to $IDF_TOOLS_PATH/tools/openocd-esp32/v0.11.0-esp32-20221026/openocd-esp32/share/openocd/scripts and * PATH which should include a few occurrences of $IDF_PATH and $IDF_TOOLS_PATH
All of them should be automatically set it you have installed per the docs, and the fact that "hello_world" compiles is a good indicator that it was OK on your install , but double-checking is always interesting.
Let me know the result of your checks.
Regards,
Hi again, Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch. The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image. Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental... Then "idf.py build" should work - at least ! I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path) Then install dos2unix, launch menuconfig, then build. Tell me how it works for you. (You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it) Regards, Le 05/02/2023 à 20:37, Ludovic LANGE a écrit :
"idf" dependency, as expressed in (new file) `main/idf_component.yml`, is just ESP-IDF - this just checks that ESP-IDF is at minimum at version 5.0
This new file expresses the dependencies with new components (like a `requirements.txt` in Python, `Gemfile` in Ruby, `package.json` in JS, etc...), and they started to remove components from ESP-IDF and make them available as external components. `mdns` is such a component : https://components.espressif.com/components/espressif/mdns
So I'm not 100% convinced it's related - but in any case you could remove this file completely and see if it changes something (you wouldn't be able to compile `mdns`-related components, but still make some progress)
Could you share the 3 log files please ?
See also "/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/CMakeFiles/CMakeOutput.log". cmake failed with exit code 1, output of the command is in the /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stderr_output_8211 and /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/build/log/idf_py_stdout_output_8211 Regards,
Le 05/02/2023 à 16:43, Michael Balzer a écrit :
It's cmake version 3.20.4.
As I wrote, everything works with the example project "hello_world".
Apparently the error occurs while the builder checks the dependencies, specifically the "idf" dependency. Where does that originate from? "hello_world" does not need this.
The checked out version is your branch llange/experimental-esp-idf-v5.
Regards, Michael
Am 05.02.23 um 15:45 schrieb Ludovic LANGE:
Hi Michael,
Sorry to hear you have issues but very happy that you're trying to compile it ! We're going to solve those :-)
I don't use this command `idf.py set-target esp32` myself - but after trying it, it works as expected. (By the look of it, it says "Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old." so I would be careful not to use it too much as you loose your sdkconfig)
The only commands I'm using are:
* menuconfig (once in a while) * fullclean (while switching ESP-IDF version ; also doing `rm -rf build/`) * clean (if some changes have been made and not caught by cmake) * build (90% of the time) * app-flash * monitor
My versions of git / bison / flex are (for the record):
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0
...
-- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4")
(I also had success with bison 3.8.2 so not an issue)
and my cmake is : cmake version 3.25.2 and ninja is at version 1.11.1
I set a required version of cmake 3.16 in the main CMakeLists.txt, as recommended by ESP-IDF v5 instructions, but if it's the issue we can modify this. Could you please check your version and see if there is something to try here ?
During the `set-target esp32` run, my output is similar to yours but continues:
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options. Executing action: fullclean Executing action: set-target Set Target to: esp32, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old. Running cmake in directory SRCS/OVMS-wt2/vehicle/OVMS.V3/build Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32 -DCCACHE_ENABLE=0 SRCS/OVMS-wt2/vehicle/OVMS.V3"... CMake Warning (dev) at CMakeLists.txt:8 (message): WARNING - OVMSv3 build is only supported on ESP-IDF 3.3.x This warning is for project developers. Use -Wno-dev to suppress it.
-- Found Git: /usr/local/bin/git (found version "2.39.1") -- The C compiler identification is GNU 11.2.0 -- The CXX compiler identification is GNU 11.2.0 -- The ASM compiler identification is GNU -- Found assembler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working C compiler: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc - 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: SRCS/ESP-IDF-TOOLS/5.0/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-g++ - skipped -- Detecting CXX compile features -- Detecting CXX compile features - done -- Building ESP-IDF components for target esp32 Processing 2 dependencies: [1/2] espressif/mdns (1.0.7) [2/2] idf (5.0.0) -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig -- Looking for sys/types.h -- Looking for sys/types.h - found -- Looking for stdint.h -- Looking for stdint.h - found -- Looking for stddef.h -- Looking for stddef.h - found -- Check size of time_t -- Check size of time_t - done -- Found Python3: SRCS/ESP-IDF-TOOLS/5.0/python_env/idf5.0_py3.10_env/bin/python (found version "3.10.9") found components: Interpreter -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS -- Performing Test C_COMPILER_SUPPORTS_WFORMAT_SIGNEDNESS - Success -- App "ovms3" version: 3.3.003-316-gcb90ef8c-dirty -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/build/esp-idf/esp_system/ld/memory.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_system/ld/esp32/sections.ld.in -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.api.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.libgcc.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-data.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.syscalls.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/esp_rom/esp32/ld/esp32.rom.newlib-funcs.ld -- Adding linker script SRCS/ESP-IDF/5.0/components/soc/esp32/ld/esp32.peripherals.ld -- Adding linker script SRCS/OVMS-wt2/vehicle/OVMS.V3/main/ovms_boot.ld -- wolfssl : EXCLUDE_ASM = SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/aes_gcm_x86_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/chacha_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/fe_x25519_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/poly1305_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-aes-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha256-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-32-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-curve25519.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha3-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/port/arm/armv8-sha512-asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha256_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha3_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sha512_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/sp_x86_64_asm.S;SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfcrypt/src/wc_kyber_asm.S -- Found BISON: /usr/bin/bison (found version "2.3") -- Found FLEX: /usr/bin/flex (found version "2.6.4") -- Found Perl: /usr/local/bin/perl (found version "5.36.0") -- IDF Version: 5.0.0 - NOT enabling strverscmp -- Component idf::main will be linked with -Wl,--whole-archive -- Component idf::pcp will be linked with -Wl,--whole-archive -- Component idf::ovms_buffer will be linked with -Wl,--whole-archive -- Component idf::can will be linked with -Wl,--whole-archive -- Component idf::canopen will be linked with -Wl,--whole-archive -- Component idf::wolfssl will be linked with -Wl,--whole-archive -- Component idf::console_ssh will be linked with -Wl,--whole-archive -- Component idf::console_telnet will be linked with -Wl,--whole-archive -- Component idf::crypto will be linked with -Wl,--whole-archive -- Component idf::dbc will be linked with -Wl,--whole-archive -- Component idf::esp32adc will be linked with -Wl,--whole-archive -- Component idf::esp32bluetooth will be linked with -Wl,--whole-archive -- Component idf::esp32can will be linked with -Wl,--whole-archive -- Component idf::esp32system will be linked with -Wl,--whole-archive -- Component idf::esp32wifi will be linked with -Wl,--whole-archive -- Component idf::ext12v will be linked with -Wl,--whole-archive -- Component idf::max7317 will be linked with -Wl,--whole-archive -- Component idf::mcp2515 will be linked with -Wl,--whole-archive -- Component idf::microrl will be linked with -Wl,--whole-archive -- Component idf::obd2ecu will be linked with -Wl,--whole-archive -- Component idf::ovms_http will be linked with -Wl,--whole-archive -- Component idf::ovms_location will be linked with -Wl,--whole-archive -- Component idf::ovms_mdns will be linked with -Wl,--whole-archive -- Component idf::ovms_netlib will be linked with -Wl,--whole-archive -- Component idf::ovms_ota will be linked with -Wl,--whole-archive -- Component idf::pushover will be linked with -Wl,--whole-archive -- Component idf::ovms_webserver will be linked with -Wl,--whole-archive -- Component idf::ovms_plugins will be linked with -Wl,--whole-archive -- Component idf::ovms_tls will be linked with -Wl,--whole-archive -- Component idf::ovms_script will be linked with -Wl,--whole-archive -- Component idf::ovms_server will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v2 will be linked with -Wl,--whole-archive -- Component idf::ovms_server_v3 will be linked with -Wl,--whole-archive -- Component idf::ovms_tpms will be linked with -Wl,--whole-archive -- Component idf::powermgmt will be linked with -Wl,--whole-archive -- Component idf::retools will be linked with -Wl,--whole-archive -- Component idf::retools_pidscan will be linked with -Wl,--whole-archive -- Component idf::retools_testerpresent will be linked with -Wl,--whole-archive -- Component idf::sdcard will be linked with -Wl,--whole-archive -- Component idf::simcom will be linked with -Wl,--whole-archive -- Component idf::spi will be linked with -Wl,--whole-archive -- Component idf::strverscmp will be linked with -Wl,--whole-archive -- Component idf::swcan will be linked with -Wl,--whole-archive -- Component idf::vehicle will be linked with -Wl,--whole-archive -- Component idf::vehicle_bmwi3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_boltev will be linked with -Wl,--whole-archive -- Component idf::vehicle_cadillac_c2_cts will be linked with -Wl,--whole-archive -- Component idf::vehicle_chevrolet_c6_corvette will be linked with -Wl,--whole-archive -- Component idf::vehicle_dbc will be linked with -Wl,--whole-archive -- Component idf::vehicle_demo will be linked with -Wl,--whole-archive -- Component idf::vehicle_fiat500 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniq5 will be linked with -Wl,--whole-archive -- Component idf::vehicle_hyundai_ioniqvfl will be linked with -Wl,--whole-archive -- Component idf::vehicle_jaguaripace will be linked with -Wl,--whole-archive -- Component idf::vehicle_kianiroev will be linked with -Wl,--whole-archive -- Component idf::vehicle_kiasoulev will be linked with -Wl,--whole-archive -- Component idf::vehicle_maxus_edeliver3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_mercedesb250e will be linked with -Wl,--whole-archive -- Component idf::vehicle_mgev will be linked with -Wl,--whole-archive -- Component idf::vehicle_minise will be linked with -Wl,--whole-archive -- Component idf::vehicle_mitsubishi will be linked with -Wl,--whole-archive -- Component idf::vehicle_nissanleaf will be linked with -Wl,--whole-archive -- Component idf::vehicle_none will be linked with -Wl,--whole-archive -- Component idf::vehicle_obdii will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaulttwizy will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe will be linked with -Wl,--whole-archive -- Component idf::vehicle_renaultzoe_ph2_obd will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarted will be linked with -Wl,--whole-archive -- Component idf::vehicle_smarteq will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodel3 will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslamodels will be linked with -Wl,--whole-archive -- Component idf::vehicle_teslaroadster will be linked with -Wl,--whole-archive -- Component idf::vehicle_thinkcity will be linked with -Wl,--whole-archive -- Component idf::vehicle_toyotarav4ev will be linked with -Wl,--whole-archive -- Component idf::vehicle_track will be linked with -Wl,--whole-archive -- Component idf::vehicle_voltampera will be linked with -Wl,--whole-archive -- Component idf::vehicle_vweup will be linked with -Wl,--whole-archive -- Component idf::vehicle_zeva will be linked with -Wl,--whole-archive -- Component idf::vfsedit will be linked with -Wl,--whole-archive -- Component idf::zip will be linked with -Wl,--whole-archive -- Components: app_trace app_update bootloader bootloader_support bt can canopen cmock console console_ssh console_telnet crypto cxx dbc driver duktape efuse esp-tls esp32adc esp32bluetooth esp32can esp32system esp32wifi esp_adc esp_app_format esp_common esp_eth esp_event esp_gdbstub esp_hid esp_http_client esp_http_server esp_https_ota esp_https_server esp_hw_support esp_lcd esp_local_ctrl esp_netif esp_partition esp_phy esp_pm esp_psram esp_ringbuf esp_rom esp_system esp_timer esp_wifi espcoredump espressif__mdns esptool_py ext12v fatfs freertos hal heap http_parser idf_test ieee802154 json libtelnet log lwip main max7317 mbedtls mcp2515 microrl mongoose mqtt newlib nvs_flash obd2ecu openthread ovms_buffer ovms_cellular ovms_http ovms_location ovms_mdns ovms_netlib ovms_ota ovms_plugins ovms_script ovms_server ovms_server_v2 ovms_server_v3 ovms_tls ovms_tpms ovms_webserver partition_table pcp perfmon powermgmt protobuf-c protocomm pthread pushover retools retools_pidscan retools_testerpresent sdcard sdmmc simcom soc spi spi_flash spiffs strverscmp swcan tcp_transport ulp unity usb vehicle vehicle_bmwi3 vehicle_boltev vehicle_cadillac_c2_cts vehicle_chevrolet_c6_corvette vehicle_dbc vehicle_demo vehicle_fiat500 vehicle_hyundai_ioniq5 vehicle_hyundai_ioniqvfl vehicle_jaguaripace vehicle_kianiroev vehicle_kiasoulev vehicle_maxus_edeliver3 vehicle_mercedesb250e vehicle_mgev vehicle_minise vehicle_mitsubishi vehicle_nissanleaf vehicle_none vehicle_obdii vehicle_renaulttwizy vehicle_renaultzoe vehicle_renaultzoe_ph2_obd vehicle_smarted vehicle_smarteq vehicle_teslamodel3 vehicle_teslamodels vehicle_teslaroadster vehicle_thinkcity vehicle_toyotarav4ev vehicle_track vehicle_voltampera vehicle_vweup vehicle_zeva vfs vfsedit wear_levelling wifi_provisioning wolfssh wolfssl wpa_supplicant xtensa zip -- Component paths: SRCS/ESP-IDF/5.0/components/app_trace SRCS/ESP-IDF/5.0/components/app_update SRCS/ESP-IDF/5.0/components/bootloader SRCS/ESP-IDF/5.0/components/bootloader_support SRCS/ESP-IDF/5.0/components/bt SRCS/OVMS-wt2/vehicle/OVMS.V3/components/can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/canopen SRCS/ESP-IDF/5.0/components/cmock SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_ssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/console_telnet SRCS/OVMS-wt2/vehicle/OVMS.V3/components/crypto SRCS/ESP-IDF/5.0/components/cxx SRCS/OVMS-wt2/vehicle/OVMS.V3/components/dbc SRCS/ESP-IDF/5.0/components/driver SRCS/OVMS-wt2/vehicle/OVMS.V3/components/duktape SRCS/ESP-IDF/5.0/components/efuse SRCS/ESP-IDF/5.0/components/esp-tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32adc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32bluetooth SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32can SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32system SRCS/OVMS-wt2/vehicle/OVMS.V3/components/esp32wifi SRCS/ESP-IDF/5.0/components/esp_adc SRCS/ESP-IDF/5.0/components/esp_app_format SRCS/ESP-IDF/5.0/components/esp_common SRCS/ESP-IDF/5.0/components/esp_eth SRCS/ESP-IDF/5.0/components/esp_event SRCS/ESP-IDF/5.0/components/esp_gdbstub SRCS/ESP-IDF/5.0/components/esp_hid SRCS/ESP-IDF/5.0/components/esp_http_client SRCS/ESP-IDF/5.0/components/esp_http_server SRCS/ESP-IDF/5.0/components/esp_https_ota SRCS/ESP-IDF/5.0/components/esp_https_server SRCS/ESP-IDF/5.0/components/esp_hw_support SRCS/ESP-IDF/5.0/components/esp_lcd SRCS/ESP-IDF/5.0/components/esp_local_ctrl SRCS/ESP-IDF/5.0/components/esp_netif SRCS/ESP-IDF/5.0/components/esp_partition SRCS/ESP-IDF/5.0/components/esp_phy SRCS/ESP-IDF/5.0/components/esp_pm SRCS/ESP-IDF/5.0/components/esp_psram SRCS/ESP-IDF/5.0/components/esp_ringbuf SRCS/ESP-IDF/5.0/components/esp_rom SRCS/ESP-IDF/5.0/components/esp_system SRCS/ESP-IDF/5.0/components/esp_timer SRCS/ESP-IDF/5.0/components/esp_wifi SRCS/ESP-IDF/5.0/components/espcoredump SRCS/OVMS-wt2/vehicle/OVMS.V3/managed_components/espressif__mdns SRCS/ESP-IDF/5.0/components/esptool_py SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ext12v SRCS/ESP-IDF/5.0/components/fatfs SRCS/ESP-IDF/5.0/components/freertos SRCS/ESP-IDF/5.0/components/hal SRCS/ESP-IDF/5.0/components/heap SRCS/ESP-IDF/5.0/components/http_parser SRCS/ESP-IDF/5.0/components/idf_test SRCS/ESP-IDF/5.0/components/ieee802154 SRCS/ESP-IDF/5.0/components/json SRCS/OVMS-wt2/vehicle/OVMS.V3/components/libtelnet SRCS/ESP-IDF/5.0/components/log SRCS/ESP-IDF/5.0/components/lwip SRCS/OVMS-wt2/vehicle/OVMS.V3/main SRCS/OVMS-wt2/vehicle/OVMS.V3/components/max7317 SRCS/ESP-IDF/5.0/components/mbedtls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mcp2515 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/microrl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/mongoose SRCS/ESP-IDF/5.0/components/mqtt SRCS/ESP-IDF/5.0/components/newlib SRCS/ESP-IDF/5.0/components/nvs_flash SRCS/OVMS-wt2/vehicle/OVMS.V3/components/obd2ecu SRCS/ESP-IDF/5.0/components/openthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_buffer SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_cellular SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_http SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_location SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_mdns SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_netlib SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_ota SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_plugins SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_script SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v2 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_server_v3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tls SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_tpms SRCS/OVMS-wt2/vehicle/OVMS.V3/components/ovms_webserver SRCS/ESP-IDF/5.0/components/partition_table SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pcp SRCS/ESP-IDF/5.0/components/perfmon SRCS/OVMS-wt2/vehicle/OVMS.V3/components/powermgmt SRCS/ESP-IDF/5.0/components/protobuf-c SRCS/ESP-IDF/5.0/components/protocomm SRCS/ESP-IDF/5.0/components/pthread SRCS/OVMS-wt2/vehicle/OVMS.V3/components/pushover SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_pidscan SRCS/OVMS-wt2/vehicle/OVMS.V3/components/retools_testerpresent SRCS/OVMS-wt2/vehicle/OVMS.V3/components/sdcard SRCS/ESP-IDF/5.0/components/sdmmc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/simcom SRCS/ESP-IDF/5.0/components/soc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/spi SRCS/ESP-IDF/5.0/components/spi_flash SRCS/ESP-IDF/5.0/components/spiffs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/strverscmp SRCS/OVMS-wt2/vehicle/OVMS.V3/components/swcan SRCS/ESP-IDF/5.0/components/tcp_transport SRCS/ESP-IDF/5.0/components/ulp SRCS/ESP-IDF/5.0/components/unity SRCS/ESP-IDF/5.0/components/usb SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_bmwi3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_boltev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_cadillac_c2_cts SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_chevrolet_c6_corvette SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_dbc SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_demo SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_fiat500 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniq5 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_hyundai_ioniqvfl SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_jaguaripace SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kianiroev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_kiasoulev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_maxus_edeliver3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mercedesb250e SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mgev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_minise SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_mitsubishi SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_nissanleaf SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_none SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_obdii SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaulttwizy SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_renaultzoe_ph2_obd SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarted SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_smarteq SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodel3 SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslamodels SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_teslaroadster SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_thinkcity SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_toyotarav4ev SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_track SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_voltampera SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_vweup SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vehicle_zeva SRCS/ESP-IDF/5.0/components/vfs SRCS/OVMS-wt2/vehicle/OVMS.V3/components/vfsedit SRCS/ESP-IDF/5.0/components/wear_levelling SRCS/ESP-IDF/5.0/components/wifi_provisioning SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssh SRCS/OVMS-wt2/vehicle/OVMS.V3/components/wolfssl SRCS/ESP-IDF/5.0/components/wpa_supplicant SRCS/ESP-IDF/5.0/components/xtensa SRCS/OVMS-wt2/vehicle/OVMS.V3/components/zip -- Configuring done -- Generating done -- Build files have been written to: SRCS/OVMS-wt2/vehicle/OVMS.V3/build
So the next line that should have been printed, instead of the error, would have been:
-- Project sdkconfig file SRCS/OVMS-wt2/vehicle/OVMS.V3/sdkconfig
Could you check that your env variable `IDF_PATH` is pointing to the proper copy of ESP-IDF (v5 then) ? It's currently set to `/home/balzer/esp/esp-idf`.
(The main CMakeLists.txt includes `$ENV{IDF_PATH}/tools/cmake/project.cmake`)
The important env variables for ESP-IDF would be:
* CMAKE_COLOR_DIAGNOSTICS set to 1 to have beautiful error messages * ESPBAUD set to 921600 * ESPPORT set to your usb device (mine is /dev/cu.usbserial-0001) * ESP_IDF_VERSION (5.0 here) * IDF_PATH should be set to the proper 5.0 root * IDF_TOOLS_EXPORT_CMD on my installation is equivalent to $IDF_PATH/export.sh * IDF_TOOLS_INSTALL_CMD on my installation is equivalent to $IDF_PATH/install.sh * IDF_TOOLS_PATH should be set to proper 5.0 tools root * IDF_PYTHON_ENV_PATH on my installation is equivalent to $IDF_TOOLS_PATH/python_env/idf5.0_py3.10_env * OPENOCD_SCRIPTS on my installation is equivalent to $IDF_TOOLS_PATH/tools/openocd-esp32/v0.11.0-esp32-20221026/openocd-esp32/share/openocd/scripts and * PATH which should include a few occurrences of $IDF_PATH and $IDF_TOOLS_PATH
All of them should be automatically set it you have installed per the docs, and the fact that "hello_world" compiles is a good indicator that it was OK on your install , but double-checking is always interesting.
Let me know the result of your checks.
Regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Hi, Just as a curiosity, I setup GitHub to build the v5 branch with "GitHub actions". You can find the latest runs here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions The configuration file is here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental... /Note: It's a specific branch because I had to add some configuration files (default sdkconfig options for example), change the reference to wolfssl submodule, add a patch for our mongoose version, ... ; but in the future I could make a PR for this feature if we find it useful./ /(I also would like to experiment a little bit with static code analysis, unit tests, etc...)/ Regards, Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
Hi again,
Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch.
The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image.
Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
Then "idf.py build" should work - at least !
I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path)
Then install dos2unix, launch menuconfig, then build.
Tell me how it works for you.
(You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it)
Regards,
Ludovic, using the docker image I managed to make some progress. I can now start the build process, but then run into printf format errors on main/ovms_module.cpp, e.g. /project/main/ovms_module.cpp: In function 'void print_blocks(OvmsWriter*, TaskHandle_t, bool)': /project/main/ovms_module.cpp:438:37: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=] I'm here: commit 19e36125c6e0597c901eb82a546ef82c1dea8a1e (HEAD -> experimental-esp-idf-v5, llange/experimental-esp-idf-v5) Author: Ludovic LANGE <llange@users.noreply.github.com> I thought maybe you've sorted that out in your new build branch, but apparently that has the same error, which leaves me wondering how the automated build can work… I see you don't have CONFIG_FREERTOS_USE_TRACE_FACILITY in your new "sdkconfig.defaults.esp5", so the module isn't included in your build. But you also have CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y, which automatically enables CONFIG_FREERTOS_USE_TRACE_FACILITY in my setup. Disabling both options, I just almost got through, just a final linker error: /project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac' I assume there are more differences in your new branch / sdkconfig, I'll try that one next. Regards, Michael Am 10.02.23 um 09:37 schrieb Ludovic LANGE:
Hi,
Just as a curiosity, I setup GitHub to build the v5 branch with "GitHub actions".
You can find the latest runs here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
The configuration file is here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
/Note: It's a specific branch because I had to add some configuration files (default sdkconfig options for example), change the reference to wolfssl submodule, add a patch for our mongoose version, ... ; but in the future I could make a PR for this feature if we find it useful./ /(I also would like to experiment a little bit with static code analysis, unit tests, etc...)/
Regards,
Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
Hi again,
Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch.
The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image.
Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
Then "idf.py build" should work - at least !
I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path)
Then install dos2unix, launch menuconfig, then build.
Tell me how it works for you.
(You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it)
Regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, I'm sorry to read that you're facing those issues. It's almost certain that my sdkconfig, after being changed back and forth to disable certain modules that would not compile, is now not in a "pristine" state, and that's certainly why your build and mine do not activate the same compilation paths. I'll be interested in getting your sdkconfig file to see what is left to fix to have it properly compile. (In the meantime I have forced the compilation of this part of the module, fixed the compilation errors you were likely to have, and force-pushed those fixes on the 2 branches experimental-esp-idf-v5 and experimental-esp-idf-build-workflow) Regarding the linking error, I'm not sure why you have it, as it's looks like it is part of the mbedtls of ESP-IDF 5.0 - I'll see if I can reproduce it when I have your sdkconfig. Regards, Ludovic Le 17/02/2023 à 22:54, Michael Balzer a écrit :
Ludovic,
using the docker image I managed to make some progress.
I can now start the build process, but then run into printf format errors on main/ovms_module.cpp, e.g.
/project/main/ovms_module.cpp: In function 'void print_blocks(OvmsWriter*, TaskHandle_t, bool)': /project/main/ovms_module.cpp:438:37: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
I'm here:
commit 19e36125c6e0597c901eb82a546ef82c1dea8a1e (HEAD -> experimental-esp-idf-v5, llange/experimental-esp-idf-v5) Author: Ludovic LANGE <llange@users.noreply.github.com>
I thought maybe you've sorted that out in your new build branch, but apparently that has the same error, which leaves me wondering how the automated build can work…
I see you don't have CONFIG_FREERTOS_USE_TRACE_FACILITY in your new "sdkconfig.defaults.esp5", so the module isn't included in your build. But you also have CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y, which automatically enables CONFIG_FREERTOS_USE_TRACE_FACILITY in my setup.
Disabling both options, I just almost got through, just a final linker error:
/project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac'
I assume there are more differences in your new branch / sdkconfig, I'll try that one next.
Regards, Michael
Am 10.02.23 um 09:37 schrieb Ludovic LANGE:
Hi,
Just as a curiosity, I setup GitHub to build the v5 branch with "GitHub actions".
You can find the latest runs here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
The configuration file is here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
/Note: It's a specific branch because I had to add some configuration files (default sdkconfig options for example), change the reference to wolfssl submodule, add a patch for our mongoose version, ... ; but in the future I could make a PR for this feature if we find it useful./ /(I also would like to experiment a little bit with static code analysis, unit tests, etc...)/
Regards,
Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
Hi again,
Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch.
The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image.
Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
Then "idf.py build" should work - at least !
I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path)
Then install dos2unix, launch menuconfig, then build.
Tell me how it works for you.
(You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it)
Regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Ludovic, the issue is bound to the docker image version, I was using "espressif/idf", which is "latest". The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image). So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action: ### SETUP ### cd ~/esp/Open-Vehicle-Monitoring-System-3 # setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow # switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive # apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch # install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults # install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml ### BUILD ### cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3 # launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix # OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds # OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL # build: idf.py build # flash & start USB monitor: idf.py app-flash && idf.py monitor The build boots & works, issues you described excluded. An issue I didn't expect: I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized …and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging. But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic! Regards, Michael Am 18.02.23 um 00:53 schrieb Ludovic LANGE:
Hi Michael,
I'm sorry to read that you're facing those issues.
It's almost certain that my sdkconfig, after being changed back and forth to disable certain modules that would not compile, is now not in a "pristine" state, and that's certainly why your build and mine do not activate the same compilation paths.
I'll be interested in getting your sdkconfig file to see what is left to fix to have it properly compile.
(In the meantime I have forced the compilation of this part of the module, fixed the compilation errors you were likely to have, and force-pushed those fixes on the 2 branches experimental-esp-idf-v5 and experimental-esp-idf-build-workflow)
Regarding the linking error, I'm not sure why you have it, as it's looks like it is part of the mbedtls of ESP-IDF 5.0 - I'll see if I can reproduce it when I have your sdkconfig.
Regards,
Ludovic
Le 17/02/2023 à 22:54, Michael Balzer a écrit :
Ludovic,
using the docker image I managed to make some progress.
I can now start the build process, but then run into printf format errors on main/ovms_module.cpp, e.g.
/project/main/ovms_module.cpp: In function 'void print_blocks(OvmsWriter*, TaskHandle_t, bool)': /project/main/ovms_module.cpp:438:37: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
I'm here:
commit 19e36125c6e0597c901eb82a546ef82c1dea8a1e (HEAD -> experimental-esp-idf-v5, llange/experimental-esp-idf-v5) Author: Ludovic LANGE <llange@users.noreply.github.com>
I thought maybe you've sorted that out in your new build branch, but apparently that has the same error, which leaves me wondering how the automated build can work…
I see you don't have CONFIG_FREERTOS_USE_TRACE_FACILITY in your new "sdkconfig.defaults.esp5", so the module isn't included in your build. But you also have CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y, which automatically enables CONFIG_FREERTOS_USE_TRACE_FACILITY in my setup.
Disabling both options, I just almost got through, just a final linker error:
/project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac'
I assume there are more differences in your new branch / sdkconfig, I'll try that one next.
Regards, Michael
Am 10.02.23 um 09:37 schrieb Ludovic LANGE:
Hi,
Just as a curiosity, I setup GitHub to build the v5 branch with "GitHub actions".
You can find the latest runs here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
The configuration file is here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
/Note: It's a specific branch because I had to add some configuration files (default sdkconfig options for example), change the reference to wolfssl submodule, add a patch for our mongoose version, ... ; but in the future I could make a PR for this feature if we find it useful./ /(I also would like to experiment a little bit with static code analysis, unit tests, etc...)/
Regards,
Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
Hi again,
Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch.
The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image.
Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
Then "idf.py build" should work - at least !
I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path)
Then install dos2unix, launch menuconfig, then build.
Tell me how it works for you.
(You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it)
Regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Doing the watchdog init ourselves avoids the issue. To do so, we need to change line 38 in ovms_main to… #if !CONFIG_ESP_TASK_WDT_INIT …and disable that config option. Regards, Michael Am 18.02.23 um 10:12 schrieb Michael Balzer:
Ludovic,
the issue is bound to the docker image version, I was using "espressif/idf", which is "latest".
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action:
### SETUP ###
cd ~/esp/Open-Vehicle-Monitoring-System-3
# setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow
# switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive
# apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch
# install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults
# install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml
### BUILD ###
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
# launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix
# OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds
# OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL
# build: idf.py build
# flash & start USB monitor: idf.py app-flash && idf.py monitor
The build boots & works, issues you described excluded.
An issue I didn't expect:
I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found
I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging.
But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic!
Regards, Michael
Am 18.02.23 um 00:53 schrieb Ludovic LANGE:
Hi Michael,
I'm sorry to read that you're facing those issues.
It's almost certain that my sdkconfig, after being changed back and forth to disable certain modules that would not compile, is now not in a "pristine" state, and that's certainly why your build and mine do not activate the same compilation paths.
I'll be interested in getting your sdkconfig file to see what is left to fix to have it properly compile.
(In the meantime I have forced the compilation of this part of the module, fixed the compilation errors you were likely to have, and force-pushed those fixes on the 2 branches experimental-esp-idf-v5 and experimental-esp-idf-build-workflow)
Regarding the linking error, I'm not sure why you have it, as it's looks like it is part of the mbedtls of ESP-IDF 5.0 - I'll see if I can reproduce it when I have your sdkconfig.
Regards,
Ludovic
Le 17/02/2023 à 22:54, Michael Balzer a écrit :
Ludovic,
using the docker image I managed to make some progress.
I can now start the build process, but then run into printf format errors on main/ovms_module.cpp, e.g.
/project/main/ovms_module.cpp: In function 'void print_blocks(OvmsWriter*, TaskHandle_t, bool)': /project/main/ovms_module.cpp:438:37: error: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Werror=format=]
I'm here:
commit 19e36125c6e0597c901eb82a546ef82c1dea8a1e (HEAD -> experimental-esp-idf-v5, llange/experimental-esp-idf-v5) Author: Ludovic LANGE <llange@users.noreply.github.com>
I thought maybe you've sorted that out in your new build branch, but apparently that has the same error, which leaves me wondering how the automated build can work…
I see you don't have CONFIG_FREERTOS_USE_TRACE_FACILITY in your new "sdkconfig.defaults.esp5", so the module isn't included in your build. But you also have CONFIG_FREERTOS_GENERATE_RUN_TIME_STATS=y, which automatically enables CONFIG_FREERTOS_USE_TRACE_FACILITY in my setup.
Disabling both options, I just almost got through, just a final linker error:
/project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac'
I assume there are more differences in your new branch / sdkconfig, I'll try that one next.
Regards, Michael
Am 10.02.23 um 09:37 schrieb Ludovic LANGE:
Hi,
Just as a curiosity, I setup GitHub to build the v5 branch with "GitHub actions".
You can find the latest runs here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/actions
The configuration file is here : https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
/Note: It's a specific branch because I had to add some configuration files (default sdkconfig options for example), change the reference to wolfssl submodule, add a patch for our mongoose version, ... ; but in the future I could make a PR for this feature if we find it useful./ /(I also would like to experiment a little bit with static code analysis, unit tests, etc...)/
Regards,
Le 06/02/2023 à 15:23, Ludovic LANGE a écrit :
Hi again,
Additionally, I've just verified that the official docker image for ESP-IDF (doc: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools... ) is able to build the branch.
The only thing to add to the image is the "dos2unix" utility ("apt update && apt-get install dos2unix"), after that you'll be able to build the image.
Do not forget to update your sdkconfig (enabling FreeRTOS compatibility and unchecking SSL for mongoose) before building, and to do the patches for mongoose / wolfssl as described here: https://github.com/llange/Open-Vehicle-Monitoring-System-3/blob/experimental...
Then "idf.py build" should work - at least !
I've used the `docker run --rm -v $PWD:/project -w /project -it espressif/idf:|release-v5.0|` command to have a shell prompt (launch that in your source file path)
Then install dos2unix, launch menuconfig, then build.
Tell me how it works for you.
(You may have some component build failure ; depending on the sdkconfig flags, I'm still trying to document it)
Regards,
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, Hi list, Thanks Michael for having taken the time to reproduce the build, and thus making this branch go from the state of "urban legend" to "has been confirmed at least once" :-) I hope more of you will be able to follow the instructions of Michael, that are very clear and should ease your work when wanting to test this branch. Ideally, I wanted that some of you having both the time (...) and a vehicle to test would be able to use this build as a daily driver, hoping that the known missing parts would not be a showstopper. Let me know, and also if you have some spare cycles you can check https://github.com/wolfSSL/wolfssl/issues/6028 in order to help fix some remaining issues on this library we depend on. In the meantime, I believe we can try to integrate (part of) this branch in master. I already started to distillate some parts of this in multiples MRs here https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... ; which could be merged without -I hope, but the review will confirm- any impact nor regression to the current master branch. Let me know if I should continue in that direction, and sorry for sounding impatient about it :-) Regards, Le 18/02/2023 à 10:12, Michael Balzer a écrit :
Ludovic,
the issue is bound to the docker image version, I was using "espressif/idf", which is "latest".
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action:
### SETUP ###
cd ~/esp/Open-Vehicle-Monitoring-System-3
# setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow
# switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive
# apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch
# install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults
# install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml
### BUILD ###
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
# launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix
# OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds
# OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL
# build: idf.py build
# flash & start USB monitor: idf.py app-flash && idf.py monitor
The build boots & works, issues you described excluded.
An issue I didn't expect:
I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found
I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging.
But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic!
Regards, Michael
Ludovic, you're totally right being impatient, sorry for the delay. My spare time is currently rare, but I've at least now merged your bug & compatibility fixes so far. Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5? We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition. Adding IDF version switches to all code sections that need differentiation may introduce some additional points of failure, but also makes identifying the idf5 rework sections easy. I haven't come to a final opinion on this, but I tend to merging this into the master as you suggest, once we know it doesn't impact idf3 compatibility. The idf5 build branch does not yet build using idf3, currently failing with a wolfssl issue: In file included from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/sha256.h:96:0, from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:52: /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/port/Espressif/esp32-crypt.h:30:24: fatal error: esp_random.h: No such file or directory Regards, Michael Am 19.02.23 um 16:29 schrieb Ludovic LANGE:
Hi Michael, Hi list,
Thanks Michael for having taken the time to reproduce the build, and thus making this branch go from the state of "urban legend" to "has been confirmed at least once" :-)
I hope more of you will be able to follow the instructions of Michael, that are very clear and should ease your work when wanting to test this branch.
Ideally, I wanted that some of you having both the time (...) and a vehicle to test would be able to use this build as a daily driver, hoping that the known missing parts would not be a showstopper. Let me know, and also if you have some spare cycles you can check https://github.com/wolfSSL/wolfssl/issues/6028 in order to help fix some remaining issues on this library we depend on.
In the meantime, I believe we can try to integrate (part of) this branch in master. I already started to distillate some parts of this in multiples MRs here https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... ; which could be merged without -I hope, but the review will confirm- any impact nor regression to the current master branch.
Let me know if I should continue in that direction, and sorry for sounding impatient about it :-)
Regards,
Le 18/02/2023 à 10:12, Michael Balzer a écrit :
Ludovic,
the issue is bound to the docker image version, I was using "espressif/idf", which is "latest".
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action:
### SETUP ###
cd ~/esp/Open-Vehicle-Monitoring-System-3
# setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow
# switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive
# apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch
# install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults
# install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml
### BUILD ###
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
# launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix
# OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds
# OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL
# build: idf.py build
# flash & start USB monitor: idf.py app-flash && idf.py monitor
The build boots & works, issues you described excluded.
An issue I didn't expect:
I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found
I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging.
But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Michael, Thanks for the merges, and for your precious spare time (unfortunately, same issue here :-)) I do not have any preference for or agains wolfSSL nor mbedTLS ; just my lack of knowledge of the project history, and the fact that the component was there and failed to compile had me take a few steps to make it work. If the preference is to use mbedTLS, so be it ; may be we should completely remove wolfSSL in the future then ? Regarding the integration, I understand the pros / cons of each one. I'd be tempted to push the "small patches with #ifdef" approach as far as possible, because I believe it'll make the review process easier and help us to confirm that there are no regression / impact. Also, I believe that "fixing" all those warnings, etc... will lead contributors to produce code that will respect those more strict compiler settings in idf4 and 5. There are however bigger changes on the road (thinking about the deprecation of TCP/IP Adapter replaced with ESP-NETIF ; which can also co-exist with idf3) which may need us to make such a decision. If you're not opposed, I'll try to continue the "small patches" dance on github, with (of course !) no obligation to merge. Let the review happen, and if a PR is not merged it won't be an issue - we will discuss the best way to do it. I'll try to make all the changes as independent as possible, sometime a rebase will be needed but we may be able to reduce the gap this way. Regards, Ludovic Le 19/02/2023 à 21:15, Michael Balzer a écrit :
Ludovic,
you're totally right being impatient, sorry for the delay. My spare time is currently rare, but I've at least now merged your bug & compatibility fixes so far.
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition. Adding IDF version switches to all code sections that need differentiation may introduce some additional points of failure, but also makes identifying the idf5 rework sections easy. I haven't come to a final opinion on this, but I tend to merging this into the master as you suggest, once we know it doesn't impact idf3 compatibility.
The idf5 build branch does not yet build using idf3, currently failing with a wolfssl issue:
In file included from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/sha256.h:96:0, from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:52: /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/port/Espressif/esp32-crypt.h:30:24: fatal error: esp_random.h: No such file or directory
Regards, Michael
Am 19.02.23 um 16:29 schrieb Ludovic LANGE:
Hi Michael, Hi list,
Thanks Michael for having taken the time to reproduce the build, and thus making this branch go from the state of "urban legend" to "has been confirmed at least once" :-)
I hope more of you will be able to follow the instructions of Michael, that are very clear and should ease your work when wanting to test this branch.
Ideally, I wanted that some of you having both the time (...) and a vehicle to test would be able to use this build as a daily driver, hoping that the known missing parts would not be a showstopper. Let me know, and also if you have some spare cycles you can check https://github.com/wolfSSL/wolfssl/issues/6028 in order to help fix some remaining issues on this library we depend on.
In the meantime, I believe we can try to integrate (part of) this branch in master. I already started to distillate some parts of this in multiples MRs here https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... ; which could be merged without -I hope, but the review will confirm- any impact nor regression to the current master branch.
Let me know if I should continue in that direction, and sorry for sounding impatient about it :-)
Regards,
Le 18/02/2023 à 10:12, Michael Balzer a écrit :
Ludovic,
the issue is bound to the docker image version, I was using "espressif/idf", which is "latest".
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action:
### SETUP ###
cd ~/esp/Open-Vehicle-Monitoring-System-3
# setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow
# switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive
# apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch
# install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults
# install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml
### BUILD ###
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
# launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix
# OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds
# OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL
# build: idf.py build
# flash & start USB monitor: idf.py app-flash && idf.py monitor
The build boots & works, issues you described excluded.
An issue I didn't expect:
I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found
I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging.
But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Michael, Ludovic,
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
My memory was that wolfssh required wolfssl? But I may be mistaken.
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition.
If this can cleanly be applied to the existing work, to allow building under either v3 or v5 IDF, that would be ideal. IMHO, the separate branch would only be required if the changes were very extensive and breaking to v3. Regards, Mark.
On 20 Feb 2023, at 4:15 AM, Michael Balzer <dexter@expeedo.de> wrote:
Signed PGP part Ludovic,
you're totally right being impatient, sorry for the delay. My spare time is currently rare, but I've at least now merged your bug & compatibility fixes so far.
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition. Adding IDF version switches to all code sections that need differentiation may introduce some additional points of failure, but also makes identifying the idf5 rework sections easy. I haven't come to a final opinion on this, but I tend to merging this into the master as you suggest, once we know it doesn't impact idf3 compatibility.
The idf5 build branch does not yet build using idf3, currently failing with a wolfssl issue:
In file included from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/sha256.h:96:0, from /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:52: /home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/port/Espressif/esp32-crypt.h:30:24: fatal error: esp_random.h: No such file or directory
Regards, Michael
Am 19.02.23 um 16:29 schrieb Ludovic LANGE:
Hi Michael, Hi list,
Thanks Michael for having taken the time to reproduce the build, and thus making this branch go from the state of "urban legend" to "has been confirmed at least once" :-)
I hope more of you will be able to follow the instructions of Michael, that are very clear and should ease your work when wanting to test this branch.
Ideally, I wanted that some of you having both the time (...) and a vehicle to test would be able to use this build as a daily driver, hoping that the known missing parts would not be a showstopper. Let me know, and also if you have some spare cycles you can check https://github.com/wolfSSL/wolfssl/issues/6028 in order to help fix some remaining issues on this library we depend on.
In the meantime, I believe we can try to integrate (part of) this branch in master. I already started to distillate some parts of this in multiples MRs here https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... ; which could be merged without -I hope, but the review will confirm- any impact nor regression to the current master branch.
Let me know if I should continue in that direction, and sorry for sounding impatient about it :-)
Regards,
Le 18/02/2023 à 10:12, Michael Balzer a écrit :
Ludovic,
the issue is bound to the docker image version, I was using "espressif/idf", which is "latest".
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
So to build the current experimental state, I recommend using the docker image and basically doing the steps Ludovic formalized in the github action:
### SETUP ###
cd ~/esp/Open-Vehicle-Monitoring-System-3
# setup branch: git remote add llange git@github.com:llange/Open-Vehicle-Monitoring-System-3.git git branch -t experimental-esp-idf-build-workflow llange/experimental-esp-idf-build-workflow
# switch to branch: git checkout experimental-esp-idf-build-workflow git submodule update --init --recursive
# apply mongoose patch: git apply --directory=vehicle/OVMS.V3/components/mongoose/mongoose vehicle/OVMS.V3/support/mongoose-espv5.patch
# install v5 sdkconfig defaults: cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5 vehicle/OVMS.V3/sdkconfig.defaults
# install v5 idf components: cp vehicle/OVMS.V3/support/idf_component.yml.esp5 vehicle/OVMS.V3/main/idf_component.yml
### BUILD ###
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
# launch docker shell: docker run --rm -v $PWD:/project -w /project -it espressif/idf:release-v5.0 # init docker image (needs to be done on every start): apt-get update && apt-get install -y dos2unix
# OPTION 1: start with default config: rm vehicle/OVMS.V3/sdkconfig # NOTE: this will build for ESP32 >= rev3, excluding the SPIRAM bug workarounds
# OPTION 2: update your existing sdkconfig: idf.py menuconfig # → press '/' # … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY # … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION # … disable MG_ENABLE_SSL
# build: idf.py build
# flash & start USB monitor: idf.py app-flash && idf.py monitor
The build boots & works, issues you described excluded.
An issue I didn't expect:
I (0) cpu_start: Starting scheduler on APP CPU. E (0) task_wdt: esp_task_wdt_add(747): TWDT was never initialized … E (10) task_wdt: esp_task_wdt_add(747): TWDT was never initialized
…and then repeated 4x per second: E (3130) task_wdt: esp_task_wdt_reset(783): task not found
I'll try to find the cause, as we cannot silent these ("early" logging) they make using the shell challenging.
But, besides that, it has Wifi & cellular connectivity, so looks very promising -- nice work, Ludovic!
Regards, Michael
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Mark, You're certainly right : WolfSSH writes here https://github.com/wolfSSL/wolfssh : "wolfSSH is dependent on wolfCrypt, found as a part of wolfSSL". So it seems we need to bundle it still, and it's a good thing we managed to have it more or less compile with ESP-IDF 5+ (a few bugs are still being ironed out - especially the OPENSSL compatibility layer, which may not be used if mongoose does use mbedTLS instead). Regarding the integration, I tried (my best :-)) to have it build on both ESP-IDF 3, ESP-IDF 5 (and also ESP-IDF 4 with a small patch to the ESP-IDF build system itself). Of course I need help for testing / reproducing the builds and I'm grateful to those of you sparing some time to do exactly that. I have another round of PRs waiting for some peer-review : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... -> @List, do not hesitate to have a look - especially for the ones that are a little bit touchy: * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/831 is trying to guess whether the multiple switch case falls-through are wanted, or not. It impacts the code of multiple people, so it would be interesting if those people could have a look at it. * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/835 is also a big piece and would benefit from a peer-review. Thanks in advance ! Regards, Le 20/02/2023 à 08:07, Mark Webb-Johnson a écrit :
Michael, Ludovic,
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
My memory was that wolfssh required wolfssl? But I may be mistaken.
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition.
If this can cleanly be applied to the existing work, to allow building under either v3 or v5 IDF, that would be ideal. IMHO, the separate branch would only be required if the changes were very extensive and breaking to v3.
Regards, Mark.
Ludovic, I've merged all your PRs, including the two "touchy" ones. I've seen no issues but a couple of bug fixes included. I still need to test these with idf5 (i.e. the new idf5 branch state), idf3 builds & runs fine. The IDF version switches of course don't add readability, as expected. But if they can be kept that small, I don't see any problems. I would opt for excluding the IDF 4 branches, to aid in keeping these as small as possible. I don't see any advantage in IDF 4 over 5 -- do you? Regards, Michael Am 22.02.23 um 17:23 schrieb Ludovic LANGE:
Hi Mark,
You're certainly right : WolfSSH writes here https://github.com/wolfSSL/wolfssh : "wolfSSH is dependent on wolfCrypt, found as a part of wolfSSL".
So it seems we need to bundle it still, and it's a good thing we managed to have it more or less compile with ESP-IDF 5+ (a few bugs are still being ironed out - especially the OPENSSL compatibility layer, which may not be used if mongoose does use mbedTLS instead).
Regarding the integration, I tried (my best :-)) to have it build on both ESP-IDF 3, ESP-IDF 5 (and also ESP-IDF 4 with a small patch to the ESP-IDF build system itself). Of course I need help for testing / reproducing the builds and I'm grateful to those of you sparing some time to do exactly that.
I have another round of PRs waiting for some peer-review : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%...
-> @List, do not hesitate to have a look - especially for the ones that are a little bit touchy:
* https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/831 is trying to guess whether the multiple switch case falls-through are wanted, or not. It impacts the code of multiple people, so it would be interesting if those people could have a look at it. * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/835 is also a big piece and would benefit from a peer-review.
Thanks in advance !
Regards,
Le 20/02/2023 à 08:07, Mark Webb-Johnson a écrit :
Michael, Ludovic,
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
My memory was that wolfssh required wolfssl? But I may be mistaken.
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition.
If this can cleanly be applied to the existing work, to allow building under either v3 or v5 IDF, that would be ideal. IMHO, the separate branch would only be required if the changes were very extensive and breaking to v3.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, Thanks for your time in reviewing those patches. Do not hesitate to tell me when I can rework a PR to simplify it, or make it more readable. If you still have some energy, a new round of PRs is ready here : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%... After this round, there will still be 2 or 3 PRs that will apply cleanly, then we will have to discuss a few things: * We need to re-implement (if possible) the crash handling that were implemented as part as our ESP-IDF fork (`xt_set_error_handler_callback` and `esp_task_wdt_get_trigger_tasknames`). There is a new API (`esp_core_dump_image_get` and `esp_core_dump_get_summary`) but I'm not familiar enough with the crash handling mechanism (both the old one, and the new API) to handle it at the moment :-) I just disabled it in the `experimental-esp-idf-build-workflow` branch, which is not the proper approach * `spi_flash_erase_range` has been replaced by `esp_flash_erase_region` (but with esp_flash_default_chip that may need to be initialised via `esp_flash_init()`) - it is used in `module_perform_factoryreset` of `vehicle/OVMS.V3/main/ovms_module.cpp`. We would need to check this (I just disabled it, not good) * Our ESP-IDF fork added a field `uxMutexesHeld` to `struct xTASK_STATUS` : https://github.com/openvehicles/esp-idf/commit/95e43fc2c4360f8126a0985bf037a... , which is then used in `module_tasks()` in `vehicle/OVMS.V3/main/ovms_module.cpp`. Do we want to continue to have this field (and need to maintain a fork of ESP-IDF) ? * Mongoose SSL (using mbedTLS) is a complex issue... We may be able to switch to the latest Mongoose be we would loose a lot of our patches we are very difficult to port to the new version (which changed a lot). A very small number of those patches seems not needed any more, but for the others we need to decide what to do if we pursue this route. * And many more interesting discussions :-) Regarding ESP-IDF v4 : I used it because it was an intermediary step (between v3 and v5) with less deprecations, so it was easy to port from v3. ESP-IDF v5 introduced a lot of deprecations and changes, but having done the v4 port gave me confidence that it could be done. (/Note: v4 needs a patch to support WHOLE_ARCHIVE - which I don't know if it is important, or not, to have/) As ESP-IDF v5 is a "recent" release (5.0.0 is 2022-12-2, 5.0.1 is 2023-02-17), it may be possible that some of our dependencies out there are not (yet) ready to be compatible with v5 (while they are OK with v4): * For example wolfSSL (I know I know... but we may need it for wolfSSH) seems to have some issues related to ESP-IDFv5 + hardware-acceleration, * https://github.com/trombik/esp_wireguard is not (yet) working with v5: https://github.com/trombik/esp_wireguard/issues/33#issuecomment-1430615198 (This is a pet project of mine : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/issues/752 ) So, to answer your question, I'll try to keep v4 compatibility in my branches for some time in case it's needed - but it's perfectly OK to skip it in the "official" OVMSv3 if it works fine without. Regards, Le 24/02/2023 à 17:34, Michael Balzer a écrit :
Ludovic,
I've merged all your PRs, including the two "touchy" ones. I've seen no issues but a couple of bug fixes included.
I still need to test these with idf5 (i.e. the new idf5 branch state), idf3 builds & runs fine.
The IDF version switches of course don't add readability, as expected. But if they can be kept that small, I don't see any problems.
I would opt for excluding the IDF 4 branches, to aid in keeping these as small as possible. I don't see any advantage in IDF 4 over 5 -- do you?
Regards, Michael
Am 22.02.23 um 17:23 schrieb Ludovic LANGE:
Hi Mark,
You're certainly right : WolfSSH writes here https://github.com/wolfSSL/wolfssh : "wolfSSH is dependent on wolfCrypt, found as a part of wolfSSL".
So it seems we need to bundle it still, and it's a good thing we managed to have it more or less compile with ESP-IDF 5+ (a few bugs are still being ironed out - especially the OPENSSL compatibility layer, which may not be used if mongoose does use mbedTLS instead).
Regarding the integration, I tried (my best :-)) to have it build on both ESP-IDF 3, ESP-IDF 5 (and also ESP-IDF 4 with a small patch to the ESP-IDF build system itself). Of course I need help for testing / reproducing the builds and I'm grateful to those of you sparing some time to do exactly that.
I have another round of PRs waiting for some peer-review : https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%...
-> @List, do not hesitate to have a look - especially for the ones that are a little bit touchy:
* https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/831 is trying to guess whether the multiple switch case falls-through are wanted, or not. It impacts the code of multiple people, so it would be interesting if those people could have a look at it. * https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pull/835 is also a big piece and would benefit from a peer-review.
Thanks in advance !
Regards,
Le 20/02/2023 à 08:07, Mark Webb-Johnson a écrit :
Michael, Ludovic,
Actually one of the next things I wanted to try/determine is why you want/need to use wolfSSL instead of mbedTLS, which we've been using since wolfSSL failed so miserably about the Let's encrypt root certificate transition. Is there an issue with mbedTLS in idf5?
My memory was that wolfssh required wolfssl? But I may be mistaken.
We still need to decide on the integration way. Mark's suggestion was doing the idf5 transition in a separate branch that will later become the new "master". That would keep the idf3 build clean from any regressions, but need merging any work done on that branch into the idf5 branch, which may become a lot of additional work, depending on the time needed to finish the transition.
If this can cleanly be applied to the existing work, to allow building under either v3 or v5 IDF, that would be ideal. IMHO, the separate branch would only be required if the changes were very extensive and breaking to v3.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Ludovic, I was about to review & test your latest changes, but unfortunately did an update of the release-v5.0 docker image and am now experiencing the missing mbedtls module issue again :-/ /opt/esp/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/zip/libzip.a(zip_crypto_mbedtls.c.obj):(.literal._zip_crypto_pbkdf2+0x0): undefined reference to `mbedtls_pkcs5_pbkdf2_hmac' /opt/esp/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/zip/libzip.a(zip_crypto_mbedtls.c.obj): in function `_zip_crypto_pbkdf2': /project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac' Did you have this, if so did you find a solution? Regards, Michael Am 18.02.23 um 10:12 schrieb Michael Balzer:
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Hi Michael, No I did not have this issue yet - as I'm still on v5.0.1 If it were me, I'd recommend that you use 'tag' names ( https://github.com/espressif/esp-idf/tags ) instead of branch names (https://github.com/espressif/esp-idf/branches ) as it seems they are somehow in a state of flux on branch `release/v5.0`. The docker image has all the branches and tags available, and among those is the `v5.0.1` tag: https://hub.docker.com/r/espressif/idf/tags?page=1&name=5 So instead of pulling `espressif/idf:release-v5.0` it would be `espressif/idf:v5.0.1` and it "should work". I'll have a look at the next v5 when it's tagged - may be they will document a deprecation or a change in includes.... we'll see. If you really really want that we investigate this (moving) `release/v5.0` branch, let me know, and I'll try to have a look at it. Regards, Le 04/03/2023 à 14:04, Michael Balzer a écrit :
Ludovic,
I was about to review & test your latest changes, but unfortunately did an update of the release-v5.0 docker image and am now experiencing the missing mbedtls module issue again :-/
/opt/esp/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/zip/libzip.a(zip_crypto_mbedtls.c.obj):(.literal._zip_crypto_pbkdf2+0x0): undefined reference to `mbedtls_pkcs5_pbkdf2_hmac' /opt/esp/tools/xtensa-esp32-elf/esp-2022r1-11.2.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/11.2.0/../../../../xtensa-esp32-elf/bin/ld: esp-idf/zip/libzip.a(zip_crypto_mbedtls.c.obj): in function `_zip_crypto_pbkdf2': /project/components/zip/libzip/lib/zip_crypto_mbedtls.c:124: undefined reference to `mbedtls_pkcs5_pbkdf2_hmac'
Did you have this, if so did you find a solution?
Regards, Michael
Am 18.02.23 um 10:12 schrieb Michael Balzer:
The build works using the same sdkconfig with "espressif/idf:release-v5.0" (and again fails at that mbedtls module when switching back to the "latest" image).
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
Ludovic, `int` or `int32_t` is correct, `INT` is defined by the fatfs (/esp-idf/components/fatfs/src/integer.h) as `int`. Btw, I recommend using ctags with an index on both the esp-idf and the OVMS tree, makes looking up definitions very easy. Regards, Michael Am 23.01.23 um 22:19 schrieb Ludovic LANGE:
A new things that need to be checked : in https://github.com/llange/Open-Vehicle-Monitoring-System-3/commit/f31117a48d... i had to replace `INT` with another type. This time I choose `int32_t` but I'm not really sure because I could not find a way to see where and how INT was defined. I could only verify (by compilation tricks) that sizeof(INT) == sizeof(int32_t).
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
participants (4)
-
Ludovic LANGE -
Mark Webb-Johnson -
Michael Balzer -
Michael Geddes