Sunday, June 28, 2009

Some clarifications

  1. The zImages in the dual-boot installer packages are only for flashing. Do not use them as your main kernel, i.e. do not place them in the miniSD. Get your zImage separately from the downloads section on the google code project page.
  2. If your screen flashes, it means kernel panic. At the moment I have notice of this happening only in three scenarios: when you have done something wrong and the kernel cannot mount the ext2/ext3 root filesystem on the second partition of the miniSD, when it can mount it but there's no /sbin/init (or can't execute it), or when you unplug the USB cable in linux. The later is a bug in the serial USB gadget that is yet to be fixed.

Saturday, June 27, 2009

Yet another dual-boot release: serious spurious bug fixed

You can download it here.

I didn't noticed this bug because as you know I modified my A320 and attached a serial port converter. Today I was playing around with it and noticed the problem.

It turns out that the Ingenic provided function to initialize the UART disables the pull-up resistors of the TX and RX pins. That means that the RX pin is left floating if not connected to an external circuit (which is the case of ALL of you). U-Boot listens to the serial port for commands, and if it detects a break condition or some other input, it stops the boot process and waits for further commands, which never arrive. The fix is as simple as leaving the pull-ups enabled.

I am sorry for not detecting this earlier. Please upgrade your dual boot.

Also, I made a couple of "aestetic" changes as suggested by someone: no more "white screens" while loading. The "white screen" glitch is caused by the LCD initialization code both in the original firmware system loader and in the linux framebuffer driver. Normally you should not see this white screen because the LCD backlight should be off. However the dual boot SPL shows the splash screen and leaves the LCD backlight on.

The original firmware case is solved by switching the backlight off just before jumping into the system loader. The system loader quickly initializes the LCD, so you'll see a black screen only for a split second.

However, in linux I cannot do that because it takes significantly longer for the framebuffer driver to kick in, so it's better to leave the LCD on. But here, as opposed to the original firmware, we have the sources. The solution has been just to always switch the backlight off before performing the LCD initialization in the framebuffer driver.

LCD type autodetection not possible

Quick post: I'm almost 100% sure that LCD type autodetection is not and will never be possible. The /RD signal of the LCD is just not connected, so despite the fact that the LCD has a specific register to identify the model, it cannot be read.

Makes sense: maintaining two or more firmwares is definitely something to avoid, so if the makers of the A320 are doing it, it's because that's the only way.

Please, note that they use a trick to somewhat alleviate the problem: the LCD initialization code is stored in a special place in the NAND flash which is never touched when performing normal firmware updates. However, those of you that have used the unbricking tool have noticed that when restoring from scratch, one has to specify the LCD model by selecting the appropriate .DL file.

So, for the time being, there will be two releases, one for each LCD type. We cannot use the trick that the original firmware does because we cannot use the NAND flash to store settings. However, if (when) linux becomes a firmware replacement, we'll go that way.

Friday, June 26, 2009

New dual-boot release: fixed slowdown in original firmware

As usual, get it here.

I know some people is more than happy with what is actually a side effect of the slower pixel clock: no more screen tearing in certain emulators/games. However, I feel the priority is making dual-boot completely transparent to original firmware. And most importantly, the original firmware is unacceptably slow for some. For those that do need the slow pixel clock "untearing" effect, someone will soon release an "LCD underclocking" application (.app).

Regarding "tearing", it's a visible artifact resulting from frequency mixing. The two frequencies involved are the LCD refresh frequency (set by the LCD pixel clock) and the application screen refresh frequency (commonly called FPS or frames per second). When you multiply two frequencies you obtain two other frequencies: the sum and the substraction. The sum is usually too high to be noticed (65Hz+60Hz = 125Hz), but the substraction is a whole different story (65Hz-60Hz = 5Hz, which is very visible). This is the same effect you can see when you use a camcorder to record an old tube TV.

The only way to get rid of it is retrace syncronization, that is, to force the application to refresh screen at the same rate than the LCD is refreshed. I haven't studied very well how the LCD works and is connected, but I suspect that there is no easy way to synchronize the applications and the LCD. It may not be impossible, but it is certainly going to be difficult.

