Tuesday, July 7, 2009

New kernel binaries

I just compiled and uploaded the latest kernel for ILI9325 and ILI9331 LCD controllers (choose yours).

These are the changes:
  • Battery reading implemented.
  • LCD backlight working.
  • Fixed kernel oops when USB cable unplugged.
The later is a long standing bug. It turns out the USB device controller was calling a non-existent suspend function when the cable was unplugged. One hour chase, one second fix.

On a side note, thanks for your valuable comments and suggestions in the previous post.


  1. Hi booboo, what some nice (and needed) additions.
    But I'd like to know. Can you implement overclocking in the system menu and/or in the front end ?

  2. The Ingenic code supports cpu frequency scaling. But as it is implemented now it has certain limitations: CPU frequency is only scaled down from the initial CPU frequency, which is not set by linux. It is set by the SPL very early in the boot process.

    The dingux SPL (actually a modified version of the U-Boot SPL) sets the frequency to 336MHz to be 100% compatible with the original SPL.

    To make clocking over 336MHz possible the easiest approach is to set the CPU frequency on kernel startup (which is not very difficult) and leave the scaling mechanism as is (only scales down).

    Note also that it might not be possible to overclock to 430MHz. I still have to confirm it, but the CPU frequency must be a multiple of 48MHz in order for the USB to work.

  3. I'm really a noob in Linux, but why do we need usb to work during application (assuming i'm not a coder). Maybe we could set a default OC for coders and one for the others guys.

  4. Usb is necessary as a console for developers and as a way to transfer files for everyone. The A320 detects the USB cable connected, so IN THEORY it should be possible to restrict the CPU frequencies to those that allow USB working only while the cable is plugged. However, that is very complex and there are a damn lot of issues involved (not only the cpufreq code has to be modified but also the USB driver), and I'm not sure it's worth the trouble to get just a 10% increase in performance (from 384MHz to 430MHz).

  5. Ok i understand everything now. I didn't think of file transfer (stupid of me). So dev will have to include the Overclocking in their code (as slaanesh seems to do in Mame4all Dingoo).

  6. What about setting it to 432MHz, if possible? The extra 2MHz should not burn anything.

  7. Hello there booboo! I don't have a dingoo, but I apreciate your work a lot! I am don't know much about linux, but watching some youtube videos we can see some emulators running. So I would Like to ask you somethings, just out of curiosity:

    I don't know exactly, but looks like the emulators don't run at full speed. I would like to know if they need interanal optimization or if they will speed up with optimization of linux?

    Are you planning to add keyboard/mouse support for it? Maybe another good soul could ever port OpenOffice to it. Who knows the possibilities?

    If I recall dingoo have a internal memory. Do you think it could be used as virtual memory if it eventually lacks of ram?

    Thanks for everything!

  8. @jpelintra

    I did a quick test trying 432MHz and it crashed immediately. I think that is not a matter of high frequency but that the PLL setup code messed things up.

  9. @ silas: openoffice on a 32Mb RAM device? don't think so :) Let lone the fact of the screen resolution.... Some of the emulators will need changes to run "full speed", it depends on the system emulated and the demands of the game played.

  10. I've tested 420Mhz and 396Mhz using A600's CPU speed utility. As far as I can tell these speeds work for me. They certainly gave increased performance in my port of MAME. The problem i have with the CPU speed changes is setting the Dingoo back to normal 336Mhz. I get segmentation faults. I haven't really investigated this yet, but I will look into it.
    I thought I read somewhere that 420Mhz was the maximum speed due to the 166Mhz RAM? Older Dingoo models has 133Mhz speed RAM but I believe that you'd have to be unlucky to have an older model.

  11. I know Mame4All is being converted to work on the Dingoo but why can't SDLMAME be converted? Mame4all seems to be at a very early stage (version .37b) where as SDLMAME is uptodate. Won't alot of games not work or require alot of searching for very old rom sets?

  12. @slaanesh
    I think I've got an old one (as I order it) as soon as that Dealextreme got some... Do you plan to release a test version or will you release it only when it'll be "bug free" ?

  13. I tried some early ports of mame and the only one I ever had any luck with was advance mame. That one built and actually ran successfully about a month or 2 back but advance mame needs a ton of configuration since it is made for cabinets and has a ton of video output options and I never got around to getting them right. But advance mame would also work.

  14. @Slaanesh

    Programming the JZ4740 clock generator module means programming the PLL and a set of dividers that take the PLL output and generate the different clocks (CPU, peripheal, memory, USB, etc).

    For example: PLL = 400MHz, CPU clock = 400MHz (div 1), memory clock = 133MHz (div 3). If your RAM chips are 166MHz (all but the very earliest are), you're safe even if you program the PLL to output 430MHz. If your chips are 133MHz chances are that they will also work at 430MHz/3 = 143MHz, since it's only 7% increase over the 133MHz specification. Of course you could also set the memory divider to 4, which would result in a 107,5MHz RAM clock.

  15. Hi BooBoo great work you're doing with the Dingux, keep the good work! But what i would like to ask is: Any news about the Linux for the Gemei X-760+? Would you call it Gemux? There's a lot of people who can hardly wait for it. =]



    TUXIE would fit it better