• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Bootloader
  • Assigned To No-one
  • Operating System PortalPlayer-based
  • Severity Low
  • Priority Very Low
  • Reported Version Version 3.1
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by torne - 2008-12-30
Last edited by linuxstb - 2009-05-12

FS#9730 - Support loading rockbox from osos on ipod

Attached patch allows the rockbox ipod bootloader to load rockbox from the osos image in RAM, in the same way the retail OS is loaded. This should work on any ipod model, but I have only tested on an 80GB Video.

This allows a sufficiently brave user to replace the osos image with rockbox + rockbox bootloader, which shaves roughly five seconds off booting but still allows booting the retail OS from apple_os.ipod using the hold switch. The speed gain is twofold: the apple ROM no longer has to load a 7.5MB firmware image which won’t be used (just the 1MB of rockbox), and the rockbox loader no longer has to load rockbox at all.

The portalplayer entry point has been modified so that part of the padding space at the beginning of the image now contains the string “Rockbox\1” at offset 0×20. This allows the bootloader to check if rockbox is indeed loaded in the osos image. (the 0×01 byte is to guard against a vague thought that a future version of this might be incompatible - unlikely, but it makes it a nice power of 2).

If a rockbox.ipod file actually exists on disk it is loaded in preference to the osos image (same behaviour as apple_os.ipod).

To actually make use of this after patching, it is necessary to compile a new rockbox build and a new bootloader, and then with ipodpatcher:
1) dump the apple os to apple_os.ipod
2) install rockbox.ipod as the osos firmware image
3) append the rockbox bootloader to the image
Then, delete or rename rockbox.ipod from the ,rockbox folder. Booting with hold turned off will then boot more quickly into the rockbox version installed in osos. With hold turned on, the apple OS will be loaded from disk.

The bootloader change should be 100% backward compatible: if the osos image is the apple OS, then it will behave identically to unpatched bootloaders.

Closed by  linuxstb
2009-05-12 20:42
Reason for closing:  Accepted
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

Committed as r20921 - thanks!

As discussed on IRC, the current ipodpatcher and Rockbox bootloader already support a method for doing something which should get almost the same speedup:

ipodpatcher -wf bootloader-MODEL.ipod

This replaces retailos in the firmware partition with just the Rockbox bootloader (instead of appending the RB bootloader to the end of retailos).

If you want to dual-boot, you need to run the “ipodpatcher -rf apple_os.ipod” command before the above command, and put that file in the root of your ipod’s FAT32 partition.

I would be interested to see a comparison of the boottime a) with the standard ipodpatcher/rbutil installation; b) with this method of “-wf bootloader.ipod”; and c) with this patch. I remember testing b) a long time ago, and this gave a very noticable speed improvement over a). So I wouldn’t expect the difference between b) and c) to be that large - and b) has the advantage of not needing to write a new rockbox.ipod to the firmware partition when you update.

Thanks! It works for me on my 30 gig 5th generation iPod and it seems like the right way to go about doing this. It might be a tiny bit faster if it checked for an image in RAM first, and then only initialized ata and tried to read from disk if there is no image in RAM. However, your way allows updating of Rockbox without rewriting the firmware partition. People would get confused if they’re running an old version even though they put a new version in /.rockbox.


Can you try the “-wf bootloader.ipod” method and see how that compares with this patch?

torne commented on 2008-12-30 23:25

I’ve just actually tried to do a reasonably precise timing of this, and it doesn’t help as much as I thought.. I can’t reproduce what I thought was a 5+ second saving by far.. confirmation bias?

Average of 5 tries each, from hitting menu key to rockbox’s menu appearing:
osos contains retailos + rb loader, load rb from disk: 10.3 seconds
osos contains rockbox + rb loader patched as above: 8.9 seconds (1.4 sec improvement)
osos contains just rb loader, load rb from disk: 9 seconds (1.3 sec improvement)

The error bars on this are kinda big, since it’s subject to my reaction times, but it looks like for the ipod video 80gb there’s not really any benefit to this patch over just putting the loader in osos on its own, and it’s under 1.5 seconds in any case (though that’s still a nice improvement!)

I’m told that people have previously observed much bigger speedups by putting the loader in osos on its own, but that may be different models? I’d be interested to hear anyone’s timing results for these three cases, on any model…

torne commented on 2008-12-31 00:22