What you can be sure of is that the original firmware makes no efforts to synchronize, and that is not going to change anytime soon. Our best bet regarding this issue is definitely linux.

Finally one personal note: this has been so fast because I had plenty of time. I've been sick at home for the last three days: I had a very bad muscle contracture on tuesday evening and have had to stay in bed for the last two days. Today I'm better but can't stay sit or standing for very long. Fortunately with help from my wife I found a way to comfortably use my laptop while laying on my stomach. It's quite funny but works. Don't be surprised if you don't see any updates for the next days since I have lots of work (the one that pays the bills) pending.

Gotcha !!! (LCD pixel clock problem fixed)

This is what I've done: I built a program with the SDK that runs on the original firmware and that writes all the registers and stuff to a log file. I booted the original firmware with and without dual boot and compared the log files.

And man, this "bug" is so exotic I have to explain it (warning: your head may explode):

This is a summary of events related to clocks and LCD that happen from reset:
  1. The SPL initializes the PLL and all system clocks.
  2. The system loader initializes the LCD and shows the Dingoo Digital splash screen.
  3. Either the system loader or the ccpmp.bin program that it loads initialize again the system clocks.
The initialization of the system clocks has one funny detail: you program the PLL for a certain frequency (say 336MHz) and you configure it to output either that frequency or half that frequency. The different peripheals (including the LCD) generate their clocks by dividing the PLL output.

This is what happens in the original firmware:
  1. The SPL code initializes system clocks: PLL 336MHz, PLL output 336/2=168MHz.
  2. The system loader initializes the LCD clock generator. It programs the divider to obtain 16.8MHz. It accounts for the "divide by two" configuration and thus the required divider for the LCD is 10 (168MHz / 10 = 16.8MHz).
  3. The system loader (or ccpmp.bin) initializes again the system clocks. As the configuration of the system clocks is the same set in step (1), nothing changes, in particular the LCD clock.
This is what happens with dual boot:
  1. The dual boot SPL initializes system clocks: PLL 336MHz, PLL output 336MHz (not divided by two !!!).
  2. The system loader initializes the LCD clock generator. It programs the divider to obtain 16.8MHz. As the PLL output is not divided by two, the required divider for the LCD is 21 (336MHz / 21 = 16MHz, which is the best possible approximation to 16.8MHz).
  3. The system loader (or ccpmp.bin) initializes again the system clocks, but now, something changes: the PLL output is programmed to be divided by two. As the LCD clock divider remains unchanged, the net result is that the LCD clock is divided by two, resulting in 8MHz.
As you see, this is actually a bug in the original firmware !!!. Either you must initialize the LCD after the system clocks or you must recalculate the LCD clock after a change in the system clocks configuration.

IMPORTANT: something similar was happening with the USB clock. That might explain the effect of plugging the USB cable that some users notices, though I can't think of what is actually happening. Also, I can't explain why some users hardly notice the slowdown while others say it's unbearable.

Not sure if this was the only thing that needed to be fixed. I'm still investigating in the GPIO differences I noticed.

I have already fixed it and plan to repackage it all again and make another release. However, there's an interesting dilemma here: some users are extremely happy because the reduced LCD pixel clock seems to fix tearing in some games/emulators. I all for fixing it because:
  • I don't have time to play. I'm too busy coding :-)
  • The whole idea is to leave the original firmware unchanged.
  • It is not ok for some users. We need something that works for everybody.
There is an easy solution: just as there is an application to overclock the A320, it is very easy to program an application to change the LCD pixel clock. I'm a bit swamped so I beg your pardon but I won't program such application. If someone wants to, here's the code you need (from this file):

/* Timing setting */
__cpm_stop_lcd();

pclk = 16800000; /* Pixclk */

pll_div = (REG_CPM_CPCCR & CPM_CPCCR_PCS); /* clock source,0:pllout/2 1: pllout */
pll_div = pll_div ? 1 : 2 ;

