Rockbox Development > New Ports
SanDisk Sansa c200v2, m200v4, clipv1, clipv2, clip+, and fuzev2
csavery:
I just checked it all again. Downloaded again, ran md5sum at linux prompt. Matches value in mkamsboot.
Mine is 1599cc73d02ea7fe53fe2d4379c24b66
Opened fuzpa.bin in hex editor again and double checked value at 0x219 is 0x71
Looking at mkamsboot code I see the model id is only checked when the md5 doesn't match.
So it must be that the model id increment has not yet been added into a new mkamsboot.
I think what *must* of happened is that at first I compiled mkamsboot with r26185 and it didn't yet have the correct md5 for 2.03.33 so it failed and gave me the wrong model id reason. Then after I updated and re-compiled I didn't realize it wasn't the model id but the md5 that was actually wrong before.
I just verified this by removing the "case: 0x71" I had added and the result is good OF.
Except... the mkamsboot DOES need to have the new model_id value added since otherwise it DOES give the wrong error message about model_id.
I guess I should add a bug in FlySpray for that then.
Update - funman: Ahh, yes, thank you for checking that. I see it too. Probably just needs a second case statement so it now accepts either model id. It's no longer unique.
Anyway, happy here. Firmware upgrade worked ok. Should I add a bug or patch for this?
As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!
funman:
--- Quote from: csavery on May 21, 2010, 05:07:09 PM --- Should I add a bug or patch for this?
--- End quote ---
Well I'm not sure what to do, see my post just above
--- Quote from: csavery on May 21, 2010, 05:07:09 PM ---As of r26239 I am not hearing clicks any more during play state changes. Sweet. Thanks!
--- End quote ---
Hmm I didn't know about this : is it caused by r26238 ? (r26237 still has them?)
csavery:
Actually I'm noticing it in r26239 still. It happens during pause at the end of the fade and during play before the fade starts. It fades down and then a little "phhht" sounds occurs, or when play is pressed after a pause it makes a slight "phht" and then fades up. During shutdown it may happen a couple times or just once. It pretty much always there, though I've noticed a few times when pause is quiet.
NightWalker:
I have a fuvev2 and a clip+
Rename and erase on SD fails with
*PANIC* wait for TRAN state failed <PRG> 1 on both (Not something new)
Using a 16GB class 6 card and the current build (r26241)
everything works fine with 4GB class 2 card
Keep up the great work!
funman:
@FlynDice
sd_wait_for_state() timeouts after 1 second, is that an arbitrary choice ?
I looked for maximum delays after STOP_TRANSMISSION in the spec but I didn't find any
--- Quote from: spec page 29 ---As soon as the data transfer is completed, the card will exit the data write state and move either to
the Programming State (transfer is successful) or Transfer State (transfer failed).
--- End quote ---
I think TAAC / NSAC / TRAN_SPEED don't take in account how much time the card spends in PROGRAMMING state.
I tried to read linux source code for MMC/SD but it is a nightmare of object code, I can grep for STOP_TRANSMISSION but I don't know where/when it is issued.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version