Sunday, July 12, 2009


Work in progress... miscellaneous updates in no particular order:

My neighbour told me that something has (finally!) arrived from Hong Kong. I may be the newer LCD A320 or the Gemei x760+. I'm living in a different place this month (you know: wife and kids, holidays, beach...), and won't be able to pick it up until next week.

I've just fixed the ethernet over usb. Next kernel/rootfs release will communicate only via ethernet: telnet for console (developers) and FTP for file transfer. This is how it works:
  1. A320 boots, sets up the usb0 interface ( and launches DHCP, telnet and FTP daemons. The default gateway is set to
  2. PC detects a new USB ethernet adapter plugged and gets an address via DHCP. It is assigned by the DHCP server in the A320.
  3. Since the PC is the default gateway, if you configure routing you can get internet access from the A320.
I think I have now a quite complete uclibc based toolchain and rootfs. I'm still working in a FAT-only rootfs, which should be ready for release sometime next week.

I've included all the SDL stuff except SGE, because it doesn't use autotools and the included makefile is not cross-compile ready. I could not compile Allegro either: looks like it's too bound to i386 architectures. If you can port it, I'll be glad to include it in the next kernel/rootfs release.


  1. This is great news. No longer need getty and full telnet and ftp support will be really nice for developers.

  2. This is some great news!
    Now I can imagine multiplayer on Dingoo via:
    A320 > pc > internet > pc > A320

    Can't wait to try duke3d deathmatch :)

  3. Yo man - brilliant stuff! I'm a linux userspace dev (and homebrew GEEK) and would love to get stuck in to this project (maybe userspace input overlay, etc). Would you be willing to share your toolchain?

  4. The linux for gemei x-760+ work?

  5. @cRTrn13

    Of course, the idea is to release the toolchain in binary and source (actually a patch against buildroot 2009.05).

    Would be great to have an ipkg (or opkg as someone suggested) repository where users could directly download and install packages to the A320.


    The x760+ has been purchased with the donations, and the intention is to try get dingux working on it too. I'll start working on it as soon as I get my hands on it.

  6. @cRTrn13

    If you want to start developing anything I can create a subproject for you in the google code page with svn access (or you can create your own project).

  7. @cRTrn13: maybe you want to work on this:
    the virtual keyboard ticket is open for takers. :)

    @booboo: great news about the ethernet stuff! as for the daemon:
    can you expose the power key? I'd like to make the buttons configurable
    in the daemon and I there's no event for it.

    also what I've found out while coding so far: 2 processes can write to
    the framebuffer at the same time (tested in my vm and on the dingoo).

    there are synchronization issues (which I think can be fixed). but
    it works quiet well for static backgrounds with some glitches left
    (I stop the background process spawned by the daemon when the UI comes up).

    blocking input with EVIOCGRAB also seems to work (at least with a simple
    test prog in the background).

  8. @Booboo

    I have disassembled the X760+ LCD inicialization code using TP030WHEA1.dl with IDA. But I know that only this isn't enough to Linux work in Gemei. Well, I try it and don't work, :(. I try send to you in an e-mail, but I'm getting an error. Maybe this is usefull for you when you receive your Gemei X760+. How to send the code to you? Thank you. Great work!

  9. @torque

    The keyboard driver currently generates a keypress/keyrelease of KEY_POWER two seconds after the power slider is pressed (while ALL other keys are released). This is intended for someone in the userspace to handle it and shut down the system. This is not what you want.

    The KEY_MENU scancode is currently assigned to power+select (see Please suggest a scancode for power alone.

    I guess that both processes writing to the framebuffer is only feasible if you stop the running application (emulator or whatever). But the, if the process is stopped, you cannot inject keystrokes (or you can, but the process won't respond to them until you close the overlay).


    email me: iggarpe at gmail dot com.

  10. @booboo: yes in the case of the virtual keyboard it's almost mandatory that the background app remains active. even if it queues up all virtual keystrokes and executes them when the application is resumed this is far from optimal.

    syncing both processes' update times might work by waking up the background process, waiting a little until it has refreshed the screen and then stop it again and draw the UI on top. this is not very accurate, but I think it could work. at least it'd be fun to try. :) if this works out, all the awful flicker might go away and this could be a viable solution.

    I meant exposing the immediate keypress. this way we can (in the future) remap the now hard-wired button combinations issuing KEY_VOLUMEUP, KEY_MENU, etc. the delayed KEY_POWER event can remain as it is. just send another key code if it's the short press / release. this is not a high-priority issue, but I can imagine some people would like to remap things.

  11. @booboo: sorry, i misread the part about the scancode. how about ... KEY_RIGHTALT ?

  12. Question about Dingux i recently installed it but my save states don't work i installed it like 2 weeks ago. Does this problem still exist?

  13. @torque
    I'm not an artist really although I could throw something together probably. It's more the coding side am interested in but you've got that covered...?

    Looks like torque is on this one already - dont want to duplicate work...

    Anything else I can help with guys?

  14. @booboo

    Ahh you suggested a package repro - somehow I totally missed that! Yeah - sounds like a good idea... will take a look :)

  15. I don't see the benefit of ipkg, compared to loop mounted read-only files...
    What could be less difficult than to copy a file to the 'packages' dir of the dingoo?

  16. not going to port ipkg - as you it's unnecessary - but would be cool to have a simple package manager that searches for available software, installs, etc. Obviously it's easy to do manually as well.
    It's not a major amount of work so get something small working (even if it's just a 'search, download & install' tool)...

  17. @cRTrn13 said: the ticket is also for the coding side of things. I just wrote down some notes. A quickly thrown together prototype would suffice for now, so if you want to you can do that. There are still other things to do and some help would be appriciated. There's a text renderer and drawing / filling rectangles is also possible, maybe you could use that, or just load bitmap(s). If you want to I can add you to the project.

    I'd like to see ipkg too. I don't know what it's capable of, but comfortable updates and installing software from a simple menu frontend from a central repository are things I think could make sense.

  18. @torque
    My A320 should be with me in the next few days and then I can start playing around with your project. Would be happy to help and see what I can do getting a basic input system working :)

    That's pretty much what I was thinking re the package manager - just a simple way of finding packages, downloading them from repro and managing updates... Doesn't have to be as advanced as ipkg (nor should it be imho).

  19. @torque
    Also, just been thinking... why not use SDL? (Dingux supports it right?)

  20. @cRTrn13: Great, contact me when you want access to the project (see the wiki page). You can start hacking right away if you like. Everything can be done in a virtual machine or on your computer.

    SDL prevented me from reading input (and possibly from simulating it). I also had another issue I can't remember. You should know that I'm learning about low-level linux hacking as I go along. I couldn't estimate whether it would be possible to work around that (now I think it should be possible). A valid reason might also be that SDL (+gfx/ttf/image) introduces a lot of overhead size-wise (not an issue when dynamically linked). Anyway, I wanted to do some low-level stuff again for a while and this is a good opportunity.

    There's rectangles, text and anitialiased lines (alson non-aa, have to finish and expose that). Also there's input handling. I don't think we could benefit from SDL much at this point. Except sound, maybe ... but simple sound playback using alsa (hopefully) should be easy to implement. It's currently not required, anyway. For image loading I have some stuff which I could pull in from another project.

  21. Just had a question on virtual memory. I noticed when working with virtualboy, the original source has no provisions for working on a 32meg system. When using this build you get into problems when loading large roms because it just tries to malloc 32megs and there isnt enough memory so it fails. The gp2x port takes this into consideration and I believe loads the rom in pieces as needed.

    Now I have seen reports that the recent mame build also has this problem, so I figured Id ask if there was anyway to have the kernel handle this since it usually takes care of all the virtual memory. I dont think we should have a swap partition since this is a flash disk but wasnt sure if there was anyway to have the kernel do the handling without that, or maybe everyone loading roms should just mmap the disk space itself.

    Either way just figured id bring it up to see if there was a kernel based solution.

  22. In regard to FAT only rootfs, does that mean an EXT3 partition is no longer needed on the SD card and everything can be drag/drop with Mac or PC?

    Thanks again for all your care & effort BooBoo!

  23. @Link

    Yes, the ext2/ext3 partition is no longer needed and everything would be easily installable from win/osx.


    There are two kernel solutions:

    a) Swap: your program loads the entire 32MB, and as it runs out of memory, some pages are written to swap and its physical memory freed. You end up with, say, 20MB actually in physical memory and the other 12MB swapped to disk. As you use the ROM, pages that are swapped are loaded, for which first some other pages must be first swapped to disk.

    Swap is not really intended for this, and has very serious issues when writing to flash memory (which suffers from wear and as a limited number of write cycles). DISCARDED.

    b) memory mapping. This is IMHO the ONLY VALID solution. Instead of loading the entire 32MB ROM, you just mmap it. This means telling the kernel that a 32MB contiguous area of RAM is mapped byte to byte to a certain file. From there on, every time you access a memory page a fault happens and the kernel handles it by allocating physical memory to that virtual address and loading its contents from the proper offset of the file. This means you end up assigning physical memory only to those areas of the ROM that you are accessing. This is all viable because of the access pattern: a large set of data (a ROM) in which you will be accessing only a small subset (a game level) at a given time. Note also that there are NO WRITES to flash storage. When you proceed to a new level, if the system runs out of memory, some pages (the oldest used, I presume) are just discarded and its physical memory reused for the newly accessed.

    The only real drawback of memory mapping (besides having to port the code) is that data in files must have exactly the same format as it would have once loaded in memory, that is all contiguous in a single block. In particular, this means NO COMPRESSION.

    I think its an acceptable drawback. We have little RAM in the A320 but plenty of flash storage. If one really wants to take the entire ROM collection with him, maybe a sort of "cache" mechanism could be implemented: ROMS would be stored in compressed format, but they would be first decompressed to a special directory before mmapping them. They would be decompressed only if they are not already, and there would be a maximum number of ROMS allowed to stay in decompressed format. The user would end up with that special directoy containing only the ROMS he's plaing more often.

  24. A note on ipkg:
    ipkg really falls over if you don't have enough RAM (and 32MB is not enough)! The format itself is probably ok, but the tools are unusable in their present state. It might be useful for compatibility, but I really wouldn't base anything new on it. I would recommend a port of opkg to buildroot. Or using loop mounted files as others are suggesting.

  25. @Ed
    Yup - I think would be easier just to write something simple from scratch - can use the ipkg/opkg file format but otherwise a rewrite would be in order. Also it's not TONs of work to get something simple up and running.

    Do you have a VM ready that I could use?

  26. Those were my 2 conclusions as well

  27. @Ed

    IIRC, I've used ipkg on a WRT54G/OpenWRT/whiterussian with 16MB. Though now of course OpenWRT is using opkg...

  28. Great work, man!

    I don't own a Dingoo (yet, no money :P) but I'm sure I'll be using DINGUX when I get one.

    Also, I've heard it's now possible to use a MAME emulator while on DINGUX. But... what about PSX emulation?

    Are the SNES sloppyness problems solved by using DINGUX?

  29. @booboo

    I don't doubt that you have - most of the time it will run fine, and indeed I've run it on an 8MB psion, but when it starts to eat memory it really goes to town, and you will run out of RAM for sure. opkg uses the same file format as ipkg (just renamed to .opk) but is a fork that has fixed the ton of memory leaks that were present in ipkg. (well, barely a fork really as ipkg is dead). More info:

  30. so just checking but you're planning on releasing a uclibc toolchain built using OpenEmbedded? As well as a fat based rootfs? Sometime this week?

  31. Seeing as this is a bit of a miscellaneous thread, I was wondering if anyone has already compiled a Dingoo based gdb. This is something that would be extremely handy for obvious reasons.
    Also, I'm currently using cygwin to do all my compiling as I don't have a Linux box. As a result, I'm using mipsel-linux-gcc 3.3.1. I see that the Linux version of the SDK has 4.1.2 and glibc 2.6.1.
    Does anyone have the cygwin version of this? I saw that it was initially available but seems to have disappeared from ingenic's ftp site :-(