Monday, July 27, 2009

Baffling dual-boot bug

There's one dual-boot bug that keeps me utterly baffled. I'm not sure if this is happening to others beside me because it involves the serial console connection. I'll describe it here with the dual purpose of confirming that it happens to others and requesting suggestions:

1- Install dual boot.
2- Plug the USB cable (either connected to a PC or just to the wall charger).
3- Reset the device while holding SELECT pressed.

The SPL dingux splash screen appears but it does not boot dingux, just hangs there. If you perform the same procedure but without the USB cable connected dual boot works file.

So what's so baffling and why didn't I notice this before?

It boots fine if the serial console cable is connected. And that's the cable one needs to see what's going on during the boot process. So if I connect it the problem dissapears, and if I don't connect it I can't see what's going on.

Question is: does this happen too to those that haven't installed the serial console?.

It may be that the SPL code fails to load u-boot, or that the u-boot code fails to load zImage. One could think that maybe the u-boot code is receiving some stray input from the unconnected serial console and stopping to wait for more input, but then, why does this happen only when the USB power is plugged?.

Looks like the only way to investigate this is to modify the SPL and u-boot sources to output debug stuff to screen.

UPDATE 1: just don't know why I didn't think of it before. I just connected the serial console AFTER the boot hangs and confirmed that u-boot has received some garbage input and is sitting there like a stupid waiting for further instructions. I'm not sure how the USB power applied is causing this garbage in the serial input when it's undriven, but that is definitely what's happening. The fix should be dead easy: modify u-boot to completely ignore any input.

