Tuesday, August 18, 2009


Lost in Pyrinees for a few days with the family. Trees, cows, bulls, horses and not much broadband. Let's hope the x760+ is waiting at home when I'm back.

Saturday, August 15, 2009

MP4nation still sucking big time (UPDATED)

This is copy of an email I just sent to admin@mp4nation.net. I also opened another ticket.

The x760+ was clearly marked as "on stock" when I placed the order (otherwise I would have placed it somewhere else), but ok, I can accept the x760+ was actually backordered. But customer support is just pulling my leg: every and each time I've opened a ticket they just reply that the item will ship in a couple of days.

This. Sucks. Big. Time. Stay away from MP4nation.

Hope at least I get the money back. To those who donated the money to get dingux running on the x760+, all I can say is that this is out of my control. Sorry.


1- I placed order #18466 on jun 25 (almost two months ago).

2- After 20 days I opened ticket #736735, and this was the reply:

"I am sorry for the delay and the inconvenience caused, the item (or items) you had ordered became backordered. However it is now back in stock and your order is to be processed and sent within the next 2 working days."

3- After 30 days I opened ticket #955719 asking for immediate shipment or immediate refund, and this was the reply:

"Your order will be sent by EMS on Friday to you, it should arrive by Tuesday to you. We are sorry for the delay."

So far, the order is still "processing". Every time I contact customer support they reply that my order will ship in a couple of days. At this point, after two months, I just want the money back.

UPDATE: MP4nation has finally refunded the payment. Ordering from dealextreme. I was a bit pissed off by them selling an item not in stock while clearly marked as "in stock", but what is truly inacceptable are lies about restock and immediate shipping. I could have got the money back one month ago.

Thursday, August 13, 2009

New release of dualboot and system

Get it all from here. You are urged to update at least zImage/rootfs to fix the data corruption on SD/MMC write.

Dualboot now supports partitionless cards (those in which filesystem starts at sector 0). Besides that, the only change is that now u-boot cannot be stopped (which was useful anyway only for those with a serial console installed). Noise in the RX line when undriven was causing garbage chars to be read as input and u-boot stopped boot and waited (forever) for further commands. This is most likely relevant only for people like me with a serial console installed, and even if you are one of those, you may have not noticed it, since it only happens if the RX pin is undriven and the USB cable is connected (noise probably comes from the USB circuitry).

If you have already a working system (which means your card is partitioned) and have never experienced spurious lockups during dingux boot, probably you don't need to update your dualboot, but I would advise to do so anyway.

The kernel has some minor fixes (likely unnecessary, just happened to notice them while hunting the miniSD data corruption on write bug) and the miniSD interface configuation set to 1-bit. Consider this a workaround, because it seems to fix the data corruption but kills throughput. You better have a slow interface than one that can kill your filesystem, no matter how low is the probability.

Regarding the rootfs, the changes are:
  • Updated initramfs to allow to specify several alternate "boot=" and"root=" arguments. This is required to support both partitionless and normal cards.
  • Added option "utf8" in initramfs when mounting boot partition, so foreign language characters are properly handled (thanks Rookie1).
  • Changed MMC controller to 1-BIT mode. Clobbers performance but data corruption on writes seems to be fixed. Workaround until the real problem is identified and fixed.
  • Added patch set for timidity in SDL_mixer (/etc/timidity.cfg and /usr/share/midi/instruments/*).
  • Upgraded to busybox-1.14.3.
REMEMBER: ethernet-over-USB and SD/MMC are as of this release suboptimally configured as a workaround for known bugs. I am working on these issues, please be patient.

Developers are encouraged to read README-A320.

And now for something completely different, I'm in touch with the Qi Hardware team. They are a group of former OpenMoko employees now working on both open hardware and software devices. Their first device is also based on an Ingenic SoC and they are making great efforts to improve kernel support. Most important is that they are in touch with Ingenic and are trying to get them to open more documentation and code (yesterday a newer 2.6.27.x kernel was released!). This is very promising and we will be working together.

Thursday, August 6, 2009

Workaround for showstopper card write corruption

I've been lately throwing some serious time on this issue. It is a slow process because each trial-and-error iteration takes about 5 minutes (must write hundreds of MB to get the corruption to show up). I'm checking the SD/MMC code line by line with the aid of the leaked JZ4740 manuals (which are far far far from being clear), comparing the driver kernel code to the uCOS-II code also released by Ingenic (I've got the feeling it is a bit more up to date) and so on. I've fixed the DMA round robin prioriry bug, which was of course not the cause of the corruption, fixed some other apparent bugs in the jz_mmc.c code, and I'm testing everything that comes to my mind, including slowing down the SD/MMC clock. But it is a slow process, please be patient. There's also the possibility that I can have access to further Ingenic documentation (will comment on this in another post) which could help on this issue.

Well, the good news is that one of the things I tried worked: setting the SD/MMC interface in 1-bit mode (instead of 4-bit) seems to fix the corruption. The downside is that the throughput goes down the drain (yeah, you guessed it, one fourth of throughput of the 4-bit mode). I was about to say that this pretty much rules out a DMA related problem, but I'm not sure that's 100% true since lower throughput also means lower stress on the DMA subsystem which could avoid the glitch or corner case causing the corruption. Anyway, the main suspect is still the SD/MMC interface, either the silicon or the A320 hardware. My bet so far is that the code is not properly detecting and handling an error condition that arises during writes.

I'll be preparing today a new release of dual-boot and system packages. Besides the SD/MMC interface in 1-bit mode, it will include some other improvements like support for partitionless cards.