GP2X Gp2x: Technical Faq’s


Random GP32/GP2X/Wiz & Pandora Moocher
Jul 20, 2003
Bath, Somerset, UK
Not a lot here yet but this is an idea I was discussing with Hando to try and keep a list of the Frequent Technical Questions that are no doubt going to crop up as we approach the console release to cut down on the same questions again and again.

This could then be moved to a public forum at the appropriate time.
Feel free to add to it ;).


Q: What version of the Linux Kernel is installed on the GP2X?
A: The stock Linux Kernel installed on the GP2X is based on the ARM-LINUX Kernal.Org 2.4.25 sources with patches.


Q: Why did Gamepark Holdings not use a 2.6 based Kernel, surely that is more suitable for an embedded device?
A: Whilst 2.6 is indeed better suited for an embedded device, currently the most recent vendor supported and certified Linux Kernel for the MagicEye MF2520 processing unit (used in the GP2X) is based on 2.4.25.


Q: Can I upgrade my GP2X to a 2.6 based Kernel?
A: Not currently however the community is working on upgrading the existing 2.4 patches to 2.6. Contributors are very welcome to get involved by participating in the SourceForge project (The Open2x Project).


Q: Can I bypass Linux and run programs directly on the hardware?
A: Yes, more information can be found .... I’ll update this as we find out more.


Q: What is a Bootloader?
A: A Bootloader is a piece of software/firmware that initialises the hardware to a suitable state to pass control over to an operating system. Embedded Bootloaders such as the one used on the GP2X should be seen as an analogue of the BIOS and GRUB or the Windows bootstrap in a traditional PC environments.


Q: What Bootloader does the GP2X use?
A: The GP2X uses ‘Das U-Boot’ to initialise the hardware and boot an operating system or custom code. More information on U-Boot can be found on the official 'Das U-Boot' site or the GP2X Linux Kernel SourceForge site above.


Q: What DevKit can I use to develop for the GP2X?
A: make some stuff up for this one, I guess DKArm after WinterMute gets it building based on gLibC (For Linux anyway), for now any GCC targeted @ ARM-LINUX should do the job with some tweaks. Note: Add to the WiKi stuff on GCC4.


Questions to add, bootloader, flashing..... well whatever we find out I guess.
Well, I've got programs running directly on the hardware now, and even managed to initialise the LCD :) So the hardware certainly works (even if it's missing a few things)

However, I really hope GPH are going to give retail units a better method of loading stuff pre-linux than U-Boot and a serial cable :huh:
Squidge posted on Sep 19 2005 at 09:31 AM said:
However, I really hope GPH are going to give retail units a better method of loading stuff pre-linux than U-Boot and a serial cable :huh:

If I have to write an FAQ on how to use HyperTerminal I am off, that would push me over the edge ;).

Glad to hear your making progress though, that's cool. I would ask for screenies but I don't think that's such a good idea at the moment. Is it just a Hello World running or something more interesting?
Last edited by a moderator:
Much more interesting than hello world - it's a chequered pattern on the LCD, whilst I learn the 2D stuff on the chip.

It seems that there's a "standard" frame buffer, and a 2D frame buffer. The 2D one requires the screen to be built up of macro blocks (32x32 pixel blocks). No, it's not tiling, it just seems a really weird configuration. Probably due to the built-in mpeg decoding.

Need to play more.
It would make sense considering how MPEG streams are built. Nice to know it's not all simple or there would just be no fun in it ;).

Do both the rigs work out of interest or just the one?
Both boards work, or should that be, worked ;)

One of them doesn't have Linux on it anymore, as I erased the kernel to make room for somewhere to shove my own stuff :ph34r:

Should be easy enough to restore when GPH give us a kernel that actually works :)

(I use way too many emoticons... I even found myself putting them in some hand written documents!)
Sounds like they should push back the rollout date.. given its nearing the end of Sept and theres no working linux env yet, it seems doubtful they'll be able to get somethign useful out the door y October or November.. they should've been assembling them already for that :) Hmm..

craigix posted on Sep 19 2005 at 05:42 PM said:
Suprisingly manufacture only takes 3 days for 1000 units.

Thats impressive :). I assume there using the GP32 production line or did that go to the 'other' GamePark ;).
Last edited by a moderator:
Squidge posted on Sep 19 2005 at 08:31 AM said:
Well, I've got programs running directly on the hardware now, and even managed to initialise the LCD :) So the hardware certainly works (even if it's missing a few things)

However, I really hope GPH are going to give retail units a better method of loading stuff pre-linux than U-Boot and a serial cable :huh:

Well now this is something.. what was actually needed to bang the hw?
Last edited by a moderator:
At the moment, I use a hacked up GCC 3.4.3 to output srec files, then open these up in a text viewer, copy the entire contents to the clipboard, ask u-boot to load an s19 file, and paste it in. you can then jump directly to the start address of your app. Since u-boot sets up most things for you, all my crt0.s contains is stack pointer initialisation (which probably isn't required).

To make things easier, I changed the original boot command to sequence so that it requested an srec file upon processor reset, rather than trying to load linux.

However, the boards crash a lot on startup before u-boot is initialised, and my display setup routines are even less reliable. I'm assuming the cx5874 needs configuring too, but that looks like an i2c interfaced chip. yeucky.

When I get something more interesting (or more reliable) running, I'll post the code, but probably not here, and it doesn't seem very secure from the exposed screenshots. Either that, or we have someone willfully exposing info..
Squidge, is the frame buffer memory layed out like the GP32's? It would be nice to now be able to write 4 horizontal pixels in one hit.
It's easier than the GP32's :) Starts top left and increments horizontally. By default, it's 16-bit (5-6-5), so you can hit two pixels in one go with a dword write. If you change it to 8-bit, you can probably hit 4 pixels at once, but I've not tried that, as I hate managing palettes.

Whatever you do, make sure to always request frame buffer memory via the frame buffer device to ensure the memory is completely contiguous and allocated, as memory allocated in user mode is normally allocated on write access and may be spread over multiple non-sequential pages. Memory allocated in user-land also may not have the required cache(mmu) configuration.

Or, you could use SDL, but we know SDL sucks for performance apps, and isn't as fun as hacking the hardware :)

At the moment, I'm trying to get some SD card access routines working when run from u-boot - would make a nice linux replacement :)
Oh wow, thats great news. I can get started and update DrMD's rendering routines now, thanks. At least the memory is layed out in a nice way, its going to make the rendering routines a lot more effecient.

Good luck with the SD access code, sounds very usefull.

Thanks for the info.