[Ovmsdev] Awfully quiet out there
Mark Webb-Johnson
mark at webb-johnson.net
Fri Feb 16 16:06:48 HKT 2018
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 <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 at 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 at 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 at linux-0rpb:~/esp> cd esp-idf
>> greg at 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 at 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 at 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 at 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 at 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 at gmail.com> wrote:
>>
>> Yes and yes.
>> greg at 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 at 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 at 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 at 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 at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
>>>
>>
>>
>> _______________________________________________
>> OvmsDev mailing list
>> OvmsDev at lists.teslaclub.hk
>> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
>>
>>
>>
> _______________________________________________
> OvmsDev mailing list
> OvmsDev at lists.teslaclub.hk
> http://lists.teslaclub.hk/mailman/listinfo/ovmsdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvehicles.com/pipermail/ovmsdev/attachments/20180216/7dbe07af/attachment.htm>
More information about the OvmsDev
mailing list