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

[kugel.]

I did tests with ADC and was not successful.

[funman]

Any progress on the SD side?

I have working read/write using DMA in my tree.

But we still can't access data past 1GB on >1GB models

--
You mention offsets in the Fuze OF, but which firmware version exactly are you disassembling ?

EDIT:
I tried the DMA code in the bootloader, the FAT32 partition is read correctly, and the beginning of rockbox.sansa as well (since I can see the correct size and checksum on screen); but the calculated checksum is always wrong .. I couldn't figure what was wrong.

I pasted my current diff (with some plugin keymaps, too lazy to sort it from the DMA/SD code ) since I couldn't figure what was wrong.

Note that when using a bootloader from SVN and this code, plugins/rockbox/lang files load just fine..

[atomikpunk]

Hi again,

daniel_at: thanks for the pics, I really clear things up in my mind. It seems to me the buttons are all linked to a single supply (GND or VCC) on one side, and all connected to independent connector pins on the other. As for the wheel, well that still to be looked upon, but I think it'll be easier to test using a custom firmware once we will have a "safety button" for the dual boot.

kugel: From what I see, it definitely isn't ADC and definitely is using DBOP (so a standard "logic" interface).

funman: I *think* it is v. 1.1.11 but I'll have a look tonight. It definitely is the first version we could get from bagder's site (if there are more, been a long time since I looked there...). If you have a bit of time, would you mind explaining how to use the current SVN, I got lost with the "new" bootloader and stuff and since you're not online anymore...

Keep up the good work everyone!

[caladan]

The wheel could be a standard rotary encoder using some kind of magnetic relays..

[atomikpunk]

After review, it is indeed the 1.1.11 fuze firmware revision that I have here.

Caladan, yes you are right and from the pics from Daniel, it looks like it I know some hall effect sensors have 4 pins and this is exactly the kind of sensor they could have used with a polarized wheel.

[kugel.]

funman, I tried to apply your patch. It's seems not to be against svn, since I'm missing a file it wants to patch.

[funman]

sorry it was missing parts of the new files, I corrected the paste in my previous message

[kugel.]

With the corrected patch, I'm able to successfully boot into the main menu on my fuze reliably.

The display is slightly greenish, and the area where the statusbar should be is flickering. I can turn the backlight on with inserting the usb cable. Obviously I'm not able to browse anything due to the lack of buttons.

Edit: I forgot to mention: I've made a 500MB partition to work around the >1GB problematic for now. But now as it boots successfully I'll have a look at the getting the whole 4GB to work (which will likely be problematic without seeing the filebrowser).

[daniel_at]

The blinking top status-bar on the fuze build disappears if I remove the line 394 in lcd-fuze.c:

Code: [Select]

    lcd_write_data((unsigned short *)lcd_framebuffer, LCD_WIDTH*LCD_HEIGHT);
Seems do be a copy-pasta snipped from lcd_update...

[kugel.]

Small update: I found that the buttons for the Fuze are the same as the ones for the e200v2, at least the ones implemented (i.e. not scrollwheel, home(fuze)/rec(e200v2) and hold).

[funman]

I finally found what was wrong in the bootloader:
I was not incrementing the SDRAM pointer, so data would be overwritten after each sectors transfer; only if the requested sectors number was >= 128 (which it seems only happened in the bootloader)

I committed the (read and write) code in r19211 , with the DMA driver which will be used for I2SOUT (pcm playback) and perhaps I2SIN (pcm recording).

It will require some modifications though:

• Currently the end of transfer notification works only if 1 channel is active
• Unlike in SD transfers, the data flow needs to be controlled manually
• Maybe fix some bugs ..

Don't forget the major bug remaining : we can't access data past 1GB on the internal storage.

NOTE: LambdaCalculus37 reported his 2GB Clip is correctly detected as 2GB by rockbox.
I believe 2GB is the maximum theorical size on not High Capacity SD cards.

[yapper]

I believe 2GB is the maximum theorical size on not High Capacity SD cards.

I thought 4GB was the limit, but Wikipedia claims 8GB

[Hillshum]

According to sdcard.org, 2gb is the non-hc limit

[cosmocat]

the limit for sd card and microsd cards are differents.
sd card : 1GB, 2GB and 4GB
sdhc card : 4GB, 8GB, ...

but in our case, for a microsd card :
micro sd card : 1GB, 2GB
micro sdhc card : 4GB, 8GB...

if it could help...

[philibuster]

According to sdcard.org it says "up to 2gb" for both micro and normal SD.

wikipedia (gasp) has a good writeup about the "openness" of the "standard" and says that all <1gb should work in every case, but SD supports up to 4gb with some hacking.
http://en.wikipedia.org/wiki/Secure_Digital_card#SD_.28non-SDHC.29_cards_with_greater_than_1_GB_capacity