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

[FlynDice]

Funman:  Thanks for the caching article, sorry to drop & run on you like that but I had kids getting up and had to run off to fly across the country...

I don't know if I'm misunderstanding your comment on irc about looking in the OF for mrc/mcr whether you didn't find them or just what you found wasn't real interesting.  I found them in the e280 by _not_ forcing thumb in the objdump/disassembly.

The clipv2(the new one) had roughly the same mmu startup routines as the e200.     http://pastie.org/435466

Still researching dma and cache but nothing really new so far.

[funman]

No problem ^^

The mrc/mcr instructions are not interesting, there's nothing that we aren't doing already.
And indeed they are ARM instructions which don't exist in thumb mode.

I have played with your patch and updated FS#10048, still no success with caching, but at least the MMU works fine!

I also opened FS#10092 which cleans up a bit system_init() : it would be nice to test on e200v2 & m200v4 (domonoky?)

By the way, has progress on c200v2 stopped?

If someone is willing to write code and test it on target, I can help by disassembly for LCD & buttons.

[sko]

@funman:
I have tested your MMU patch (e250v2):

• playback (ogg) stops after 2-3 seconds (worked before)
• if I enable i/dcache bootloader looks fine, but main build start screen (the one before the menu) is mirrored and RB hangs there, one time it showed a prefetch error message (mirrored too), unfortunately i didn't notice the address (and wasn't able to reproduce until now), but I think it was FFFFFFFC.

I  also tested your cleanup-patch and I couldn't find any problems, so I think it works.

[FlynDice]

I"ve been looking at he gigabeat fx the past few days seeking clues and noticed that they don't seem to use the IRAM, at least not in the way that we use it for the as3525.  I thought the main difference between the 922 and 920 is the smaller I/Dcaches on the 922.  In their app.lds they have no IRAM and in boot.lds theyhave an IRAMSIZE of 4K  but it isn't used for anything it seems.  Do they use it differently? And if so is there a good reason?

Edit:Ach nevermind, been submerged in this a little too long and everything's starting to run together on me, I was thinking our IRAM was part of the 922 instead of part of the as3525....

[saratoga]

  In their app.lds they have no IRAM and in boot.lds theyhave an IRAMSIZE of 4K  but it isn't used for anything it seems.  Do they use it differently? And if so is there a good reason?

The Gigabeat F doesn't use IRAM because theres so little of it.  4KB isn't enough for codecs (which are currently designed for at least 48KB).  We could use it for core stuff, but so far no obvious use for such a small amount has been found.

[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 ?

[Hillshum]

@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

Could this mean if we wrote to the controller sideways on the Fuze it would work?

[wpyh]

Well, if I replace the backdrop with some other bitmap measuring 220x176, the corruptions don't happen. Therefore the corruption is very data-specific.

Could the corruptions be some kind of side-effect from CPU calculations? Such as registers being mapped to RAM, and we use that part of RAM to decode the bitmap?

[saratoga]

Sounds like the buffer being used for the bitmap is being overwritten, either by a bad pointer or because we've double mapped a piece of memory.

[calv]

Well this problem appears even without MMU enabled, so logical=hardware addresses. But on the hardware side the memory (and even I/O) could be mapped to multiple places and overlap in some places. Maybe we are using addresses, where memory and I/O overlap. It could even be, that we are using the correct I/O addresses, which are nonsense (hardware-wise): working because of hardware mapping, but at the same time overwriting RAM. The OF could even use the same addresses, but then mapped by the MMU to different hardware addresses, where RAM is not selected, and thus not overwritten.

Maybe finding out at what exact addresses in RAM the backdrop gets corrupted and comparing those addresses to our I/O addresses could bring some clue about this.

Only one of my usual wild guesses, though 

[kugel.]

The backdrop is corrupted without memory mapping too (in fact, not only the backdrop, but every bmp above ~190px wideness). And we're using the correct RAM addresses.

The loading is problematic, because the issue was revealed by a commit which changed the bmp loader to load a whole pixel row at once, instead of only 8px of a row at a time.