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

[embrion]

Can you report back with the following:
1) enable the radio, go to the debug/radio menu and note the first two numbers (1st will be 1242)
2) go to the debug/hw info menu and note the CGU_PERI value

1) 1242 1053
2) CGU_PERI: 0F93018F

[FlynDice]

I cleaned up the sd-as3525v2 init_controller and sd_init_card code and I get much more reliable boots into the main code now.  Update your bootloader also.

edit:  Still need to disable i&dcache

[funman]

I see we leave ROM clock enabled unlike the OF, I'll run a battery bench to see if it changes anything to disable it

No significant difference : 5h15 runtime

[embrion]

and how long was it before change?
I'm willing to test everything unless it can brick my Fuze (yeah, I know everything can but I think lovering voltage or clocking is less probable in hurting anything )

[funman]

and how long was it before change?

No significant difference

It was not different = it was the same (5h15 or so).

You can read (and post) battery benches on SansaRuntime.

Btw i'm running a bench with radio, hard part will be to benchmark the OF (I don't want to check the Clip every 10 minutes).

I think saratoga suggested to plug the Clip to soundcard input, record it and then analyse the wav file. Would it change current consumption if something is plugged on the jack or not ?
(If it's the case I need to benchmark rockbox with the jack plugged as well)

[saratoga]

I think saratoga suggested to plug the Clip to soundcard input, record it and then analyse the wav file. Would it change current consumption if something is plugged on the jack or not ?
(If it's the case I need to benchmark rockbox with the jack plugged as well)

Typical line in impedance is very large, so its not much different then driving the air (nothing plugged in).  Will definitely use a bit less power then headphones.

[funman]

rockbox runtime with FM : 7h 40 minutes (starting at 97% battery)

EDIT: some findings on Clip+/SD

I added a sleep(HZ) after the clock is switched to 400kHz, and card powering up succeeds

Then I wondered why card stays in identification mode after it sent its RCA: so I send a SD_SEND_STATUS to the card just after switching clock to full speed and it responds:

0xD5554520 => status = 2 = identification

And here comes the weirdness:

I noticed that the disk info debug menu gave weird information (ridiculously small number of blocks), so I printed the CSD in rockbox.sansa and it gives:

• card_info.csd[3] = 0x03534453
• card_info.csd[2] = 0x44303447
• card_info.csd[1] = 0x80234829
• card_info.csd[0] = 0xD5554520

Note how the last one is identical to the status we got from the previous command (and also how it is completely different from the expected CSD for my Clip+ 4GB).

Perhaps we should check MCI_RAW_STATUS from the isr to see if a command was not sent correctly?

BTW here is the list of CSDs for Clipv2 and Clip+ that I have (they should be in correct order, with first 32 bits being bits 127:96 of the CSD):

Code: [Select]

    /* Clipv2 1GB */
    0x00260032,
    0x5F5983D3,
    0xBEFBCFFF,
    0x92404019,

    /* Clipv2 2GB */
    0x00260032,
    0x5F5A83D3,
    0xBEFBCFFF,
    0x9280401B,

    /* Clip+ 4GB */
    0x400E0032, //127:96
    0x5B590000, //95:64
    0x1D8A7F80, //63:32
    0x0A4040B9, //31:0

    /* Clip+ 8GB */
    0x400e0032,
    0x5b590000,
    0x3b377f80,
    0x0a4040af,

    /* Clip+ 2GB */
    0x00260032,
    0x5F5A83AE,
    0xFEFBCFFF,
    0x928040DF,

[mc2739]

I noticed that the disk info debug menu gave weird information (ridiculously small number of blocks), so I printed the CSD in rockbox.sansa and it gives:

• card_info.csd[3] = 0x03534453
• card_info.csd[2] = 0x44303447
• card_info.csd[1] = 0x80234829
• card_info.csd[0] = 0xD5554520

This looks to me to be the CID instead of the CSD

[3] and [2] decode as:
127:120 = Manufacturer ID = 0x03 for Sandisk
119:104 = OEM/Application ID = "SD" ASCII Code 0x53, 0x44
103:64 = Product Name = "SD04G" ASCII Code 0x53, 0x44, 0x30, 0x34, 0x47

[ranma]

Chasing mkamsboot weirdness again.
It's still possible to get a borken mkamsboot if you don't make clean after changing dualboot. :/
Below prevents that but is rather hacky, it would be better to generate dependencies for the .c-files and include those in the makefile...

Code: [Select]

Index: Makefile
===================================================================
--- Makefile    (revision 24914)
+++ Makefile    (working copy)
@@ -47,6 +47,9 @@
 LIBOBJS := $(patsubst %.c,%.o,$(addprefix $(OBJDIR),$(LIBSOURCES)))
 EXTRADEPS := $(LIBUCL)
 
+dualboot.o: dualboot.h
+mkamsboot.o: dualboot.h
+
 $(OBJDIR)%.o: %.c
        @echo CC $< $
        $(SILENT)mkdir -p $(dir $@)

[edit]
funman: Your dbop patch works for me
Below is my current version of dualboot.S
This combines your dbop patch with my 'use i2c for usb status'.
BTW the reason my usb status check was not working at first was that
I didn't clear the interrupt mask and the bootloader runs with interrupts enabled...
So when the I2C read finished it would get an interrupt, execute the nops and
data words until running into start again. Lather, rinse, repeat.

I first tested this using JTAG, then flashed it and tested it again:
Power on with USB unplugged, left button not pressed: Boots rockbox
Power on with USB plugged in, left button not pressed: Boots OF
Power on with USB unplugged, left button pressed: Boots OF
Power on with USB unplugged, right button pressed: Boots OF (old button code)
Power on with USB unplugged, down button pressed: Boots rockbox (just for cross-checking )

BTW, the audio master usb status bit also gets set if it's only power and not the data lines.
However the OF handles this situation correctly and does not go into usb storage mode.

Code: [Select]

Index: rbutil/mkamsboot/dualboot/dualboot.S
===================================================================
--- rbutil/mkamsboot/dualboot/dualboot.S	(revision 24980)
+++ rbutil/mkamsboot/dualboot/dualboot.S	(working copy)
@@ -22,24 +22,27 @@
 .text
 
 /* AS3525 hardware registers */
-.set GPIOA,     0xC80B0000
-.set GPIOB,     0xC80C0000
-.set GPIOC,     0xC80D0000
-.set GPIOD,     0xC80E0000
-.set CGU_PERI,  0xC80F0014
+.set GPIOA,          0xC80B0000
+.set GPIOB,          0xC80C0000
+.set GPIOC,          0xC80D0000
+.set GPIOD,          0xC80E0000
+.set CGU_PERI,       0xC80F0014
+.set CGU_DBOP,       0xC80F0038
+.set DBOP,           0xC8120000
+.set I2C_AUDIO_BASE, 0xC8070000
 
 
 /* Vectors */
 
         ldr   pc, =start    /* reset vector */
-        /* next vectors are unused */
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
-        .word   0
+        /* next vectors are unused, halt cpu */
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
+1:      b 1b
 
 /* These values are filled in by mkamsboot - don't move them from offset 0x20 */
 
@@ -88,12 +91,14 @@
 #endif
 
 #ifdef USB_PIN  /* TODO : remove this check when we'll have an USB driver */
+/*
         ldr     r0, =GPIOA
         mov     r1, #0
         str     r1, [r0, #0x400]
         ldr     r1, [r0, #(4*(1<<USB_PIN))]
         cmp     r1, #0
         bne     boot_of
+*/
 #endif
 
         /* Here are model specific tests, for dual boot without a computer */
@@ -170,14 +175,63 @@
         cmp     r2, #0              @ test input from pins
         bne     boot_of             @ branch directly to OF if either pin high
 #elif defined(SANSA_C200V2)
-        /* check for RIGHT on C6, should changed to LEFT as soon as it
-         * known in which pin that is in order for consistency  */
+        ldr     r0, =CGU_DBOP
+        mov     r1, #(1<<3)         @ DBOP freq = PCLK, clock enabled
+        str     r1, [r0]
+
+        @ only for LCD ?
+        ldr     r2, =GPIOB
+        mov     r1, #0xc
+        str     r1, [r2, #0x420]    @ GPIOB_AFSEL
+        ldr     r2, =GPIOC
+        mov     r1, #0xff
+        str     r1, [r2, #0x420]    @ GPIOC_AFSEL
+
+        ldr     r0, =DBOP
+        ldr     r1, =0x6e167
+        str     r1, [r0]            @ DBOP_TIMPOL_01
+        ldr     r1, =0xe007e007
+        str     r1, [r0, #4]        @ DBOP_TIMPOL_23
+
+        mov     r1, #10
+1:      nop
+        subs    r1, r1, #1
+        bne     1b
+
+        mov     r1, #(1<<12)        @ 16 bit data width
+        orr     r1, r1, #(1<<16)    @ enable write
+        orr     r1, r1, #(1<<19)    @ tri-state output
+        str     r1, [r0, #8]        @ DBOP_CTRL
+
+        ldr     r1, =0xf0ff         @ precharge
+        str     r1, [r0, #0x10]     @ DBOP_DOUT
+
+2:      ldr     r1, [r0, #0xc]      @ DOBP_STAT
+        ands    r1, r1, #(1<<10)
+        beq     2b                  @ make sure fifo is empty
+
+        mov     r1, #31
+        orr     r1, r1, #(1<<12)    @ 16 bit data width
+        orr     r1, r1, #(1<<15)    @ start read
+        orr     r1, r1, #(1<<19)    @ tri-state output
+        str     r1, [r0, #8]        @ DBOP_CTRL
+
+3:      ldr     r1, [r0, #0xc]      @ DOBP_STAT
+        ands    r1, r1, #(1<<16)
+        beq     3b                  @ wait for valid data
+
+        ldrh    r1, [r0, #0x14]     @ DBOP_DIN
+
+        ands    r1, r1, #(1<<2)     @ bit 2 unset = button left pressed
+        beq     boot_of
+
+        /* check for LEFT or RIGHT on C6 */
         ldr     r0, =GPIOC
         mov     r1, #0
-        str     r1, [r0, #0x400]      /* set pin to output */
+        str     r1, [r0, #0x400]      /* set all GPIOC to input */
 
         ldr     r1, [r0, #256]        /* 1<<(6+2) */
-        cmp     r1, #0                /* C6 low means button pressed */
+        cmp     r1, #0                /* C6 low means r-button pressed */
         beq     boot_of
 #elif defined(SANSA_M200V4)
 .set row, (1<<5) /* enable output on A5 */
@@ -197,7 +251,63 @@
         #error No target-specific key check defined!
 #endif
 
+        /* enable i2c audio master clock */
+        ldr     r0, =CGU_PERI
+        ldr     r1, [r0]
+        orr     r1, r1, #(1<<17)
+        str     r1, [r0]
 
+.set pclk, 62000000
+.set i2c_clk, 400000
+.set i2c_prescaler, ((pclk + i2c_clk -1) / i2c_clk)
+.set I2C2_DATA,  0x00
+.set I2C2_SLAD0, 0x04
+.set I2C2_CNTRL, 0x0c
+.set I2C2_DACNT, 0x10
+.set I2C2_CPSR0, 0x1c
+.set I2C2_CPSR1, 0x20
+.set I2C2_IMR,   0x24
+.set I2C2_SR,    0x30
+.set I2C2_SADDR, 0x44
+.set AS3514_I2C_ADDR, 0x46
+.set AS3514_IRQ_ENRD0, 0x25
+        ldr     r0, =I2C_AUDIO_BASE
+        /* disable i2c interrupts */
+        mov     r1, #0
+        str     r1, [r0, #I2C2_IMR]
+        /* setup prescaler */
+        ldr     r1, =i2c_prescaler
+        str     r1, [r0, #I2C2_CPSR0]
+        mov     r1, r1, lsr #8
+        str     r1, [r0, #I2C2_CPSR1]
+        /* setup i2c slave address */
+        mov     r1, #(AS3514_I2C_ADDR << 1)
+        str     r1, [r0, #I2C2_SLAD0]
+        mov     r2, #0x51
+        str     r2, [r0, #I2C2_CNTRL]
+
+        /* wait for not busy */
+i2c_busywait:
+        ldr     r1, [r0, #I2C2_SR]
+        tst     r1, #1
+        bne i2c_busywait
+
+        /* read irq_enrd0 */
+        mov     r1, #AS3514_IRQ_ENRD0
+        str     r1, [r0, #I2C2_SADDR]
+        orr     r2, r2, #(1 << 1)
+        str     r2, [r0, #I2C2_CNTRL]
+        mov     r1, #1
+        str     r1, [r0, #I2C2_DACNT]
+i2c_wait:
+        ldr     r1, [r0, #I2C2_DACNT]
+        cmp     r1, #0
+        bne     i2c_wait
+
+        ldr     r1, [r0, #I2C2_DATA]
+        tst     r1, #(1 << 3)
+        bne     boot_of
+
         /* The dualboot button was not held, so we boot rockbox */
         ldr     r0, ucl_rb_end      /* Address of compressed image */
         ldr     r1, ucl_rb_size     /* Compressed size */

[/edit]

[funman]

Below prevents that but is rather hacky, it would be better to generate dependencies for the .c-files and include those in the makefile...

I added something similar in r24915 after kugel found this problem (svn up before sending patches!), but I agree generating dependencies would be better.

funman: Your dbop patch works for me
Below is my current version of dualboot.S
This combines your dbop patch with my 'use i2c for usb status'.
BTW the reason my usb status check was not working at first was that
I didn't clear the interrupt mask and the bootloader runs with interrupts enabled...
So when the I2C read finished it would get an interrupt, execute the nops and
data words until running into start again. Lather, rinse, repeat.

I would like to know the opinion of bertrik on the addition of i2c code, this would replace the "USB_PIN" check and work on every c200v2 and on Clip+.

Just one note: you forgot to set PCLK frequency in CGU_PERI. I suggest using the 24MHz clock (clk_sel == 00b and no divider)

About the missing vectors, could we just use "bx lr" for fiq and irq? for fault handlers an infinite loop would be fine since we don't know if we can return safely.

BTW, the audio master usb status bit also gets set if it's only power and not the data lines.
However the OF handles this situation correctly and does not go into usb storage mode.

This is not a big problem for now, perhaps the OF does this check with the usb controller

[ranma]

About the missing vectors, could we just use "bx lr" for fiq and irq? for fault handlers an infinite loop would be fine since we don't know if we can return safely.

IIRC "subs pc, lr, #4" is the proper way to return from interrupt handlers.
On the other hand I don't see why any interrupt should happen at that stage.
And if the interrupt request is not cleared it might generate the next interrupt right away.

[torne]

Yes, subs pc, lr, #4 is for irq/fiq returns. bx will return to the wrong instruction and won't change mode back to svc.

[funman]

I committed the simplest change: replace the vectors by infinite loops

bertrik said he was ok with the principle of using i2c in dualboot, so I think now the only problem is we don't explicitely set PCLK in CGU_PERI.

At the moment we only enable GPIO peripheral and the PrimeCell PL061 GPIO controller doesn't seem to have any requirement on clock frequency.

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.

We also need to check what the CGU_PERI (divider and clock selection) bits are on as3525v2.

[funman]

rockbox runtime with FM : 7h 40 minutes (starting at 97% battery)

OF runtime with FM : 8h 50 minutes.

This is much closer than with audio files, so explicitely powering the FM off at startup could give nice results.

EDIT: Change committed, I get 1h30 more runtime on Clipv1 (just like Jouni Paulus reported on SansaRuntime)

[embrion]

Thanks, I'll check with mu Fuze and report back.

EDIT: ok, NO IMPROVEMENT in my case