Cross-Development Environment

[BobC]

Borrowing from the earlier Eclipse thread that wandered into Netbeans and QEMU, it may be useful to climb to the top of the stack and think about releasing a pre-cooked virtual machine (VM) for each "common enough" set of TS boards.

This is just the beginning of an idea, intended to stimulate conversation: I haven't implemented anything like this myself.

The VM would runs the board's Linux via QEMU, but could also have a full NetBeans environment installed that can either be accessed through the VM's display, or (as I would) remotely via X11 on the host (Linux/Cygwin). But even if a full NetBeans install isn't included, the relevant NetBeans plugins may be included to simplify NetBeans setup on the host system.

The VM could "own" the target system, using it as a distcc peer, as a test server, and could automatically place binaries there. (The target would not be in charge of the build.) All target access (at least for development purposes) would be through the VM.

In a shop with multiple developers working on the project, each developer would have at least one development VM running, and all the developer VMs could also participate in distcc, as well as any distributed or parallel automated testing.

The QEMU burden would be significant, but it would eliminate the need for cross-compilers, making it easier to maintain a consistent (identical) build environment not only on the target, but also on each developer's system.

I haven't yet looked at the NetBeans "Remote Development Host" capabilities, but I suspect that may be a good way for locally hosted NetBeans instances to work with the VMs and the target.

What I like best is that the VM is platform-independent: The same VM can run on Win7, Linux and Mac. At most, a second ARM-native VM (without QEMU) may be needed when developers start having ARM systems at their desks.

Ultimately, the goal is to maximally enable customer development with minimal support required.


Sane or insane?

[amclain]

TL;DR: Good concept, but not something TS should support.

I really like the idea of running a development environment in a virtual machine. I’ve implemented almost exactly what you’ve described: A Ubuntu virtual machine with NetBeans set up to cross-compile to ARM and compile tests for x86 to run locally. The cross-compiled code is dropped onto the TS board via SCP, and I stay connected to the target board’s terminal via SSH in a dedicated window. If you want to be even lazier you could set up NFS; it’s just my personal preference not to use it. I have a handful of other tools installed that are outside the scope of developing for the TS products.

This type of configuration works great on an individual level. It takes a little bit of time to set up, but you only have to do it once and it’s really not that hard. One benefit to doing it this way is that you are able to customize your workspace the way you like it. The other HUGE benefit is that you get to learn how your tools work by doing the setup yourself. Once set up, updates are easy: Simply use your Linux distro’s package manager.

The part that causes problems is having a central entity trying to maintain an image of a development environment that pleases everybody. Different people like different things, and some developers have a way of being incredibly... “opinionated”... about their preferences. If the VM is packaged with NetBeans, what happens to the people who would rather use Eclipse? What about people who don’t like the Linux distro that’s bundled? What about people who want to use VMware instead of VirtualBox? Except for the beginners, most people are probably going to end up having to modify and customize their VM image. That brings up another problem. What happens when TS releases a software update? If TS releases a new image and you decide to use it, you lose all of the hard work spent customizing your old image.

So although I think building a development environment that simplifies your workflow is a good idea, I think the responsibility should fall on the individual, not TS. The big thing that people tend to forget is what has to be given up in order to get something. TS, like any business, has a finite amount of resources. Personally I’d prefer them to spend their time doing what they do best: Building awesome embedded hardware. Maintaining and supporting a VM image means less time spent developing and supporting their product line.

-Alex

[BobC]

Much of what I discussed in my initial post was influenced by work TS is already doing: http://wiki.embeddedarm.com/wiki/TS-SDK

The main issue is eliminating the need to deploy and maintain cross-compilers: Using a Debian ARM VM instance (e.g., QEMU) for all build activities (and perhaps some test activities too) should eliminate the need for cross-toolchains for any of the various x86 operating systems (Win7, OSX, Linux), meaning no need to keep them in sync with the native tools shipped on the TS platform. It should also simplify distcc deployments: Each developer's VM needs only to know about the other VMs and the TS target system. If the TS target system isn't being used for testing, it could also participate as a distcc node.

One possible issue is the alpha status of QEMU on Win7, though there are many reports of it running fine under an Ubuntu VirtualBox VM. So it may be simpler to distribute the QEMU instance wrapped into a Linux VM.

As the above link discusses, NetBeans has "Remote Development Host" support (which I haven't yet used). Any NetBeans install within the Linux VM (not QEMU) would be primarily for convenience (to have Something That Just Works), and need not be included. Tailoring the local VM to the developer's preferences should be perfectly OK, but may not be needed at all when the IDE is run natively, outside the VM. At the very least, the TS NetBeans plugins could be distributed with the VM (for convenience), if not all of NetBeans itself.

As time permits, I'll take an Ubuntu VirtualBox VM, build within it an ARM QEMU VM, in which I'll install a TS Linux image (or any other bare-bones ARM Linux image). I'll first see if it works at all, then see how much of a hassle it is compared to installing, configuring and maintaining a cross-toolchain.

[BobC]

Just found another advantage of running QEMU within a VM: QEMU doesn't appear to support saving the run-state of an image! From what I've read so far, you must do a normal machine shutdown before quitting QEMU, otherwise the next system start will take significantly longer, and may have other problems.

With a VM such as VirtualBox, the VM state can be saved and restored, including the state of any running QEMU instance(s). I would expect an emulated CPU to take much longer to boot compared to the seconds required to restore a VM.

Of course, this means many of us would then be running Debian ARM within 32-bit Ubuntu x86 under 64-bit Win7. Which I still think will be at least an order of magnitude faster than trying to compile natively on a 200 MHz ARM.

[BobC]

As a first try-it-out QEMU ARM distro, this one came up easily after installing the required QEMU packages on my new Ubuntu 12.04LTS VirtualBox VM.

[Edit: BogoMIPS: Debian ARM = 377.65, Ubuntu x86 = 6340.78, native TS-7500 = 190]

[BobC]

QEMU is slower at being a compile host than I thought it would be. The main surprise is I found no meaningful difference between running GCC under Cygwin vs. under Ubuntu in a VirtualBox VM. If anything, the VM was slightly faster.

It looks like cross-compilers, along with the required environments for each TS board, will be the way to go.

Still, it should be beneficial to distribute the tools and environments as an x86 VM, which provides the following benefits:

- The same x86 VM runs on every host OS supported by the selected VM (OSX, Win7, Linux, whatever), so only a single configuration need be maintained by TS. Grabbing the latest VM gets ALL TS cross tools at once.

- VMs can participate as distcc peers, with suitable network support.

- A full pre-configured development IDE may be included in the VM, remotely accessible via RDP and X11, or locally accessed. And the files needed to configure a native IDE may be included (or linked to).