Rockbox

Try this patch. It enables the high-speed mode only for v2 cards, like the clipv1 driver does.

Thank you very much

But i think i am too silly to patch the souce file. I have no experience in programming and i have tried it for 2 hours now and i stuck.


....is there some easier way to test your patch then

http://www.rockbox.org/wiki/CygwinDevelopment

and this?

http://www.rockbox.org/wiki/SimpleGuideToCompiling


at: "In that folder type ../tools/configure which will bring up a list of all possible devices "

There is noch such folder....and what means "../"....under "help" there ist so such command.

sorry i am very confused. Maybe i will try it a second time tomorrow. I hope there will be a person with more experience who can test this faster than me.

I have a Clip+ with a SanDisk 16GB microSDHC card (class 4) showing exactly the same issue;

On booting Rockbox (tested stable release, and current daily build as of 2010-12-12) the contents of the SD card is not shown in the file browser. "Rockbox Info" shows "HD1 Not Present". The "View Disk Info" Debug screen does correctly identify both SD cards (internal 8GB and 16GB microSD card). The Original Firmware sees the card and uses it quite happily. I've tried with the card partitioned and the partition formatted with FAT32, and with FAT32 written directly onto the card (no partitions, using mkfs.vfat -F 32 -I)

I decided to try building my own firmware this afternoon. I tried applying the "sd_highspeed.patch" provided by Bertrik. Interestingly this patch appeared to be in the svn code already so perhaps it has recently been applied to the mainline code. I also applied the second of the USB patches (as3525v2-usb.diff) from  FS#11664 . I mention this because I discovered something odd: If I plug the Clip+ into my Linux box it detects two block devices (both internal and microSD storage devices) and I can mount them both. In fact I have copied ~3.5GB from the microSD card to the internal memory in this way, apparently without issues. When I unplug the USB cord, the Rockbox firmware suddenly believes that the microSD card exists and a "<microSD1>" entry appears in the file browser. I can then play music from the microSD card, etc. If I power off and power back on, the player fails to see the SD card once again.

OK, it's some sort of timing issue initialising the SD card. I've added a few delays in firmware/target/arm/as3525/sd-as3525v2.c:sd_init_card() and the card is now reliably detected on boot.

Unfortunately I was somewhat liberal with my delays! I'll try to narrow down the minimum set of changes to make it work properly.

OK. The attached patch fixes the problem for me (ie, with my player and this particular SD card). A shorter delay also works but an extra millisecond every time the card is initialised is hardly going to hurt.

Nice build system you guys have, btw. Makes the compile/test cycle very quick.

@William R Sowerbutts

Thank you very much.

I have tried your patch and it worked.

In Rockbox Info it shows "HD1 14.8GB" GB now and in "Files" i can see "microSD1".

In addition i can play a song from the disk.

If i should do some other tests, let me know. I will help if i can.

Thanks!

Jolly good. No idea how we go about getting this merged into svn -- anyone?

@William R Sowerbutts

Thank you very much.

I have tried your patch and it worked.

In Rockbox Info it shows "HD1 14.8GB" GB now and in "Files" i can see "microSD1".

In addition i can play a song from the disk.

If i should do some other tests, let me know. I will help if i can.

Thanks!

Hi Will, thanks for figuring out what makes the cards work again!

Indeed the first patch has already been applied. I've been merging some fixes/cleanups from another sd-card driver (for the sansa clip v1, fuze v1) to the sd-card driver for the clip+/fuzev2, this weekend.
Part of this cleanup is actually replacing some delays with more proper code. I think that for some commands, we don't actually need the delay, as long as we just properly wait for the card's reply (which we're currently not doing consistently).
I'd like to finish that merge/cleanup and (together with your extra delay) have it tested by someone who is affected by this problem (you perhaps).

Happy do to so. Let me know when you have a patch and/or updated code in SVN. I'll build a new version and test on my Clip+.

Cheers

Will

I think I'll commit your fix soon, so people affected by this can have a functional sd-card.

The sd card code for AMSv2 players already has various (in my eyes arbitrary) delays and adding yet another one seems a bit 'wrong'.
I looked a bit into it this weekend and I think the following is happening: we don't always properly wait for the response of the card after sending a command. Many commands are responded with a simple 48-bit 'R1' response that we can easily wait for. However some commands trigger an 'R1b' response, which means that the cards sends an 48 bit response but also keeps asserts a 'busy' signal. I guess we don't properly wait for this busy signal to be de-asserted, so we send the next command already before we are actually allowed to do so. I'd like to figure out if we can tell the sd card controller to wait for this busy-signal. Unfortunately I don't have a datasheet of this controller, I'll try to find out if/where we can find one. The end result of this investigation would be that the sd driver becomes more robust and is not using those arbitrary delays any more. This is a bit out-of-scope for this task though.