Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
werich:
tested r21248 (after format from the OF) on fuze 8GB (microSD temporarily removed cause it seems to work, as before).
Putting only a few files on it worked as it should (including building a correct DB) - but with more songs it didn't play these new ones, DB build stops immediately with 0 songs (not like before as it recognized at least the first 4GB correct). The accessible memory-border seems to be much lower now - 1 GB estimated. Maybe the 1GB with SD driver access funman mentioned at IRC yesterday?
Good thing is the filesystem corruption seems to be gone.
(edited: made it more clear)
funman:
OK this looks like previously the bank switching failed, and now the initialization of bank switching fails.
To confirm you could format your Fuze with a size-limited file system:
mkfs.vfat -F 32 /dev/sdb $((0x7A7800/4-0xF000)) # for 1GB filesystem, test with r21248
mkfs.vfat -F 32 /dev/sdb $((0x7A7800-0xF000)) # for 4GB filesystem, test with r21247
and see if rockbox functions properly.
I had a look at the disassembly again and I found these:
* The OF sometimes use direct copy from MCIFIFO and doesn't use DMA (I don't know when exactly)
* The OF change pclk & fclk before and after bank switching, but not when initializing bank switching (this is done in early hardware init)
* The current OF has no support for 16GB, sorry ^^
I could perform some tests if I could reproduce this problem but "unfortunately" my Fuze works perfectly ..
matsch:
I observed 'view buffering thread' of Clip v1 while playing mp3.
MP3 playing stops occasionally when buffer usefl is filled up. Buffer pcm is 0.
I reduced buffer size by changing 'Max Entries in File Browser' to 4450
and 'Max. Playlist Size to 1000'. With this settings the bug can be repoduced with a certain mp3 file.
Shortly after starting play I hear a hissing noise and playing stops. After changing back the settings the file plays on.
some files play fine with the 4400/1000 setting, some not.
funman:
Before the thread becomes filled with loads of bug reports about SD/internal storage:
* r21227 and before work fine (prior using the data cache)
* r21228 and after show random behaviour : file system corruption, problems in bank switching (can't access the full capacity)
I insist on the random behaviour because storage access works fine for some people and some revisions, and doesn't work the day after, even if the difference between the two builds are not related to Sansa AMS.
If the file system is corrupted, plugins and codecs which are loaded from the storage can't obviously be relied upon, so any crash report (data abort at XX ..) is basically useless.
Easy solution : don't use them.
If you want to use the unstable, unsupported, unreleased development version of rockbox, you should use r21227 or anterior.
How to report that your Sansa doesn't work: please do not, we already know that our code is broken.
Let me add that my Fuze 4GB worked very fine (I still see unfrequent corruption of the LCD display, but that has always been) yesterday, but not today; even if no related changes have been committed.
That seems like an extra argument to the randomness of the problems we have.
EDIT: my Fuze infinitely loops into sd_transfer_sectors() because the SD controller reports a DATA TIMEOUT (bit 3 of MCI_STATUS).
Still the exact same problem I saw before committing r21247 to set timeouts specified in SD Specification.
Still random though : my Fuze boots after I added debug code in INT_NAND() ..
@matsch : thanks for the report, I'll try to reproduce when I find some time
freddy:
Hi people
I just tried rockboy and it works quit :) well after a small patch to the button code. I made a little patch that makes the scroll wheel work in rockboy again. Most games I tried work very well already. Should I make an FS entry for this patch ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version