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:

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.