Rockbox

Your local repo isn’t quite up-to-date, it seems, there’s no lcd_enabled anymore.

Just my opinion, I don’t think it should be committed with so much duplicated code. But I guess that’s not your plan anyway ;)

I have a checkout from March 9th .. sorry.

For now it’s just intended to help developers to write their code, not to be committed don’t worry !

now with lcd !

   clipv2.diff (53.1 KiB)

complete button code by pbxy : http://forums.rockbox.org/index.php?topic=14064.msg147461#msg147461

To read hold : You have to set A7 direction out, set pin A7, wait a little bit (I used for(i=0;i<50;i++) asm volatile(”nop”); ) , read A3; unset pin A7 and set the direction to input to read power button.

   sansa-clipv2_button-clip.c (2.4 KiB)

(uncleaned, unsynced, tic-tac-toe included :P ) initial work on reverse engineering the SD controller.

My code can get past the identification phase, but I do not know how to change the clock frequency (since ident. works I suppose it’s already set to 400kHz).

The DMA controller looks very much the exact same than in Sansa AMS (PL081), but I don’t know how to enable data transfer with the SD registers (I know the FIFO register however)

   0001-Clipv2.patch (287.2 KiB)

synced

   0001-Clipv2.patch (86.1 KiB)

tools/{scramble,configure}.c have been committed.

mkamsboot part will be committed as part of  FS#10253 

Since the SoC shares a lot with as3525, I will rename the as3525 architecture to as35xx and commit clean parts of this patch.

link to start of fuzev2 work by ecrips : http://github.com/ecrips/Rockbox-FuzeV2/commit/8a9030bbd1f895958b5c455e398cf1ab499c27b5

After contacting the person working at AMS on the Linux/U-Boot ports for AS353X (Ulrich Herrmann), it seems that the SD controller is made by Synopsys.

They aren’t ready to share code/information at the moment, let’s hope we will see linux/u-boot patches being submitted soon or perhaps get the datasheet from AMS if they start answering our mails again ..

synced diff.

now in contact again with AMS marketing product manager for the datasheet (he answered!)

   0001-Clipv2.patch (66 KiB)

we got the as3531 datasheet from AMS and the registers are definitely different from what we have in clipv2
other possibilities:
- extended as3525 to include arm926ejs and other modifs
- as3530/as3536 : unlikely since they ship with a (expensive?) H264 decoder

This might be a silly question but does the clipv2 have a version number in CCU_VERS? I realise that’s not a full identifier for the SoC but it might narrow it down some…

synced.

CCU_VERS on Clipv1 : 0×1000 (1.0)
CCU_VERS on Clipv2: 0×2323 (2.803)

In the as3525v13 datasheet, the value read should be 0×2001 (1.2), so perhaps they used an older chip revision in my Clipv1, assuming the CCU_VERS meaning didn’t change, we see a very new version of AS3525 (perhaps a not released to the other manufacturers chip?)

Also note I didn’t see references to CCU_VERS in Clipv1 OF disassembly.

   0001-Clipv2.patch (66 KiB)

Since it’s just a version number, not a chip ID, it may be related or may not be… it’s possible it’s version 2.803 of something totally different :) Not surprised the OF doesn’t refer to it, though..

What does the as3531 datasheet say the version should be?

0×23 = 35 decimal, so 2323 hex could be interpreted as 3535 decimal too, perhaps this indicates an as3535 chip?

This register doesn’t exist on as3531

The chip could well be a 3535, but we’d have to ask the 3535 datasheet to AMS.

Any taker? I don’t want to harass my contact but I see no problem if someone else does ^^

You could possibly ask your contact if they know which SoC has a CCU_VERS of 0×2323 :)

Before asking for more sheets we should follow Torne’s suggestion.

answer from AMS:
——8←—-
Version register at address 0xC8100014 of AS3525 is bit 7:4 main version (full mask set change) and and bit 3:0 minor version (single mask changes).
I think the 8 bits in the register are doubled, so you read 0×2323 and it means 0×2 second full mask version with 0×3 third metal mask revision.

For AS353x the chip version number is located at address 0x005500DC. With 16 bit data, 8 bit major (upper bits) and 8 bit minor (lower bits) version.
——8←—-

It doesn’t fit exactly with the description in the datasheet and with what we see in Clipv1, but at least it makes clear that it’s not a as353x (0x005500DC = CCUV_AD_VERSION on as3531)

synced last patch

   0001-Clipv2.patch (64.1 KiB)