Sunday, October 10, 2010

GPIO tables updated

ChinaChip provided the A320 schematic, so after studying it I've completed the A320 GPIO table here:

Some interesting updates:
  • PD3 and PD4 are unused GPIO but connected to test pads. Could be used for hardware mods (but first those pads would have to be located on the PCB). I'll open one of the A320 this evening and have a look.
  • PD22 is connected to the HOLD key (0=pressed, already pointed out in the comments by BouKiCHi).
  • PB30 confirmed to be battery charge status input.
  • PD20 is the battery charge control output (1=charge enabled). Actually, this turns on a NMOS which shunts a resistor to ground. This resistor is used to set the charge control, so in theory a PWM output could be used to achieve lower charge current. However, this pin's alternate function is SSI data output, so PWM might be achieved by spitting out continuously the appropriate data.
Not related to GPIO, but also interesting:
  • The FM chip audio output is (as expected) connected to the LINE_IN inputs of the JZ4732.
  • As I had guessed, the LCD read signal is not connected, and thus it is not possible to identify the LCD type or synchronize the GRAM refresh to the VSYNC.
As I mentioned earlier, I also have the x760+ schematics and I'm making the GPIO tables, soon to be published.


  1. I hope this will lead to some small improvements such as USB plugging or a FM player for Dingux. Even if A330 if neat, A320 is still beloved and a few improvements in Dingux would make it really gain a bit of a new life.

  2. @luri Fiedoruk

    What do you mean by "USB plugging"?.

    Regarding FM player, it should not be very difficult: the FM chip is controlled through the I2C bus, it's just a matter of enabling it and then switching the audio input. It's just that this has been for probably for everybody the last item in the priority list...

  3. Currently, when I plug Dingoo on USB, while running Dingux, I see no battery indicator (part of what you found in the tables) or that the Dingoo is plugged and can transfer files.

    But more important, probally are good TV-Out, sleep (disable LCD after a while and later enter energy economic mode).

    Anyway, nice to have you working on it, even if you have only time to create documentation, it will be more than good :)

  4. @Iuri Fiedoruk

    - TV-out is already done.
    - Displaying the battery is easy, I think it is also easy to detect if dingux starts with usb cable charging now. I will take a look.

    -> Sleep mode? Yes! I miss this thing. I'm thinking in faking a sleep mode by blocking the keys/turning off LCD and underclocking using some daemon. Someone did a daemon to turn off the LCD when using the HOLD key, so it is a matter of knowing how to block all input in the daemon.

    - Do you know how can I block all the button input from an external program/script ?
    - How can I acess the GPIO directly in C ?

  5. .As I had guessed, the LCD read signal is not connected, and thus it is not possible to identify the LCD type or synchronize the GRAM refresh to the VSYNC.

    it could identify the LCD type through strings in dl files, and it's impossible to synchronize GRAM refresh to VSYNC cause of the directions of them are orthometric.

  6. @luri

    I'm still catching up with the latest developments.

    As Rodrigo says, the OpenDingux guys got the TV out working already (kudos).


    Have a look at /proc or /sys, look for *jz*.

    The more I think about it, the more I feel that audio volume, LCD brightness and poweroff/suspend should be entirely handled in the kernel. That's just a few lines of code and you forget about daemons and instantly standarize those controls, which are always available no matter what application is in the foreground (i.e. using the framebuffer).

  7. @booboo

    So, do you think it is easy to get sleep function working in dingux?

  8. Yes, but about TV-out, are the overclock problems solved? Last time I've checked, it was not easy to run TV-Out in Dingux.

  9. Booboo, I totally agree with your point: brightness, audio volume should be in th kernel and standardized for all apps.

  10. @Rodrigo

    The OpenDingux guys already got sleep working, but only when running from the internal flash. There seems to be some problem related to having the rootfs on removable media. Anyway this is related to kernel power management, and would not benefit from the info obtained from the schematic.

    Mmmm... not that I think about, getting the SoC to sleep properly is not the only thing required for a proper system sleep. You place peripheals in sleep mode too (or remove power from them if at all possible), so we should make sure that power management is properly implemented in each driver, and that certain GPIO conditions are met (like power amp shutdown, etc).

    Power off would benefit from having the schematics, but I think that the dingux power off patch is more or less fine. The external helper circuit is connected to special pins on the SoC in such a way that a SoC poweroff turns off power to the whole system, including all peripheals.

  11. @booboo:
    The problem is not really that the rootfs is on the SD card. As you already stated, when booting from NAND, it is possible to make the dingoo sleep, but it seems that the SD card is not properly unmounted. Apparently, and according to Larsc the problem lies on the MMC core itself and not on the jz driver...

    Regarding the FM chip, dargalf was working on it, but he failed to find a way to power on the chip.

    And about the sound volume: why inside the kernel? That's not a correct way of doing things. In fact, I just need to find a way to make SDL use the software volume and it should work out of the box for most dingux apps.

  12. @bob

    I have the A320 schematics. Tell dargalf to contact me if he wants to give it another try.

    The FM chip chip does not have specific power switching. It's powered as long as the system is on. Power is removed only when the CPU is shut down. It is controlled via I2C, was he able to communicate with the chip at all?.

    Note that the FM chip audio output is fed into the "LINE_IN" pins of the JZ4732. This means that the internal codec mux must be configured to route this audio to the outputs, to which the headphones and power amps are connected. Don't know if the jz audio driver supports this.

    Sound volume: yes, that's not the correct way of doing things in general, but the A320 has some specific characteristics that might make it advisable:

    - Has no pointing device and very limited keyboard input. The user is meant to interact only with the foreground application, and there is no easy way to switch between different processes.

    - It has no desktop and no window manager. Applications cannot share the keyboard and framebuffer. A "system daemon" would have, as a minimu, to be able to filter keystrokes, which I'm not sure is even possible. If you want the "system daemon" to provide also some visual feedback you need to write to the framebuffer, which again cannot be shared.

    So each application must handle these system wide controls itself, which forces the developer to do things it should to need to worry about and makes standarization difficult.

    Given these premises, and being the functionality we need SO SIMPLE in principle, doing it all in the kernel is IMHO the simplest and best solution.

    However, I agree that if you want some visual feedbak on screen things get a bit more complex and then I become reluctant to do it in the kernel.

    What about this:

    1- Implement in the kernel special key combination detection, and generate special events sent to userspace via the event interface. One of these key combinations should send the event to userspace AND enter a "capture" mode where no keystroke would be sent to the console. Pressing the same key combination would resume sending keystrokes to console.

    2- Implement a secondary framebuffer. This framebuffer would be shown only when it's open by the system daemon. It could also be software overlayed over the primary (transparency and such) for more eye candy, as long as the overhead is acceptable.

    So the "system daemon" sits there doing nothing in the background and listening to events. When it receives the special keystrokes it raises, lowers the volume/brightness, etc. One of these keystrokes will make it enter interactive mode: will open the secondary framebuffer, display some info and a menu, etc.

  13. yes i managed to communicate with the fm chip, but only for reading, which returned all FF's in the registers. writing failed completely, no error at all, if i get time i'll look over things, but i'm pretty busy with work these days, and get hardly any time to work on things (booboo should know what it's like :D)

    so i probably won't get any time to work on it this side of next summer, though i have done more work with that kind of fm chip than most, so vaguely know how they operate, if anyone needs help with it (my theory was the sleep pin was connected to a gpio, but who knows really)

  14. I don't know if this is a stupid question, but with this new specifications, could the corruption card problems be solved? I still having serious problems with my 4gb kingston card working with dingux.

  15. so this time you are indeed working on bringing linux to x760+?

  16. @booboo:

    I have a working power switch daemon, that enables the user to change brightness, volume, reboot/poweroff via power+button shortcuts. It currently lack a graphical feedback, but we planned to add an additionnal framebuffer to provide that feedback.

    It is made entirely in user-space, I modified nothing inside the kernel for that.

    Also, should you have any question/remarks/ideas about opendingux, don't hesitate to pop in #opendingux.

  17. Err, I mean #dingoonity of course.

  18. think hes gone and died again.

  19. Thanks for the work on this BooBoo!

    There is a place in the US taking preorders for the Gemei 330. Do you have one yet? Just curious as to how the hardware is put together, gaming controls etc.

    Thanks again and look forward to your efforts!


  20. Hola Booboo, antes que nada, felicitaciones por todo el trabajo excelente que haces. Gracias a vos la Dingoo es lo que es. Tengo una pregunta amigo, es posible hacer funcionar el Tv-Out del modo nativo con overclock? Pregunto porque cuando overclockeo algun emulador no puedo usar el TV-Out, habría alguna manera de corregir eso? Es difícil? Ojalá puedas responderme. Saludos!

  21. Guys quick question, the changes that you mentioned (TV-out, power-off and volume control) where can I get the update to the Dingux??