Rockbox

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.

   PP502x_iPod_shutdown_by_of.pa... (1 KiB)

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.

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.

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.

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

Rock on. Thanks for the explanations you two.

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.

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

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.

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 :)

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.

   PP502x_iPod_shutdown_by_of-al... (1.3 KiB)

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?

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?

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

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…

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? :)