Development Sdk And Emulator?


Karel Jansens said:
So I asked someone whether they could port a certain application to the Pandora (the app is Linux-based and OSS) and the return questions were: Is there an SDK for Pandora and an emulator?

So? Is there?
A toolchain is what you really need, thats at codesourcery. Check the wiki for links.
Then you can add any IDE on it you want i.e. codeblocks.

You should know theres no emu for the pandora...there are some tools though for running opengl es on a opengl based pc.

What's the app anyway?
 
Last edited by a moderator:
Karel Jansens said:
So I asked someone whether they could port a certain application to the Pandora (the app is Linux-based and OSS) and the return questions were: Is there an SDK for Pandora and an emulator?

So? Is there?

Not as such. The few people I've talked to have set up a qemu instance to run an ARM system emulator, which is as close to an emulator as we're likely to get. As for an SDK, it's linux, so.. whatever your linux development environment is. You'll need to get a cross-compiler set up to compile for the device (I've found CodeSourceryG++ to work well), or set up a compiler in your qemu instance and do your development there. I'd post instructions on how to get this set up, but I'm in the process of building my environment out, since I'm a relative noob to embedded linux, too. :D

Once I get my environment built out, I may provide an outline as to how it was done and post it to the wiki. Then again, without hardaware to test against, I'm only guessing at whether I'm doing it right, so my documentation may well be useless in the end. In the meantime, here are some useful google terms (try various combinations):

qemu
arm
armel
linux
crosstool
codesourcery
gnueabi

Happy reading!
 
Last edited by a moderator:
Given that qemu doesn't support omap3530, a system qemu is probably not the way to go as it won't be able to boot any omap3 kernel.
 
Really though, your not going to be using qemu to test kernels, you are going to use it to test user code, which is not going to talk to any omap specific hardware, only linux device drivers. So you can use it for this purpose, and if the code works, you can run the exact same executable on real hardware. A decent project for this would be http://vm-kernel.blogspot.com/

There is a proper omap3 emulator for Windows, but it's about $5000 for a single user license, and you need to prove your a company and give them in-depth details about your project before they'll even think about selling you one. The only "evaluation" is a flash-based demo. It does however fully support the omap, including the peripherals and dsp.
 
Squidge said:
There is a proper omap3 emulator for Windows, but it's about $5000 for a single user license, and you need to prove your a company and give them in-depth details about your project before they'll even think about selling you one.

Im curious, that isnt fully sw emulated right?, but uses a specialized OMAP chip for simulation? Most setups im familiar with require some hw simulator to run the application on.

To add the only time ive seen qemu help was with wolf4sdl to help with finding some alignment problems, and that beacuse the original author didnt have any arm hw.
 
Last edited by a moderator:
It seems Virtio claim to do one, but I'm not quite so sure as there website is confusing. One minute they are saying: "The virtual platform is a high performance software simulator of the OMAP3430 Software Development Platform" ... "With this fast full-function software simulation, software developers can start developing and integrating their software long before hardware becomes available." ... "

then again, it says: "The Virtual Platform is based on the OMAP3430 Software Development Platform which includes the OMAP3430 System on Chip (SoC) along with all the board components and peripherals. This platform also includes the development boards that contain the audio codec and touch screen controller (TSC21001), camera interface (OV9640), various flash memory models and more.".

So it seems to include hardware, unless thats just describing what is offered in software (ie, "this is what the SDP offers, which we emulate").

There seems to be no definite answer, although I would assume hardware, as bugs in software emulations can cause days, sometimes weeks of lost developer time, and thus not practical. (I had the same problem at work in which an upgrade to our debugger decided that "to increase performance of the debugger, instructions set emulation is used for some commands rather than requesting the cpu to step each instruction", but the instruction emulator had bugs, so it crashed if you single stepped through a certain piece of code, but worked fine otherwise)
 
Squidge said:
Really though, your not going to be using qemu to test kernels, you are going to use it to test user code, which is not going to talk to any omap specific hardware, only linux device drivers. So you can use it for this purpose, and if the code works, you can run the exact same executable on real hardware.

Really? That would require all of the used shared libraries and there is a very high probability these won't work correctly on the host system (for instance what about different pixel layouts?).

On the other hand qemu user works well for simple applications that rely for instance only on the glibc. Note however qemu NEON implementation has enough bugs in it that ffmpeg with NEON doesn't work.

QUOTE
A decent project for this would be http://vm-kernel.blogspot.com/

I wonder how you can say this project is of any use: the svn repository requires a password, and it's written in a language I can't read. Do you have some more info, that looks very interesting :)
 
