Details

This patch reimplements voltage scaling for the AMS Sansas. I have set the reduced voltage level at 1.05 V in the hope that the lower voltage will be more likely to expose any bugs that may show up. When actually implemented I would expect to use 1.10 as the reduced voltage. kugel and mc2739 came up with this solution several month ago I have simply massaged the implementation here a bit.

This patch uses cpu_boost() during sd card accesses when a microsd is present to raise the core voltage back to 1.20V. This means that for the clip, and also for the other targets when a microsd card is not present, it does not use cpu_boost() on card access and remains at the lower voltage.

I have run this at 1.05 on my e280v2 for several hours now both with and without a microsd with no problems.

This breaks my microsd card access. The player when initially switched on will not read the card. This is when i access it through files form the main menu. If i pop the card out and in again it reads the contents and i can get access to play music from the card. After a while it crashes out with error.

Undefined instruction
at: 30800CF8

Side note, the the previous patch at 1.10v worked okay. I have an 8 GB class 2 Sandisk SDHC on an e260V2.

The error i am getting is directly related to the card. As we would expect. This does not seem related to cpu boost and i have inspected the buffer thread information. I have tried inserting a card and then just listening to the FM radio and the player will still crash with the same error.

I do not know how long before you drop the voltage back to the 1.05 after card insertion, maybe this coincides with the error. I have tried this with another 8 GB Sandisk Class 2 SDHC card this one with different disk info in the debug menu and very much the same results.

Modified my voltage back up to 1.10 and it is running okay now. I have been playing around with inserting and removing the card. Sometimes it is missing that i have taken the card out or put it in. This causes it to think there is an SD card inserted when i take it out and removes it when i am putting it in. I am not sure how you are detecting that the card has been ejected or put in but that currently can misread what is happening.

Since the card detection seems to be creating a problem I don't think it's worth the effort to try to sort it out. This patch simplifies things and uses cpu_boost() on anything that has a microsd slot(all except clip...)

The voltage is still at 1.05 but is easily changed to 1.10. If 1.05 gives you problems try changing line 370 in system-as3525 from CVDD_1_05 to CVDD_1_10.

Edit: I have noticed some blue pixels that I didn't see before applying this patch. They show up consistently on the Rockbox logo displayed by the main firmware (not bootloader). They are about half way down the display in one line. This is with r23123. I do not see them with a clean build.

Edit 2: I have reapplied the first patch with r23123 and do not see the blue pixels.

I can't duplicate the blue pixels here. I've got r23123 with this patch applied and I've tried rebooting a whole bunch of times with no luck.
I am puzzled why the first patch would not exhibit the same problem as it is basically the same process with a check to see if there is a card present.
And no, I am not doubting your results as you are the ultimate tester!

Ok, I think this one should work on all players with no problems. I have not dropped the voltage on this one so it stays at 1.10.
It does check for the presence of a µSD card to boost, a much better way than the first patch, so if you don't have a µSD card installed, it should not boost.
I think this one is ready to commit if we don't see any problems.

That figures, I actually unboosted unconditionally to avoid the problem of someone removing the µSD during the disk access and ending up stuck at boosted... But it seems you got a different problem.
The way i read cpu_boost(bool on_off) in system.c there is a safety check to reset the boost counter to 0 if it goes negative.

I don't think you need the #ifdef HAVE_MULTIDRIVE unless the intent is to leave out that code on the clip. card_detect_target() should always return false for the clip.
cpu_boosted seems to take care of the card removal problem for us just fine....