[Ovmsdev] ESP-IDF v4 / v5 - baby steps

Mon Feb 20 04:58:53 HKT 2023

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%3Aopen+is%3Apr+author%3Allange+draft%3Afalse 
>> ; 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 at 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 at lists.openvehicles.com
>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev
>
>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.openvehicles.com
> http://lists.openvehicles.com/mailman/listinfo/ovmsdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20230219/b60d56ce/attachment-0001.htm>