Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
FlynDice:
The one second is indeed arbitrary I think. Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete. Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works. I'll have time later tonight to look at this, I'm between flights right now.
I can't access the irc logs and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log. With v10 I did get my clip+ to run down to empty by clearing my settings. However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access. It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled. If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.
EDIT:
http://pastie.org/973066 will definitely solve the card stuck in PRG state problem. It passes write & verify but I got mixed results for speed, some faster some slower on tests. I can't be sure that it won't introduce something else though without more widespread testing. ;)
funman:
--- Quote from: FlynDice on May 22, 2010, 06:43:52 PM ---The one second is indeed arbitrary I think. Perhaps just increasing it will take care of that problem or we could wait for the card to signal not busy after the transfer is complete. Since the card is basically programming the info on its own and we don't need to manage it I think just increasing the timeout here would be the preferable solution if it works. I'll have time later tonight to look at this, I'm between flights right now.
http://pastie.org/973066 will definitely solve the card stuck in PRG state problem. It passes write & verify but I got mixed results for speed, some faster some slower on tests. I can't be sure that it won't introduce something else though without more widespread testing. ;)
--- End quote ---
OK, going to test it. No idea for the the slower speed though.
I'll see if yielding while the card is busy affects speed too much, it shouldn't change a lot since we yielded anyway if the card was in programming state, unless if had finished programming immediately.
EDIT: I got some "read multiple blocks failed" when playing off µSDHC class 6 on Clip+. I'll try to add back the wait for state TRAN after the busy wait.
EDIT2: same crashes, I'll now try with extended delay when waiting for TRAN state
--- Quote from: FlynDice on May 22, 2010, 06:43:52 PM ---I can't access the irc logs and flyspray for some reason so I can't see if you got my message about the cpu_freq_patch that I left in the log.
--- End quote ---
I think logbot is on the same server than the website so no irclogs until the site is back. (and messages while the site went down won't be logged).
--- Quote from: FlynDice on May 22, 2010, 06:43:52 PM ---With v10 I did get my clip+ to run down to empty by clearing my settings. However when I juiced it back up and looked at the hardware page I noticed that there was no frequency switching going on, just a steady 40 MHz until there was a card access. It seems that 40 MHz is enough performance that boosting is not needed at least without the equalizer & compressor enabled. If I enable the compressor and equalizer I get boosting on a regular basis and the clip+ crashes after about 30 mins.
--- End quote ---
It still boosts but if it's fast enough you won't have the time to see it in the debug page.
DSP settings and voices make crashing happen more quickly, I'll run my tests with it enabled.
Here are some results with cpufreq:
With v10 (I think it's that one, can't access flyspray, anyway it was CPU@40MHz and no delays when changing freqs) on Clip+ playing from internal I had 15h15 runtime, so even if we make it work it makes battery life not better if not worse, probably because of the higher DRAM/PCLK freq (40MHz instead of 24).
On Fuzev2 I got 19h from internal, 11h33 from µSD (Samsung 1GB, not HC, no class). I'll try with the Transcend SDHC 4Gb class 6, some messages on the forum said higher class cards crashed more.
I also tried another version for Clips which use 24MHz PCLK, but doesn't go lower than 24 when switching (24, 30, 60), and it crashed quite fast (freezes, data abort in thread code).
I wonder if there is anything special about Fuzev2 or if we just didn't see any crash because we tested this model less.
funman:
--- Quote from: funman on May 21, 2010, 05:00:16 PM ---get_model() isn't called if the md5sum of the OF is in the list.
Btw, before we add an OF release it is always tested on a real device first.
I see indeed that the model id has changed from 0x70 to 0x71 so it makes me wonder:
Perhaps we should not rely on this field to detect model of the OF ?
What if Sandisk decides to release a Clip+ firmware with model id = 0x71 too ?
--- End quote ---
I checked other firmwares and this field has already changed in the past:
It is 0x23 on the one c200v2 OF we have, and on the last 2 Fuzev1 OFs.
So we must disable this check completely because it is not representing of the model.
EDIT: I have a patch for that, just waiting for svn to be up again.
To be clear, if you use released binaries or unmodified SVN there is no risk of bricking.
DonDan:
I have tested the "as3525v2-cpufreq-v10" patch with the 26241 revision on a fuze2 8GB with a transcend CL6 8GB uSD .
I still have a few crashes with the v10, when recording and when browsing the PictureFlow demo. During playback with crossfeed enabled and everything else disabled, I have no crashes at all.
Without the "as3525v2-cpufreq" patch I can record Mic/Radio for more than 4 hours without a crash (tested with output to mp3 and wv).
I have done a battery-bench with a 33 min rock music album with 258 VBR (Lame3.99 --vbr-new -V 0) with Crossfeed enabled (forgot to disable), playback from internal memory. Earplugs with impedance = 16 Ohm and volume set to -20dB.
It lasts for 12h and 30 min, "Battery bench ended, reason: power off", no crash.
If you need more fuze2 testing give a shout!
EDIT: I can't reproduce the PictureFlow freeze, maybe it is some PictureFlow specific bug.
The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:
*PANIC*
unhandled IRQ (source unknown!)
funman:
--- Quote from: DonDan on May 23, 2010, 10:34:04 AM ---The Recording crashes come every time, it is just a matter of time, sometimes just a few seconds other times I must wait for 30 min. I doesn't matter if the source is radio or mic neither if the output is mp3 or wv.
The error message is always the same:
*PANIC*
unhandled IRQ (source unknown!)
--- End quote ---
I have just made a commit (r26250) which should make this panic message a bit more precise, I suspect it should now show I2SIN interrupt.
Can you confirm?
FlynDice, I have put a patch for SD on FS#11312
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version