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.
http://www.dingux.com/2011/02/bootin....html#comments

Since you asked so nicely I'm going to post some bits and pieces about M1. But first some necessary background.

There are several approaches to figuring out encryption / compression schemes, all involve deep analysis of the data before and after the decoding step.

Unless the system is very simple you won't get far by just looking at the (usually very few) patterns available. In fact it's pretty easy to come up with some hypothesises that will turn out to be false later and will derail the whole research, taking up days to weeks to disprove. This is what accounts for most of the time, and all the failures tend to be quite discouraging. This is the pure analytical approach. Andreas Naive does statistical analysis, it's easier in the sense that it gives you some hints and directions of what to try. However, to even attempt that you need to have the knowledge, tools and experience - things that I lack You also need to have plenty of test data if the results are to have any meaning.

We got a bit lucky with M2/M3 protection. I still have no idea how Andreas managed to identify the encryption so fast and reverse it (though if I was to hazard a guess then I suppose the work he did on Atomiswave carts helped a bit - it's not the same system but bears resemblance). I explained what I know about NAOMI to him and then we had some brainstorming (which was mostly him shooting down my silly suggestions), and eventually came up with some ideas on how to generate the test patterns he needed. I modified my dumper tools to output the data.

I should explain that M3 turned out to be just a variant of M2 that uses cart's own RAM buffer. This is also the major weakness of this system that we exploited. See, it's easy to say "generate test data", but how exactly do you present your own patterns to the decoder if all it can do is access read-only memory? Well, one way would be to inject the pattern into EPROM chip that serves as game program carrier. It's possible but you're limited by available space (up to some 4MBs), while erasing and reprogramming takes a lot of time. Not to mention EPROMs have rather limited number of erase cycles they can go through (about 100) before errors start to show up. Obviously you'll also need all the necessary equipment to do the job in the first place
Another problem was that M2/M3 is actually position-dependant. In other words, the same value at address A and A+n will decode to different result. Data is decrypted in 16-bit words, so to fully test just one address location I'd have to reprogram the EPROM over 65 thousand times. Not really my idea of fun.

But, as I said, there is a RAM buffer on the cart. We figured it will help us crack M3 and then we'll worry about M2. Having the ability to actually upload data to the cart and read back the result reduced the hardware testing times to mere minutes. Obviously Andreas needed very specific patterns but that was just a few changes in the program code on my side. This also allowed the tests to be run on pretty much every cart out there (not just those in my possesion) without resorting to any hardware modifications. It's thanks to this feature that we were able to crack the encryption keys on most games so quickly.

This was M2/M3. M1 is completly different system. The complexity of the encryption is nowhere near that of M2/M3 so it's much weaker from cryptographic point of view - but it took much more work and many more months of head scratching to figure it out. Kinda funny, now that I think about it, that I identified and named the methods used on NAOMI carts as M1 through M3, and it was M3 to go down first and M1 last. Well, we have M4 now too

Anyway, M1 didn't work the same way M2/M3 did. I had only one cart, with only one encrypted sequence on it, so not exactly a lot of data to work on. Trying to "decrypt" other ROM areas only produced confusing results. What's worse, trying to decrypt data from the EPROM area gave completly different and incoherent results. The only way to inject custom patterns into decoder was to spoof a ROM chip.
Soon it became obvious why EPROM approach doesn't work - on this cart type ROMs are paired and read two at once, to produce 2*16 = 32 bits of data for each address location. EPROM output is only 16 bits wide - and while cart compensates for that during normal data transfers, decryption engine just treats the other 16 bits as pulled up. Thus completly changing any patterns we'd want to test. I had to create a device that would make up for the lack of any writable memory on the cart. That's where Altera Cyclone II FPGA comes in again

Just to sum this up, I needed 32 bits for data, tristatable and preferably bidirectional for logic analyzer. Add at least 16 bits of address to that, and some additional control signals (chip selects mostly). Tons of soldering. To add insult to injury the ROMs are 5V and FPGA inputs can handle 3V3 tops (some people abuse the protection

- txt and fb2 file format support (and rudimentary epub support)
- UTF-8 text encoding
- horizontal and vertical layouts
- TTF fonts
- read from either both screens or just one. Backlight of inactive screen will be turned off to save battery life

Version 0.056
fixed line breaking when there are no spaces
kind of profile support: differently named copies of iku.nds will use separate setting files [if loader passes argv]

Version 0.055
solved "out of memory" error for many epubs
indication of font, size and screen configuration in settings

Version 0.051
added progress bar