Wednesday, May 25, 2011

New Gemei X760+

In the comments of the previous post Neno provided the following link:

http://www.it.com.cn/audio/mp4/news/2010/03/10/09/757299_1.html

So I asked ChinaChip. That is the upcoming Gemei X760+ (yes, same name than the old x760+, fun!), and the specs in the linked page are wrong. It's due out by the end of May according to ChinaChip.

It's CC1800 based, same SoC than in the Gemei A330. LCD is 4.3" 480x272. I like the wealth of controls in the lower side.

Unfortunately work on the CC1800 has been slow. It's no fun to write code based on other code with no comments and no programmer's manual, plus I recently got sponsoring for porting dingux to a JZ4755 based device (can't say much about that at the moment), which will be eating up absolutely all of my spare time for the next couple of months. As I already said, I'm not happy being the bottleneck here, so I asked ChinaChip to let me disclose the information they provided on the CC1800 but got no reply, so for now I must honor my promise of keeping the information closed.

Wednesday, April 27, 2011

A320 back to production

It could be infered from the fact that support for a new LCD type was implemented, but I just got confirmation from ChinaChip.

Thursday, April 21, 2011

Support added for new LCD type (ILI9338)

A couple of maintenance releases, which basically boild down to the addition of support for a new LCD type, ILI9338. The support was implemented and tested by ChinaChip, I just prepared the dual boot installer and added the new zImage to the old system package.

Check out the google code downloads page here.

Saturday, March 12, 2011

Running code on the GA330

Check out usbtool here:

http://github.com/iggarpe/cc1800

The CC1800 has 16KB of SRAM located at 0x0010000, and also mapped at 0x00000000 if certain bit of a special register is set. At boot time this bit is clear and ROM is mapped at 0x00000000.

The A330 can be made to boot from SD card by pressing DOWN during power up. In this mode the ROM code will load sectors 2-17 into SRAM at address 0x00100000 and execute. The code in rom.bin will then in turn execute the USB boot code, and from then on you can use the usbtool above to upload and execute your code through USB. Much more convenient that moving an SD card around.

Note however that since the USB boot code is not executed from ROM but from SRAM, the same SRAM you will be uploading to (at least until the SDRAM controller has been initialized), some restrictions apply: the USB boot code code in rom.bin is loaded at 0x00100000, and first thing it seems to do is move itself to 0x00102000, that is, to the second half of the 16KB of available SRAM. This means you can use only the first 8KB for your code AND the stack.

GA330 unbricking tool

http://www.mediafire.com/?ed998x4zj86c1a2

Mind you, I haven't been able to make it work. I managed to brick one of the two GA330 that ChinaChip kindly provided, but haven't been able to restore the firmware. Not that I care much anyway since I don't really need the native firmware running for porting the linux kernel.

Note that the USB boot mode is not used in any of the CC1800 based machines that I know of, due to a ROM problem, so actually you will be using SD card boot to run a fixed USB boot code.

To prepare the boot SD card in windows use the ChinaChipSDBurnTools.exe utility. First argument is the drive letter, second argument is rom.bin file. Example:

ChinaChipSDBurnTools.exe I: rom.bin

This will just write the rom.bin file to sectors 2-17 in the SD card, so it will probably destroy the contents of the card. From linux you can use the dd command. Assuming the SD card drive is /dev/sdi, then:

dd if=rom.bin of=/dev/sdi bs=512 seek=2

You can actually make a boot SD card which is also usable for storage: just make it so that the first (and possibly only) partition starts somewhere beyond sector 17. How to do that is beyond the scope of this post.

Insert the card and plug the USB cable while you press DOWN. The GA330 should be now in USB boot mode.

From there on you need to use the Burning_tool(CC1800 V1.14)_W35.exe tool. The first big button will install the USB driver (at least it will copy the files in C:\Windows\System32\ChinaChipUSB, you might need to point windows to that directory when new hardware is found). The second big button starts the burn process, which you can only do after selecting the IPL, DL and HXF firmware files.

If you succeed unbricking your GA330 with this tool, please report in the comments.

EDIT: if you happen do have your serial console connected, please log and send me the output during the unbricking (57600 8N1, the code in the SD card that implements the USB boot mode will output a few lines 115200 8N1, so you'll see some garbage).

Saturday, February 19, 2011

GA330 native firmware SDK

This might very well be old news, but just in case.

You can find the native firmware SDK for the A330 here:

http://code.google.com/p/mp4sdk/downloads/detail?name=A330-SDK-Setup-20101106.exe&can=2&q=

It's an "unofficial" release.

Tuesday, February 15, 2011

Booting the GA330

Just a few tech comments I left out in the previous post due to lack of time... but after a quick clarification about ChinaChip:

They have a lot of open fronts in a very competitive market and a limited set of resources, I assume that if the project has been put on hold is because they had no choice. Note however that they're still providing information and support, but with some limitations.

As I said, I have schematics, docs (which suck but are just what they have) and BSP code. I'm now working on the tools to boot code on the GA330 through the USB port, and as soon as I get it working and a kernel booting with a serial console, I'll publish it all (but I still believe it will be of little use to other developers without the docs and BSP). I don't like to be the bottleneck, but that's how things are now.

Now for the tech details:

The CC1800, like the JZ4732 and other SoCs alike, has several boot modes implemented in the internal ROM. The code checks the state a of a few pins and then proceeds to boot from NAND, NOR, SD or USB. Actually, USB boot means the ROM code sets up the USB port in device mode and waits for instructions. You can get CPU info, upload code to SRAM, and execute it, that's pretty much all.

Note that I wrote SRAM, not SDRAM. That's why you usually need a two stage process to boot code via USB: upload and execute a tiny piece of code to SRAM which configures and initializes the SDRAM controller (and some other peripherals) so that memory is accessible, and then upload and execute the large piece of code, the kernel, to SDRAM.

Surprisingly, in the two CC1800 based machines I have, the GA330 and an HD8900, the bootsel[2] pin is tied to 3.3V. This means you can't enter USB boot mode. The bootsel[1] pin is connected to the down input of the d-pad, which means that switching the GA330 on while keeping down pressed you enter SD boot mode. In this mode the CC1800 loads the content of sectors 2-17 (a total of 16 sectors, 8KB) from the SD card to SRAM and executes it.

It turns out that due to some errors in the CC1800 design (not sure if it's the silicon or the ROM code) the USB0 port being used wasn't stable. Since the ROM code can't be changed, the hardware designers were forced to use some other alternate boot mode, and went with SD. Now, if you put in the SD a modified version of the USB boot code in ROM which uses USB1 instead of USB0, you're back on track and can complete the flash burn process through the USB1 port.

(note that in SoC of this complexity it is very usual to have tens or even hundreds of errors which are generally described by the manufacturer together with workarounds in the corresponding errata sheets, see the LM3S9B96 from Texas Instruments for instance)

Needing to have an SD card inserted to enter USB boot mode is a small inconvenience for the manufacturer, but can be a blessing for final users, because:

  1. It makes a dual boot unnecessary. You will be able to boot dingux from the SD card without any modifications to the GA330.
  2. Even if a dual boot is necessary, the install method would require only an SD card (no more USB driver madness).

For us developers it's an insignificant inconvenience. We need USB boot because it makes compiling and testing code very easy, and we just happen to need an SD card inserted all the time. Note that the partition table in sector 0 of the SD card is not affected, so you can set the first partition to start anywhere beyond sector 17 and have an usable data partition while still keeping the boot code in sectors 2-17.

Saturday, February 12, 2011

Update on dingux for the GA330

It's been way too long since the last entry. First I delayed it a bit just to have something actually substantial to write, and then then stretched it a bit longer, and well, here we are.

After coming back from China I had a list of tasks I had agreed with the ChinaChip management and engineers to get dingux up and running on the A330 in the near term. There was also the possibility of they sponsoring the development. To make a long story short, I was willing to anything between working on my spare time for free and being hired full time, and I was expecting something in between: I'm way too expensive for full time dedication (plus it's probably too soon for that) and while I'd be happy to work in my spare time, that would of course come with no commitment to any schedule or even to completion.

Since then, there's been some kind of priority rearrangement in ChinaChip and the "dingux on the A330" project as been put on hold. That means that the engineers that would do their part (mostly adapting their firmware to allow comfortable dingux installation in the internal flash) aren't available at the moment to work on it. And delivery of the required information to get a kernel port to the CC1800 running has been... well... slow. I got the most important part a couple of weeks ago. And no sponsoring. So I'll do my best but again, don't hold your breath, since as of now my job and my family allow only for a very limited amount of spare time.

The partial CC1800 programmer's manual I've got is 38 pages long. And consists of a couple of paragraphs describing each peripheral and tables of registers. Only the names of the registers and the bit fields. All in Chinese. The Texas Instruments OMAP3503 programmer's manual is +3000 pages. Go figure.

Not that I'm really complaining, since I truly believe that's what they have from the people that actually designed the CC1800. The cheese is in the BSP, which is code, which means if something is not properly done or downright broken you can't fix it, since you don't have a reference programmer's manual.

I wanted to end this post with some tech details about the A330 boot process and memory map, but I have to leave now, so it'll go in the next post.