PSRAM fix in esp-idf release v3.3
Mark, it seems the fix has finally arrived in the official release 3.3 branch: https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact. Regards, Michael -- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Finally… Crazy that this took so long. We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com/>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up. What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com/>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain? Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)? Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 <https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913>
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... <https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8>
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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
Yes, differences on the test branches are minor, also in esp-idf. But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work. I'll fetch the current toolchain version and check what is needed. Regards, Michael Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc...
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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 http://lists.openvehicles.com/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
Everyone, I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master. To build now, you need to: 1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download the toolchain for your OS from https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/inde..., simply replace your existing toolchain installation by unpacking the archive. Test your toolchain installation by checking xtensa-esp32-elf-gcc --version. 2. Pull our latest esp-idf master and -important- update the submodules 3. Pull/checkout our latest OVMS master 4. Update your sdkconfig from support/sdkconfig.default.hw31 The build should then result in version 3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 16 2020 10:53:38) or higher. Regards, Michael Am 15.07.20 um 08:07 schrieb Michael Balzer:
Yes, differences on the test branches are minor, also in esp-idf.
But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Regards, Michael
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc...
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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 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
Hey Michael, thanks for the great little "howto". Worked perfectly fine for me on Linux. My new ovms3.bin comiled, installed und runs: 3.2.013-336-ga4349710/ota_1/main (build idf v3.3.2-879-g0137aef47 Jul 16 2020 12:22:49) Greetinx Chris Am Donnerstag, den 16.07.2020, 11:27 +0200 schrieb Michael Balzer:
Everyone,
I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master.
To build now, you need to:
1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download the toolchain for your OS from https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-start ed/index.html#setup-toolchain, simply replace your existing toolchain installation by unpacking the archive. Test your toolchain installation by checking xtensa-esp32-elf-gcc --version.
2. Pull our latest esp-idf master and -important- update the submodules
3. Pull/checkout our latest OVMS master
4. Update your sdkconfig from support/sdkconfig.default.hw31
The build should then result in version 3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879- g0137aef47 Jul 16 2020 10:53:38) or higher.
Regards,
Michael
Am 15.07.20 um 08:07 schrieb Michael Balzer:
Yes, differences on the test branches are minor, also in esp- idf.
But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Regards,
Michael
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de> wrote: Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2 892#issuecomment-658327913
https://github.com/espressif/esp-idf/commit/f 4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
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 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
_______________________________________________ OvmsDev mailing list OvmsDev@lists.openvehicles.com http://lists.openvehicles.com/mailman/listinfo/ovmsdev
OK. I’ve done this on the api.openvehicles.com <http://api.openvehicles.com/> build system (Linux based). My edge build gives: 3.2.013-298-g025f838/ota_0/edge (build idf v3.3.2-879-g0137aef Jul 16 2020 19:25:08) But, the Mac osx download link gives: curl https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-96-g2852398-5.2.0.ta... <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.14.0 (Ubuntu)</center> </body> </html> Oh, good grief. I’ll try to take it up with espressif… Regards, Mark.
On 16 Jul 2020, at 5:27 PM, Michael Balzer <dexter@expeedo.de> wrote:
Everyone,
I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master.
To build now, you need to:
1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download the toolchain for your OS from https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/inde... <https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/index.html#setup-toolchain>, simply replace your existing toolchain installation by unpacking the archive. Test your toolchain installation by checking xtensa-esp32-elf-gcc --version.
2. Pull our latest esp-idf master and -important- update the submodules
3. Pull/checkout our latest OVMS master
4. Update your sdkconfig from support/sdkconfig.default.hw31
The build should then result in version 3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 16 2020 10:53:38) or higher.
Regards, Michael
Am 15.07.20 um 08:07 schrieb Michael Balzer:
Yes, differences on the test branches are minor, also in esp-idf.
But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Regards, Michael
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com/>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com/>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 <https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913>
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... <https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8>
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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 <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 <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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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
Mark, try: https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-96-g2852398-5.2.0.... …got that from here: https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... But the link needs to be fixed anyway. Regards, Michael Am 16.07.20 um 13:48 schrieb Mark Webb-Johnson:
OK. I’ve done this on the api.openvehicles.com <http://api.openvehicles.com> build system (Linux based). My edge build gives:
3.2.013-298-g025f838/ota_0/edge (build idf v3.3.2-879-g0137aef Jul 16 2020 19:25:08)
But, the Mac osx download link gives:
curl https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-96-g2852398-5.2.0.ta... <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.14.0 (Ubuntu)</center> </body> </html>
Oh, good grief. I’ll try to take it up with espressif…
Regards, Mark.
On 16 Jul 2020, at 5:27 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master.
To build now, you need to:
1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download the toolchain for your OS from https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/inde..., simply replace your existing toolchain installation by unpacking the archive. Test your toolchain installation by checking xtensa-esp32-elf-gcc --version.
2. Pull our latest esp-idf master and -important- update the submodules
3. Pull/checkout our latest OVMS master
4. Update your sdkconfig from support/sdkconfig.default.hw31
The build should then result in version 3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 16 2020 10:53:38) or higher.
Regards, Michael
Am 15.07.20 um 08:07 schrieb Michael Balzer:
Yes, differences on the test branches are minor, also in esp-idf.
But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Regards, Michael
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com/>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com/>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc...
Btw:
In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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 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 _______________________________________________ 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
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26
That works great. gcc version 5.2.0 (crosstool-NG crosstool-ng-1.22.0-96-g2852398). Saves me building it manually. Regards, Mark.
On 16 Jul 2020, at 8:07 PM, Michael Balzer <dexter@expeedo.de> wrote:
Mark,
try: https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-96-g2852398-5.2.0.... <https://dl.espressif.com/dl/xtensa-esp32-elf-macos-1.22.0-96-g2852398-5.2.0.tar.gz>
…got that from here: https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... <https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8#diff-0633a6582c888c6fc5bc6a3c00dba496R56>
But the link needs to be fixed anyway.
Regards, Michael
Am 16.07.20 um 13:48 schrieb Mark Webb-Johnson:
OK. I’ve done this on the api.openvehicles.com <http://api.openvehicles.com/> build system (Linux based). My edge build gives:
3.2.013-298-g025f838/ota_0/edge (build idf v3.3.2-879-g0137aef Jul 16 2020 19:25:08)
But, the Mac osx download link gives:
curl https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-96-g2852398-5.2.0.ta... <https://dl.espressif.com/dl/xtensa-esp32-elf-osx-1.22.0-96-g2852398-5.2.0.tar.gz> <html> <head><title>404 Not Found</title></head> <body bgcolor="white"> <center><h1>404 Not Found</h1></center> <hr><center>nginx/1.14.0 (Ubuntu)</center> </body> </html>
Oh, good grief. I’ll try to take it up with espressif…
Regards, Mark.
On 16 Jul 2020, at 5:27 PM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Everyone,
I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master.
To build now, you need to:
1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download the toolchain for your OS from https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/inde... <https://docs.espressif.com/projects/esp-idf/en/release-v3.3/get-started/index.html#setup-toolchain>, simply replace your existing toolchain installation by unpacking the archive. Test your toolchain installation by checking xtensa-esp32-elf-gcc --version.
2. Pull our latest esp-idf master and -important- update the submodules
3. Pull/checkout our latest OVMS master
4. Update your sdkconfig from support/sdkconfig.default.hw31
The build should then result in version 3.2.013-298-g025f838b/factory/edge (build idf v3.3.2-879-g0137aef47 Jul 16 2020 10:53:38) or higher.
Regards, Michael
Am 15.07.20 um 08:07 schrieb Michael Balzer:
Yes, differences on the test branches are minor, also in esp-idf.
But we probably also need to pull in the latest changes on the esp-idf 3.3 branch, which may be some more work.
I'll fetch the current toolchain version and check what is needed.
Regards, Michael
Am 15.07.20 um 04:13 schrieb Mark Webb-Johnson:
Finally… Crazy that this took so long.
We have a GetOVMSHardware() in ovms_version.cpp that picks up the esp_chip_info_t structure and has chip.revision (documented as "chip revision number”). That is stored in metric m.hardware. My bench unit is showing rev=ESP32/1. I checked a bunch of recent cars connected to api.openvehicles.com <http://api.openvehicles.com/>, but all showed the same. So not sure if the v3 silicon is not reported in that chip.revision, if we are just using existing stocks, or an IDF update is required to pickup the new silicon version number. The v3 seems fairly recent (March 2020?) and I don’t see a v2 listed. Anyway, I’ve just yesterday received a new batch of modules so will check those to see if it shows up.
What do we need to do to switch to this? Presumably I turn off auto-build of the firmware on api.openvehicles.com <http://api.openvehicles.com/>, you merge your SPIRAM branch to master, we tell everyone to download the new toolchain, then we switch both our edge builds back to master branch with new toolchain?
Apart from the CONFIG_SPIRAM_SUPPORT 2MB workaround, I can’t see any significant differences between remotes/origin/spiram-fix-test and master? Is the only difference the ovms_websockethandler.cpp change to std::string (vs extram::string)?
Regards, Mark.
On 15 Jul 2020, at 2:11 AM, Michael Balzer <dexter@expeedo.de <mailto:dexter@expeedo.de>> wrote:
Mark,
it seems the fix has finally arrived in the official release 3.3 branch:
https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913 <https://github.com/espressif/esp-idf/issues/2892#issuecomment-658327913>
https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bc... <https://github.com/espressif/esp-idf/commit/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8>
Btw:
> > In the v3 silicon, the issue has been fixed, and the workaround is no longer required.
I guess that means from some manufacturing point on we should provide two builds, one for the older hardware and one for the modules with v3 chips, as the fix definitely has a performance impact.
Regards, Michael
-- 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 <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 <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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <mailto:OvmsDev@lists.openvehicles.com> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <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 <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
On 2020-07-16 02:27, Michael Balzer wrote:
I've merged the latest release/v3.3 esp-idf into our idf fork and merged the PSRAM fix test branch into our OVMS master. [...] 1. Update your toolchain to release 1.22.0-96-g2852398-5.2.0: download [...] Test your toolchain installation by checking xtensa-esp32-elf-gcc --version
This is awesome; I have built this version of the toolchain under FreeBSD and will update the FreeBSD port soon.
2. Pull our latest esp-idf master and -important- update the submodules
(For reference) this is what I use: git pull git submodule update --recursive I hope this update generates some momentum for us to move towards a v4 esp-idf and gcc8. That said I'm still very happy to get the psram fix toolchain and esp-idf for my (non-mainstream) build environment. Craig
participants (4)
-
Chris van der Meijden -
Craig Leres -
Mark Webb-Johnson -
Michael Balzer