val = (__cpm_get_pllout() / pll_div) / pclk;
val--;
if (val > 0x1ff)
val = 0x1ff;

__cpm_set_pixdiv(val);

REG_CPM_CPCCR |= CPM_CPCCR_CE ; /* Update divide */

__cpm_start_lcd();

Another suspect: DMA starvation (updated: not really)

I've been thinking about the slowness problem and did some tests. I have another suspect: DMA starvation.

I think that as I already mentioned in the previous post, the original firmware doesn't reconfigure the LCD stuff if it is already configured, which means that the LCD stays configured as I do in the dual bool SPL code.

And in the SPL code, I set the pixel clock to 16MHz. It is quite high and has the advantage of a high refresh rate which is why some display artifacts in the emulators seem to be gone.

The downside is that it consumes a large amount of DMA bandwidth and the rest of functions that need DMA, like NAND flash / miniSD access, get starved.

I've verified that in linux when I set the LCD pixel clock to 24MHz the LCD works fine buy the kernel can't read from the miniSD. I suppose something similar is happening in the original firmware. The guy that ported linux to the onda vx747 also mentioned this problem (DMA starvation) and he implemented DMA round robin priority, but I'm not sure if that's the way to go because I'm sure we don't want the LCD display to be affected by disk access (either NAND of miniSD). He also implemented some optimizations in the framebuffer driver that I still have lo give a look at.

I have two ways of fixing the problem:
  1. Deinitialize the LCD just before jumping to the original firmware system loader. I don't know how to do this in an effective way because I don't know exactly how the original firmware detects that the LCD has already been initialized.
  2. Find out the LCD pixel clock that the original firmware is using and use it in the SPL. This is done by programming an application to run on the original firmware that reads the configuration registers and saves them to a log file.
I'll give a try to both approaches.

UPDATE: I've read all the internal registers both with and without dual boot. As suspected, the LCD pixel clock is different... but it is actually lower with dual boot !!!. That trashes my DMA starvation theory. There are some other differences (in particular some GPIO registers) that I'm investigating. Stay tuned.

Dual boot pixclk = 8 MHz
Original FW pixclk = 16.8 MHz

Uninstall capability added to dual-boot installer

As before, get it from the google code project page here.

This is a quick release for those experiencing problems. Doing a full firmware restore takes time and will erase your files, so I though it would be relatively easy to add uninstall capability to the dual-boot installer. The instructions to boot the installer are the same, but the installation menu now allows you to choose between flashing dual-boot or original firmware.

IMPORTANT:
  • The problem of original firmware running slow is not fixed.
  • The restoration is done by flashing the original 8K of SPL code. But this is the SPL taken from my A320 after restoration of original firmware v1.1. I'm almost sure this code is the same for all A320s out there, but obviously I cannot test it. Please report success (or failure).
Regarding the slowness problem, I can't reproduce it in my A320. However, I have an hypotesis: people have reported that despite the slowness of the original firmware, emulators run ok and LCD tearing and other artifacts are less evident or have vanished. The dual boot SPL initializes the LCD and shows a splash screen. The original SPL does not do it and maybe the original firmware detects that the LCD is already initialized and doesn't do it again, leaving the initial configuration, in particular the pixel clock. I used a 16MHz pixel clock which results in a high refresh rate which could be alleviating LCD artifacts during emulation, but for some reason the menu application chokes on that.

I'm going to send modified versions of the dual-boot SPL to people that has reported the slowness problem. If the LCD initialization is the problem, I can skip it when booting into the original firmware.

Please be patient, keep in mind that I cannot reproduce the problem in my A320 and that makes things difficult. The newer A320 with the ILI9331 LCD is on its way from DX, but I bet it won't be here before a week or so.

Thursday, June 25, 2009

Slow???

Some people have reported that the original firmware (at least the menu) runs slower. I would like to get as much information as possible about this problem, so if you have noticed something, send me an email ("About Me" ---> "View my complete profile") with a description as complete as possible: description of the problem, firmware version, everything in the "About" screen and the hidden system info screen, etc. Even a video showing the problem would help.