Last edited by a moderator:
The scratchbox sdk environment for maemo works reasonably well, or even very well, if you manage to set it up properly. For myself it worked fine the first time, others have reported more problems (I did pay attention to the details in the installation procedure though..)

It's set up with an ARM environment as well as an x86 environment, and an 800x480 xnest-based display. You can build your application as x86 or as arm executable (it's got a full set of libs for both). qemu is used when running an app compiled in arm mode. That works fine, except for the few cases where qemu doesn't support some particular arm code (in the official qemu version anyway). If so, you can test your application in the x86 environment, and build the final version as arm when you're ready. Then upload your .deb to either your repo or directly to the device.

I'm pretty happy with that development environment. It certainly beats what I had to use for Palm development. I also love that I can drop out of scratchbox mode and use the full power of a debian system to do the actual development (editors, git, etc.) at the same time as I'm building&testing inside scratchbox.
 
Tor said:
The scratchbox sdk environment for maemo works reasonably well, or even very well, if you manage to set it up properly. For myself it worked fine the first time, others have reported more problems (I did pay attention to the details in the installation procedure though..)

Yes it's a nice environment. And it seems to rely on user level qemu (just like Android SDK) so this means we could potentially use a similar setup for Pandora! I thought it was system level emulation as Android sdk; it's good to be proven wrong... sometimes :lol:

The use of xnest probably solves the problem I mentionned about FB discrepancies. Too bad xnest is broken on CentOS and RHEL 64 bit, so I can't run that :(
 
Last edited by a moderator:
Tor said:
qemu is used when running an app compiled in arm mode. That works fine, except for the few cases where qemu doesn't support some particular arm code (in the official qemu version anyway).

BTW could you provide some examples of these failures? I will track the problems and propose patches to the qemu team.
 
Last edited by a moderator:
>BTW could you provide some examples of these failures? I will track the problems and propose patches to the qemu team.

I'm not the best person for that, as I don't really run into such problems very often (extremely rarely in fact). There are others over at ITT and the maemo developer's list who do different kind of development and they should be much more up-to-date on this than myself.

BTW, there is an N800/N8x0 emulation project out there. If I understand it correctly it uses a qemu patched with support for more ARM instructions than the standard qemu - or maybe just a development version. In any case, to my understanding the reason the 'official' qemu project doesn't support all ARM code is because of intellectual property rights or patents or some such - not because the qemu team isn't aware of those instructions.

The n8x0 emulation project goes far beyond what's needed for the SDK, but it could be of interest anyway because it shows what's possible. Link below:
http://blog.haerwu.biz/2008/04/11/nokia-n800-emulation/
 
Tor said:
In any case, to my understanding the reason the 'official' qemu project doesn't support all ARM code is because of intellectual property rights or patents or some such - not because the qemu team isn't aware of those instructions.

qemu now has supports for all ARMv7 instructions.

Also I have provided patches for some ARMv6 instructions that were wrong, which probably would help n8x0 emulation.
 
Last edited by a moderator:
Question: I've been sniffing through the Angstroem package listings and found that the app I've been looking for (FBReader, BTW) has already been ported to that architecture (http://www.angstrom-distribution.org/repo/?pkgname=fbreader). Does that mean that one of those packages listed is likely to run on the Pandora?

The FBReader developer has let me know the following:

===============

> Looks like a port for Pandora requires significant efforts because
>
> 1) We should create a new (SDL-based) UI
> 2) It is not clear how to build and test a binary package for Pandora
>
> Moreover, at the moment we are busy with crating new mainstream
> FBReader version and with FBReaderJ (FBReader for Android platform)
> development. So I think a port before the 15th December is not
> possible.
>
> However Pandora platform is very interesting, thank you for the
> information. When a device will be available I would like to buy it
> and port FBReader to this platform.
>
> Regards,
>
> -- Nikolay Pultsin


