Rockbox Development > New Ports

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

<< < (290/386) > >>

saratoga:

--- Quote from: funman on February 25, 2010, 01:34:06 PM ---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)

--- End quote ---

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: ---    /* 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,


--- End code ---

mc2739:

--- Quote from: funman on February 26, 2010, 07:47:31 AM ---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
--- End quote ---

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: ---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 $@)

--- End code ---

[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: ---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 */

--- End code ---
[/edit]

funman:

--- Quote from: ranma on March 01, 2010, 12:58:04 AM ---Below prevents that but is rather hacky, it would be better to generate dependencies for the .c-files and include those in the makefile...

--- End quote ---

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


--- Quote from: ranma on March 01, 2010, 12:58:04 AM ---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. :)

--- End quote ---

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.


--- Quote from: ranma on March 01, 2010, 12:58:04 AM ---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.

--- End quote ---

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

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version