The string is built using git describe, which fetches the most recent tag from the current tree: balzer@leela:~/esp/esp-idf> git describe --always --tags --dirty v3.1-dev-391-g8d8d62da That's set at… balzer@leela:~/esp/esp-idf> git show v3.1-dev commit 22489d70214a5b7650ab197ffd6ab73e9c50a772 Merge: c4448714 f58c5b21 Author: Jiang Jiang Jian <jack@espressif.com> Date: Fri Dec 1 22:06:43 2017 +0800 Merge branch 'bugfix/wdt_periph_enable' into 'master' watchdogs: make sure timer group peripherals are enabled See merge request !1623 So you're missing that tag ref after doing a fresh clone… …and indeed, the tag is missing from our fork on github, it's only present in the esp origin: https://github.com/openvehicles/esp-idf/tree/v3.1-dev → 404 https://github.com/espressif/esp-idf/tree/v3.1-dev → ok So it seems we forgot to push the tags we fetched from upstream into our own fork. I did that now, so if you pull again, you should get the tag and the version string should be up to date. But that should have had no effect on your issue then, as the revision tree is consistent. Tags are just that -- tags. Another idea on your issue then: is your partition table unchanged & correct? balzer@leela:~/esp/Open-Vehicle-Monitoring-System-3/vehicle/OVMS.V3> cat partitions.csv # OVMS 16MB flash ESP32 Partition Table # Name, Type, SubType, Offset, Size nvs, data, nvs, 0x9000, 0x4000 otadata, data, ota, 0xd000, 0x2000 phy_init, data, phy, 0xf000, 0x1000 factory, app, factory, 0x10000, 4M ota_0, app, ota_0, , 4M ota_1, app, ota_1, , 4M store, data, fat, , 1M Regards, Michael Am 16.02.2018 um 19:24 schrieb Greg D.:
Hi Michael,
Yes, that was one of the first things I checked. It points to /home/greg/esp/esp-idf, which is the current esp-idf directory.
m.version is this:
OVMS > metrics list m.version m.version 3.0.0/factory/main build (idf v3.0-dev-1781-g8d8d62da) Feb 15 2018 22:01:48 OVMS >
Where would I find the source of that string in the build environment?
Greg
Michael Balzer wrote:
Greg,
have you checked your IDF_PATH?
What does "m.version" show?
Regards, Michael
Am 16.02.2018 um 09:27 schrieb Greg D.:
Present and accounted for. Also, when I compile code, there's no warning about cross-versions, and I have a fresh copy of esp-idf from Github. When I had the wrong branch, there was a warning about mismatched versions.
So, the git log matches, yet what I'm building doesn't; that's like, impossible, right?
Greg
Mark Webb-Johnson wrote:
Another thought - maybe the compiler version?
3.1 requires xtensa gcc 1.22.0-80 (g6c4433a-5.2.0).
https://esp-idf.readthedocs.io/en/latest/get-started/linux-setup.html
Regards, Mark.
On 16 Feb 2018, at 2:19 PM, Stephen Casner <casner@acm.org <mailto:casner@acm.org>> wrote:
Mine says:
OVMS > metrics list m.version m.version 3.0.0/factory/main build (idf v3.1-dev-212-g00fa3889-dirty) Feb 7 2018 22:10:10
But, truth be told, I'm currently compiing from my own fork of espressif/esp-idf that I set up to issue a PR to espressif for my changes that support the memory diagnostics.
-- Steve
On Thu, 15 Feb 2018, Greg D. wrote:
Ok. Back to half-sanity. rm -rf esp-idf, Refetched from master including submodule stuff, rm -r build, make clean, make, make flash. Compiles and runs.
But still shows wrong version for m.version, and /store is still a mess. Not sure if I care about the m.version; what is going on with vfs?
Back to the TV...
Greg
Stephen Casner wrote:
Right.
-- Steve
On Thu, 15 Feb 2018, Greg D. wrote:
Ok, so master from the openvehicles clone?
Greg
Stephen Casner wrote:
Gre,
No, we left behind the v2.1 of esp-idf a while ago. We're now on master.
-- Steve
On Thu, 15 Feb 2018, Greg D. wrote:
Mmm, never mind... I realize we're still based on v2.1, right?
I've re-fetched stuff from the 2.1 branch, and still have the same results. v3.0.0 listed as m.version, and junk in /store.
Now what?
Greg
Greg D. wrote: Ok, this is odd... Are you sure esp-idf v3.1 is actually on Github? Tried re-fetching everything, and found this:
greg@linux-0rpb:~/esp> git clone https://github.com/openvehicles/esp-idf.git Cloning into 'esp-idf'... remote: Counting objects: 44182, done. remote: Compressing objects: 100% (8/8), done. remote: Total 44182 (delta 0), reused 1 (delta 0), pack-reused 44174 Receiving objects: 100% (44182/44182), 50.53 MiB | 11.75 MiB/s, done. Resolving deltas: 100% (31074/31074), done. greg@linux-0rpb:~/esp> cd esp-idf greg@linux-0rpb:~/esp/esp-idf> git branch -a * master remotes/origin/HEAD -> origin/master remotes/origin/feature/psram_malloc remotes/origin/master remotes/origin/release/v2.0 remotes/origin/release/v2.1 remotes/origin/release/v3.0 greg@linux-0rpb:~/esp/esp-idf>
Shouldn't there be a v3.1 listed there too? Last entry is 3.0.
Anyway, the first question is whether we have one problem or two... Is my problem with /store related to v3.0 vs v3.1, or is it a separate problem on its own? Do I simply need to clear flash and reload my config? If so, what is the best way?
Greg
Mark Webb-Johnson wrote: Nope. Old hardware. Out of ideas. I thought it just picked up the git version.
Regards, Mark.
On 15 Feb 2018, at 12:07 PM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
No difference.
Are you on the new hardware?
Greg
Mark Webb-Johnson wrote: In your ovms directory: make clean rm -rf build make flash
That’s all I can think of.
Regards, Mark
On 15 Feb 2018, at 11:59 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Yes, and yes. The top entry exactly matches your log.
Greg
Mark Webb-Johnson wrote: And you’ve already ‘git pull’ and ‘git submodule update’ in that esp idf? If you ‘git log’, you should get:
commit 8d8d62da9e58305c8f7f4792264f8cab3ffe104b (HEAD -> master, origin/master, origin/HEAD) Merge: 5bf85d06 ca3faa61 Author: Mark Webb-Johnson <mark@webb-johnson.net <mailto:mark@webb-johnson.net>> Date: Tue Feb 13 13:27:55 2018 +0800
Merge remote-tracking branch 'espressif/master'
(which is where the 8d8d62da comes from)
Regards, Mark.
On 15 Feb 2018, at 11:42 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Yes and yes. greg@linux-0rpb:~/esp/esp-idf> git branch -a * master remotes/origin/HEAD -> origin/master
remotes/origin/feature/psram_malloc remotes/origin/master remotes/origin/release/v2.0 remotes/origin/release/v2.1 remotes/origin/release/v3.0 greg@linux-0rpb:~/esp/esp-idf> git remote -v origin https://github.com/openvehicles/esp-idf.git (fetch) origin https://github.com/openvehicles/esp-idf.git (push) greg@linux-0rpb:~/esp/esp-idf>
Greg
Mark Webb-Johnson wrote: In your esp idf directory, can you check ‘git branch -a’. Make sure you are on ‘master’ branch. Also ‘git remote -v’. Make sure you are on openvehicles clone. Mark
On 15 Feb 2018, at 10:24 AM, Greg D. <gregd2350@gmail.com <mailto:gregd2350@gmail.com>> wrote:
Hi Mark,
So, I changed the CONFIG_LWIP_SO_REUSE value and did a make flash. That displayed another option, default Yes, changed to no. But, same result with /store.
One significant difference is that you're on idf 3.1 and I'm on 3.0... (3.0.0/factory/main build (idf v3.0-dev-1781-g8d8d62da) Feb 14 2018 18:12:05)
Did I miss a cog on this?
Greg
Mark Webb-Johnson wrote: My store seems ok: OVMS > vfs ls /store ovms_config obd2ecu play
OVMS > metrics list m.version m.version
3.0.0/factory/main build (idf v3.1-dev-391-g8d8d62da) Feb 13 2018 14:05:21
Anybody else seeing this issue?
Regarding the CONFIG_LWIP_SO_REUSE, in menuconfig you can use ‘/‘ to search for it. The parameter is in Component Config / LWIP.
Regards, Mark.
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk <mailto:OvmsDev@lists.teslaclub.hk> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/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.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
_______________________________________________ OvmsDev mailing list OvmsDev@lists.teslaclub.hk http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-- Michael Balzer * Helkenberger Weg 9 * D-58256 Ennepetal Fon 02333 / 833 5735 * Handy 0176 / 206 989 26