As I've been blogging about lately, I'm getting ready for my EclipseCon tutorial which will walk the attendees through adding support for a cross-compile environment to the CDT. The target of this environment will be qemu running a tiny Linux platform which includes the latest release kernel, busybox, dropbear with sftp-server from OpenSSH, using the free glibc C run-time and gcc cross compile tools from CodeSourcery.
I'm using the default ARM target for the latest qemu which unfortunately has a bug in the FIFO emulation that interfaces with the emulated SecureDigital card where I want my root file system. I asked on the qemu-devel list and someone there sent me a patch they had posted a couple of weeks ago. Checking out the qemu source from svn into the CDT, I was able to fix up the function where this was done and I was quickly up and running with my root file system on the SD card image. Very, very cool!
The next highlight was when I got the ssh components running and I was able to connect to the qemu target using the Remote System Explorer from the Eclipse Target Management project. Also, very, very cool. I want to use RSE and the CDT remote launch to get the results of the build up and running on the target.
So now that I know how to build stuff from the command line, the next step will be the meat of the tutorial, creating the managed build integration for the cross compiler. Of course, you'll have to come to the tutorial to see the result, and actually work with me though the process. But it should be fun!
And now that I've actually started working with qemu in the CDT, I'm starting to get that itch to add 3D graphics support again...
Hey Doug,
ReplyDeleteGreat post, three comments:
- First, 3d acceleration in qemu would be awesome!
- Second, it's unclear to me if you actually use CDT to build qemu or other open source packages?
- Third, is this tutorial/walk-through you're going to be doing only going to be available to attendees? I mean there's no way I'll be able to attend, but I'd love to watch a screencast or something of it. Make sure to let us know.
Thanks again, keep up the good work!
1) It would and I don't think it would be too hard either. The idea would be to design my own "chip" that would feed the OpenGL or OpenGL ES commands to the host libraries.
ReplyDelete2) I'm using the compilers and libraries (SDL in particular) that come with Wascana. And I'm using CDT to navigate and edit and build the qemu code. I haven't tried debug yet...
3) Well, I know how tough it is to get to EclipseCon. I will make the results of the tutorial public, either as a webcast kind of thing, or we'll just add the work to CDT 6 ;).
3D graphics support for qemu would be great indeed :)
ReplyDeleteYou could use the now open source specs for intel chipsets and emulate one of these. This will get you the driver for
free but it could be quite a bit of work.
Or emulate a simpler 'virtual' chip that is actually more like a ringbuffer for OpenGL commands (something along the lines of virtio already in qemu), but then you need to care about drivers as well.
Or use gallium's software rendering
and pass through a socket / virtio
gallium -> gallium. They already use that for debugging AFAIK. There was a project to use that for Xen but it seems vaporware so far.
Or you could go with chromium (i.e., transfer OpenGL over a socket without touching qemu at all). This way is already implemented (VMGL) and would work with KVM and Xen too (and probably also be faster).
VirtualBox seems to be following the chromium approach too.
I 've actually tried that, it took ~2-3 hours to make VMGL work with recent x.org and a small patch to integrate it with qemu's SDL window.
The problem was chromium lacks support for a few OpenGL extensions used by KDE for its effects and since this was the main reason I wanted 3D I decided to leave it for a while. But if you just want to play quake in a VM it works reasonably well (70-80% of native speed).
I 'm sure you would get at least a little help if you decided to start such a project :-)
Thanks, pkt, these are great suggestions.
ReplyDeleteMy focus initially is on mobile devices and OpenGL ES in particular. It's a different beast than trying to support existing X or Windows drivers. And I will be needing to create my own drivers anyway and will be focusing on Linux for that.
For the general PC X and Windows case, I'm looking to VirtualBox to provide that solution. They already have a good start.
Hi,
ReplyDeleteI'm currently working on an Eclipse-CDT based environment dedicated to SystemC/TLM platform and e-sw development/simulation (result will be mainly open source).
We're working on Qemu integration in a SystemC/TLM platform and thus we also need to integrate a cross tool-chain using the CDT extension points.
I would like to know what do you plan to do more than what is done in the gnuarm plugin for the cross toolchain integration in the MBS?
I'm looking forward to your tutorial !
Dimitri.