If you want to remove the dual-boot, you can do it by doing a full firmware restore. Google for the unbricking tools. Remember that you'll lose all your stored files, so backup them before restoring.

I just can't think of a feasible reason for the slowness: the dual boot SPL mimics the hardware initialization of the original firmware up to the last operation, most notably the CPU and peripheal clocks. But I might have missed something...

So, please report and document as completely as possible the problem and I'll look in to it as time permits.

Dual boot installer released

Get it from the google code project download section here.

The README file explains it all. You can flash dual boot in your A320 both from Windows and Linux. Note that the installer will give you the ability to select from original firmware on internal flash or linux on miniSD. The later means the dual boot code will look for a zImage kernel file in the first partition of the miniSD and launch it. That's all.

IMPORTANT: I'm almost 100% sure the ILI9331 variant works fine, but could not test it since the newer A320 (paid by your generous donations) hasn't arrived yet. Postal service sucks big time here. If you have any troubles, please let me know.

Some notes for rootfs developers:
  • The flashed U-Boot environment can't be changed. It just loads a zImage from miniSD and that's all.
  • If you want to pass special command line parameters to the kernel, you must embed them in the zImage (see CONFIG_CMDLINE). That means you need to recompile the kernel.
  • If you want an initramfs, you'll also have to embed it into the kernel (see CONFIG_INITRAMFS_SOURCE).
I guess that U-Boot environment could be read from miniSD, but I don't see the point at the moment and didn't bother to implement. Will do if the need arises.

This is how the installer works: the instructions let you boot a zImage. It's just the kernel with three particularities:
  • The console font size is set to 8x16 (instead of the tiny one).
  • The NAND flash support is enabled and forced to 2K page size (required to properly write the SPL area which is the first eraseblock).
  • There is an embedded initramfs which contains libc, busybox, mtd-tools, dialog, and a script that executes on startup, shows a disclaimer and does the job.
Using Linux to do the actual flashing has the advantage of having a single installer. The instructions for Windows and Linux differ because they use different tools to boot the kernel with embedded initramfs, but once the kernel is running the flashing (or any other task that I might perform) is independent of the PC operating system.

UPDATE 1: yes, the logo is shown even if you are booting into the original firmware. I though it was nice to show it as sort of saying "this A320 is modded to boot linux". However, it can be easily changed if enough people prefer it not shown.

UPDATE 2: please please please read the keyboard related section of this document. It explains the current key map and special key combinations in linux, in particular how to reboot the machine. I've noticed that the immediate reboot key combination (POWER+START+SELECT) is a bit inconvenient if you are rebootint into the original firmware, because you must be quick releasing SELECT or you boot again into linux. This wasn't a problem when boot selection was being done by U-Boot because it takes a little time to load, but now selection is done right in the SPL, in fact the SELECT key state reading is the first thing done. I'll be glad to hear your comments and suggestions on this issue.

UPDATE 3: some clarification: the dual-boot installer lets you boot linux withou having to use a PC. But you had to have linux installed already in your miniSD as described in the QuickStart guide in the wiki section of the google code project page. I guess it's been a bit confusing that I've released a kernel image at the same time than the dual boot installer. You still need to install the root filesystem in a second ext2/ext3 partition.

UPDATE 4: yes, formatting and installing the root filesystem from windows is not yet solved, but it is not difficult and someone (maybe me) will do it soon. All we need is to place the rootfs file in the FAT partition and embed a initramfs into the zImage that will first mount the FAT partition and then the rootfs file as a loopback device.

Wednesday, June 24, 2009

Names, names, names

