search

Marus / cortex-debug

Visual Studio Code extension for enhancing debug capabilities for Cortex-M Microcontrollers
MIT License
1.02k stars 241 forks source link

Use windows subsystem for linux for tools #66

Open babryce opened 6 years ago

babryce commented 6 years ago

This is a feature request, if it is possible add support for windows subsystem for linux (WSL)

basically if the flag were set true the commands for arm toolchain would or maybe openocd would be:

bash -c

At present this doesn't look possible because if it is under windows the executable name appends the .exe

Marus commented 6 years ago

I'll have to look into this; have never actually setup anything with the windows subsystem for linux stuff yet. Generally if I want to use Linux I just spin up a different/additional VM.

While I'm sure the toolchain itself should function under the subsystem, does OpenOCD actually work properly under it, just wasn't sure if it was going to be able to properly access the debug probes from the subsystem.

babryce commented 6 years ago

It looks like you might be right and WSL doesn't fully support USB yet but they are getting there it looks like: https://blogs.msdn.microsoft.com/commandline/2017/05/10/bashwsl-insiders-build-now-supports-usbserial-comms-and-mounting-removable-storage-network-shares/

It seems a lot lower resource intensive than VM to me, works well for compile/make tools.

On Sun, Jun 10, 2018 at 8:54 PM, Marcel Ball notifications@github.com wrote:

I'll have to look into this; have never actually setup anything with the windows subsystem for linux stuff yet. Generally if I want to use Linux I just spin up a different/additional VM.

While I'm sure the toolchain itself should function under the subsystem, does OpenOCD actually work properly under it, just wasn't sure if it was going to be able to properly access the debug probes from the subsystem.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66#issuecomment-396096129, or mute the thread https://github.com/notifications/unsubscribe-auth/Afp4eFADscNSwZ--vvhrJsAsIBC6mwQSks5t7b_hgaJpZM4Uhjjz .

Marus commented 6 years ago

I don't think I'll look into this right now, but should they add support for USB through WSL then I might consider it.

kmitchel commented 5 years ago

@Marus I'm having to switch over to using the VSCode WSL pluggin. Compiling on /mnt/c with WSL2 is horrible. Cortex-Debug is attempting to run GDB (which works) and OpenOcd on WSL. Can I please get an option for Cortex-Debug to not attempt to spawn OpenOcd, and I would just manually launch it on the Windows side.

I'm trying 'external'.

haneefdm commented 5 years ago

@kmitchel, @Marus recently added this in version V0.2.7. Maybe you should give it a try and report back.

See the first bullet in the ChangeLog for V0.2.7

We would love to know how well this works for you. On WSL2 MS now recommends that for fastest file IO you should do it all in the Linux side of the file-system. They totally changed their policy/implementation between WSL and WSL2. WSL2 is more like a VM now.

kmitchel commented 5 years ago

It looks as if external is what I need...but for some reason I can't connect to 127.0.0.1:3333. Not sure if Win10 is being stupid or me.

The file system changes are no joke. Compiling Betaflight, I timed it at like 18 seconds on the linux file system, and 2:39 on the mnt point. I wish I had timed it on WSL1.

Looks like I can't open ports on the Win10 side from WSL.

haneefdm commented 5 years ago

I think in WSL2, it gets its own IP address and your windows host will get has its own. 127.0.0.1 refers to localhost/loopback which in this case will be the Unix host in Unix and Windows host on the Windows side.

You can always use the fully qualified IPV4 address of your Windows host.

On windows, you can use 'ipconfig' with no arguments to see your actual IPv4 address.

kmitchel commented 5 years ago

Connecting on various IPs gives me connection time outs. I am able to wget nginx running on Win10 side. External does work without WSL, on 127.0.0.1.

On Mon, Jun 17, 2019 at 8:05 PM Haneef Mohammed notifications@github.com wrote:

I think in WSL2, it gets its own IP address and your windows host will get has its own. 127.0.0.1 refers to localhost/loopback which in this case will be the Unix host in Unix and Windows host on the Windows side.

You can always use the fully qualified IPV4 address of your Windows host.

On windows, you can use 'ipconfig' with no arguments to see your actual IPv4 address.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AAPRSYC5FG3TBQOL75QQKMLP3ARDJA5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4Y7ZY#issuecomment-502894567, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPRSYCMQRIEALT3REEXAKDP3ARDJANCNFSM4FEGHDZQ .

haneefdm commented 5 years ago

Can you start command-line gdb on WSL2 and have it connect to OpenOCD? If that does not work, neither will Cortex-Debug. The IP:port simply passed to gdb.

kmitchel commented 5 years ago

arm-none-eabi-gdb times out ...disabled firewall...different ip's. Firewall was interfering with the shared 172.18.47.0 network.

On Mon, Jun 17, 2019 at 9:05 PM Haneef Mohammed notifications@github.com wrote:

