Wednesday, July 1, 2009

Porting a menu frontend

I got a little time to check out frontend menu systems for the A320. As always, the way to go is reuse existing open source software, and I came up with two candidates: gmenu2x and gp2xmb. If you know some other, please let me know.

You may recall that one of the first quick ports I did when I got linux running on the A320 was gmenu2x. I did that using the huge glibc and other stuff from the Ingenic toolchain, but this time I wanted to do it the right way: using an uclibc toolchain.

I quickly went over OpenEmbedded and settled with buildroot. It's the tool by the uclibc guys and has a nice kernel like configure menu to which I'm used. I succesfully built the toolchain, and I recommend using buildroot for compiling just the toolchain and some basic libraries. For bigger or specialized libraries (like SDL), I recommend configuring and building manually using the just built toolchain. I'll be testing this toolchain in the following days and release a new uclibc based rootfs.

These are the porting results:
  • gmenu2x: unable to get the latest stable version working in linux nor in the A320. The svn code compiled and sort of worked both in linux and in the A320 but despite the icons seems to be loaded they're not shown on screen. Didn't go any further because I do not intend to debug the gmenu2x code.
  • gp2xmb: got the svn code working almos right from the start, both in linux and in the A320. The sound is choppy in both cases, which leads me to believe it's not a problem of the kernel sound driver (reminder: still using the buggy and ugly OSS driver).
Personally I prefer gp2xmb. There's quite a lot of work to be done to adapt to the A320 (plus the sound problem), but the code seems quite clean and well structured. Check out the video:

Note: it should be only the second half, but for some reasong I could not edit it without breaking further the audio sync (in which you can notice it's choppy), sorry. You see how I reset dingux using POWER+START+SELECT, boot into the original firmware, power off, power on and get a bit too late to select dingux thus booting again into original firmware, etc. Notice that in the latest dual-boot release you can press SELECT to boot dingux anytime while the dingux splash screen is show, that is, you actually need not to power on while pressing SELECT.

18 comments:

  1. I would like to thank you for your precious work!

    About the rootfs: I think it would be important, focusing on a sort of "standard" development environment (containing both rootfs and main libraries such as mad and sdl, and why not? applications too), all available in a same "repository" (your google code page could be the right place). At the moment I can see that having to refer to google code and openhandhelds with different rootfs, and apps built for the both of them (and .app files for the original fw!) is misleading both for developers and users.

    Thanks again!

    ReplyDelete
  2. This is great news :)
    Making something out of the dingoo is a community effort, but there are always a few devs that stick out :D

    ReplyDelete
  3. eres un genio, gracias por todas tus horas de tiempo libre

    ReplyDelete
  4. Yes I agree with batman52.
    Could you please post an 'official' set of files?
    - the 'runtime' rootfs
    - the 'devel' rootfs with headers and so on
    - the toolchain, or precise instructions and set of files to build it

    These files would have to be versioned and their version should increment for each major release

    We also have to agree on a standard package format...

    ReplyDelete
  5. I would like to recommend OpenMoko's opkg package format as a standard. It is present in buildroot so it would be easy to compile and use.

    ReplyDelete
  6. @kmeaw

    Could you please develop on the opkg pros?

    ReplyDelete
  7. Just wondering what was wrong with the previous toolchain I had posted. Adding extra libraries inside buildroot is almost trivially easy, you just have to create a new element in the packages directory and setup its config file correctly. Buildroot will handle the rest of building and placing in the correct locations. Thats all I did for sdl_gfx and sdl_sound.

    ReplyDelete
  8. go with gp2xmb, it's much more polished & more familiar to users... not to mention sexier, lol

    ReplyDelete
  9. @Evan

    Nothing wrong. Just want to experiment and optimize things as much as possible (soft-float, -O2 instead of -Os, and such).

    Plus, as someone said, eventually we should provide a "closed package".

    @cyberic

    I'll be testing my setup (and adding some libraries) for the following days, and I'll release my toolchain and a new rootfs by the weekend.

    ReplyDelete
  10. Ahh, at this point I dont remmember what -O i built that toolchain with. I believe the last one I had left it at -Os but I had tried -O3 before since that was one of the options.

    One thing that may be good to look at is to see if there is a way to embed the -mtune options so that along with the soft-float the mtune is on by default as well

    ReplyDelete
  11. @Evan

    What are the -mtune options?

    ReplyDelete
  12. Im pretty sure mtune just takes a cpu option, so usually its just mips32 I believe

    ReplyDelete
  13. Which libraries will be included in the system?

    I think SDL is very popular and would be worth having.

    For image decoding, libpng and libjpeg, preferably SDL_image too so it integrates nicely with SDL.

    zlib is useful and required by libpng anyway.

    For font rendering FreeType, SDL_ttf and a good standard font (DejaVu? Droid?) would be very handy.

    A small XML parser would be useful too. Maybe Expat or a minimal build of libxml2.

    For audio, SDL_sound with MP3 and Ogg Vorbis support. SDL_mixer too maybe; I don't know how often it is used.

    ReplyDelete
  14. @kmeaw:
    opkg is based on ipkg.
    I would prefer a cramfs or squashfs image, which we could mount on a loop devices and/or overlay the root filesystem with mini_fo or unionfs

    ReplyDelete
  15. This comment has been removed by the author.

    ReplyDelete
  16. @mth:

    @mth:

    Each library you listed are the ones I already included in mine, except the xml ones which I did later but didnt post. That is a pretty good list and definitely what should be included.

    The only other one off the top of my head that we may want is Mesa/GL. I built this at one point but never got around to testing it so I have no idea if it even has suitable performance for anything. If it does then that would definitely be another to have.

    ReplyDelete
  17. @Evan: Where did you post the link to your toolchain? I can't find it in the last 8 or so posts. Does it include the configuration you used for buildroot? I too like to play with different versions and settings, but it's much easier to start from a configuration that's known to work.

    I like GL a lot, but in my opinion it's only worth it if hardware accelerated. The Dingoo has a frame buffer and some acceleration features for decoding videos, but I didn't read anything about texturing or shaders.

    ReplyDelete
  18. @mth:

    The toolchain is up on the openhandhelds site that has most of the other dingoo related files. Its under the dev tools section. Ill try to post the config somewhere sometime soon but if you just want to try a toolchain you really dont need the config file. The only options you need to start with are selecting mipsel as the type, mips32 processor and thats it. Since you arent including any other packages everything you need to modify is just in the toolchain menu.

    ReplyDelete