Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
funman:
sko: thanks, but can you please comment on the FlySpray tasks? It's easier to follow than a fast evolving forum thread ;)
I have experimented a bit to understand why the Sansa AMS crashes a lot and seem to suffer from memory corruption, so I'll try to resume again if someone can see some light:
* The Sansa Fuze backdrop is corrupted (_ALWAYS_ in the same manner), even if we don't use the DMA for SD transfers (I reimplemented the direct copy from FIFO for this test)
* The crashes and backdrop corruption happen, wether the instructions and data caches are disabled or enabled
* The crashes and backdrop corruption happen, wether the MMU is disabled or not
* The crashes happen on low memory models (Clip, 2MB) and "high" memory models (Fuze, e200v2, 8MB)
* The crashes happen if we use our custom sdram_init() or the OF routine (I tested this on my Clip, only replacing the delay function of the OF by my own)
* The md5sum plugin can reproduce this memory corruption : the "quit" boolean value change even if the only part in the code where its value is changed is not run
* (When changed to work around the above problem) the md5sum plugin shows correct sums for ALL the files. The mentioned backdrop corruption might then happen on the framebuffer and not on the bitmap file itself
Feel free to correct me, and to verify my experiments.
I don't know in which direction to look now :/
wpyh:
funman: maybe you could create some kind of "memtest" program to see where the corruption happens. The location where the corruption happens should be constant, since I also see the background corruption problem on my 8GB Fuze at always the same coordinates.
freqmod:
I played a bit with the flash buffering patch FS #9332 and it seems to me that the last part of the buffer write is corrupted.
If i made the buffer smaller i got more, but shorter shuttering, when i made the buffer 4096 bytes it was nearly a constant 1/2 sec of playing, 1/2 sec of shuttering. That would support the ram timing theory, and that the problems are not based on the location in the memory.
btw. files with low bitrate (speex with ~15kbps) plays nearly perfectly, and i listened to an audiobook for 5 hours yesterday with only a bit skipping at the start, and without crashing. (when i did not fast forward, paused or anything like that).
mc2739:
@funman
Here is an interesting observation for you.
The e200 screen is 176 wide and 220 tall compared to the Fuze which is 220 wide and 176 tall.
I reconfigured so that my e200 screen is rotated 90 degrees to match the Fuze and I get the same screen corruption as seen on the Fuze.
I have not had any screen corruption in the standard configuration
funman:
@wpyh : I already tried some memset/memtest but didn't see any problem, even if I waited 1 minute before write & read.
I'll retry on the whole 8MB of SDRAM.
@freqmod : which player are you using ? I thought FS#9332 only brings improvement on players with 2MB of SDRAM (Clip/m200v4)
@mc2739 : thanks, at least the problem is consistent between e200v2 & Fuze!
I loaded a white bitmap as the backdrop on my Fuze but I don't remember seeing any non white pixel..
@kugel : do you have informations / tests on this backdrop corruption ?
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version