Welcome to the Rockbox Technical Forums!
Yes, but look further down. It does a check in a function called get_model - this returns unknown with the new 2.03.33 image - well, the one I have anyway - just downloaded from sansa site.I added, case 0x71:and then compiled and ran mkamsboot. It succeeds with this model_id value added. I haven't copied it to my Fuze yet because I'd like to confirm somehow that others have seen this new model_id in 2.03.33.The model_id is not the version # but seems it should refer to the device model. Of course, my device has changed but I am definately seeing the value 0x71 in location 0x219 in the latest OF image fuzpa.bin
jennifur@alice:/mnt/disk$ mkamsboot fuzpa_orig.bin bootloader-fuzev2.sansa boot.binmkamsboot Version r26241-100521This is free software; see the source for copying conditions. There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.[INFO] Original firmware MD5 checksum match[INFO] Model: Sansa Fuze v2 - Firmware version: 2.03.33[INFO] Firmware patching has begun ![INFO] Original firmware size: 168920 bytes[INFO] Packed OF size: 90016 bytes[INFO] Bootloader size: 76240 bytes[INFO] Packed bootloader size: 33945 bytes[INFO] Dual-boot function size: 364 bytes[INFO] UCL unpack function size: 168 bytes[INFO] Total size of new image: 124493 bytes[INFO] Patching succeeded!jennifur@alice:/mnt/disk$
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!
As soon as the data transfer is completed, the card will exit the data write state and move either tothe Programming State (transfer is successful) or Transfer State (transfer failed).
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.
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.
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 ?
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!)
Page created in 0.09 seconds with 20 queries.