SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2

[ranma]

CGU_PERI &= ~0x7f should be alright for i2c, I am not too sure about DBOP since now we run it at 62MHz. Perhaps we'll need to modify the timing registers.

Bootup status on CGU_PERI is already 0x0f810000 (after the 'enable GPIO clock code'),
so &= ~0x7f should be unecessary, but can't hurt.
I added 'infinite loop if right pressed' to my bootloader to verify this:

Code: [Select]

> halt
target state: halted
target halted in ARM state due to debug-request, current mode: Supervisor
cpsr: 0x60000053 pc: 0x00000084
MMU: disabled, D-Cache: disabled, I-Cache: disabled
> arm disassemble 0x70 6 
0x00000070      0xe59f0164      LDR r0, [r15, #0x164]
0x00000074      0xe3a01000      MOV r1, #0x0
0x00000078      0xe5801400      STR r1, [r0, #0x400]
0x0000007c      0xe5901100      LDR r1, [r0, #0x100]
0x00000080      0xe3510000      CMP r1, #0x0
0x00000084      0x0afffffe      BEQ 0x00000084
> reg r0
r0 (/32): 0xC80D0000
> mdw phys 0xC80F0000 0x20
0xc80f0000: 00002630 00006a2f 00000000 00000008 00000051 0f810000 0000010d 00000011
0xc80f0020: 00000001 00000001 00000020 00000020 000000cd 00000191 00000000 00000000
0xc80f0040: 00002630 00006a2f 00000000 00000008 00000051 0f810000 0000010d 00000011
0xc80f0060: 00000001 00000000 00000020 00000020 000000cd 00000191 00000000 00000000

[funman]

Can you post a patch (without DBOP modifications since it's unrelated) on flyspray so we can test on each model before committing ?

[ranma]

Can you post a patch (without DBOP modifications since it's unrelated) on flyspray so we can test on each model before committing ?

Here you go:
http://www.rockbox.org/tracker/task/11085
http://www.rockbox.org/tracker/task/11085?getfile=21542
Tested on my C240v2.

[funman]

thanks! i committed it for c200v2 only, I'll try on my devices so we can remove the USB pin and use this code on all devices.

[mc2739]

thanks! i committed it for c200v2 only, I'll try on my devices so we can remove the USB pin and use this code on all devices.

Tested on e200v2 - no problems noted

[FlynDice]

Just a little update on progress (or lack thereof) for for me with the clip+.

I have found that I only need to disable the Dcache.  The player boots up fine with just the Icache and mmu enabled.  I have not played around with the memory mapping and cacheable areas yet but will get there eventually.  The problem with the dcache enabled has been getting the SD card past the ident state while initializing.  For some reason the card is sending back an rca of 0x0000XXXX.  I can get it past there to the STBY   state by issuing a second SD_SEND_RELATIVE_ADDR command, but then I cannot get it to TRAN state with a SD_SELECT_CARD cmd.

While investigating the Dcache I found that the 926ejs has a test & clean cache coherency function that may come in useful later.  It seems it knows if the cache is dirty and will loop until clean.

I have found a spot(0x6464) in the of's send_cmd function that sets or unsets B5 depending on the disk but I haven't been able to see a difference when I've used it.

As far as clocks go, the plla/b registers are different but it seems most all of the rest of the clock registers still use bits 1:0 as clock select and most are set to 1 for plla.  CGU_INTCTRL (offset 0x20) seems it may be different from as3525v1 as it is also has 1 stored to it but that is a read only bit for CGU_INTCTRL in the as3525v1.  I think  the CGU_PROC register is the same as v1  and the dividers work just like the v1.

[funman]

Perhaps B5 is to select internal/µSD ?

I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.

The code is a bit after a read of GPIOA A2 which is tells if an µSD card is present.

About CGU_PROC here is what I found:

• I commented out the code touching it in system_init() because it would prevent boot
• I've found a function which only touches bits 7:4 / or bits 3:0, so the register looks very much like AS3525v1 : divider on 7:4, pre-divider on 3:2, and clk_sel on 1:0 (at 0x236C in Clip+)

C code of that function (I simplified the setting of CGU_* by setting only the divider bits, other bits are not modified):

Code: [Select]

static inline void delay(void) { int i = 40; while(i--) ; }

void mod_cgu (void)
{
    max_div_peri = ((peri_setting >> 2) & 0xf) + 1;
    min_div_proc = ((proc_setting >> 4) & 0xf) + 1;

    div_proc = min_div_proc * max_div_peri;
    if(div_proc > 0xf)
        div_proc = 0xf;

    if(min_div_proc > 0xf)
        min_div_proc = 0xf;

    CGU_PROC = (proc_setting & 0xf) | ((div_proc - 1) << 4);
    delay();

    int div_peri = 1;
    /*
     * pclk: faster -> slower
     * fclk: slower -> faster
     */
    while(div_proc > min_div_proc && div_peri < max_div_peri)
    {
        if(div_peri < max_div_peri)
        {
            CGU_PERI_DIV = div_peri; /* bits 7:2 */
            delay();
            div_peri++;
        }

        if(div_proc > min_div_proc)
        {
            CGU_PROC_DIV = (div_proc - 2); /* bits 7:4 */
            delay();
            div_proc--;
        }
    }
}

Perhaps tuning some delays might make the Clip+ boot with modified (= faster ?) CGU_PROC

BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.
Though it's OK to store it on 32 bits, because all (?) commands needing RCA as an argument only need "stuff bits" as 31:16

[FlynDice]

Perhaps B5 is to select internal/µSD ?

Yes this is what I think also.

I don't remember seeing a different base address like (there are 2 PL180 controllers in the AS3525v1), and MCI_HCON only reports 1 card present.

I think the MCI_HCON value is reporting 2 cards.  Look at the HCON_NUM_CARDS macro in the linux patch.

BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.

But the RCA is the 16 MSB and if it sends  0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd.  Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.

[funman]

BTW 0x0000XXXX is correct for RCA, it is a 16 bits register.

But the RCA is the 16 MSB and if it sends  0x0000XXXX then it's using an RCA of 0x0000 which is not going to work for the SD_SELECT_CARD cmd.  Using an RCA of 0 for the SD_SELECT_CARD cmd actually deselects the card.

Oops right.

I just tried a build with only dcache disabled, and I'm printing the RCA.

It alternates between 0x0 and 0xD555 .. weird. Perhaps we need to loop until we receive a correct RCA ?

EDIT: I tried to print the CID, and there is only one 32 bits word set: 0xC0FF8000 which is the response to the previous command.

So it looks like the responses are late / or stay in the register for too long / or we read them too quickly (much likely)

EDIT2: Fixed (in svn) : I added a (probably much too long) delay before reading response and my Clip+ boots fine with both caches ON.

The delay can certainly be lowered, right now boot time is quite much longer than before (although should not be more than 4 seconds: 2 in bootloader, 2 in rockbox.sansa).

Now internal storage works (please report bugs), let's focus on sound and µSD !

It'd be nice to know if this code also works on Clipv2

[FlynDice]

@funman:

SD seems to work great now with both caches enabled.

I have been struggling with the CGU_PERI clock select register for awhile.  For some reason b 1:0 are being cleared and I cannot find where this is happening in our code.  I tried to put a panic right after it gets set in system-as3525.c to be sure it was being set correctly but I get a dark screen that won't recover.  I'm wondering if this is some sort of fallback that the chip does on it's own if the settings are screwed up a bit, ie going to a safe 24 MHz frequency with clk_main?

The radio seems to work.  I can scan channels and it seems to find the right presets and the mode will change from stereo to mono if i unplug the headphones.

I will post a patch with some cache coherence functions that take advantage of the test & clean function that the 926ejs has available.  They are supposedly more efficient than the regular arm cache coherence functions and I did find some versions in the OF.  They are much simpler, you don't need to supply a range, it can tell if the cache is dirty and just cleans it until there are no more dirty lines.  See p2-23 of the ARM926EJ-S TRM.

I'll look at adding the LP bits to MCI_PWREN, adding HS, and 4bit bus and see how things work.

In the linux patch there is some info on the AS3543 vs the AS3514, It looks quite similar but I have not really studied it yet.  Maybe a clue or 2 for sound?

[funman]

I had some problems with SD yesterday: I played around with the plugins and some would randomly crash, sometimes with undefined instructions.

I suppose we don't properly check if a transfer was successful or not, when writing works it will be easier to use test_disk plugin.

For the sound I had tried the definitions of i2c registers in as3531 datasheet without luck, there was not much difference with as3514 (the mute bit for headphones is shifted by one).

About CGU_PERI, I have no idea right now : perhaps the bits give some status ? Something like "clock is now stable".. I suppose we'll find the explanation in the OF

EDIT: it seems bits 1:0 are never set, perhaps it assumes PLLA as source ?

We could check by either using only PLLB, or measuring the speed of some peripheral ?

EDIT2: the LCD doesn't use DBOP so we need to find another peripheral

[FlynDice]

re: PCLK source

This gets set in line 301 0f system-as3525.c as  AS3525_PCLK_SEL.  Instead of using the macro I tried setting this to both 1 for PLLA and 3 for FCLK and when the player booted up in the debug page it showed b1:0 of CGU_PERI as both being 0.

[ranma]

funman:
I had a look at recording. It seems to fault and the fault handler itself is faulting in memset16, called from lcd_clear_viewport.  The memset16 disassembly looks like every 4th word was overwritten with zeroes:

This is what it's supposed to look like

Code: [Select]

30200f08 <memset16>:
30200f08:	e3100002 	tst	r0, #2	; 0x2
30200f0c:	13520000 	cmpne	r2, #0	; 0x0
30200f10:	10c010b2 	strneh	r1, [r0], #2
30200f14:	12422001 	subne	r2, r2, #1	; 0x1
30200f18:	e1811801 	orr	r1, r1, r1, lsl #16
30200f1c:	e1a03001 	mov	r3, r1
30200f20:	e3520008 	cmp	r2, #8	; 0x8
30200f24:	ba00000f 	blt	30200f68 <memset16+0x60>
30200f28:	e52de004 	str	lr, [sp, -#4]!
30200f2c:	e1a0c001 	mov	ip, r1
30200f30:	e1a0e001 	mov	lr, r1
30200f34:	e2522020 	subs	r2, r2, #32	; 0x20
30200f38:	a8a0500a 	stmgeia	r0!, {r1, r3, ip, lr}
30200f3c:	a8a0500a 	stmgeia	r0!, {r1, r3, ip, lr}
30200f40:	a8a0500a 	stmgeia	r0!, {r1, r3, ip, lr}
30200f44:	a8a0500a 	stmgeia	r0!, {r1, r3, ip, lr}

And this is the actual disassembly:

Code: [Select]

> arm disassemble 0x30200f08 16
0x30200f08      0xe3100002      TST r0, #0x2
0x30200f0c      0x13520000      CMPNE r2, #0x0
0x30200f10      0x00000000      ANDEQ r0, r0, r0
0x30200f14      0x12422001      SUBNE r2, r2, #0x1
0x30200f18      0xe1811801      ORR r1, r1, r1, LSL #0x10
0x30200f1c      0xe1a03001      MOV r3, r1
0x30200f20      0x00000000      ANDEQ r0, r0, r0
0x30200f24      0xba00000f      BLT 0x30200f68
0x30200f28      0xe52de004      STR r14, [r13, #-0x4]!
0x30200f2c      0xe1a0c001      MOV r12, r1
0x30200f30      0x00000000      ANDEQ r0, r0, r0
0x30200f34      0xe2522020      SUBS r2, r2, #0x20
0x30200f38      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}
0x30200f3c      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}
0x30200f40      0x00000000      ANDEQ r0, r0, r0
0x30200f44      0xa8a0500a      STMGE r0!, {r1, r3, r12, r14}

[edit]
Getting hotter:
The triggering function seems to be enc_set_parameters()  in apps/recorder/pcm_record.c
Explains the overwrite pattern:
It initializes chunk->flags with 0, struct enc_chunk_hdr just so happens to be 4 words.
[/edit]

[pbxy]

It'd be nice to know if this code also works on Clipv2

Using r25204 the main binary finally loads successfully.
Some buttons don't work: left, down, hold, vol up.

http://www.imagebanana.com/img/j61f6av2/happyclipv2.jpg

Great work! Thank you a lot!

Edit: Yes, FM is detected!

[funman]

Nice! Is the FM detected? (you should have the FM menu entry if it was)

About the buttons perhaps modifying the button driver like the Clipv1 would help: read only 1 row at each tick, and prepare the next row to be read at the next tick. Can you look at it ?

Not sure why hold button doesn't work though.