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

[jberkenbilt]

A developer contacted me by private message, and we have arranged transfer of the device.  I'll be putting in the mail tomorrow so it can start it's journey across the Atlantic ocean, hopefully arriving before the Fuze v3 comes out. :-)  Thanks!

[sko]

I've got rockbox (version: r21520M-090714 ) on my sansae200v2 :

-Bootloader works pretty fine.
-Even if the backlight from the WheelLight is disabled, when my sansa is "computing", it's lighting.
-There is no possibility of seeking an mp3 file.
-The database building is crashing.
-Except the "database crash", I don't have many crashes.

I can't reproduce your problems, you should try again with a new build since 21520 is rather old (as currently 21877 is the latest revision).

[mc2739]

I've got rockbox (version: r21520M-090714 ) on my sansae200v2

It is not appropriate to post about bugs on modified builds. Please build from a clean and updated svn checkout and then verify that you are still having problems with that build.

[FlynDice]

@mc2739:

      Would you post the cpu boosting voltage scaling fix you and kugel came up with a few days ago in irc on FS so we could get some more people to try it out?  It worked very well for me with CVVD at 1.05 volts and I would expect it to work very well at the 1.10 setting for everyone.

I would rather find a way to make the uSD card work without boosting but that's proving to be a bit difficult right now...

[kugel.]

It was basically just boosting in sd_enable().

[mc2739]

@FlynDice

Here is a link to the patch:  http://pastie.org/542480

[kugel.]

This is the *developement* thread, not the *bug report* thread. Please move bug reports to the official test builds thread.

[Hillshum]

I assume I can post bugs with the Clip here, seeing as there is no test thread?

On my Clip, the moment I turn on crossfade, playback crashes. Disabling crossfade gets playback working again (I think a reboot is needed).

[funman]

debug -> buffering thread shows the audiobuffer is -244144 bytes (minus 238kB)

[FlynDice]

I've been busy studying up on SD cards lately and thought I would pose some questions and observations here as this area seems to have quieted down.

In looking at the code it appears that we assume the internal card is simply another sd card that is embedded in the device.  I am speculating that perhaps this is not the case or they are different enough that they need to be treated slightly differently.

It appears we can access the embedded card using the NAND_BASE address and the pl180 offsets  so it is at least compatible in this way.  It seems to need a higher clock frequency to operate though.  Funman mentioned the OF targets 65 MHz for the embedded and 20 MHz for the uSD.

Saratoga tested the frequency for the SD card and found it running at PCLK speed (62MHz) which is too fast for the specand leads me to believe that PCLK = MCLK for the uSD card.  We need <=25MHz for standard speed and <= 50MHz for HS.  We have to divide MCLK to get the card clock speed MCICLK  so our choices here are actually PCLK/2 =31MHz for HS and PCLK/4 = 15.5 MHz for standard speed.  Saratoga said the OF uses 16 MHz for standard speed which is the OF PCLK(64MHz) / 4.

The other thing I've been thinking of here is that our embedded card is at least a consistent, fixed object, even if we don't completely know all of it's characteristics, and in fact it seems be less problematic than the uSD card.  On the other hand the uSD card can vary in size, speed, and specification and should require a bit more probing for card related info.

Also, I'm assuming we have 2 pl180's working here at the 2 base addresses or am I mistaken?

[funman]

I've been busy studying up on SD cards lately and thought I would pose some questions and observations here as this area seems to have quieted down.

In looking at the code it appears that we assume the internal card is simply another sd card that is embedded in the device.  I am speculating that perhaps this is not the case or they are different enough that they need to be treated slightly differently.

It appears we can access the embedded card using the NAND_BASE address and the pl180 offsets  so it is at least compatible in this way. 

Yes the internal storage is just a SD card, controlled by the 2nd pl180 controller (with NAND_BASE base address)

It seems to need a higher clock frequency to operate though.  Funman mentioned the OF targets 65 MHz for the embedded and 20 MHz for the uSD.

I only saw this info in a table used in clocking code, I can't tell for sure how that works (perhaps the MCI_CLOCK divider is different)

Saratoga tested the frequency for the SD card and found it running at PCLK speed (62MHz) which is too fast for the specand leads me to believe that PCLK = MCLK for the uSD card.  We need <=25MHz for standard speed and <= 50MHz for HS.  We have to divide MCLK to get the card clock speed MCICLK  so our choices here are actually PCLK/2 =31MHz for HS and PCLK/4 = 15.5 MHz for standard speed.  Saratoga said the OF uses 16 MHz for standard speed which is the OF PCLK(64MHz) / 4.

By the way the OF PCLK seems to be dynamic, but I still don't understand when/how pclk changes.

The other thing I've been thinking of here is that our embedded card is at least a consistent, fixed object, even if we don't completely know all of it's characteristics, and in fact it seems be less problematic than the uSD card.  On the other hand the uSD card can vary in size, speed, and specification and should require a bit more probing for card related info.

I tried in my tests to modify MCI_CLOCK and it always failed, but I didn't try to modify it only for µSD cards.

I should receive a problematic card by the post, I'll look again at the code when I'm able to reproduce problems with SD card.

Also, I'm assuming we have 2 pl180's working here at the 2 base addresses or am I mistaken?

You are right and not mistaken.

[FlynDice]

I have used these 2 patches to test the SD behavior.

This patch leaves the internal SD alone and lowers the uSD frequency to 15.5 MHz.  I can navigate the files on the uSD but the files will not play.  I tried modifying the delays to get the files to play but have been unsuccessful so far.
http://pastie.org/561237

I believe this patch only enables the ide ahb interface & clock (CGU_IDE bits 6:7) for the internal card and not the uSD.  Rockbox runs just fine with the ide stuff disabled for the uSD.  If I disable it for the internal card though I get an SD transfer error....     
http://pastie.org/561241

[funman]

This patch leaves the internal SD alone and lowers the uSD frequency to 15.5 MHz.  I can navigate the files on the uSD but the files will not play.  I tried modifying the delays to get the files to play but have been unsuccessful so far.
http://pastie.org/561237

Did you try with a 48MHz PCLK? So the µSD freq would be 24MHz (closer to 25)

I believe this patch only enables the ide ahb interface & clock (CGU_IDE bits 6:7) for the internal card and not the uSD.  Rockbox runs just fine with the ide stuff disabled for the uSD.  If I disable it for the internal card though I get an SD transfer error....     
http://pastie.org/561241

Hopefully this can save a bit of battery, but I think this should be discussed with the people designing the storage layer (gevaerts) because every target needs to be changed.

Note that we could make the code specific to as3525 by moving it from sd_enable()

[FlynDice]

Hopefully this can save a bit of battery, but I think this should be discussed with the people designing the storage layer (gevaerts) because every target needs to be changed.

I wasn't trying to save power with this but simply to investigate how this thing is put together...

The uSD works fine without clk_ide but the internal fails.
Do you suppose clk_ide could be wired into the internal pl180's MCLK?

I do not doubt your statement that the internal card is indeed just an SD card.  My thought is that unlike a uSD card that needs to respect a specification so it can be used with any number of other devices that also use that spec, our "internal sd" is hardwired into the device so the designer would have more control over how it is operated.

I don't know if any of this really matters all that much, I'm just trying to understand what's going on here.

[funman]

Do you suppose clk_ide could be wired into the internal pl180's MCLK?

No idea .. we know it's used somehow, but not in which way