[Ovmsdev] PSRAM fix in esp-idf release v3.3

Thu Jul 16 19:48:09 HKT 2020

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.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 at 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/index.html#setup-toolchain <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 at expeedo.de <mailto:dexter at 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/f4333c8e3a554e8bb4210d825cbdf4bcaa1fc1b8 <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 at lists.openvehicles.com <mailto:OvmsDev at lists.openvehicles.com>
>>>> http://lists.openvehicles.com/mailman/listinfo/ovmsdev <http://lists.openvehicles.com/mailman/listinfo/ovmsdev>
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> OvmsDev mailing list
>>> OvmsDev at lists.openvehicles.com <mailto:OvmsDev at 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 at lists.openvehicles.com <mailto:OvmsDev at 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 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/20200716/ff7006b3/attachment.htm>