Thank you all for your suggestions. Some thoughts, in no particular order:

  • Someone suggested "booboo linux". While I feel praised, I don't think it's fair. Yes, I've put quite a bunch of work on this, but remember that I did all on top of the linux code base and the Ingenic patches. I you think of it, my contribution is comparatively tiny. I'm standing on the shoulders of giants.
  • Not any name will do. The domain must be available. I've put the name in the dual-boot splash screen and I think it's a great way to promote the project, but for that to be effective it must lead to a web page. I love "lingoo", but is not available. Chances of a short name like "dix", being available are also close to none (and yes, being a non native english speaker it was not immediately obvious to me what it sounds like).
  • What about "dingux" ?. The domain is available.

Again, your comments are highly welcome.

UPDATE: changed to DINGUX. Some don't like how it sounds, but seemed a good blend of dingoo and linux and I want to focus on coding. The domain is now www.dingux.com, please update your links.

Tuesday, June 23, 2009

Quick update

Sorry for the slow updates. I've had to deal with lots of unexpected trouble during testing of dual-boot, plus school finished recently and thus my two daughters require more attention.

I appreciate your support very much and I know you're all holding your breath for the dual-boot functionality, so, please excuse me for the delay.

This is what's been done:
  • Dual boot code has been moved from U-Boot to the SPL: removes tiny delay introduced when booting the original firmware.
  • LCD support implemented both in SPL and U-Boot (both ILI9325 and ILI9331). The LCD now goes live immediately on bootup, which is great when loading linux because otherwise you would see a black LCD for a couple of seconds until the kernel framebuffer driver kicks in, and it is a bit confusing.
  • Implemented access to the SPL area (first eraseblock of NAND) in the linux kernel. This allows flashing the dual-boot binaries from linux.
  • Streamlined the flashing of the dual-boot binaries from linux.
This is what needs to be done:
  • Add a simple dialog that shows a disclaimer and asks for confirmation before flashing the dual-boot binaries.
That is very easy and I just need a couple of hours to do it, so I can assure there will be a release tomorrow or the day past tomorrow.

One final note: someone posted a comment pointing out that lingoox might sound a bit offensive in some contexts. If this is a problem we're on time to change it... so please let me know.

Tuesday, June 16, 2009

You made it! (again)... ordering a Gemei x760+

Thank you all your support, encouragement, and donations.

There's now enough donated money so I'm ordering a Gemei x760+ and will start working on it as soon as I get my hands on it.

My A320 so far has given me maybe a hundred hours of fun, but isn't it weird only two of them were actually listening to music, playing videos or playing games?.

Sunday, June 14, 2009

Dual boot video

Still preparing the dual boot package release. Meanwhile, here's a short video of dual boot working. The final version lits the LCD as soon as you switch it on, but shows nothing on it until the kernel framebuffer driver takes control. It's not nice but is better than having a dark screen (which felt like something was not working).

