Hello,
I believe we finally have a working Windows port of newt and its related
tools. Here I will provide some instructions for getting the Windows
port up and running. For details on the port implementation, please see
the previous email.
All feedback is appreciated.
Thanks,
Chris
INSTALLATION:
1. Download and run the Go installer for Windows, if you do not already
have Go.
https://golang.org/dl/
2. Download the Docker Toolbox for Windows (version 1.9.0c or later).
https://www.docker.com/docker-toolbox
3. Run the Docker Toolbox installer. All the default settings are OK.
4. You may need to add "C:\Program Files\Git\usr\bin" to your PATH
environment variable. The installer says it updates this setting
automatically, but it did not seem to work for me.
5. Pull or clone the latest code from the newt repository.
https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
6. Build and install the newtvm tool. This tool is located in the
newt/tools/newtvm directory in the above repository. This is done as
follows:
cd newt\tools\newtvm
go install
The product of this step is the following executable:
%GOPATH%\bin\newtvm.exe
The newtvm tool is what allows you to run programs in the Linux docker
instance. You will probably want to make sure the %GOPATH%\bin
directory is in your path.
USAGE:
1. Run the Docker Quickstart Terminal application. By default, the
Docker Toolbox installer creates a shortcut to this program on your
desktop. Wait until you see an ASCII art whale displayed in the
terminal window. The first time you run this, it may take several
minutes to complete.
You will need to run the Docker Quickstart Terminal once each time you
restart your computer.
2. Open a command prompt (e.g., Windows-R, "cmd", enter).
3. Within the command prompt, execute commands as though you were
running newt in linux, but prefix each command with "newtvm". For
example:
newtvm newt help
The newtvm tool will take a long time to run the first time you execute
it. The delay is due to the fact that the tool must download the mynewt
docker instance.
EXAMPLE:
The following example demonstrates building and running the test
project in sim.
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target create sim_test
Creating target sim_test
Target sim_test successfully created!
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target set sim_test
project=test
Target sim_test successfully set project to test
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target set sim_test
compiler_def=debug
Target sim_test successfully set compiler_def to debug
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target set sim_test
bsp=hw/bsp/native
Target sim_test successfully set bsp to hw/bsp/native
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target set sim_test
compiler=sim
Target sim_test successfully set compiler to sim
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target show
sim_test
arch: sim
bsp: hw/bsp/native
compiler: sim
compiler_def: debug
name: sim_test
project: test
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm newt target build
sim_test
Building target sim_test (project = test)
Compiling cons_fmt.c
Compiling cons_tty.c
Archiving libfull.a
Compiling os.c
<...>
C:\Users\ccollins\newt\incubator-mynewt-larva>newtvm
project/test/bin/sim_test/test.elf
[pass] os_mempool_test_suite/os_mempool_test_case
[pass] os_mutex_test_suite/os_mutex_test_basic
[pass] os_mutex_test_suite/os_mutex_test_case_1
[pass] os_mutex_test_suite/os_mutex_test_case_2
<...>
NOTES:
1. Debugging of sim executables with gdb is still unsupported, but I
believe support can be added in the future.
2. To communicate with real hardware (e.g., via JTAG), you need native
Windows tools. In other words, OpenOCD must be run as a standalone
application, and not within the newtvm tool.
3. You will have issues if you try to run newt from a directory that is
not within your home directory. By default, the VirtualBox VM only
allows write access to your home directory. If you wish to build code
using newtvm in a different directory, you will need to modify the
shared folder settings in VirtualBox.
On Tue, Oct 27, 2015 at 10:41:22AM -0700, Christopher Collins wrote:
> Hi all,
>
> I wanted to share some details about what is planned for the Windows
> port of Mynewt. There is still some work to be done, but here is a
> rough description of what is planned.
>
> Thanks to a lot of help from Todd and Ray, we have a Windows port that
> is mostly working. I wanted to provide a summary to see if anyone
> anticipates any major issues. I am certain that I got some of the
> docker concepts wrong, so please feel free to correct any of my
> misconceptions :).
>
> Rather than create Windows ports of all the necessary components, we
> just run Linux versions of all the software in a virtual machine.
> Windows communicates with the Linux VM via transient ssh connections.
> When the user issues a command intended to run in Linux from a Windows
> command prompt, the corresponding Linux command is executed in the Linux
> VM. This allows the user to utilize Linux from within Windows without
> having to explicitly mess with VMs. All commands intended to run in
> Linux would need to be prefaced by a script that we provide to ensure
> the necessary ssh mechanism is used.
>
> There are a few shortcomings with this solution, as described:
> * There is no protection against the VM accidentally becoming
> unusable (e.g., required files getting deleted in the VM).
> * Upgrading any Linux tools, in particular the newt tool, requires
> the user to download a complete VM containing the upgrade.
>
> These shortcomings are addressed by a tool called Docker. When
> executed, Docker creates a consistently reproducible and self-contained
> environment in Linux. By creating a custom docker image, a user can
> have assurance that a particular set of commands will always execute
> successfully.
>
> In addition, docker images use a layered format. To receive updates to
> one or more of the linux tools, the user just needs to download the
> newest layers (similar to applying a patch).
>
> The Windows install of Docker ("docker toolbox") consists of:
> * A Windows port of ssh.
> * A copy of Oracle VirtualBox.
> * A minimal Linux VM that runs in VirtualBox.
> * The docker tool.
>
> In addition, we would need to provide:
> 1. A docker image consisting of an environment with:
> * The newt command-line tool
> * Go
> * A multilib-capable native gcc / glibc
> * An arm-none-eabi gcc
> * Native gdb
>
> 2. A Windows batch file (script) that allows the user to run Linux
> commands from a command prompt. The batch file would also ensure
> that the VM is running.
>
> Every time the user uses the script to run a command, the following
> sequence of events occurs:
> 1. A new docker environment is created in the Linux VM.
> 2. The specified command is sent to the docker environment via ssh.
> 3. The Linux command runs.
> 4. The output from the command is sent back to Windows via ssh.
> 5. The output is displayed in the Windows command prompt.
>
> All the user files (C source, yml, .o, .a, .elf, etc.) reside on the
> Windows file system, not in the Linux filesystem within the VM. So, the
> user does not need to interact with the VM at all to manipulate any
> files related to his or her project.
>
> So that is the proposal for how the Windows port will work. My main
> concern with this solution is that setting up docker in Windows 10 is
> problematic. There are issues configuring the host-only interfaces
> required for the ssh connections. There is a new version of the docker
> toolbox to be released shortly (within a week or two) that is supposed
> to address these isses, so hopefully it is not something we need to
> worry about.
>
> There are a few other issues that I have run into, but it is difficult
> to tell how serious they are because of the Windows 10 problems. So, I
> think we are stuck waiting for the next docker toolbox release before I
> can determine what we can and cannot hide behind the batch file.
>
> Finally, one annoyance is that this solution only works on an actual
> Windows box. The Linux VM fails to start if Windows itself is already
> running in a VM. I don't anticipate this being an issue for users, but
> it creates quite a bit of hassle for people developing the Windows port.
>
> Thanks for reading,
> Chris
