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

[funman]

Ok so using 82.666MHz clock for IDE shows better results than with 62MHz

The OF seems to use 64MHz (384/6) , if we want to see if it works alright with 64MHz, we need to change the PLLA setting to a multiple of 64MHz. (like 384MHz)

If you don't know how to change it (you need to modify the PLLA setting!) I'll try to come with a patch tomorrow.

Thanks for testing!

[iudex]

So, what's now to do?

[saratoga]

I put a list of requirements we'd agreed on informally for a release on the wiki page.  Of course those are just the minimum for a release, theres much more then that left undone.

[FlynDice]

Ok, here's the second go at something to show what the clocked rates are.  Tell me if you think this should go on FS as a patch or if this is ok just attaching to a post.  This patch only assumes that clk_main = 24 MHz.  Everything else is calculated using the actual dividers read from registers.  It takes into account synchronous, asynchronous, fastbus, optional clock inputs and seems to work very well for me.  The layout may stretch a bit long vertically for the fuze but it fits nicely in the e200 screen.

[funman]

If you don't know how to change it (you need to modify the PLLA setting!) I'll try to come with a patch tomorrow.

I couldn't make a patch with 64MHz freq for pclk which booted on my Fuze (showed a white screen), so I suggest just reverting this with a comment.

test_disk with CGU_IDE at 90MHz (real : 82.66MHz) just passes, so unless someone else has an idea..


@FlynDice : if you can make your patch scroll in both directions (think of the Clip..) it should be committed

EDIT: I added FS#10216 to fix possible ATA problems on 8GB models, but it requires testing by a owner of such a device. wpyh?

[saratoga]

funman:  I just realized that I sent you my 8GB player and kept the 4GB (not the other way around as I was thinking for some reason) so I can't test.  However I did the test anyway about the 2GB mark and it obviously transfers without trouble.  If anyone else wants to try this on a real 8Gb target and let us know if it works:

Apply this patch: 
http://www.duke.edu/~mgg6/rockbox/diskcheck.patch

Then use this file:
http://www.duke.edu/~mgg6/rockbox/myfile.txt

with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

BE SURE TO CHANGE /DEV/SDC TO WHATEVER YOUR DEVICE MOUNTS AS!

This will write the sequence 1 2 3 ... to the block 0x7A7800.  Then check the debug screen under "View IO ports".  DIR0 is "0" and DIR4 is "1" if everything is working.  If its not, you'll get some other value (at least I hope, I can't test it on mine).  Then repeat with funman's patch to see if it works the next time.  Then you'll probably want to reformat to fix your file system.

[FlynDice]

I postedFS# 10219 for my debugclocks patch.  Scrolling is a bit beyond me right now but I did put some paging into it that should work for a clip.  See what you think.

[funman]

with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

The seek= option must be 7964671 (0x7A7800 minus 1 minus OF size)

Also don't forget to write a filesystem which is 3GB or so. This way rockbox won't write data across the 4GB limit, and you don't risk bricking your player.

Also

Code: [Select]

+        _DEBUG_PRINTF("DIR0: %x DIR4: %x", *(buf2+512), *(buf2+512+4));
should be

Code: [Select]

+        int *wordbuf = (int*) buf2;
+        _DEBUG_PRINTF("DIR0: %x DIR4: %x", wordbuf[512/4 - 1], wordbuf[512/4]);
And should return 0x7f and 0x80.

That will show the last word of last sector of first bank, and first word of first sector of second bank.

EDIT:

I postedFS# 10219 for my debugclocks patch.  Scrolling is a bit beyond me right now but I did put some paging into it that should work for a clip.  See what you think.

Thanks, I added a few modifications and committed it.
Also thanks to your patch for making me notice a bug in Clip LCD driver

EDIT2:

Code: [Select]

+    sd_read_sectors(0, 0x7A7800 - 1, 2, buf2);should be

Code: [Select]

+    sd_read_sectors(0, 0x7A7800 - 0xF000 - 1, 2, buf2);because we also skip the OF in sd_read_sectors() .. sorry for the confusion.

Be sure to share your methods with your results so multiple persons can check them!

[saratoga]

with dd as so:
sudo dd if=myfile.txt of=/dev/sdc bs=512  seek=8026112

The seek= option must be 7964671 (0x7A7800 minus 1 minus OF size)

I don't think the OF shows up over USB, so you don't need to correct for it.  At least using 7A7800/2 on my 4GB (since I lack an 8GB) gave me the expected results with dd (first word of the first block of the new bank is 0x01, while the second is 0x02). 

[funman]

That's because the OF doesn't show up, we need to correct it.

0 ....(OF).... 0xF000 ..... 0x7A7800 (real sectors)
........(OF).................0 ... 0x7A7800-0xF000 (usb)
........(OF).................0 ... 0x7A7800-0xF000 (rockbox)


And on your 4GB Fuze, you only have 1 bank !

[FlynDice]

The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions.  This patch will turn the info back to "live" info that will change realtime.

[kugel.]

The debugclocks info is in svn now but the info displayed is static, ie whatever the state of the frequencies was when the page was displayed will not change for current conditions.  This patch will turn the info back to "live" info that will change realtime.

The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?

[FlynDice]

The usae of while(1) is weird too. Why not just button_get instead (without the timeout part)?

Don't look to me for pretty or elegant coding solutions .  I'm sure you can tell by now I pretty much go find out how someone else did whatever I need done and copy it. If it works great, if not I shake it a little and try again! In fact I think that's a part of your code from the debug io ports that I copied for that part...

Please, if you think you have a better way, change it or tell me how and I will.

[kugel.]

In fact I think that's a part of your code from the debug io ports that I copied for that part...

Haha, seems so

You can be sure I only copied other code too

[FlynDice]

I have had a bit of success with the mmu tonight, not enough to say I have it working but enough to focus on what the problem may be and a taste of what may be possible with the mmu working.  I am not going to post a patch yet, maybe later tonight if I can make some more progress.  I think there are other folks who could make headway faster so I thought I would just post my findings so far in the hopes that they are useful now.  I have been playing around today with a clocking setup of PLLA=384, FCLK=192, PCLK=64, with bus synchronous for boosted and fastbus @ 32MHz unboosted(the performance of this setup was quite acceptable I thought also).  I tried the mmu setup I had been working on before the clocking issues came up and got the same i2c problems that go along with that.  So I added the delays to ascodec.c and tried again and found I could play music just fine, until the first song ended...... Then it was as if playback locked up.  I could still navigate the ui but I couldn't get playback to start again without rebooting.  Here are the things I noticed:  In the buffering thread it was showing about 44MHz average for decoding and was boosted very minimally. On the clocking display you will notice that the sd and msd freqs go to 405khz for disk accesses and then back to an invalid value when the access is over.  Well they end up locked at 405 when my music stops playing and the frequency is locked at 192MHz for the player, all while still able to navigate the ui.  I'm thinking this points to some type of sd access problem and that's an area I'm not very familiar with yet.  Then again I've been know to draw an incorrect conclusion or 2 so what do you folks make of it?