First and foremost: sorry for being so hard to get in touch with lately. We've been in defcon 1 for the last week at work preparing a demo for the current project (OMAP3530 based) which is crucial to the future of the company, so I had reduced my daily routine to sleep-eat-work-sleep. My inbox is exploding.

Sweetlimre commented on having a writable home directory (see interview). If I recall correctly, I wrote about this already. The main application executed by busybox's init process is responsible for this. At this stage in the boot process no HOME environment variable has been set. I could easily modify busybox's init to set it to "/usr/local/home", but I felt it's better to stick to a vanilla busybox as much as possible. Oh, wait: maybe if (as I recommended) the main menu application is using exec() to launch emus/apps things are not so simple. Need some input from devs here, and if the only solution is to modify busybox's init, so be it.

Regarding the modified buildroot I'm using, as he requested it's now available for download at the google code project page. I hadn't published it before just because I could not find time to fix all the dirty hacks I used, which resulted in a partially manual build. I'll be glad to add anything developers suggest. Just send me the buildroot recipe. I would really like to stay away from OpenEmbedded. I have to use it for the OMAP3530 and IMHO it is way overengineered.

Some good news on the Ingenic front: the Qi-Hardware guys have managed to get Ingenic to release their kernel development trees DAILY. This means immediate access to any useful fix they make. There are 2.6.24.3 and 2.6.27 branches, and I'm working on porting the A320 support code to the later, mostly to see if it helps somehow with the USB/DMA and SD/MMC standing bugs. Note that in the case of embedded devices like the A320 I don't think that newer kernel is necessarily better.

Regarding the Gemei x760+ things are going slower than expected. I dumped the hardware initialization .DL from NAND flash and disassembled it, only to discover I was looking in the wrong place. Let me explain:

When the JZ4740 boots a piece of code called the IPL (Initial Program Loader) is executed from ROM. Depending on the state of some pins this code either enters USB boot mode or boots from NOR or NAND flash. In the A320 we can only choose to enter USB boot mode or boot from NAND. The IPL only supports 512 and 2048 page size NAND, so despite the fact that the NAND chip in the A320 has a 4096 page size it is handled by the IPL as if it was 2048.

The IPL reads the four first pages (8KB total) of NAND into the instruction cache (because the SDRAM is not yet available). This is called the SPL (secondary program loader) and its purpose is to do a basic hardware initialization, most notably making the SDRAM available, and load the system loader from NAND. The A320 SPL also handles the NAND as if it was 2048.

In the original firmware the SDL is stored in the first 8KB of the first NAND block (0x00000-0x3FFFF). It loads the system loader from 0x50000-0xBFFFF. Before loading the operating system the A320 system loader does something interesting: it loads from 0x40000-0x4FFFF a piece of code that I call the hardware initialization DL. It is a dynamic linked object code chunk that does board-specific hardware initialization: GPIO, LCD, etc. This is the interesting stuff. In both the older and newer A320 the LCD initialization code was reverse engineered from this DL.

However, the x760+ LCD initialization seems to be mostly done by the system loader itself. It stil loads the DL and uses it for some GPIO initialization that is also related to the LCD controller, but not much more. The DL does contain a large LCD register initialization code routine, but it is unused (and I lost a lot of time reverse engineering it).

Since the system loader code is much larger (~260KB) than the DL code (~10KB), it's gonna take some time to reverse engineer the LCD handling code. Note also that I had already reverse engineered the A320 DL code and that helped a lot, but the system loader is unexplored territory.