faizanmir21
commented
1 month ago Connection refused while compiling the environment. See below.
Open shankari opened 1 month ago
faizanmir21
commented
1 month ago Connection refused while compiling the environment. See below.
faizanmir21
commented
1 month ago I think it was getting blocked by the NREL firewall. Was able to access using the hotspot network.
louisg1337
commented
1 month ago I am currently on the third step on the Pionix guide where you have to run the cmake commands, and I am getting this error:
cb57bb2cbe6f:/ext/source# cmake \
-DCMAKE_TOOLCHAIN_FILE=../../bullseye-toolchain/toolchain.cmake \
-DCMAKE_INSTALL_PREFIX=/mnt/user_data/opt/everest \
-S . -B build-cross
-- The CXX compiler identification is unknown
-- The C compiler identification is unknown
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - failed
-- Check for working CXX compiler: /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++
-- Check for working CXX compiler: /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++ - broken
CMake Error at /usr/share/cmake/Modules/CMakeTestCXXCompiler.cmake:62 (message):
The C++ compiler
"/bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /ext/source/build-cross/CMakeFiles/CMakeTmp
Run Build Command(s):/usr/bin/make -f Makefile cmTC_f7171/fast && /usr/bin/make -f CMakeFiles/cmTC_f7171.dir/build.make CMakeFiles/cmTC_f7171.dir/build
make[1]: Entering directory '/ext/source/build-cross/CMakeFiles/CMakeTmp'
Building CXX object CMakeFiles/cmTC_f7171.dir/testCXXCompiler.cxx.o
/bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++ -D__ARM_ARCH_8__ -D__arm__ -Wno-psabi -o CMakeFiles/cmTC_f7171.dir/testCXXCompiler.cxx.o -c /ext/source/build-cross/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
make[1]: /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++: No such file or directory
make[1]: *** [CMakeFiles/cmTC_f7171.dir/build.make:78: CMakeFiles/cmTC_f7171.dir/testCXXCompiler.cxx.o] Error 127
make[1]: Leaving directory '/ext/source/build-cross/CMakeFiles/CMakeTmp'
make: *** [Makefile:127: cmTC_f7171/fast] Error 2
CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:3 (project)
-- Configuring incomplete, errors occurred!
See also "/ext/source/build-cross/CMakeFiles/CMakeOutput.log".
See also "/ext/source/build-cross/CMakeFiles/CMakeError.log".It seems like something is wrong with bullseye, but when I ran the commands to install and untar it, it looked normal and didn't give me any errors.
cb57bb2cbe6f:/# wget http://build.pionix.de:8888/release/toolchains/bullseye-toolchain.tgz
Connecting to build.pionix.de:8888 (35.242.226.179:8888)
saving to 'bullseye-toolchain.tgz'
bullseye-toolchain.t 100% |**********************************************************************************************************************************************************************************************| 606M 0:00:00 ETA
'bullseye-toolchain.tgz' saved
cb57bb2cbe6f:/# ls
=0.10.9.5 =3.7.4 bin etc media root sys workspace
=0.11.0 =5.9.1 bullseye-toolchain.tgz ext mnt run tmp
=2.8.2 =9.5.0 dev home opt sbin usr
=3.4.6 assets entrypoint.sh lib proc srv var
cb57bb2cbe6f:/# tar xfz bullseye-toolchain.tgz To get here, I did docker exec into the everest-ac-demo-manager-1, which was built using our one line demos in the latest branch of everest-demo.
shankari
commented
1 month ago this is the same error that Faizan got. When you untar the toolchain, what directory does it create? Maybe you have to untar it in a different way or move it around or sth. you need to show that you have a /bullseye-toolchain/crosstool/bin directory.
louisg1337
commented
1 month ago When I untar the toolchain it creates a directory called bullseye-toolchain the same place that I downloaded the bullseye-toolchain.tgz file. Going off of this error:
make[1]: /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++: No such file or directory
It is weird because I do have a /bullseye-toolchain/crosstool/bin directory, and I have the armv8-rpi4-linux-gnueabihf-g++ file within it.
cb57bb2cbe6f:/# ls
=0.10.9.5 =3.7.4 bin entrypoint.sh lib proc srv var
=0.11.0 =5.9.1 bullseye-toolchain etc media root sys workspace
=2.8.2 =9.5.0 bullseye-toolchain.tgz ext mnt run tmp
=3.4.6 assets dev home opt sbin usr
cb57bb2cbe6f:/# cd bullseye-toolchain/crosstool/bin/
cb57bb2cbe6f:/bullseye-toolchain/crosstool/bin# ls
armv8-rpi4-linux-gnueabihf-addr2line armv8-rpi4-linux-gnueabihf-dwp armv8-rpi4-linux-gnueabihf-gcov armv8-rpi4-linux-gnueabihf-ld.gold armv8-rpi4-linux-gnueabihf-readelf
armv8-rpi4-linux-gnueabihf-ar armv8-rpi4-linux-gnueabihf-elfedit armv8-rpi4-linux-gnueabihf-gcov-dump armv8-rpi4-linux-gnueabihf-ldd armv8-rpi4-linux-gnueabihf-size
armv8-rpi4-linux-gnueabihf-as armv8-rpi4-linux-gnueabihf-g++ armv8-rpi4-linux-gnueabihf-gcov-tool armv8-rpi4-linux-gnueabihf-lto-dump armv8-rpi4-linux-gnueabihf-strings
armv8-rpi4-linux-gnueabihf-c++ armv8-rpi4-linux-gnueabihf-gcc armv8-rpi4-linux-gnueabihf-gdb armv8-rpi4-linux-gnueabihf-nm armv8-rpi4-linux-gnueabihf-strip
armv8-rpi4-linux-gnueabihf-c++filt armv8-rpi4-linux-gnueabihf-gcc-10.3.0 armv8-rpi4-linux-gnueabihf-gdb-add-index armv8-rpi4-linux-gnueabihf-objcopy
armv8-rpi4-linux-gnueabihf-cc armv8-rpi4-linux-gnueabihf-gcc-ar armv8-rpi4-linux-gnueabihf-gprof armv8-rpi4-linux-gnueabihf-objdump
armv8-rpi4-linux-gnueabihf-cpp armv8-rpi4-linux-gnueabihf-gcc-nm armv8-rpi4-linux-gnueabihf-ld armv8-rpi4-linux-gnueabihf-populate
armv8-rpi4-linux-gnueabihf-ct-ng.config armv8-rpi4-linux-gnueabihf-gcc-ranlib armv8-rpi4-linux-gnueabihf-ld.bfd armv8-rpi4-linux-gnueabihf-ranlib
cb57bb2cbe6f:/bullseye-toolchain/crosstool/bin# Any ideas on where I would move it or where I should untar it instead?
louisg1337
commented
1 month ago I think that this may be our issue, I'm figuring out how to install this dependency right now to see if that fixes it.
cb57bb2cbe6f:/# ldd /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++
/lib64/ld-linux-x86-64.so.2 (0x7f44e57a8000)
libc.so.6 => /lib64/ld-linux-x86-64.so.2 (0x7f44e57a8000)
Error loading shared library ld-linux-x86-64.so.2: No such file or directory (needed by /bullseye-toolchain/crosstool/bin/armv8-rpi4-linux-gnueabihf-g++)I don't know a lot about Linux, so please correct me if I'm wrong, but it seems like the issue we are experiencing is because I am trying to use Alpine Linux (via the docker container) instead of Ubuntu. Apparently Alpine uses musl as its C library, which doesn't have the package above, while Ubuntu uses glibc, which does have the package.
In the Alpine Linux wiki, they have a way to run glibc binaries on Alpine, which is by installing gcompat via apk add gcompat. After that, the cmake command seemed to work successfully.
shankari
commented
1 month ago Perfect! Unfortunately, we bricked the uMWC while experimenting today so I can't test this until I get some new firmware. But maybe you can zip up the directory that we are supposed to copy over using rsync and upload it to someplace internal to NREL? I can then pull it and install it once everything is working again.
We will need to repeat this once the docker image with the setChargingProfile is ready
louisg1337
commented
4 weeks ago Unfortunately I've hit another roadblock, instead this time with the final make build commands. When I run the command, the build gets to about 60-65% done before it substantially slows down, and eventually stops making progress. I don't get any errors either, it kind of just freezes. I've ran this build command a few times, and it has always happened like this. Heres an example of what I've been stuck on for the past 10 ish minutes.
...
[ 64%] Building C object _deps/ext-mbedtls-build/library/CMakeFiles/mbedtls.dir/ssl_ticket.c.o
make[2]: Leaving directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
[ 64%] Building CXX object modules/CMakeFiles/API.dir/API/API.cpp.o
[ 64%] Building C object _deps/ext-mbedtls-build/library/CMakeFiles/mbedtls.dir/ssl_tls.c.o
[ 64%] Building C object _deps/ext-mbedtls-build/library/CMakeFiles/mbedtls.dir/ssl_tls13_keys.c.o
[ 64%] Linking C static library libmbedtls.a
make[2]: Leaving directory '/ext/source/build-cross'
[ 64%] Built target mbedtls
make[2]: Entering directory '/ext/source/build-cross'
make[2]: Leaving directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
[ 64%] Building CXX object modules/Auth/lib/CMakeFiles/auth_handler.dir/AuthHandler.cpp.o
[ 64%] Linking CXX executable controller
make[2]: Leaving directory '/ext/source/build-cross'
[ 64%] Built target controller
make[2]: Entering directory '/ext/source/build-cross'
make[2]: Leaving directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
[ 64%] Building CXX object modules/CMakeFiles/EnergyManager.dir/EnergyManager/EnergyManager.cpp.oI figured it may be because the docker container doesn't have enough resources, but I'm decently below my max utilization for everything. I'll keep working on this and see if I can get this to work.
shankari
commented
4 weeks ago It might just be slow. There is a reason that "compile the Linux kernel" used to be the standard workload for performance testing in the old system papers.
Bump up the resources anyway just to be on the safe side and then just wait for 30mins or so
louisg1337
commented
4 weeks ago I tried bumping all the resources to 75% of what my computer can handle (12 gb RAM, 6 cores, 3 gb swap) and it still is stuck in the low 60s. I left it for about a hour and it doesn't seem to be making any progress past that. I did get an error now, however, although it seems a bit unhelpful. Here are the logs:
...
[ 53%] Built target slac_fsm_ev
[ 53%] Building CXX object _deps/everest-framework-build/lib/CMakeFiles/framework.dir/everest.cpp.o
[ 53%] Building CXX object _deps/everest-framework-build/lib/CMakeFiles/framework.dir/runtime.cpp.o
[ 53%] Built target slac_fsm_evse
[ 60%] Built target websockets_shared
[ 60%] Building CXX object _deps/everest-framework-build/lib/CMakeFiles/framework.dir/yaml_loader.cpp.o
make[2]: Entering directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
make[2]: Leaving directory '/ext/source/build-cross'
[ 61%] Built target controller
Consolidate compiler generated dependencies of target ocpp
make[2]: Leaving directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
[ 61%] Building CXX object _deps/libocpp-build/lib/CMakeFiles/ocpp.dir/ocpp/v16/charge_point.cpp.o
[ 61%] Building CXX object _deps/libocpp-build/lib/CMakeFiles/ocpp.dir/ocpp/v16/smart_charging.cpp.o
armv8-rpi4-linux-gnueabihf-g++: fatal error: Killed signal terminated program cc1plus
compilation terminated.
make[2]: *** [_deps/everest-framework-build/lib/CMakeFiles/framework.dir/build.make:328: _deps/everest-framework-build/lib/CMakeFiles/framework.dir/runtime.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 61%] Building CXX object _deps/libocpp-build/lib/CMakeFiles/ocpp.dir/ocpp/v16/charge_point_configuration.cpp.o
[ 61%] Building CXX object _deps/libocpp-build/lib/CMakeFiles/ocpp.dir/ocpp/v16/charge_point_state_machine.cpp.oI read somewhere online that the armv8-rpi4-linux-gnueabihf-g++: fatal error: Killed signal terminated program cc1plus error is usually do to lack of memory, so I dug a bit deeper into whether or not the container itself was getting all the resources I allocated. I then realized that in docker-compose.ocpp201.yml there was a 1 core limit on the CPU and 1 gb limit for the ram. I then bumped it up to 6 cores and 10 gb of ram and it finally built. The container consistently used around 5 cores and the ram fluctuated between 2-6 gb, so the boost was definitely needed. I'll write up a nice guide under this post so that in the future the steps to build using Docker are outlined.
louisg1337
commented
4 weeks ago The cross compiling steps are outlined here, in the EVerest docs. You are required to have EVerest built natively, which means you need a Linux machine, and the rest of the commands are Linux based as well. We can circumvent this hardware requirement by doing this build process on a docker container which 1) has EVerest built on it, and 2) runs Linux Alpine. Thankfully, we have one line demos which builds EVerest to these containers for us. Below is a complete walkthrough of the steps I took to utilize Docker to build for hardware.
everest-demo/.env found here.
everest-ac-demo-manager-1, the docker container we will be working in, from utilizing all the resources we allocated..env and change EVEREST_MANAGER_CPUS and EVEREST_MANAGER_MEMORYto 1 below the maximum values set in Step 1.demo-iso15118-2-ac-plus-ocpp.sh and change
git clone --branch "${DEMO_BRANCH}" "${DEMO_REPO}" everest-demo to
cp -r "${DEMO_REPO}" everest-demobash demo-iso15118-2-ac-plus-ocpp.sh -r $(pwd) -3everest-ac-demo running.everest-ac-demo-manager-1 container via docker exec -it <container_id> /bin/bash.apk add gcompatcd .. to navigate to the / directory.wget http://build.pionix.de:8888/release/toolchains/bullseye-toolchain.tgz
tar xfz bullseye-toolchain.tgzext/source cmake \
-DCMAKE_TOOLCHAIN_FILE=../../bullseye-toolchain/toolchain.cmake \
-DCMAKE_INSTALL_PREFIX=/mnt/user_data/opt/everest \
-S . -B build-crossmake -j$(nproc) -C build-cross
make -j$(nproc) DESTDIR=./dist -C build-cross installdocker cp <container_id>:/ext/source/build-cross ~/Desktop shankari
commented
3 weeks ago Affer switching to the custom build that includes smart charging, ran into this error
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR: Found unsuitable version "1.1.1n", but
required is at least "3" (found
/bullseye-toolchain/sysroot/usr/lib/arm-linux-gnueabihf/libcrypto.so, )
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:592 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindOpenSSL.cmake:599 (find_package_handle_standard_args)
build-cross/_deps/libevse-security-src/CMakeLists.txt:46 (find_package)This was caused by https://github.com/EVerest/libevse-security/commit/8777cc2079f9529a3975395d9259e5d2cbf1fc5a
Double-checked the uMWC, and found
/usr/lib/arm-linux-gnueabihf/libcrypt
libcrypt.a libcryptsetup.so.12 libcrypt.so libcrypt.so.1.1.0
libcrypto.so.1.1 libcryptsetup.so.12.6.0 libcrypt.so.1So we will have to revert the libevse change. Let's try only removing that dependency and see if it works.
EDIT: Removed dependency in build-cross/_deps/libocpp-src/CMakeLists.txt and in /ext/source/build-cross/_deps/libevse-security-src/CMakeLists.txt (wait those are the same, so why didn't it work the first time?) It has moved forward now...
EDIT: cmake completed successfully, starting build...
shankari
commented
3 weeks ago Build failed with
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:544:21: error: 'X509_ADD_FLAG_NO_DUP' was not declared in this scope; did you mean 'X509_FLAG_NO_AUX'?
544 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_AUX
make[2]: Leaving directory '/ext/source/build-cross'
make[2]: Entering directory '/ext/source/build-cross'
[ 61%] Building CXX object _deps/libmodbus-build/CMakeFiles/modbus.dir/src/modbus_client.cpp.o
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:544:44: error: 'X509_ADD_FLAG_NO_SS' was not declared in this scope; did you mean 'X509_FLAG_NO_IDS'?
544 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_IDS
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:547:22: error: 'X509_add_cert' was not declared in this scope; did you mean 'X509_add_ext'?
547 | if (1 != X509_add_cert(untrusted.get(), get(untrusted_cert), flags)) {
| ^~~~~~~~~~~~~
| X509_add_extReplaced all the text in /ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp with the version before the latest changes: https://github.com/EVerest/libevse-security/blob/34ced9f4452c2ffe3145f4ff200c42dc83278c47/lib/evse_security/crypto/openssl/openssl_supplier.cpp
Ran into issues with
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:188:9: error: 'EC_KEY_ptr' was not declared in this scope; did you mean 'EVP_PKEY_ptr'?
188 | EC_KEY_ptr ec_key(EC_KEY_new_by_curve_name(nid));
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:211:9: error: 'RSA_ptr' was not declared in this scope
211 | RSA_ptr rsa_key(RSA_generate_key(bits, RSA_PRIME, nullptr, nullptr));
| ^~~~~~~
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp: In static member function 'static evse_security::CertificateValidationResult evse_security::OpenSSLSupplier::x509_verify_certificate_chain(evse_security::X509Handle*, const std::vector<evse_security::X509Handle*>&, const std::vector<evse_security::X509Handle*>&, bool, std::optional<std::filesystem::__cxx11::path>, std::optional<std::filesystem::__cxx11::path>)':
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:544:21: error: 'X509_ADD_FLAG_NO_DUP' was not declared in this scope; did you mean 'X509_FLAG_NO_AUX'?
544 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_AUX
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:544:44: error: 'X509_ADD_FLAG_NO_SS' was not declared in this scope; did you mean 'X509_FLAG_NO_IDS'?
544 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_IDS
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:547:22: error: 'X509_add_cert' was not declared in this scope; did you mean 'X509_add_ext'?
547 | if (1 != X509_add_cert(untrusted.get(), get(untrusted_cert), flags)) {
| ^~~~~~~~~~~~~
| X509_add_extCopied over deleted code. There are still failures. Trying to just revert the dependency and rebuild. This was only changed 2 weeks ago, and computers are faster than me.
shankari
commented
3 weeks ago Reverted back to version 0.6.0, OCPP compile is failing with
[ 84%] Building CXX object _deps/libocpp-build/lib/CMakeFiles/ocpp.dir/ocpp/common/types.cpp.o
In file included from /ext/source/lib/staging/evse_security/conversions.cpp:6:
/ext/source/lib/staging/evse_security/../evse_security/conversions.hpp:27:16: error: 'CertificateInfo' in namespace 'evse_security' does not name a type; did you mean 'CertificateType'?
27 | evse_security::CertificateInfo from_everest(types::evse_security::CertificateInfo other);
| ^~~~~~~~~~~~~~~
| CertificateTypeTrying to revert to the commit just before this change.
EDIT: Setting the git_tag to 4330ce2e28e25535dd01558edb2331891c146769 built!
Now, let's try to cross-compile again. Will check with SIL before pushing out to the uMWC...
shankari
commented
3 weeks ago Now it is required in libocpp
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find OpenSSL, try to set the path to OpenSSL root folder in the
system variable OPENSSL_ROOT_DIR: Found unsuitable version "1.1.1n", but
required is at least "3" (found
/bullseye-toolchain/sysroot/usr/lib/arm-linux-gnueabihf/libcrypto.so, )
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:592 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake/Modules/FindOpenSSL.cmake:599 (find_package_handle_standard_args)
build-cross/_deps/libocpp-src/CMakeLists.txt:28 (find_package)Not easy to roll this back, so let's just try to edit and assume that the dependencies are not too bad.
shankari
commented
3 weeks ago Broke in the same way
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp: In static member function 'static evse_security::CertificateValidationResult evse_security::OpenSSLSupplier::x509_verify_certificate_chain(evse_security::X509Handle*, const std::vector<evse_security::X509Handle*>&, const std::vector<evse_security::X509Handle*>&, bool, std::optional<std::filesystem::__cxx11::path>, std::optional<std::filesystem::__cxx11::path>)':
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:599:21: error: 'X509_ADD_FLAG_NO_DUP' was not declared in this scope; did you mean 'X509_FLAG_NO_AUX'?
599 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_AUX
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:599:44: error: 'X509_ADD_FLAG_NO_SS' was not declared in this scope; did you mean 'X509_FLAG_NO_IDS'?
599 | int flags = X509_ADD_FLAG_NO_DUP | X509_ADD_FLAG_NO_SS;
| ^~~~~~~~~~~~~~~~~~~
| X509_FLAG_NO_IDS
/ext/source/build-cross/_deps/libevse-security-src/lib/evse_security/crypto/openssl/openssl_supplier.cpp:602:22: error: 'X509_add_cert' was not declared in this scope; did you mean 'X509_add_ext'?
602 | if (1 != X509_add_cert(untrusted.get(), get(untrusted_cert), flags)) {
| ^~~~~~~~~~~~~
| X509_add_extI guess the interim changes are not known to work. Off to check the openssl code...
shankari
commented
3 weeks ago ok so verified that these are from SSL 3 https://man.archlinux.org/man/X509_add_cert.3ssl.en But the OpenSSL docs have a slightly different method name https://www.openssl.org/docs/man1.1.1/man3/X509_STORE_add_cert.html which has been unchanged since version 1.
And grepping seems to find the old value as well. Did this ever work? When was it added? /bullseye-toolchain/sysroot/var/lib/dpkg/info/libssl1.1:armhf.symbols: X509_STORE_add_cert@OPENSSL_1_1_0 1.1.0
There are no symbols for X509_ADD_FLAG_NO_DUP and X509_ADD_FLAG_NO_SS
It was added in https://github.com/EVerest/libevse-security/commit/acc12fe5353d8090fc8cb0a84564b52ad7301e51
which is good for PKI but is not needed for our demo. Reverting to the version before that for just this location:
https://github.com/EVerest/libevse-security/commit/acc12fe5353d8090fc8cb0a84564b52ad7301e51#diff-9b5e7ace83962c09e4fd78bac64e78b58816ec321a0ef6ecf90c97493d1ff6c6R593
Having said that, I do see a X509_STORE_add_cert(store_ptr.get(), get(parents[i])); but this is if (1 != X509_add_cert(untrusted.get(), get(untrusted_cert), flags)) {....
shankari
commented
3 weeks ago Final issue: it looks like openssl cleaned up their code by adding consts and plumbing them through. So the calling code has consts but the function does not.
/ext/source/build-cross/_deps/libocpp-src/lib/ocpp/common/websocket/websocket_libwebsockets.cpp:175:61: error: invalid conversion from 'const X509_STORE_CTX*' {aka 'const x509_store_ctx_st*'} to 'X509_STORE_CTX*' {aka 'x509_store_ctx_st*'} [-fpermissive]
175 | X509* server_cert = X509_STORE_CTX_get_current_cert(ctx);
| ^~~
| |
| const X509_STORE_CTX* {aka const x509_store_ctx_st*}I am making the assumption that the underlying implementation has not changed significantly, so we just need to un constify it. I did consider removing the const, but it is passed in as an argument, so we would need to go through and remove all the call sites and potentially their call sites and so on, which will make this very complex.
I can create a new struct fairly easily, but copying over the fields is complicated. And some of them are functions. https://docs.huihoo.com/doxygen/openssl/1.0.1c/structx509__store__ctx__st.html
So I just use memcpy to copy over all the pointers. If the underlying functions are not actually const, this will be bad, but see assumption above.
X509_STORE_CTX* non_const_ctx = X509_STORE_CTX_new();
memcpy(non_const_ctx, ctx, sizeof(ctx)); // args are (dest, src, size)
X509* server_cert = X509_STORE_CTX_get_current_cert(non_const_ctx);This code, copied three times, lets the compile succeed!
shankari
commented
3 weeks ago Verified that there is also a firmware file and only one firmware file
./dist/mnt/user_data/opt/everest/share/everest/modules/YetiDriver/firmware/yetiR1_2.1_firmware.binwhich is built here
./modules/YetiDriver/cmake_install.cmake: file(INSTALL DESTINATION "${CMAKE_INSTALL_PREFIX}/share/everest/modules/YetiDriver/firmware" TYPE FILE FILES "/ext/source/modules/YetiDriver/yetiR1_2.1_firmware.bin")Double-checked and the instructions from Pionix say that it should be in the "
shankari
commented
3 weeks ago edited /ext/cache/cpm/libevse-security/f4c722882414e8cb77a2f572b45fde98e2647f8d/libevse-security/lib/evse_security/crypto/openssl/openssl_supplier.cpp and /ext/cache/cpm/libocpp/6502037f667273b3f55e917ec94a3fe0a2d27720/libocpp/lib/ocpp/common/websocket/websocket_libwebsockets.cpp
Recompiled. But I can't kill the existing process! Need to pull all the patches and recompile to restart the new version.
shankari
commented
3 weeks ago SIL fails
2024-06-14 01:05:31.810823 [INFO] ocpp:OCPP201 :: Loading CA csms bundle to verify server certificate: /ext/source/build/dist/etc/everest/certs/ca/v2g/V2G_ROOT_CA.pem
2024-06-14 01:05:31.851814 [INFO] ocpp:OCPP201 :: LWS connect with info port: [443] address: [host.docker.internal] path: [/ws/cp001] protocol: [ocpp2.0.1]
2024-06-14 01:05:31.851958 [DEBG] ocpp:OCPP201 int ocpp::WebsocketTlsTPM::process_callback(void*, int, void*, void*, size_t) :: Callback with unhandled reason: 85
2024-06-14 01:05:31.852062 [DEBG] ocpp:OCPP201 int ocpp::WebsocketTlsTPM::process_callback(void*, int, void*, void*, size_t) :: Client connecting...
2024-06-14 01:05:31.852196 [DEBG] ocpp:OCPP201 void ocpp::WebsocketTlsTPM::client_loop() :: Init client loop with ID: 7f35cdd71b38
2024-06-14 01:05:31.853606 [DEBG] ocpp:OCPP201 int ocpp::WebsocketTlsTPM::process_callback(void*, int, void*, void*, size_t) :: Callback with unhandled reason: 29
2024-06-14 01:05:31.858875 [DEBG] ocpp:OCPP201 int ocpp::WebsocketTlsTPM::process_callback(void*, int, void*, void*, size_t) :: Verifying server certs!
2024-06-14 01:05:31.900821 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module ocpp (pid: 4010) exited with status: 11. Terminating all modules.Trying SP2 and then SP1 as backup
shankari
commented
3 weeks ago So it is almost certainly a cert issue. We are going with SP1 tomorrow and will have to figure out how to debug cert issues in the future.
shankari
commented
3 weeks ago With all these changes, SP1 works with EIM. PnC still fails because of SP1 and because the CSMS can't validate the cert. Set charging profile works, and returns the proper response
2024-06-14 02:05:33.588493 [DEBG] iso15118_car pybind11_init_everestpy(pybind11::module_&)::<lambda(const std::string&)> :: Decoded message (ns=urn:iso:15118:2:2013:MsgDef): {"V2G_Message":{"Header":{"SessionID":"CADE7FF7DE3FFF4F"},"Body":{"ChargingStatusRes":{"ResponseCode":"OK","EVSEID":"DE*PNX*00001","SAScheduleTupleID":1,"EVSEMaxCurrent":{"Multiplier":-1,"Unit":"A","Value":66},"MeterInfo":{"MeterID":"YETI_POWERMETER","MeterReading":10},"AC_EVSEStatus":{"NotificationMaxDelay":0,"EVSENotification":"None","RCD":false}}}}}Checking in these changes and re-cross-compiling...
EDIT: The demo is cursed. I finally got to the point where I had a stable build that included all the changes required for crosscompiling and was running (at least in a restricted version). And then the pionix release server went down, so no toolchain for me...
bd830b356e53:/# wget http://build.pionix.de:8888/release/toolchains/bullseye-toolchain.tgz
Connecting to build.pionix.de:8888 (35.242.226.179:8888)
wget: can't connect to remote host (35.242.226.179): Connection refusedEDIT: This is because I was on the VPN which blocks port 8888. getting off allows the download; phew!
shankari
commented
3 weeks ago Cross-compile was successful.
# cd /ext/source/build-cross/dist
# tar czvf charin-e2e-demo-smart-charging.tar.gz mnt/$ docker cp everest-ac-demo-manager-1:/ext/source/build-cross/dist/charin-e2e-demo-smart-charging.tar.gz .$ systemctl stop everest.service (this didn't work immediately, so had to start and then stop)
$ ps -aef | grep manager
everest 1604 1069 0 04:15 pts/0 00:00:00 grep --color=auto manager$ scp ~/joet-everest/everest-demo/charin-e2e-demo-smart-charging.tar.gz everest@...:/tmp$ pushd /tmp/
$ tar xzvf charin-e2e-demo-smart-charging.tar.gz
$ mv mnt/user_data/opt /mnt/user_data/$ /mnt/user_data/opt/everest/bin/manager --conf /mnt/user_data/custom_configs/2_config-dc-iso2.yaml
2024-06-14 04:21:21.275342 [ERRO] manager void Everest::Config::load_and_validate_manifest(const string&, const json&) :: Failed to load and parse manifest file /mnt/user_data/opt/everest/libexec/everest/modules/JsIMDSimulator/manifest.yaml: File 'manifest.(yaml|json)' does not exist
2024-06-14 04:21:21.279842 [ERRO] manager int boot(const boost::program_options::variables_map&) :: Failed to load and validate config!
2024-06-14 04:21:21.280027 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Caught top level boost::exception:
/ext/source/build-cross/_deps/everest-framework-src/lib/config.cpp(262): Throw in function void Everest::Config::load_and_validate_manifest(const string&, const json&)
Dynamic exception type: boost::wrapexcept<Everest::EverestConfigError>
std::exception::what: Failed to load and parse manifest file /mnt/user_data/opt/everest/libexec/everest/modules/JsIMDSimulator/manifest.yaml: File 'manifest.(yaml|json)' does not exist
[boost::log::v2_mt_posix::current_scope_info_tag*] = Everest::Config::Config(std::shared_ptr<Everest::RuntimeSettings>, bool)That won't actually work any more because the modules in the config have changed.
$ /opt/everest/libexec/everest/modules/JsIMDSimulator
$ /mnt/user_data/opt/everest/libexec/everest/modules/IMDSimulatorLet's copy over the config that we use with our SIL
$ scp ~/joet-everest/everest-demo/config-sil-ocpp201-pnc.yaml everest@169.254.223.122:/tmp$ /mnt/user_data/opt/everest/bin/manager --conf /tmp/config-sil-ocpp201-pnc.yaml
2024-06-14 04:27:19.688053 [ERRO] ocpp:OCPP201 void ocpp::v201::DeviceModel::check_integrity(const std::map<int, int>&) :: Integrity check in Device Model storage failed:Number of EVSE configured in device model is incompatible with number of configured EVSEs of the ChargePoint: 2: 1
terminate called after throwing an instance of 'ocpp::v201::DeviceModelStorageError'
what(): Number of EVSE configured in device model is incompatible with number of configured EVSEs of the ChargePoint: 2: 1It actually has 2 EVSEs and two connectors
$ sqlite3 opt/everest/share/everest/modules/OCPP201/device_model_storage.db
sqlite> select * from component;
20|InternalCtrlr|||
21|EVSE||1|
22|Connector||1|1
23|Connector||2|1
24|EVSE||2|It now starts up, but tries to connect to the local OCPP server, which fails. Resetting the host...
sqlite> update variable_attribute set "value"='[{"configurationSlot": 1, "connectionData": {"messageTimeout": 30, "ocppCsmsUrl": "ws://169.254.223.121/ws/cp001", "ocppInterface": "Wired0", "ocppTransport": "JSON", "ocppVersion": "OCPP20", "securityProfile": 1}}]' where id=161The OCPP connection is now set up correctly and we can receive a setChargingProfile!
2024-06-14 04:53:09.342111 [ERRO] ocpp:OCPP201 void ocpp::v201::ChargePoint::handle_set_charging_profile_req(ocpp::Call<ocpp::v201::SetChargingProfileRequest>) :: Received profile validity: ChargingScheduleChargingRateUnitUnsupportedsetting response to {
"status": "Rejected"
}But it is invalid because the rate is incorrect. Fixing that...
Next step: I see a message saying:
2024-06-14 04:55:39.453787 [INFO] ocpp:OCPP201 :: Logging SecurityEvents to file
2024-06-14 04:55:39.560707 [INFO] ocpp:OCPP201 :: TxStartPoints from device model: PowerPathClosed
2024-06-14 04:55:39.561344 [INFO] ocpp:OCPP201 :: TxStopPoints from device model: EVConnected,Authorized
2024-06-14 04:55:39.590262 [INFO] evse_manager_1: :: Ignoring BSP Event, BSP is not enabled yet.
2024-06-14 04:55:39.805773 [INFO] evse_manager_1: :: Max AC hardware capabilities: 32A/3ph
2024-06-14 04:55:39.880845 [INFO] car_simulator_1 :: Unplug detected, restarting simulation.
2024-06-14 04:55:39.911712 [INFO] evse_manager_1: :: AC HLC mode enabled.Let's enable the uMWC BSP on this config after copying it to a safe place.
Now the error is
2024-06-14 05:09:26.842693 [DEBG] yeti_driver_1:M void Everest::MQTTAbstractionImpl::on_mqtt_message(std::shared_ptr<Everest::Message>) :: topic everest/yeti_driver_1/board_support/cmd starts with everest/
2024-06-14 05:09:26.843793 [DEBG] yeti_driver_1:M Everest::Everest::provide_cmd(std::string, std::string, JsonCommand)::<lambda(Everest::json)> :: Incoming yeti_driver_1:MicroMegaWattBSP->board_support:evse_board_support->get_hw_capabilities() for <handler>
terminate called after throwing an instance of 'std::out_of_range'
what(): No known string conversion for provided enum of type Connector_typeI guess it is time to update the firmware but let's check the code and verify first.
shankari
commented
3 weeks ago Bingo!
The connector_type in https://github.com/EVerest/everest-core/blame/14aa49efe8a29d8e3e7f8485f522b4298fbe4250/types/evse_board_support.yaml#L3 was added in the commit that I identified at the beginning of this
https://github.com/EVerest/everest-core/commit/e194737f06f7a5a90635046635f399fd4582cd46 (feeling pretty good...)
Let's update the firmware. Firmware updates are failing
$ ./umwc_fwupdate /dev/serial0 ../share/everest/modules/YetiDriver/firmware/yetiR1_2.1_firmware.bin
uMWC ROM Bootloader Firmware Updater
uMWC ROM Bootloader Firmware Updater
cobsDecode: Garbage detected
cobsDecode: Garbage detected
Current uMWC SW Version: fcb731e (Protocol 0.1)
Rebooting uMWC in ROM Bootloader mode...
Executing stm32flash -b 115200 /dev/serial0 -v -w ../share/everest/modules/YetiDriver/firmware/yetiR1_2.1_firmware.bin -R ...
stm32flash 0.7
http://stm32flash.sourceforge.net/
Using Parser : Raw BINARY
Size : 114808
Interface serial_posix: 115200 8E1
Failed to init device, timeout.Reverting back to the simulator temporarily. This should allow us to get the communication to work again and have a "new" everest starting up by default. Then, we can try to downgrade the BSP and see if it works.
shankari
commented
3 weeks ago This might actually be easier than I thought, and might be a bug in the code.
The simulator, phytec board, and BSP all set the connector type, but the uMWC does not
./simulation/JsYetiSimulator/index.js: connector_type: 'IEC62196Type2Cable',
./PhyVersoBSP/connector_1/evse_board_supportImpl.cpp: caps.connector_type = types::evse_board_support::Connector_type::IEC62196Type2Socket;
./PhyVersoBSP/connector_1/evse_board_supportImpl.cpp: caps.connector_type = types::evse_board_support::Connector_type::IEC62196Type2Cable;
./PhyVersoBSP/connector_2/evse_board_supportImpl.cpp: caps.connector_type = types::evse_board_support::Connector_type::IEC62196Type2Socket;
./PhyVersoBSP/connector_2/evse_board_supportImpl.cpp: caps.connector_type = types::evse_board_support::Connector_type::IEC62196Type2Cable;
./YetiDriver/board_support/evse_board_supportImpl.cpp: caps.connector_type = types::evse_board_support::Connector_type::IEC62196Type2Cable;Let's try hardcoding it and rebuilding...
shankari
commented
3 weeks ago Hardcoded and rebuilt. However, I now get a different error
2024-06-14 07:51:10.152283 [ERRO] yeti_driver_1:M void module::MicroMegaWattBSP::ready() :: uMWC reset not successful.
terminate called after throwing an instance of 'boost::wrapexcept<Everest::EverestInternalError>'
what(): uMWC reset not successful.
2024-06-14 07:51:10.326674 [ERRO] ocpp:OCPP201 void ocpp::v201::ChargePoint::handle_message(const ocpp::EnhancedMessage<ocpp::v201::MessageType>&) :: json_message called: [3,"3eb46edd-8338-4a57-adea-21cea3610694",{"status":"Failed"}]
2024-06-14 07:51:11.059698 [CRIT] manager int boot(const boost::program_options::variables_map&) :: Module yeti_driver_1 (pid: 2922) exited with status: 134. Terminating all modules.So it looks like the BSP initialization will fail with the new everest. Will send an email but we may just have to experiment with general ISO 15118 tomorrow and not support smart charging
shankari
commented
3 weeks ago Response from Pionix is that the power BSP (yeti board) might be bricked if we tried to flash the firmware while everest was running!! The original message had said that we could roll back by "decreasing the timestamp version in /etc/update.meta".
I was freaked out and couldn't sleep. However, the old version of everest still works although there are some "garbage detected" messages there too.
$ sudo /opt/everest/bin/manager --conf /opt/everest/conf/3_config-ac-iso2.yaml
2024-06-14 11:35:27.136600 [INFO] yeti_driver:Mic :: Module yeti_driver initialized [3592ms]
2024-06-14 11:35:27.310689 [INFO] iso15118_charge :: Module iso15118_charger initialized [3977ms]
2024-06-14 11:35:27.704641 [INFO] manager :: 🚙🚙🚙 All modules are initialized. EVerest up and running [8421ms] 🚙🚙🚙
cobsDecode: Garbage detected
cobsDecode: Garbage detected
2024-06-14 11:35:29.380468 [INFO] slac:EvseSlac :: EvseSlac: Entered Idle state
2024-06-14 11:35:29.559732 [INFO] evse_manager:Ev :: AC HLC mode enabled.
2024-06-14 11:35:29.672688 [INFO] evse_manager:Ev :: 🌀🌀🌀 Ready to start charging 🌀🌀🌀I just tried to read from the serial port and it is sending data continuously with the same repeated string (2fcb731e) so it doesn’t appear to be random noise. So I really don’t think that it is bricked.
everest@umwcdbde:~ $ cat /dev/serial0
@@xM"B
��7�~�7��s��)(2fcb731e��B
c�7�d�7�!!�@�?��t�B
d�7�}�7�+��)(2fcb731e'c�B
2�7���7���
@?�|��)(2fcb731e��DB
��7���7�p�9OB
~�7���7�h��@?�|��)(2fcb731e[��B
�7�ʣ7���ІBAlthough I can write to the serial port as non-root, so that is not the reason why we are not able to flash and does not provide any indication that we could not have bricked the board.
everest@umwcdbde:~ $ echo HELO > /dev/serial0
everest@umwcdbde:~ $I am pretty sure that it is not bricked. The communication with the uMWC has (from modules/MicroMegaWattBSP/umwc_comms/protobuf/umwc.proto)
message KeepAlive {
uint32 time_stamp = 1;
uint32 hw_type = 2;
uint32 hw_revision = 3;
string sw_version_string = 6;
}
or
message KeepAliveLo {
uint32 time_stamp = 1;
uint32 hw_type = 2;
uint32 hw_revision = 3;
uint32 protocol_version_major = 4;
uint32 protocol_version_minor = 5;
string sw_version_string = 6;
float hwcap_max_current = 7;
float hwcap_min_current = 8;
uint32 hwcap_max_phase_count = 9;
uint32 hwcap_min_phase_count = 10;
bool supports_changing_phases_during_charging = 11;
} Both of them have string sw_version_string. From our attempt to flash the yeti,
https://github.com/EVerest/everest-demo/issues/51#issuecomment-2167266067
Current uMWC SW Version: fcb731e (Protocol 0.1)And we see that repeat over and over in the serial stream
��7��7�l�Y��,(2fcb731e�2��B
ʣ7���7��)�@?�|���,(2fcb731e�-kCB
K�7���7�[��CB
ʣ7��7�D{�`�?|\��,(2fcb731eP��PB
��7��7�l�RB
�7���7��p0`�?|\��,(2fcb731eم�}B
}�7���7�l�q$@?�|��B
��7��7��A��,(2fcb731e�B��BTried to boot up the uMMW charger but I think the USB-C cable is not working. Placed an order for a new cable from IT.
The EVerest project has open hardware as well https://everest.github.io/nightly/hardware/pionix_belay_box.html which is available as a kit from Pionix. Pionix also sells the uMWC (https://shop.pionix.com/products/umwc-micro-mega-watt-charger). This is is a non-open device in a housing that shares some hardware with the Belay Box although it has a different power module that is limited to 1W output.
In this issue, we will track the steps to run a custom build of EVerest on the uMWC so that we can perform HIL testing.
@faizanmir21 The instructions are here: https://everest.github.io/nightly/hardware/pionix_belay_box.html#developing-with-everest-and-belaybox
They are for the Belay Box, but I'm hoping that they will apply to the uMWC as well. If not, we can ask the community for help.
My suggested steps are:
everest-dev.serviceand verify that it starts the dev build from/mnt/user_data/opt/everestdocker exec -it ....manager /bin/bashORdocker run -it ghcr.io/everest/everest-demo/manager:0.0.16 /bin/bash@drmrd @couryrr-afs @wjmp for visibility