Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Bugs
  • Category Operating System/Drivers
  • Assigned To No-one
  • Operating System iPod 5G
  • Severity Low
  • Priority Defer
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by dreamlayers - 2009-04-08
Last edited by torne - 2011-06-05

FS#10107 - iPod sometimes needs menu + select reset to turn on

I have a 5G 30GB iPod. Sometimes when I try to turn it on, nothing happens or there is just a brief flash of the low battery icon. After this, further attempts to power on normally do nothing, and the only way to turn on the iPod is a menu + select reset.

This is a known problem. For example, it is discussed in this thread: http://www.rockbox.org/mail/archive/rockbox-dev-archive-2009-02/0122.shtml Most people here believe this is a bug in Apple firmware in flash, and not a bug in Rockbox.

I created a small patch which shuts down Rockbox using the original firmware in flash. It writes a string to a specific location in IRAM and then resets the iPod. This causes the original firmware to act as if an attempt to boot failed. It assumes that the battery is low, and when a charger isn’t connected it shuts down. The patch seems to fix the problem. With it, I’ve never had to reset my iPod to turn it on.

I am attaching the patch as evidence that something can be done about the problem. I think the proper solution would would be to see what Rockbox needs to do and do that, instead of relying on the original firmware.

In practical terms, the patch only has has few minor disadvantages:
- there is a brief flash of the low battery icon after Rockbox shuts down
- attempts to turn on are ignored for a few seconds after Rockbox shuts down. (Just wait a few seconds after turning your iPod off before turning it on again. If you try to turn it on too soon, nothing will happen and you’ll have to do it again later, but you won’t have to do a menu+select reset.)
- If a charger is plugged immediately after the iPod is turned off, the ‘very low battery” screen is shown.

The patch could be extended to other PP502x iPods. I know the same problem happens on some other iPods, but I don’t know which ones, and I only have a 5G.

The main questions on my mind now: What state can be preserved when the iPod is turned off? What chips have power besides the LTC4066 and PCF50607?

Closed by  torne
2011-06-05 10:58
Reason for closing:  Out of Date
Additional comments about closing:   Warning: Undefined array key "typography" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 371 Warning: Undefined array key "camelcase" in /home/rockbox/flyspray/plugins/dokuwiki/inc/parserutils.php on line 407

We aren't going to reintroduce this method, it causes too many problems for too many people

It happens about half the time on the iPod Photo/Color and significantly less frequently on the iPod mini.

Here is a patch which uses the shutdown method described above on all PP502x iPods. Note that the address is different on the PP5020. It’s the same block of data that’s written to before rebooting for USB (in try_reboot() in usb.c).

I don’t know if this code works on a 1G Mini.

torne commented on 2009-04-15 09:52

Using the original patch on my 5.5G 80GB ipod and it works perfectly; no adverse effects that I can observe other than the minor side effects you mention, and I have had it turn on successfully probably 50+ times without having to reset. Previously it was unlikely to turn on more than two or three times in a row without needing a reset.

ryran commented on 2009-05-02 16:59

I am absolutely psyched about the possibilities here! I gather this isn’t the RIGHT long-term solution for RB, but I’m so happy that there’s finally some hope! (Working well on my ipod 5G.) Nice investigative work Boris. Including this in my custom build for now: http://forums.rockbox.org/index.php?topic=17338.0

Thanks! It’s nice to see that this patch is helpful, and that something can be done about this problem.

Was this problem always present in Rockbox? http://forums.rockbox.org/index.php?topic=21541.0 seems to imply the problem wasn’t present in Rockbox from over a year ago. If a version without this problem can be found, that can help in tracking down the problem.

Great! I test it since two weeks. No more menu + select reset using a modified build.
I would like to see this fix in SVN.

ryran commented on 2009-05-12 22:33

Boris:
I’m loving this. With the inclusion today of FS9730: http://www.rockbox.org/tracker/task/9730 .. I’m curious.. I assume this wouldn’t still work if I went that route and replaced the apple fw with RB + loader? I haven’t had a chance to check it out yet but if you don’t have any insight I suppose I will in the coming days.

With this patch, shutdown is performed by original firmware code which is in the firmware flash chip. What is on disk is irrelevant. As far as this patch is concerned, you don’t even need to have the original firmware on disk.  FS#9730  does not in any way conflict with this patch.

I thought this was just a bug in the iPod hardware or something, it happens on my iPod Photo/Color maybe 30% of the time.

torne commented on 2009-05-13 10:54

This works just fine with  FS#9730  as I wrote that patch and have been using both together for a month :)

ryran commented on 2009-05-13 12:33

Rock on. Thanks for the explanations you two.

torne commented on 2009-06-13 21:02

I’ve noticed an issue recently which may be connected to this patch: occasionally after my ipod video 80gb has been turned off for a long time (using a build with this patch in it) I discover that it’s booted itself back into the Apple firmware (since hold is left on) and is turned on again. It doesn’t seem to happen while off for 5-6 hours while I’m at work but it happens every couple of days overnight.

I’ve only noticed this happening since I last updated my build from SVN, but I’m not certain that my observation is flawless. I’ve managed to lose the svn build number I was on previously, unfortunately, but the one showing the problem is r19705. I have other patches but they are minor and I can’t see them being relevant :)

Is this perhaps related to Apple’s deep sleep mode? If I recall correctly that kicks in after 8 hours on standby…

Once after using disk mode in on-disk (osos) original firmware, my iPod turned on unexpectedly.
This has never happened when I only use Rockbox.

