This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#10047 - Clipv2 support
Attached to Project:
Rockbox
Opened by Rafaël Carré (funman) - Monday, 23 March 2009, 15:25 GMT+2
Last edited by Rafaël Carré (funman) - Thursday, 31 December 2009, 20:15 GMT+2
Opened by Rafaël Carré (funman) - Monday, 23 March 2009, 15:25 GMT+2
Last edited by Rafaël Carré (funman) - Thursday, 31 December 2009, 20:15 GMT+2
|
DetailsAdd 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, 20:15 GMT+2
Reason for closing: Accepted
Additional comments about closing: r24131
Thursday, 31 December 2009, 20:15 GMT+2
Reason for closing: Accepted
Additional comments about closing: r24131
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 ;)
For now it's just intended to help developers to write their code, not to be committed don't worry !
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.
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)
mkamsboot part will be committed as part of
FS#10253Since the SoC shares a lot with as3525, I will rename the as3525 architecture to as35xx and commit clean parts of this patch.
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 ..
now in contact again with AMS marketing product manager for the datasheet (he answered!)
other possibilities:
- extended as3525 to include arm926ejs and other modifs
- as3530/as3536 : unlikely since they ship with a (expensive?) H264 decoder
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.
What does the as3531 datasheet say the version should be?
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 ^^
------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)