Can you start command-line gdb on WSL2 and have it connect to OpenOCD? If that does not work, neither will Cortex-Debug. The IP:port simply passed to gdb.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AAPRSYDPJZUXIJUJ7VKK74LP3AYGNA5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX43TNI#issuecomment-502905269, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPRSYDJMUJMAM5FSKFIYEDP3AYGNANCNFSM4FEGHDZQ .

haneefdm commented 5 years ago

@kmitchel So, problem solved? Or still have issues?

kmitchel commented 5 years ago

As far as Cortex-Debug is concerned...external is the solution I need, and it does work without WSL involved. But why gdb on WSL will not connect to OpenOCD on Win10 is still a problem. I'm going to try gdb on a VM or another host, see if it's just WSL. I'll let you know how it goes.

On Mon, Jun 17, 2019, 10:00 PM Haneef Mohammed notifications@github.com wrote:

@kmitchel https://github.com/kmitchel So, problem solved? Or still have issues?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AAPRSYHRWPPZBN64DLIIRJLP3A6VRA5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX46DHI#issuecomment-502915485, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPRSYFZYJYDSA6BZ4IJWTTP3A6VRANCNFSM4FEGHDZQ .

kmitchel commented 5 years ago

OpenOCD only binds to 127.0 0.1 by default! Doh.

haneefdm commented 5 years ago

Okay, this rings a bell. On Windows, 127.0.0.1 (localhost) and 0.0.0.0 (thishost) are actually separate addresses and you can run distinct servers on those addresses. On Unixes, they are are aliases. What could be is that the actual IP addresses may also be a distinct address? Unfortunately, with OpenOCD you can only specify the port number and not the IP address to bind to. Only talking IPv4.

I will try to run an experiment later today to see Windows behavior (and maybe Linux/Mac) to confirm.

@Marus, this is why in the new port finder, if any of the localhost aliases is running a server, we avoid and pick another port.

kmitchel commented 5 years ago

I was able to pass -c "bindto 0.0.0.0" to OpenOCD to make it work.

On Tue, Jun 18, 2019, 9:10 AM Haneef Mohammed notifications@github.com wrote:

Okay, this rings a bell. On Windows, 127.0.0.1 (localhost) and 0.0.0.0 (thishost) are actually separate addresses and you can run distinct servers on those addresses. On Unixes, they are are aliases. What could be is that the actual IP addresses may also be a distinct address? Unfortunately, with OpenOCD you can only specify the port number and not the IP address to bind to. Only talking IPv4.

I will try to run an experiment later today to see Windows behavior (and maybe Linux/Mac) to confirm.

@Marus https://github.com/Marus, this is why in the new port finder, if any of the localhost aliases is running a server, we avoid and pick another port.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AAPRSYAEY3AQQ6AMFQZAFKLP3DUE5A5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX6YBMY#issuecomment-503152819, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPRSYEAHCNYOXALGLDYEPLP3DUE5ANCNFSM4FEGHDZQ .

haneefdm commented 5 years ago

Glad you found a workaround...good to know about that command for openocd.

I have a tiny javascript program that you can use to see which ports are aliases. It tries to create servers on all aliases and see which ones are distinct on a given system. I did it JS because I want to take into consideration any anomalies Node.js may add to the equation. It tests both IPv4 and IPv6.

https://drive.google.com/open?id=1zbQ6uh7rEG-1Uwr8lY5C_qMFotO29K6k

Download the file and run command 'node port-tester.js'

I run it twice in two different windows to make sure. The second run should just exit without being able to create any servers. The first one will just hang and you have to kill it with a Control-C

haneefdm commented 5 years ago

That usually means that either the executable does not have symbols and/or the path names used to compile the code cannot be found from where Cortex-Debug abd gdb are running.

On Wed, Jun 19, 2019 at 5:06 PM Kenneth Mitchell notifications@github.com wrote:

Breakpoints do not work, and VSCode just displays assembly...any suggestions?

kmitchel commented 5 years ago

Y...I screwed up. I didn't clean after adding debug symbols to build task. I assumed makefile would recompile everything that didn't have debug symbols. Everything works correctly now. Ty!

On Wed, Jun 19, 2019, 11:24 PM Haneef Mohammed notifications@github.com wrote:

That usually means that either the executable does not have symbols and/or the path names used to compile the code cannot be found from where Cortex-Debug/gdb are running.

On Wed, Jun 19, 2019 at 5:06 PM Kenneth Mitchell <notifications@github.com

wrote:

Breakpoints do not work, and VSCode just displays assembly...any suggestions?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub < https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AJ23STYR25ENQPP3VALFBDDP3LCYPA5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYDTT7Q#issuecomment-503790078 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AJ23STY5P2DBSAVMEMEZ6YTP3LCYPANCNFSM4FEGHDZQ

.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Marus/cortex-debug/issues/66?email_source=notifications&email_token=AAPRSYAL7FWMRQS7QD5QOJ3P3LZ6DA5CNFSM4FEGHDZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYD4PIQ#issuecomment-503826338, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPRSYG6WNJ6S4T3CYWPUATP3LZ6DANCNFSM4FEGHDZQ .