When the OF turns off the iPod, it enables power on via alarm (using the RTCWAK bit in OOCC1). Then whether the iPod turns on depends on what alarm time is set. I suspect that the OF uses the alarm for hibernating after extended standby. A simple workaround would be to set an alarm time which ensures the iPod won’t turn on anytime soon.

torne commented on 2009-06-15 10:52

Hm, I don’t often boot the original firmware but I couldn’t say for sure. Setting the alarm sounds like a reasonable fix..

Akur commented on 2009-06-26 17:36

I too had this problem but since I follow the instructions of the method 2 on http://www.rockbox.org/twiki/bin/view/Main/IpodPatcher to improve the Rockbox boot time, it started to happen a lot less frequently.

torne commented on 2009-06-27 01:25

Are you sure? :) It seems pretty random in any case so it’s hard to say whether it’s more or less frequent with any degree of certainty (though it does not happen at all with this patch - must’ve turned it on hundreds of times since adding it to my build).

I ran with Rockbox in OSOS for a while before this patch was written and there was no difference that I noticed, and there’s no particularly likely reason why it would cause a change in behaviour that I can think of :)

Akur commented on 2009-06-27 07:39

I only starting running Rockbox in OSOS a week ago and since it only happened twice, I was quite happy….

But maybe it is just psychological… :)

Hey guys,
I’ve got an Ipod 5.5G and am very unhappy about the shutdown issue. I’m trying to patch the source that I downloaded with the original patch from this page. I’m not completely new to compiling but not really much of a programmer. I downloaded subversion and downloaded the source, in the root directory (cleverly named “rockbox”) i placed the 5g_shutdown_by_of.patch file. I ran:

patch < 5g_shutdown_by_of.patch

and get this

haus@outremer:~/rockbox$ patch –dry-run < 5g_shutdown_by_of.patch
can’t find file to patch at input line 5
Perhaps you should have used the -p or –strip option?
The text leading up to this was:


————————– File to patch:

its waiting for input and i’m not really sure what to do here, looking for some help if there’s any to be had.

As the patch output says: use the -p option.
patch -p0 < file.diff

With the patch applied, I never got any more the problem. I remember to have see my DAP switched on automatically, with running RB or OF depending on the lock button.
But since I’m using the installation method 2 (RB + bootloader in OSOS), it never booted automatically.
I think it could be committed.

Since I stopped using the original firmware, I’ve never had an unwanted startup. I still have Rockbox installed in the usual way (with the OF in the firmware partition). I’m pretty sure I know what happens: the OF sets an alarm time for some reason such as going from standby-to-RAM to hibernate, and that alarm causes the unwanted startup. This patch should fix the problem. It’s a bit of a kludge, but I think it’s better than changing platform-independent files.

Here are some things which don’t help:
- Lowering the threshold and enabling debouncing in the PCF BVMC register
- Commenting out all PCF RTC code except for reading the current time.
- Shutting down power to the backlight[*]
- Shutting down power to the hard drive[*]
- Clearing PCF interrupts by reading INT1 through INT3 registers before PCF standby.

[*] I thought it was possible that Rockbox leaves the iPod in a configuration which results in a larger inrush current, which leads to a temporary decrease in battery voltage. However, if that was happening, this problem would depend on the current battery level, and it does not seem like the problem depends on battery level. So, I don’t feel like observing the startup current via my oscilloscope.

Does disabling the OF alarm time in this way prevent the Rockbox wake up alarm from working?

The Rockbox wake up alarm still works. The added code only calls rtc_enable_alarm(false); when the alarm is disabled. In such cases, without this patch Rockbox shuts down the iPod without enabling wake up via alarm. I tested the alarm with PP502x_iPod_shutdown_by_of-alarm_fix.patch.

Great - vote +1 to get this into SVN..
(btw - we can presumably take a look at the firmware flash code and see what it’s doing that’s different than what rockbox seems to be doing? my personal favourite suspicion is that there’s some secret flags in iram and we don’t zero it out when we shutdown)

For what targets should this patch be committed? Currently it affects all PP502x based iPods, which means 4G, Photo/Color, Mini 1G, Mini 2G, Nano 1G and 5G/5.5G (Video). I tested it on my 5G and someone else tested it on 4G. I feel comfortable assuming it will work on Photo/Color and 5.5G.

Has anyone tested this on Mini iPods, especially the Mini 1G?
Is this even needed on the Nano 1G? Has anyone tested it there?

torne commented on 2009-10-18 07:21

It definately works on 5.5G; I have been using it on mine for months.

dreamlayers, I was gonna feed the 5.5G bootflash to IDA at some point to try and track this one down, but presumably you have some/all of a disassembly for that already?

Soap commented on 2009-10-18 17:55

I have not had the startup issue on my Nano 1G, FWIW.
That said - I use my Nano infrequently so offer few datapoints.

torne commented on 2009-11-18 11:46

I’ve posted a poll on the forum here: http://forums.rockbox.org/index.php?topic=23187.0 This might show us which models have the problem…

torne commented on 2010-05-24 11:07

I reverted this change some time ago in favour of  FS#11149  which seemed to work perfectly on several models with no side effects - the patch here causes some people’s players to wake up at random times *anyway* even though we took steps to prevent this.

However, the fix from  FS#11149  doesn’t actually work for everyone; some people’s players still need to be reset sometimes.

So… any more ideas? :)

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing