OESF Portables Forum
General Forums => General Discussion => Topic started by: kopsis on July 07, 2005, 08:47:52 am
-
There's been a good deal of discussion lately regarding barriers to Zaurus software development. One of the issues seems to be the difficulty of setting up a cross-development environment.
I have a QEMU disk image that features a minimal Linux install plus the Sharp ROM compatible cross development toolchain and I'm wondering if it would be worth the effort to clean it up and release it.
There is (or at least was) already a Live CD that had the x-devel tools, but rebooting every time you want to hack a little code is mighty inconvenient and that still leaves Mac users high and dry. QEMU (http://fabrice.bellard.free.fr/qemu/) is a full x86 PC emulator that can run on Linux, Windows (http://www.h7.dion.ne.jp/~qemu-win/), and the Mac (http://www.kberg.ch/q/). It allows you to run a complete virtual Linux machine in a window on your desktop right along with all your other apps. It's a good deal slower than native execution (about 10 - 15X) but I've found it more than adequate for building Zaurus apps.
Though I still advocate the use of higher level languages like Python and Ruby for Zaurus app development, there are a variety of reasons for folks to want to develop in C/C++. This wouldn't help with the C/C++/Linux/Qtopia learning curve, but at least folks wouldn't have to struggle with tools. How about it? Would this be a big help or are there still too many barriers to development for this to make a difference?
-
I tried to use that Live CD but I couldn't figure out how to use the tools. (Following the docs for regular (not Live CD) development didn't work because the commands keep trying to write to the CD.)
I would be interested in seeing this thing that you have.
-
Curious, why cross-compilation under QEmu, when it can emulate Arm?
Edit: I've thought of one reason, with an x86 based QEmu image, one could just mount the image as a loopback, and develop with it at full speed under x86 based Linux. Though, I'm curious what your reasoning was.
-
Definitely a good idea. "just add tarballs" instant dev stuff will help get a lot of software ported, I think.
a qemu arm image would be interesting. what would you do? setup debian-arm on a disk image and have at it? Would that work for the z (other than pocket workstation, which needs a sort of host system)? Does qemu setup a similar enough virtual arm environment to seem "native"?
even with the accelerator on x86 you'll still not get 100% speed. I thnk 50% would be more like it. It would be interesting to see a speed comparison between arm emulation compiling and x86 emulation cross compiling. Though I guess you are essentially right..on an x86 box the x86 emulator should be faster.
-
Curious, why cross-compilation under QEmu, when it can emulate Arm?
[div align=\"right\"][a href=\"index.php?act=findpost&pid=87596\"][{POST_SNAPBACK}][/a][/div]
The main reasons are convenience and reliability. The "official" Sharp tools are packaged for x86 Linux. Sure, one can build native ARM tools or use Debian ARM packages but that's extra work. And if a binary fails to run corrrectly on the Zaurus it's harder to rule out the toolchain as the source of the problem.
A secondary reason is that my approach uses Damn Small Linux for the environment and that's strictly x86. Stripping down Debian ARM is a lot of work and rolling a custom distro is even more work.
Mine may not be the optimal solution, but on balance it works quite well. I'm wrining an article that will explain my approach (and the decisions behind it) in more detail. Stay tuned.
-
because you would get a 12 to 15 times reduction in cpu power (from thier site), so that nice 3.4ghz cpu becomes a 300mhz arm or less machine with alot of ram, not bad i guess but it wouldbe faster to cross compile
btw qemu doent do system emulation (ie hardware such as a full arm board with network and stuff) emulation it only supports program emulation so you can run a program on a non native host (see: http://fabrice.bellard.free.fr/qemu/status.html) (http://fabrice.bellard.free.fr/qemu/status.html))
edit:
it says 5 to 10 times my mistake, that means a 3.4ghz machine would be 700 mhz in theroy, i would like to see some benchmarks when it does system emulation thogh
-
The system I've described in this thread is now ready for folks to try out. See this post (https://www.oesf.org/forums/index.php?showtopic=13936&view=findpost&p=88747) in the Development forums for more details.