[Ovmsdev] PSRAM fix in esp-idf release v3.3
Chris van der Meijden
chris at arachnon.de
Thu Jul 16 19:10:22 HKT 2020
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 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/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 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
> > >
> > >
> >
> >
> >
> > --
> > 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
> >
> >
>
>
>
> --
> 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/89a8dbf4/attachment.html>
More information about the OvmsDev
mailing list