torpor
hack hack hack, the little machines fight back
As discussed with the gang (DJWillis mostly) on #gp2xdev, I would like to get the OPEN2X project rolling along to where its possible for us to build our own, tweaked, custom firmware. Yes, thats right: all the way from building our own 2.4.25 kernel, modules, libs, and apps, rolling it right down on into a tight set of gp2x*.img files which can be used to safely and reliably boot the GP2X, and run all your favourite apps, still compatible with the factory firmware.
So let me just report what I have found so far:
1. The OPEN2X Project. In previous weeks, there was quite some difficulty for OPEN2X hackers to get sync'ed with the Sourceforge SVN repository; this problem now seems to have gone away, and its possible to get yourself a full copy of the OPEN2X tree, such that it is in its current state, build it, and use it.
2. The Toolchain. OPEN2X comes with scripts to build the toolchain, and then the libs.
The toolchain consists of:
binutils-2.16.1
glibc-2.3.5
linux-headers-2.6.12.0
gcc-4.0.2
This is all fine and dandy: the script runs, you get a 4.0.2 gcc, you can then use it to build libs. The one problem:
**The current gcc-4.0.2 compiler cannot be used to build the open2x linux-2.4.25 kernel**
However, if you don't wish to do kernel work, this combo works just fine.
3. The Kernel. OPEN2X has, of course, a copy of the GPH-provided kernel (linux-open2x in the svn tree), and I can confirm that this kernel can be built easily enough if you have arm-linux-gcc 2.95.3 onboard, and you can boot it, and the GP2X will run along just fine with it .. in fact I have been kernel hacking on the GP2X for the last few months, and it works just fine, except for one rather cantankerous gotcha, more on that later ..
4. The Libs. Included with the OPEN2X repository is a grand archive of libs - SDL (of course, which I think includes the latest and greatest hacks/patches from paeryn to exploit the GP2X acceleration features..), as well as all the standards: libtiff/mikmod/mpeg/SDL_*/etc. The only thing I want to say about this is that I've added cairo/libsvg/libsvg-cairo and its ancilliary libs (fontconfig/glitz) to the libs/ tree, so that we can very easily use SVG 'out of the box' in the OPEN2X firmware - more on this later (hint: for a new menu).
5. There is a huge problem with all this: You cannot use the same compiler to build the kernel as you use to build the libs. The toolchain dilemna is such that you have to have multiple toolchains onboard to make a completed OPEN2X firmware, and this is wraught with issues: 2.95.3 is 'ancient' (but still works fine), so its not really fun to build all the LIBS with it, whereas 4.0.2 will not compile the linux 2.4.x series of kernels, etc.
I have recently run into an even thornier issue with this problem in my efforts to port MidiShare to the GP2X. Right now, MidiShare works just fine with my custom kernel, built with 2.95.3, and MidiShare apps can be written and run just fine on the GP2X: BUT because MidiShare consists of a kernel module+libs, it is not possible to mix and match compilers on projects using MidiShare: this means you cannot use gcc-4.0.2 from the OPEN2X toolchain to compile against MidiShare, thus: none of the 4.0.2 libs are available to a MidiShare hacker. The reason: the dreaded soft float versus hard float ogre.
So .. where does this leave us? It means that, in order to be 'complete', the OPEN2X project needs another compiler in the toolchain: one which can be used to build both the kernel, and all the libs, in one fell swoop.
My hacking so far has led me to conclude that the following toolchains, pre-built and downloaded from mysterious places all over the 'net, do not work to build the OPEN2X kernel: GCC3.0/GCC3.2.3/GCC3.3.1. I have not built these toolchains myself and so I do not believe that I've necessarily gotten these toolchains right for a kernel build .. for me the most optimal solution would be to simply get GCC3.4.4 (the highest version of GCC which can, apparently, 'safely' build the linux 2.4.x series of kernels) added to the toolchain script .. if someone has already built it for the GP2X. I 'feel' like someone has, I've heard about it, but I can't work out who it was..
Now, if you're still following along with me, the point is this: whats the point? I know that there are other toolchain hackers in this community who have also worked on similar issues: oopo/theoddbot/djwillis. What success have you guys had with building a toolchain that can boot a linux 2.4.x kernel on your GP2X?
Are you guys willing to throw your toolchain buildscripts into the OPEN2X mix so that we get either: a) one compiler to build all (kernel/libs/apps) even if its not the 'latest 4.x' whizbang, or B) two compilers easily integrated into the OPEN2X mix which produce compatible (i.e. *SAME* float specs) objects that can be mixed and matched.. so we can use 3.4.4 to build the kernel+modules, 4.0.2 to build libs+apps, and they work happily together ..
Ideally, one of you guys has already solved this issue and we can add a patch to the OPEN2X toolchain script .. but if you've got more details about the work you've done so far on this issue, please lets hear about it .. here, or on #gp2xdev (where there is much interest in getting the OPEN2X firmware buildable to the final point: gp2xkernel.img/gp2xfile.img, etc.)
So let me just report what I have found so far:
1. The OPEN2X Project. In previous weeks, there was quite some difficulty for OPEN2X hackers to get sync'ed with the Sourceforge SVN repository; this problem now seems to have gone away, and its possible to get yourself a full copy of the OPEN2X tree, such that it is in its current state, build it, and use it.
2. The Toolchain. OPEN2X comes with scripts to build the toolchain, and then the libs.
The toolchain consists of:
binutils-2.16.1
glibc-2.3.5
linux-headers-2.6.12.0
gcc-4.0.2
This is all fine and dandy: the script runs, you get a 4.0.2 gcc, you can then use it to build libs. The one problem:
**The current gcc-4.0.2 compiler cannot be used to build the open2x linux-2.4.25 kernel**
However, if you don't wish to do kernel work, this combo works just fine.
3. The Kernel. OPEN2X has, of course, a copy of the GPH-provided kernel (linux-open2x in the svn tree), and I can confirm that this kernel can be built easily enough if you have arm-linux-gcc 2.95.3 onboard, and you can boot it, and the GP2X will run along just fine with it .. in fact I have been kernel hacking on the GP2X for the last few months, and it works just fine, except for one rather cantankerous gotcha, more on that later ..
4. The Libs. Included with the OPEN2X repository is a grand archive of libs - SDL (of course, which I think includes the latest and greatest hacks/patches from paeryn to exploit the GP2X acceleration features..), as well as all the standards: libtiff/mikmod/mpeg/SDL_*/etc. The only thing I want to say about this is that I've added cairo/libsvg/libsvg-cairo and its ancilliary libs (fontconfig/glitz) to the libs/ tree, so that we can very easily use SVG 'out of the box' in the OPEN2X firmware - more on this later (hint: for a new menu).
5. There is a huge problem with all this: You cannot use the same compiler to build the kernel as you use to build the libs. The toolchain dilemna is such that you have to have multiple toolchains onboard to make a completed OPEN2X firmware, and this is wraught with issues: 2.95.3 is 'ancient' (but still works fine), so its not really fun to build all the LIBS with it, whereas 4.0.2 will not compile the linux 2.4.x series of kernels, etc.
I have recently run into an even thornier issue with this problem in my efforts to port MidiShare to the GP2X. Right now, MidiShare works just fine with my custom kernel, built with 2.95.3, and MidiShare apps can be written and run just fine on the GP2X: BUT because MidiShare consists of a kernel module+libs, it is not possible to mix and match compilers on projects using MidiShare: this means you cannot use gcc-4.0.2 from the OPEN2X toolchain to compile against MidiShare, thus: none of the 4.0.2 libs are available to a MidiShare hacker. The reason: the dreaded soft float versus hard float ogre.
So .. where does this leave us? It means that, in order to be 'complete', the OPEN2X project needs another compiler in the toolchain: one which can be used to build both the kernel, and all the libs, in one fell swoop.
My hacking so far has led me to conclude that the following toolchains, pre-built and downloaded from mysterious places all over the 'net, do not work to build the OPEN2X kernel: GCC3.0/GCC3.2.3/GCC3.3.1. I have not built these toolchains myself and so I do not believe that I've necessarily gotten these toolchains right for a kernel build .. for me the most optimal solution would be to simply get GCC3.4.4 (the highest version of GCC which can, apparently, 'safely' build the linux 2.4.x series of kernels) added to the toolchain script .. if someone has already built it for the GP2X. I 'feel' like someone has, I've heard about it, but I can't work out who it was..
Now, if you're still following along with me, the point is this: whats the point? I know that there are other toolchain hackers in this community who have also worked on similar issues: oopo/theoddbot/djwillis. What success have you guys had with building a toolchain that can boot a linux 2.4.x kernel on your GP2X?
Are you guys willing to throw your toolchain buildscripts into the OPEN2X mix so that we get either: a) one compiler to build all (kernel/libs/apps) even if its not the 'latest 4.x' whizbang, or B) two compilers easily integrated into the OPEN2X mix which produce compatible (i.e. *SAME* float specs) objects that can be mixed and matched.. so we can use 3.4.4 to build the kernel+modules, 4.0.2 to build libs+apps, and they work happily together ..
Ideally, one of you guys has already solved this issue and we can add a patch to the OPEN2X toolchain script .. but if you've got more details about the work you've done so far on this issue, please lets hear about it .. here, or on #gp2xdev (where there is much interest in getting the OPEN2X firmware buildable to the final point: gp2xkernel.img/gp2xfile.img, etc.)