One note on boot time: the current boot process involves u-boot and a one second delay before mounting the root filesystem. u-boot is necessary because we are booting from miniSD and the delay is needed to let the kernel hotplug system detect the miniSD. Eventually, when linux replaces the original firmware (don't hold your breath), those delays will dissapear.

UPDATE: yes, I said I'd be releasing binaries this weeked, but though I've dedicated quite a lot of hours, there were many issues to address. Please be patient.

Keyboard driver rewritten

Dual boot required a working way to reboot linux and get back to the original firmware, so I set out to implement that functionality into the keyboard driver, and noticed I should be using the input-polldev code rather than the original approach, so I ended up rewriting the driver (and learning in the process quite a lot about the linux input layer).

The normal keyboard map hasn't changed (mimics the GP2X), but now there are special combinations that use POWER and START. I've tried to come up with a clever set of combinations, but I'm always thinking I might be missing something important, so I kindly ask for your comments and suggestions. Please have a look at the keyboard section of the README-A320 file (you can also checkout the kernel code, compile and test it, at least until I release a new kernel binary).

Wednesday, June 10, 2009

Dual boot working !!!

Just a quick post to tell that dual boot is working now.

I'm not making a release right now, but I will most likely this weekend. The reason is that this is something people will be actually flashing in their consoles, so before making a release, I need to:
  • Test some corner cases.
  • Clean up u-boot code and commit it to google code.
  • Write detailed instructions for end users.
For the tech-oriented, this is how it works:
  • Only the first NAND block is modified. NAND is treated as if it was 2KB page size (it is actually 4K), because that is how the ROM IPL treats it.
  • u-boot SPL is placed in pages 0-3 (0x00000000-0x00001FFF).
  • u-boot is placed in pages 32-127 (0x00010000-0x0003FFFF).
  • u-boot has been modified to support A320 hardware and to understand the non-standard way in which error correction data is stored in the area where the original firmware system loader lives (pages 128 and up).
  • If SELECT key is not pressed, u-boot loads the original firmware system loader from NAND offset 0x40000, size 0x80000, into DRAM address 0x80E00000. Then jumps to 0x80E10004.
  • If SELECT key is pressed, u-boot loads linux from the miniSD.

UPDATE: for those that just joined, and answering user comments:
  • Yes, this means you can boot and use Linux on your A320 without a PC.
  • Yes, you still need some menu application. I don't provide that since I have limited time and want to focus on the kernel, but someone will (there are plenty of very skilled programmers turning their attention to the A320).
  • Hardware support is still limited to video, sound and keyboard, that is, just what you need to play emulators (can you spell mame?). Now that dual boot is working I'll focus on improving hardware support.
  • Lack of full hardware support means linux won't replace the original firmware anytime soon (but will eventually, that's my goal). So we have to get along with the original firmware and that means linux must run from the miniSD. Altering the internat NAND flash was necessary though in order to tap into the boot process and launch linux from the miniSD.
  • Work on the x760+ will start as soon as I get my hands on it. There's almost enough donated money (thank you very much again for you support) as to purchase both a newer LCD A320 and a x760+. I'm still trying to purchase the newer LCD A320 from someone who can guarantee I'll get one of the newer models, and regarding the x760+... can you suggest where to buy it?.

Monday, June 8, 2009

Dual boot documentation updated

Added what I found out so far from disassembly of the original firmware SPL, and some more thoughts on how to implement dual boot. Check it out here.

UPDATE 1: I hit an unexpected roadblock. I had u-boot working already on the A320, but the OOB format in the NAND area where the original firmware system loader is stored is rather unusual, if not completely nonstandard. That means I must study the SPL code a bit more to understand the format and modify u-boot to handle it (u-boot decides the OOB format on his own depending on the flash chip type).

UPDATE 2: main obstacle overcome. Now I know how ECC data is stored in the OOB area where the system loader is stored. Since it is non-standard I still have to modify u-boot to handle it. It's going to take a bit longer because u-boot is a bit "too smart" and autodetects NAND type, which means I have to either override it or implement special commands to manually force the NAND configuration.

UPDATE 3: done. Dual boot is working. I just need to clean up u-boot code a bit and prepare a binary and easy install instructions for end users.

New kernel binaries

I've commited some stuff to the repository:
  • Added README-A320.
  • Added support for ILI9331 LCD controller found in newer A320.
  • Make IPU memory reservation optional (and default disabled). Saves 4MB of memory and anyway it's too soon to start working on mplayer for dingoo-linux. If you really need it, just enable it (see README-A320).
  • Default enable CPU frequency scaling. JUST ENABLE IT, untested and anyway you can only REDUCE the CPU speed. Will start working on make this usable and be able to squeeze until the last MHz out of the A320.
And also have placed a couple of kernel binaries in google code downloads section. For now, you must choose the one suitable for your LCD type. When I get my hands on one of the newer A320 models I'll try to implement autodetection.

Still using OSS. It's buggy and uses a crazy amount of memory, but so far it works if you stick to the S16 sample format.

I'm making some progress on dual boot. At least it's now clear to me the only way to go is to completely reverse engineer the original firmware SPL and patch it to load u-boot from a different NAND location if SELECT is pressed. The approach of chainloading the original SPL has proven to ve a dead-end so far.

UPDATE: after too much lost sleep, I've finished disasemblying and understanding how the original firmware SPL works and I think I know now where and how to place things to properly tap into the original firmware boot process. Since I got u-boot working weeks ago, we should have dual boot working shortly.