===============

but I have to admit I don't understand a lot of what he wrote.

So, can we either use one of the existing Angstroem packages on the link above, or would it be really hard to recompile the "standard" Linux sources for the Pandora?
 
Karel Jansens said:
So, can we either use one of the existing Angstroem packages on the link above, or would it be really hard to recompile the "standard" Linux sources for the Pandora?

Most of the time recompilation is not the main issue. What about screen size? How to handle touchscreen? These will need adjustments for Pandora.
 
Last edited by a moderator:
It looks like fbreader is using something called 'ZLibrary', which is a library which can use either GTK+, Qt3 or Qt4 as the under-the-hood graphical interface. From N. Pultsin's comment above I'm not sure if he meant to add SDL as another under-the-hood library supported in ZLibrary, or an independent port.

The simplest way forward seems to be if there is GTK+ or Qt3 or Qt4 support in the Pandora environment - then there would be basically a recompile. Certainly there will be GTK+ support in the xubuntu version, but at this point I'm thoroughly confused as to what's to actually be installed! :D

Edit: As for touchscreen and screen size support - there's an fbreader for maemo, isn't it? There must be code to handle this in that version.
 
Karel Jansens said:
> However Pandora platform is very interesting, thank you for the
> information. When a device will be available I would like to buy it
> and port FBReader to this platform.

I also didn't understand it all - but I understand ^this and think it is great that people are interested. (And well done Karel for making successful contact)

Laurent said:
Karel Jansens said:
So, can we either use one of the existing Angstroem packages on the link above, or would it be really hard to recompile the "standard" Linux sources for the Pandora?
Most of the time recompilation is not the main issue. What about screen size? How to handle touchscreen? These will need adjustments for Pandora.
Right, possibly dumb question coming up...
Based on what you say, if you take a normal non-touchscreen app will the os treat the touchscreen like a mouse or does it need special programming? ie are you talking about basic touchscreen operation not working or just that it wouldn't be optimised to make best use of touchscreen.
 
Last edited by a moderator:
QUOTE
Laurent said:
Karel Jansens said:
So, can we either use one of the existing Angstroem packages on the link above, or would it be really hard to recompile the "standard" Linux sources for the Pandora?
Most of the time recompilation is not the main issue. What about screen size? How to handle touchscreen? These will need adjustments for Pandora.
Right, possibly dumb question coming up...
Based on what you say, if you take a normal non-touchscreen app will the os treat the touchscreen like a mouse or does it need special programming? ie are you talking about basic touchscreen operation not working or just that it wouldn't be optimised to make best use of touchscreen.
The way I understand it, the touchscreen is treated like any other input device, with certain signals sent from the touchscreen being intepreted by the driver and passed as corresponding actions to the GUI. For X applications, this is easy -- X handles the input device configured in Xorg.conf and interprets the signal accordingly, so tapping the screen corresponds to a left-click at that location no matter what the application is. For applications that don't use X, this may be more difficult -- you'll need to make sure your application can speak to the driver, and possibly make sure that the driver is sending the appropriate signals back to your app. I haven't messed with touchscreens outside of an X environment, so I'm a little fuzzy on the details.
 
Last edited by a moderator:
Can anyone help me answer this question in an intelligent way? I'm pretty sure Pandora will indeed come with an X server, but lately I've become rather confused.

> Are you sure Pandora runs the standard windows environment including X-
> server and Gtk+ library? If so we dont need any additional work -- the
> Angstrom package you mentioned should work well.
>
> However as far as I can understand, Pandora is very like to GP2X and
> runs SDL-based environment instead of X-server. In this case new UI
> version is required.
>
> Regards,
>
> -- Nikolay Pultsin

Thanks, clever people. ;)
 
Pandora can run X-server via KDrive. Whether this is the case for both the simple and advanced modes of operation is unknown, but the advanced version certainly uses X-server. I would imagine the simple one would too for the simple reason that it would be daft to make it incompatible with apps compatible with the advanced mode.
 
Back
Top