[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.htm>


More information about the OvmsDev mailing list