Friday, June 5, 2009

Newer A320 with ILI9331 LCD controller working !!!

Looks like the first report was a false alarm. Later reports say it works. Not too bad for a code released after zero testing...

So that's it. Linux works for users of newer A320s. I won't cancel the purchase of one of the newer A320 units though (thanks again for donations!), since I still need it for testing the framebuffer driver optimization I'm working on. Next machine to acquire is a Gemei x760+.

Please, if you make a donation, tell me what system you own or are interested in being supported, so I can prioritize use of the donated money.

NOTE: if you own one of the newer A320 with the ILI9331 LCD controller, please contact me. I might need to get someone to perform quick tests of kernels to enable LCD model selection/detection, at least until I get myself one newer A320.

Wednesday, June 3, 2009

Back to ALSA

Ingenic seems to provide both OSS and ALSA support in their kernel. I went OSS (which is deprecated) instead of ALSA just because I could get no sound output with the later while the former worked out of the box. As a side effect, OSS is lightweight compared to ALSA, which is an advantage in systems with limited RAM, as is the case of the A320.

I've been trying to fix some issues in the OSS driver and today I gave up. The code is the biggest POS I've seen in my whole life. I would write it from scratch if I had the JZ4740 manual, but for some reason beyond me Ingenic hasn't released it, so instead of learing how the hardware works and then write the code I have to understand how the hardware works from studying the code. No way with such a POS.

So I'll start working in getting sound output from ALSA, whose code seems to have an acceptable quality. It's certainly a pity losing the lightweight advantage of OSS. The libasound library that comes with the Ingenic toolchain is about 1MB size (stripped!, for god's sake, what's in there?). I'm not knowledgeable on ALSA internals, so any suggestions on how to get it thinner would be welcome.

UPDATE: confirmed... something is REALLY wrong with the Ingenic OSS driver. It takes nothing short of 3.5MB of memory !!!. Makes no sense (and the used buffers are much smaller).

Testing support for newer A320 with ILI9331 LCD controller

I finished disassemblying the .DL hardware initialization code of the newer A320 with ILI9331 LCD controller and modified the code in the kernel framebuffer driver. Since I don't have one of the newer A320 (soon to be fixed, thanks again for your donations) there's no way I can test it, so I need help here. Download the zImage (mediafire, I don't want to upload untested stuff to google code), try it and let me know if the framebuffer works.

If it works, I'll do some minor modifications in the kernel code to allow selecction of LCD initialization sequence and commit it to the subversion repository on google code. I'll be releasing two kernel images until I get one of the newer A320 units so I can work on autodetecting the LCD type.

UPDATE 1 (WRONG): at least one user has reported that the new driver doesn't work. It might be a silly detail but I'm blind and there's absolutely no way I can go any further until I get one of the newer A320. There's enough money in the donation pool (thanks again!) so I'll be ordering it in short (I'm trying to contact CraigX to see if he can make sure of shipping a newer model if I purchase it from him). Please be patient.

UPDATE 2: looks like that was a false alarm. It works. Read this entry.

Tuesday, June 2, 2009

You made it!... ordering a newer LCD A320

Thank you all for your donations. There's enough money now to order one of the newer A320 with the ILI9331 LCD controller. Next purchase target is a Gemei x760+ whose hardware is believed to be almost identical to the A320, most notable exception being probably the LCD.

As you know, there's no way I can assure I will be getting one of the newer A320, which is a must if I want to properly develop and test the hardware support for the ILI9331 LCD controller. So, in order to maximize chances of getting the newer A320, I'd like to make a little poll: please leave a comment telling where you purchased your A320, the approximate purchase date, the color (important!) and the hidden system information screen (so I know which LCD model it has, see step 1 of this entry).

Disassembly of A320_PD27_ILI9325_RLS.dl posted

