Rockbox

Tasklist

FS#10047 - Clipv2 support

Attached to Project: Rockbox
Opened by Rafaël Carré (funman) - Monday, 23 March 2009, 14:25 GMT
Last edited by Rafaël Carré (funman) - Thursday, 31 December 2009, 19:15 GMT
Task Type Patches
Category Bootloader
Status Closed
Assigned To No-one
Operating System Another
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Add Clipv2 support in mkamsboot & bootloader

Drivers are now separated from Sansa Clip (v1) for easier modifications but should (hopefully) be concatenated as it appears only the physical connections (GPIO) change, and some registers values.

Test on Clipv2 1GB
This task depends upon

Closed by  Rafaël Carré (funman)
Thursday, 31 December 2009, 19:15 GMT
Reason for closing:  Accepted
Additional comments about closing:  r24131
Comment by Thomas Martitz (kugel.) - Monday, 23 March 2009, 18:20 GMT
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 ;)
Comment by Rafaël Carré (funman) - Wednesday, 25 March 2009, 10:52 GMT
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 !
Comment by Rafaël Carré (funman) - Thursday, 26 March 2009, 13:07 GMT
now with lcd !
Comment by Rafaël Carré (funman) - Thursday, 16 April 2009, 16:33 GMT
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.
Comment by Rafaël Carré (funman) - Friday, 22 May 2009, 11:04 GMT
(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)
Comment by Rafaël Carré (funman) - Wednesday, 27 May 2009, 12:29 GMT
synced
Comment by Rafaël Carré (funman) - Thursday, 28 May 2009, 16:23 GMT
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.
Comment by Rafaël Carré (funman) - Saturday, 06 June 2009, 13:43 GMT Comment by Rafaël Carré (funman) - Thursday, 16 July 2009, 01:14 GMT
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 ..
Comment by Rafaël Carré (funman) - Thursday, 23 July 2009, 14:20 GMT
synced diff.

now in contact again with AMS marketing product manager for the datasheet (he answered!)
Comment by Rafaël Carré (funman) - Tuesday, 22 September 2009, 19:24 GMT
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
Comment by Torne Wuff (torne) - Monday, 12 October 2009, 11:22 GMT
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...
Comment by Rafaël Carré (funman) - Tuesday, 13 October 2009, 08:59 GMT
synced.

CCU_VERS on Clipv1 : 0x1000 (1.0)
CCU_VERS on Clipv2: 0x2323 (2.803)

In the as3525v13 datasheet, the value read should be 0x2001 (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.
Comment by Torne Wuff (torne) - Tuesday, 13 October 2009, 09:43 GMT
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?
Comment by Bertrik Sikken (bertrik) - Tuesday, 13 October 2009, 10:17 GMT
0x23 = 35 decimal, so 2323 hex could be interpreted as 3535 decimal too, perhaps this indicates an as3535 chip?
Comment by Rafaël Carré (funman) - Tuesday, 13 October 2009, 10:46 GMT
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 ^^
Comment by Torne Wuff (torne) - Tuesday, 13 October 2009, 10:51 GMT
You could possibly ask your contact if they know which SoC has a CCU_VERS of 0x2323 :)
Comment by Thomas Martitz (kugel.) - Tuesday, 13 October 2009, 11:20 GMT
Before asking for more sheets we should follow Torne's suggestion.
Comment by Rafaël Carré (funman) - Wednesday, 14 October 2009, 12:15 GMT
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 0x2323 and it means 0x2 second full mask version with 0x3 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)
Comment by Rafaël Carré (funman) - Thursday, 31 December 2009, 19:12 GMT
synced last patch

Loading...