OK, timed again by having the bootloader print the USEC_TIMER just before jumping to rockbox, and it varies much less: retailos+loader loading rockbox from disk takes 6.1s, loader on its own loading rockbox from disk takes 4.3s, rockbox+my loader takes 4.0s.

Here are my results, timed from centre button press to when the Rockbox logo appears. I used r19614 on my 5th generation 30 gig iPod
retailos + unpatched bootloader: 6.76
just unpatched bootloader: 5.22
just rockbox: 4.40
rockbox + patched bootloader, rockbox.ipod deleted: 4.28

I was surprised by how rockbox seemed to load faster with the bootloader added to it so I took more samples. It seems like it could be due to variability, due to my reaction time or whatever.

torne commented on 2008-12-31 12:50

You could try with this patch also: the bootloader will print out microseconds-since-poweron, then pause for ten seconds, just before jumping to rockbox. This is how I timed it more accurately :)

torne commented on 2009-01-07 21:11

OK, I’ve done yet more timing on this (using the hardware timer) and the results are repeatable and with more detail it’s clearer what’s going on.

I hacked my bootloader to record the usec timer at four points: entry to the bootloader’s main(), just before initialising the disk controller, just after all disk init, and just before returning having loaded an image. There is still some variance in the results, but the variance is consistent across all the times: i.e. it’s a variance in how long it takes to get to main() which is probably the apple rom’s fault.
The results are here:

It is faster to boot with my patch than by just placing the bootloader in OSOS, by 0.8 seconds. This is because the bootloader takes about 900ms to actually load the rockbox image (time elapsed between disk init being over, and returning), which takes no time at all with my patch. The apple rom obviously takes the hit instead, as it has to load a larger OSOS image, but it only delays transferring control to the bootloader by 50ms or so: it’s pretty efficient at loading. Probably a mixture of it not having to deal with FAT or fragmentation, the fact that it’s got to load an image *anyway* and thus it already has to do the seeking and setup, and possibly it’s just got better disk IO code :)

I’ve not timed just putting rockbox in OSOS on its own without the bootloader because, well, I’d have to hack that in in a different place. I can’t see any reason why it should be slower than with the bootloader, I expect dreamlayers’ results are just less precise timing. I’d expect it to be about 200ms faster (from the timings i have of the bootloader), in exchange for sacrificing the ability to boot the retail OS at all.

So, I think this patch could go in: it doesn’t change any existing behaviour and it makes the bootloader, er, ‘symmetrical’ :) Actually documenting/supporting this booting method might be better avoided though; it’s quite safe thanks to the emergency disk mode but it’s more fiddly than the normal way.

torne commented on 2009-01-08 16:38

Oh, before I forget, here’s the patch I used to do the timings in the previous comment. It prints in milliseconds as I figured that was accurate enough :)

torne commented on 2009-05-05 00:17

OK, I’ve just realised there is no actual summary of the results here, just a link to a vague and inadequately labelled spreadsheet :)

My ipod has been running a build set up in this way since I wrote the patch and there’ve been no problems, just for reference.

The actual conclusion:
1) Having the Apple OS and Rockbox loader in OSOS (the standard install method) took 6.3s to boot
2) Having just the Rockbox loader in OSOS (as linuxstb suggested) took 4.9s to boot, 1.4s faster
3) Having this patch, then Rockbox and the loader in OSOS took 4.1s, 2.2s faster than the standard method (so, 0.8s faster than loader-only)

So, this patch should be worth it - there is no impact on the actual Rockbox image size (as it only replaces the contents of several padding bytes) and it still loads rockbox from .rockbox/rockbox.ipod on disk if it exists (so upgrades won’t mysteriously cease working if someone forgets they are using this). There’s a tiny binary size increase for the few extra lines in the bootloader.

Anyone got opinions on if this is commitable?

torne commented on 2009-05-07 16:06

Here’s an updated patch: the code is identical, but it now adds a substantial comment to ipod.c describing the boot behaviour in detail, as the number of options has increased somewhat :)

I’m not sure whether the manual should be updated as well to describe this more advanced installation method - it does save measurable time on boot, but is fiddlier for most users who will normally just install the bootloader once from rbutil and then never touch OSOS again. The ROM’s emergency disk mode does mean that it’s technically impossible to brick the ipod this way, but if the user forgets to back up the Apple OS before overwriting it with rockbox they will be forced to restore using iTunes which is something of an inconvenience :)


Available keyboard shortcuts


Task Details

Task Editing