I've posted here the commented disassembly of the hardware initialization .DL file in the first unbricking tool (ILI9325 LCD model). I just started to work on the .DL file in the second unbricking tool just made available (ILI9331 LCD model), and should take not much long until we have the framebuffer back working in the latest A320s.

When I first read A600's comments about a required .DL file to initialize the LCD I remember to have though that it made no sense: it looked like this initialization code was being used only by the firmware upgrade tool, and thus you should be able to upgrade the firmware without the LCD working.

It turns out that the A320 boot process has many stages (IPL in ROM, SPL in the first 8K of NAND, and then the LCD initialization code). So, the .DL file is actually part of the firmware and is written to the flash during the firmware upgrade process. If you dump your NAND using the instructions in my previous post, you can find it at offset 0x4000C in the 2K dump file (size is DWORD at offset 0x40008).

BTW, thank you very much to those who have donated and to all who have encouraged me and expressed their support. This is fun, but your support makes it rewarding too. At this pace I might be ordering a new LCD model A320 and maybe an x760+ this week. If you would like some other JZ47xx based hardware to be supported, please let me know and I'll investigate it.

Update 1: work in progress on CCPMP_CFG_A320_LCM_FAIR_ILI9331_320_240.dl. So far everything as expected. No hardware changes and the ILI9331 register initialization sequence is identified. Just need to add code to the framebuffer driver and we should get it back working on the newest A320s.

Monday, June 1, 2009

New A320 hardware spotted, different LCD controller

Looks like the latest A320 hardware uses a different LCD controller (ILI9331 vs. ILI9325), and as a result the unbricking tool does not work. Be careful because you will not be able to recover your A320 after a bad flash (yet).

Also, the current linux kernel does not support this new LCD, though I'm working on that and I believe it shouldn't take too long.

Meanwhile, you can help me sending a dump of the first chunk of your A320 internal flash. Follow these instructions:

  1. Enter the A320 system setup "about" section and press the following key combination: up-right-down-up-right-down. A hidden info screen will be shown. Write down everything.
  2. Download the USB boot tool from here and unpack it in a directory of your choice.
  3. Download this configuration file, rename it as USBBoot.cfg and place it in the same directory (overwriting the existing file). This is the 2K NAND page size configuration file.
  4. Place your A320 in USB boot mode by resetting it while holding the B button pressed. Windows will detect a new device and ask you for a driver. Tell windows it is in the same directory where you unpacked the USB boot tool.
  5. Launch USB_Boot.exe by double-clicking on it.
  6. Execute the command "boot 0". Your LCD will lit up showing whatever was on the controller memory when you hit reset.
  7. Execute the command "nreadraw 0 2097152 0 0". Lots of data will be printed on the screen and after a 20-30 seconds it will stop.
  8. Execute the command "exit" to quit the USB boot tool. This is very important.
  9. Examine the USB boot tool directory and you'll see a new file named "dump.bin". Rename it as "dump_2K.bin".
  10. Download this configuration file, rename it as USBBoot.cfg and place it in the same directory (overwriting the existing file). This is the 4K NAND flash page size configuration file.
  11. Repeat from step 4, rename the resulting "dump.bin" file as "dump_4K.bin". Pack "dump_2K.bin" and "dump_4K.bin" in a single zip file, upload it to a file sharing service and place the link in a comment to this post, together with all the info you wrote down in step 1.
Update 1: use the same 2097152 (=2MB) value for both reads. Actually the value doesn't matter much since the area I want to examine is at 256KB in the 2K dump and at 512KB in the 4K dump, and is just about 10KB long.

Update 2: A600 has already received the new initialization .DL from Sofia/Dingoo, and confirmed that as I predicted it can be found at location 0x4000C of the 2K dumps (file size stored in dword at 0x40008).

Thanks!!!

Blog started !!!

I'll be posting here about progress in porting the linux kernel to the Dingoo A320 portable gaming console, and hopefully to other portable consoles with similar hardware, like the Gemei x760+.

I've placed a donate button. All donations will be used to purchase hardware in order to broaden machine support. Of course direct hardware donation would also be welcome.