UPDATE 2: fixed, should go in the next dual-boot release. Unless people reports this is causing problems, I'll wait until I make some other pending changes into the dual boot to make the release.


  1. I'm not very into linux things, but since i'm working on switching power supplies, i can tell you why this is happening: usb power is usually VERY VERY noisy in the range of 100kHZ-100MHz (frequencies interested by the serial connection comunication). Moreover i saw the photos of your serial port mod, and i think that probabilly that the some-cm-long cable you added can very probabilly act as an effective antenna (short dipole) in that frequency range. A common mode rejection inductor similar to the ones you can find in common usb2.0 cables should lower the problem. It would be interesting to try...

  2. Forget about the inductor... it won't work, since it's probabilly a radiated emission. What about (eventually) enabling pull-up resistors? If your level adaptor can work in open collector, this should work fine. No problems for us who don't have serial mod, anyway (tested many times in the past rebooting while hanged to wall charger).

  3. @batman52

    I had addressed this problem quite a long ago by enabling the RX/TX pin pull-ups. That was obviously not working, and now that I think about it, I know nothing about the strength of the internal pulls of the pins. I do not even know if they are pull-ups or pull downs (though certainly the former is most usual).

    Note that for the final user a hardware modification is not feasible. So either users that haven't modified their A320 don't have the problem or we provide a software solution. The problem seems to arise only when the RX pin is undriven. If it is undriven, the user has not installed a serial console port and thus he won't care if we completely ignore it.

  4. @batman52

    BTW, obviously there is a noise problem, but I don't believe it's direct noise from USB communication. Note that the problem is there when you connect the USB cable to the power adapter (no PC).

    I bet it is noise from a DC-DC power converter which is only active on USB power. Maybe it's the battery charger (I doubt it, in these cases they are lineal), maybe it's the main 3V3 step-down... who knows.

  5. @booboo: i didn't mean noise was coming from the usb comunication, but from the usb voltage regulator (since you said it happens with wall charger too), anyway you're right when say that an internal DC-DC (battery recharge?) would have the same effect.
    But.. since as far as i can remember, i cannot experience that problem (for sure i'll test again when i'll get back home) i supose that the serial mod exposes you more than us to the noise... When the RX pin is undriven it probabilly shows an high impedance, so even a small amount of spurious current (that can be easily collected from the cable you soldrered, coming from any noisy source in that damn close pcb) can drive significant voltage drops/rises to the parasitic capacitance of the pin itself.
    I bet that noone else will report faults. I didn't suggest any hw modification for users, though!

  6. @booboo
    dingux boots fine for me after a reset while holding SELECT button.
    Btw, sorry to hijack this thread, but any chance sdl can be compiled with joystick support for the next toolchain/rootfs release?
    It's really annoying how games don't want to compile because of it, and even more annoying that I have to remove all the joystick code to get them compiled.

  7. @zeartul: could you please try dingux booting while dingoo is attached to the wall charger?

  8. @batman52
    couldn't try it with the original wall charger (different power socket standard), but tested it with openmoko charger.
    Everything is fine, dingux boots without problems.

  9. @zeartul

    You mean that some applications are joystick-ready and will work without a joystick, but won't compile if the SDL has no joystick support?.

    If that's the case, of course I could enable joystick in the SDL, but I'm not sure it's the way to go. It would make the SDL larger by putting code that is never used.

    On the other hand, I understand that it's a PITA to have to remove code from existing applications, though I think it's the author's fault to account for missing physical joystick controller but not for missing joystick support in the SDL itself.

    What about patching the SDL so all the joystick code is removed and the related functions always return error?. SDL joystick support would appear as enabled but joystick initialization would always fail (would fail anyway since there is not physical joystick).

  10. @booboo
    Yep, they work fine without joystick, but need joystick support in SDL in order to be compiled.

    Every method is fine as long as I don't need to modify the source code of games I want to port.

    BTW, now when I got your attention :) Are you interested in joining our irc channel #dingoo-a320 on freenode? It would be great to have a more direct contact with you than just via comments here.

  11. @zeartul

    You'll probably be amazed to learn that I've never ever used IRC :-), however, this might be a good time to start. How do I join? (instructions for dummies, please).

  12. zeartul said:

    "Every method is fine as long as I don't need to modify the source code of games I want to port."

    That's funny. Every method is fine while YOU don't have to move your ass.

    Porting a game to another platform involves modifying the source code. What yo want to do is a quick compile, not a port.

  13. @booboo
    First download some irc client. Xchat is good.
    Then connect to a server "".
    If you're in, type "/join #dingoo-a320".
    That's all :)

    I admit, I'm lazy :P
    But it's better to change one thing, than to modify code for every game.
    And it's not just me and my ports. I'm sure there are lots of other games that use joystick in their code.
    It's really easier to just modify libSDL than every single game you try to port. And some of them have joystick code put in many places, so you have to search for it in dozen files.

  14. Well i got the problem that after Installing Dual-Boot Loader and copying zImage (ILI9331 in my case) and the rootfs file to my card, and reseting my dingoo and holding/pushing select
    my Dingoo hangs at the Dingux splash screen.
    While the older method by using a fat32 and a ext2/3 partition everithing works fine.
    And i got no power cable attached.
    What am i doing wrong, or is it a BUG?
    I´ve tested it with a 8gb and 2gb micro card.

  15. Booboo, I had had some comments from some of the french developers who originally used my uclibc toolchain and then switched to yours complaining about the joystick thing. I guess I kept joystick support in my toolchain but when they switched to yours none of their stuff would compile because of it. I dont know if the dpad actually maps into the sdl joystick stuff or not, wasnt sure if its actually useful to keep it or not.

    Either way if you do go on the irc channel Im sure you'll see them, Im usually on there as sasquatc4 if you wanted to discuss the java issues as well.

  16. @Suicide
    Did you rename the zImage-ILI9331 file to zImage?

  17. @ e.r.i.c
    Yes i dit.
    I tried to rename it to zimage and zImage.
    I don´t know why it wont work.
    And becouse of that prob im still using
    the FAT32 + ext2/3 method.
    But i really would like to test the Fat only Root System.

  18. @Suicide
    Could you try formatting one of your sd cards to only fat32?

  19. @ e.r.i.c.
    I already did that.
    I´ve just changed the Partition/s to FAT32 + ext2/3 after the FAT32 only Partiton with Dingux didn´t work.
    I´ve also tried to kill the existing FAT32 ( only ) Partition and then created a new FAT32 partition and formating it about 4-6 times new.
    But still no change.
    I think i did it all in the right way.
    Maybe a newer release will work , tried it with
    "dingux-system-20090726" and
    Anyway thanks for your help