Hi
Is there a Windows toolchain available that allows for cross-compiling for Jetson TK1 as target?
I would love to reduce the number of screens/keyboards/computers on my desk…
If that toolchain exist I assume/hope that the MSVC gdb-plugin would solve the debug issue. :)
The JTK1 is quite capable of compiling sofware directly on it, so nothing more than ssh access makes this fairly simple (especially if you install keys for access without passwords). I’m not sure of the state of gdb on Windows, but you can run gdbserver on a JTK1, or run gdb command line directly on a JTK1 via ssh. I don’t know if the nsignt eclipse edition runs directly on Windows or not (I have not looked), but it might (anyone know what platforms nsight runs on?).
You might be able to use Cygwin for cross compiles in combination with the Linaro tool chains…I’d expect it to get very complicated. An actual VM should work if you have enough disk space…your Windows install could host a Linux install. Cross-compiles via Cygwin would probably work with NTFS file system and not have any issues with NTFS.
The rest of this reply is if you are also wanting to flash, and not just cross compile…
The flash executable runs on Linux x86_64 only. During the flash, even if the executable ran on Windows x86_64, creating the image for transfer over to the Jetson itself requires the underlying file system type to be a native Linux type…other file systems do not have any knowledge of Linux permissions (and you’re not just creating files, you’re setting them up with permissions). Assuming Windows could mount and use Linux native file system types, you would also have to add a loopback mount ability (which Windows is not capable of).
So…you could use a VM, which definitely can succeed, and is your best bet for running JetPack, but realize you may have to “tune” the USB behavior (sometimes a VM’s USB causes mysterious failures, but this can be adjusted to work if you know VMs). Additionally expect that you cannot base it off of the NTFS partitions…you’ll have to have a dedicated ext3 or ext4 partition.
I’ve spent quite some time searching for a Windows version of Nsight but so far without success. :(
Currently the VS plugin is intended for building an ARM application locally and then allow for debugging of it on the target via ssh and gdb server. That also implies (I assume) that the VS way of handling projects necessary in order for everything to work properly. I.e. a local toolchain and so on. Building the application on the target will make the symbol files end up in the wrong place so I don’t think I can figure out a way to get that to work. While typing I got the idea that it might be possible to trick the buld system by having shared disks and build manually before trying to load the debugger. Hmm, I might try that…
In my first attempt I tried using a VM but had as you say to much USB issues so I used a physical machine instead. Since the board now is properly flashed I guess that I could go back to using a VM. The only concern I have is that it might be that the Jetpack installation is successful if the flashing part is skipped.
How I wish that the Jetpack package had been made for Windows… After all, as far as I know, most people use Windows for their daily work.
Anyway, thank you for your effort.
So now I’ve tried using a VM without flashing the board. I’m sorry to say that didn’t work since the Jetpack installation don’t install the ARM part if the it’s terminated before at the flash point. :(
Your original question seems geared towards building software from Windows to deploy on the JTK1. The nature of what is required differs depending on whether you are building for kernel space or user space. Because the kernel has no needs for linking to other software this environment is greatly simplified…if you cross-compile user space, then suddenly you need the sysroot files (this is more or less the linker and everything that is linked to along with other tools to do this…it is a subset of the final user space environment).
If you just want to build a kernel, then you may get away with using non-Linaro armhf compilers. Once you need user space the possibility of Windows-based tools goes down rapidly (and quite possibly no such tool chain exists without paying large sums of money). Assuming you do need user space development, and if a VM is your only choice, then perhaps debugging the VM install is the place to start.
I do not personally use a VM, in part because of my system resources being inadequate, but also because the VM frustrations you are running into also frustrate me. There are people here who do use and understand VMs better than me. I suggest that you describe what you are using for your VM, and any kind of setup you have for this…someone who understands VMs may know what is going wrong in your case (or at least have a suggesting of a setting to change).
Doh!
I used Virtualbox and the base installation only supported USB 1.1…
Adding the extension package and changing the USBs to 3.0 finally made the installation succeed in flashing of the board. I’m now in the process of removing one computer and its peripherals from my desk! :)
That’s a check I’ll have to think about any time I see a VM. It’s such a simple and easy thing to overlook (an old colleague of mine once gave a formal technical term to bugs and quirks easily fixed by simple and easily overlooked detail adjustments: “Well, Duh!”…how I wish I had a copyright on that term).
Flash only takes advantage of USB2, but USB1.1 would be a killer even when the VM functions perfectly…and error messages won’t give a clue (though perhaps the common “packet was nacked” might show up for USB1.1 failures).
I didn’t get any visible errors but on the other hand I didn’t try to debug it either.
For those that are about to follow my path. Unless you have quite a powerful host for the VM the operation is quite slow. :(
It’s a perfect excuse though to request for a brand new high end laptop. :)