<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Michael,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks for the merges, and for your
precious spare time (unfortunately, same issue here :-))</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">If the preference is to use mbedTLS, so
be it ; may be we should completely remove wolfSSL in the future
then ?</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Ludovic<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Le 19/02/2023 à 21:15, Michael Balzer a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:e814da89-32e6-016b-7e03-cc0cddd14a6f@expeedo.de">Ludovic,
<br>
<br>
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.
<br>
<br>
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?
<br>
<br>
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.
<br>
<br>
The idf5 build branch does not yet build using idf3, currently
failing with a wolfssl issue:
<br>
<br>
In file included from
/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/wolfssl/wolfssl/wolfssl/wolfcrypt/sha256.h:96:0,<br>
from
/home/balzer/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3/components/console_ssh/src/console_ssh.cpp:52:<br>
/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
<br>
<br>
Regards,
<br>
Michael
<br>
<br>
<br>
Am 19.02.23 um 16:29 schrieb Ludovic LANGE:
<br>
<blockquote type="cite">Hi Michael,
<br>
Hi list,
<br>
<br>
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" :-)
<br>
<br>
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.
<br>
<br>
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 <a class="moz-txt-link-freetext" href="https://github.com/wolfSSL/wolfssl/issues/6028">https://github.com/wolfSSL/wolfssl/issues/6028</a> in
order to help fix some remaining issues on this library we
depend on.
<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse">https://github.com/openvehicles/Open-Vehicle-Monitoring-System-3/pulls?q=is%3Aopen+is%3Apr+author%3Allange+draft%3Afalse</a>
; which could be merged without -I hope, but the review will
confirm- any impact nor regression to the current master branch.
<br>
<br>
Let me know if I should continue in that direction, and sorry
for sounding impatient about it :-)
<br>
<br>
Regards,
<br>
<br>
<br>
Le 18/02/2023 à 10:12, Michael Balzer a écrit :
<br>
<blockquote type="cite">Ludovic,
<br>
<br>
the issue is bound to the docker image version, I was using
"espressif/idf", which is "latest".
<br>
<br>
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).
<br>
<br>
So to build the current experimental state, I recommend using
the docker image and basically doing the steps Ludovic
formalized in the github action:
<br>
<br>
### SETUP ###
<br>
<br>
cd ~/esp/Open-Vehicle-Monitoring-System-3
<br>
<br>
# setup branch:
<br>
git remote add llange
<a class="moz-txt-link-abbreviated" href="mailto:git@github.com:llange/Open-Vehicle-Monitoring-System-3.git">git@github.com:llange/Open-Vehicle-Monitoring-System-3.git</a>
<br>
git branch -t experimental-esp-idf-build-workflow
llange/experimental-esp-idf-build-workflow
<br>
<br>
# switch to branch:
<br>
git checkout experimental-esp-idf-build-workflow
<br>
git submodule update --init --recursive
<br>
<br>
# apply mongoose patch:
<br>
git apply
--directory=vehicle/OVMS.V3/components/mongoose/mongoose
vehicle/OVMS.V3/support/mongoose-espv5.patch
<br>
<br>
# install v5 sdkconfig defaults:
<br>
cp vehicle/OVMS.V3/support/sdkconfig.defaults.esp5
vehicle/OVMS.V3/sdkconfig.defaults
<br>
<br>
# install v5 idf components:
<br>
cp vehicle/OVMS.V3/support/idf_component.yml.esp5
vehicle/OVMS.V3/main/idf_component.yml
<br>
<br>
<br>
### BUILD ###
<br>
<br>
cd ~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3
<br>
<br>
# launch docker shell:
<br>
docker run --rm -v $PWD:/project -w /project -it
espressif/idf:release-v5.0
<br>
# init docker image (needs to be done on every start):
<br>
apt-get update && apt-get install -y dos2unix
<br>
<br>
# OPTION 1: start with default config:
<br>
rm vehicle/OVMS.V3/sdkconfig
<br>
# NOTE: this will build for ESP32 >= rev3, excluding the
SPIRAM bug workarounds
<br>
<br>
# OPTION 2: update your existing sdkconfig:
<br>
idf.py menuconfig
<br>
# → press '/'
<br>
# … enable FREERTOS_ENABLE_BACKWARD_COMPATIBILITY
<br>
# … disable FREERTOS_ASSERT_ON_UNTESTED_FUNCTION
<br>
# … disable MG_ENABLE_SSL
<br>
<br>
# build:
<br>
idf.py build
<br>
<br>
# flash & start USB monitor:
<br>
idf.py app-flash && idf.py monitor
<br>
<br>
<br>
The build boots & works, issues you described excluded.
<br>
<br>
An issue I didn't expect:
<br>
<br>
I (0) cpu_start: Starting scheduler on APP CPU.
<br>
E (0) task_wdt: esp_task_wdt_add(747): TWDT was never
initialized
<br>
…
<br>
E (10) task_wdt: esp_task_wdt_add(747): TWDT was never
initialized
<br>
<br>
…and then repeated 4x per second:
<br>
E (3130) task_wdt: esp_task_wdt_reset(783): task not found
<br>
<br>
I'll try to find the cause, as we cannot silent these ("early"
logging) they make using the shell challenging.
<br>
<br>
But, besides that, it has Wifi & cellular connectivity, so
looks very promising -- nice work, Ludovic!
<br>
<br>
Regards,
<br>
Michael
<br>
</blockquote>
<br>
<br>
_______________________________________________
<br>
OvmsDev mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<br>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
<br>
</blockquote>
<br>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
OvmsDev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OvmsDev@lists.openvehicles.com">OvmsDev@lists.openvehicles.com</a>
<a class="moz-txt-link-freetext" href="http://lists.openvehicles.com/mailman/listinfo/ovmsdev">http://lists.openvehicles.com/mailman/listinfo/ovmsdev</a>
</pre>
</blockquote>
<p><br>
</p>
<div id="grammalecte_menu_main_button_shadow_host" style="width:
0px; height: 0px;"></div>
</body>
</html>