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