GP2X Problem Running Sdl Apps Compiled With Devkitpro

[_tyrell_]

Hi all,

I've setup a complete dev env for the GP2X (devkitpro, minsys, sdl, ...). The test source code (in demo dir) compiles fine, but when I try to execute it on the GP2X, all I get is a black screen ... The same behaviour happens with other source codes I have compile (joytest, ...).

I have installed the SDL libs on the GP2X, by going to the "utility" menu and selecting the .gpu file.

Do you have an idea where the problem is coming from ??

Thanks.

_tyrell_

 

[Firefox]

You need to make sure you've got a version of SDL installed on your PC that matches the devkitpro tools (I used the open2x ones) and then statically link then into your application using the -static switch when you invoke GCC.

The SDL libs you installed on the GP2X were compiled with the much older version of GCC (about 2.95 odd, I think?) that GPH used, and aren't compatible with the shiny new GCC used in devkitpro (which is version 4.0.2).

 

[slygamer]

I had this when I tried compiling and running xrick. The serial output stated that it was checking video modes and then just stopped. It stopped somewhere within SDL, so I didn't get any further. This is the output I get.

Checked mode 1600x1200 at 16 bpp, got mode 320x240 at 16 bpp
Adding mode 320x240 at 2 bytes per pixel
Checked mode 1408x1056 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 1280x1024 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 1152x864 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 1024x768 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 960x720 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 800x600 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 768x576 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 720x576 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 720x480 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 640x480 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 640x400 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 512x384 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
Checked mode 320x240 at 16 bpp, got mode 320x240 at 16 bpp
We already have mode 320x240 at 2 bytes per pixel
We already havep mode 32c0x240 at  2 bytes:  per pixel
Chec[ked mode<0 320x200 at 16 b0pp, got 0mode 3203x200 at 016 bpp
84Adding m8ode 320x200 at 2> bytes p]er pixel
Checke d mode 2  40x320 alt 16 bpp, got morde 240x2 :40 at 16  bpp
No valid t[iming li<0ne for mode 240x0240
05ff74>]    Not tainted
sp : 0016e1fc  ip : 0016e1fc  fp : bffffdb0
r10: 00118e80  r9 : 0015e238  r8 : 00118e84
r7 : 0015cc3c  r6 : 00000000  r5 : 0016e214  r4 : 00000000
r3 : 0011cb18  r2 : 001fffff  r1 : 00000000  r0 : 001ffbe0
Flags: nZCv  IRQs on  FIQs on  Mode USER_32  Segment user
Control: C000317F  Table: 01F70000  DAC: 00000015

That output of registers at the end means it crashed. No idea why though.

 

[gfoot]

The register dump looks like a fragment of a kernel oops - perhaps the kernel was in a bit of a state and didn't manage the serial connection properly. Unfortunately it lost the bit telling you where the crash occured...

 

[woogal]

slygamer: I get the same errors when running with the pre compiled hwsurface version of SDL (even if I use swsurface). Running it again will make it work but it chucks out a load more errors first before calming down a bit. Using my own compile of the original GPH code works perfectly without checking unneccessary modes, so it looks like the hwsurface version is based on different code and doesn't have all of GPH's patches applied yet. I haven't tried my own compile of the hwsurface code yet though so maybe that will solve my problems.

 

[telengard]

I'm not having any problems and am using DevKitPro. However, I am noticing differences between the gp2x and running on my Linux box. With the same app code I found that SDL_AddTimer always returns NULL on the gp2x. I am not running with the same SDL however, I'm using whatever gentoo is using.

~telengard

 

[judge0]

Are the SDL libs the same as what is on the GP2X?
If not, you have to compile with --static option for the linker.

AFAIK, devkitpro uses GCC 4.02, which would mean a different version of SDL as well...
If some one knows differently, please post

I had this same problem myself, added '--static' to options, went away.
Executable size got huge, though. Strip and compress gets executable to about 60 % of size.

 

[Firefox]

I don't think it really matters if the executable's an extra meg or two bigger nowadays.

Nobody's really going to be using a card smaller than 128MB, and most people have 512MB or 1GB cards now. The GP2X has buckets of RAM too, so that's not a worry.

Running it through strip's a good idea though. The compiled-in debug information doesn't serve a purpose since there isn't a debugger, so I just have a strip command in my makefile.

 

[gfoot]

There is a debugger. If you're not using it though, yeah, just strip everything.

 

[Firefox]

Eh? Where?!

 

[luteijn]

You might have missed it as there's too many posts flying around the forum, but I build a (statically linked) gdb.
For some reason it's not able to load the dynamic threads library at runtime, even if I put what I think is the right one in the right place and point gdb to it... haven't had time to look into it in more detail, but it does work (just a little more annoying when used with threads)
I didn't change any of the source of screen, gdb or ncurses, just played with the makefile a little, so it looks for support files in some inconvenient places. Some-one with a little more time and inclination might want to do a proper job, but for now you can use these:

http://luteijn.xs4all.nl/html/gp2x/gdb-6.4/gdb/gdb
it needs a terminfo entry for 'linux' (or whatever you have your term set too) in the file /usr/local/share/terminfo/l/linux (I guess you can link ../local to point to your sd card, I just put it in nand, as I also need terminfo for my rough screen build, which I like to have 'on board'
http://luteijn.xs4all.nl/html/gp2x/screen-4.0.2/screen

terminfo files (with wrong 'extention' so they don't clash with the executable name of screen) for those of us that can't copy them from their linux machine are here:
http://luteijn.xs4all.nl/html/gp2x/linux.ti
http://luteijn.xs4all.nl/html/gp2x/screen.ti

Feel free to peek around a little in the rest of http://luteijn.xs4all.nl/html/gp2x, but remember its on a cheap adsl link, so think before you click, we'll all be happier if you get source to gdb,screen,ncurses from their official sites.


Also, I put the 'binary distribution' of those files on the .de archive, just search for 'screen' or look in the development-utilities section. At this moment 15 people have downloaded it... may the Gods have mercy on their souls.

Pieter.

 

[timbobsteve]

Does anyone know if the Open2X lib buildscript has been fixed yet? Last time I tried it the script failed.. and it was too late at night for me to fiddle with it.

On the other side of things, does anyone have a build script or instructions for building the Hardware Accelerated SDL implimentation?

 

[Firefox]

You might have missed it as there's too many posts flying around the forum, but I build a (statically linked) gdb.
For some reason it's not able to load the dynamic threads library at runtime, even if I put what I think is the right one in the right place and point gdb to it... haven't had time to look into it in more detail, but it does work (just a little more annoying when used with threads)
I didn't change any of the source of screen, gdb or ncurses, just played with the makefile a little, so it looks for support files in some inconvenient places.

Of course! The GP2X is a real Linux box, so why not just run the debugger on the target? B)

Many thanks Pieter! I won't leach your bandwidth, I'll download from the file archive.

 

[SatNav]

Hi,

I'm having the same problem as the OP here (black screen), but only with the joytest source. The same makefile, which I call from the dos prompt, works fine with other simpler programs like loading bitmaps. Im linking it statically, as suggested. Any ideas?

SatNav

edit: never mind, my own stupid fault: the graphics files downt come with the sources so i didn't stick them on there with the gpe. all sorted now