Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Bootloader
  • Assigned To No-one
  • Operating System Another
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by Rafaël Carré - 2009-03-23
Last edited by Rafaël Carré - 2009-12-31

FS#10047 - Clipv2 support

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

Closed by  Rafaël Carré
2009-12-31 19:15
Reason for closing:  Accepted
Additional comments about closing:  

r24131

Thomas Martitz commented on 2009-03-23 18:20

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 ;)

Rafaël Carré commented on 2009-03-25 10:52

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 !

Rafaël Carré commented on 2009-03-26 13:07

now with lcd !

Rafaël Carré commented on 2009-04-16 16:33

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.

Rafaël Carré commented on 2009-05-22 11:04

(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)

Rafaël Carré commented on 2009-05-27 12:29

synced

Rafaël Carré commented on 2009-05-28 16:23

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.

Rafaël Carré commented on 2009-06-06 13:43
Rafaël Carré commented on 2009-07-16 01:14

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 ..

Rafaël Carré commented on 2009-07-23 14:20

synced diff.

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

Rafaël Carré commented on 2009-09-22 19:24

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

Torne Wuff commented on 2009-10-12 11:22

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…

Rafaël Carré commented on 2009-10-13 08:59

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.

Torne Wuff commented on 2009-10-13 09:43

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?

Bertrik Sikken commented on 2009-10-13 10:17

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

Rafaël Carré commented on 2009-10-13 10:46

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 ^^

Torne Wuff commented on 2009-10-13 10:51

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

Thomas Martitz commented on 2009-10-13 11:20

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

Rafaël Carré commented on 2009-10-14 12:15

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)

Rafaël Carré commented on 2009-12-31 19:12

synced last patch

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing