• Status Closed
  • Percent Complete
  • Task Type Patches
  • Category Bootloader
  • Assigned To No-one
  • Operating System PortalPlayer-based
  • Severity Low
  • Priority Very Low
  • Reported Version Daily build (which?)
  • Due in Version Undecided
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Rockbox
Opened by barrywardell - 2008-02-25
Last edited by Llorean - 2008-04-23

FS#8642 - Improve boot time on Sansa

Currently PortalPlayer based devices have roughly the following boot sequence:
1) OF bootloader runs and loads RB bootloader
2) RB bootloader runs and loads either Rockbox or OF

Boot time can be decreased considerably by removing step 1) and running the RB bootloader straight away on boot. This can be done (relatively) safely on Sansa since the bootloader is stored in the hidden firmware partition and we have Manufacturer mode in case anything goes wrong.

This can be achieved currently by building a rockbox bootloader and using the sansapatcher command:

sansapatcher -bl boootloader/bootloader.bin

to overwrite the OF BL with the rockbox one. WARNING: running this command with a bad bootloader.bin will require recovery using e200tool and Manufacturer mode.

However, it currently has the drawbacks that:
1) We lose the rescue mode that was in the OF’s bootloader, so if we install a bad Rockbox build/OF we have to resort to e200tool and Manufacturer mode to recover
2) The Sansa starts up by default with the CPU running at 24MHz. The OF BL changes this to 80MHz so that by the time the Rockbox BL runs the CPU is at 80MHz. This makes booting much slower when we don’t use the OF BL, often cancelling out the benefit.

I think problem 1 should disappear once we have full USB support in Rockbox and can add it to the bootloader.

Problem 2 is resolved by the attached patch, which makes the Rockbox bootloader set the CPU frequency to 80MHz when it is starting up. There was a discussion about this on irc today (25/2/08) and an objection to it for safety reasons (running at 80MHz makes the CPU hot, so if for some reason the BL crashes leaving the CPU at 80MHz it could be a problem). I don’t agree with this argument because:
1) The OF BL leaves the CPU at 80MHz, so with the current boot method we are already running the Rockbox BL at 80MHz and there has not been any reported problems.
2) If freezing at 80MHz is a really worry, the we should never run the CPU at that speed, even in Rockbox itself. It seems far more likely to have a freeze while boosted during music playback than during boot.

As motivation, here is a table of boot times using the various boot sequences:

Firmware: OF BL + RB BL (80MHz), RB BL @ 24MHz, RB BL @80MHz

OF: 10.5s, 17.7s, 8.5s
Rockbox: 4.7s, 4.0s, 2.8s

So, after that long explanation, my suggestion is when we get bootloader USB mode, we should switch to a new boot sequence, eliminating the OF bootloader and using the attached patch to speed things up.

Any comments/suggestions?

Closed by  Llorean
2008-04-23 01:51
Reason for closing:  Accepted

If Sansapatcher can dump the OF bootloader, I wouldn't mind the new Rockbox bootloader also featuring a means of restoring the OF bootloader. Kinda like on the Gigabeat, where if you hold down a button while booting, instead of dual booting it rewrites the old bootloader (if you have the right file in the right place). Basically, I think this would be beneficial in the off chance that you are having USB troubles of some sort, and need to get back to the OF's USB code to try it (the other alternative is of course RoLo, I suppose).

One option I have considered which works along these lines is that when we install the new Rockbox bootloader, instead of just overwriting the OF bootloader, we could move it to the end of the Rockbox bootloader. We would then have 3 options on startup:

1) Just boot into Rockbox
2) Hold |« to boot into the OF
3) Load the OF bootloader which would then either offer recovery mode or boot into Rockbox. This could be done for example if hold was on and rec was held while powering on. This would make it easy to get into the OF bootloader's recovery mode.

imo the recovery mode is useless once we have working recovery tools for manufac mode.

Sounds great currently i am having problems with the current build for the Sansa e series so as soon as that is fixed i might try this but once full USB support in worked out i will definitely use this as the boot time is already fast i estimate without loading the OF the RF loads in 3 seconds or so which will make it considerably faster. Although It would be a large improvement after the current issues are fixed it will make the player even better. Thank you for this.

I forgot to add that my timings aren't very scientific. I just used a stopwatch to measure the time from pressing the power button to the rockbox/sandisk logo appearing. They do give a general feel for the potential improvements though.

kfazz commented on 2008-02-26 06:16

just wanted to say that i've been using bootloader.bin instead of sansa bl for a while now, since gevaerts got fullspeed write working i guess, and using it to upload new builds. haven't seens ansa OF in a week, and no problems here.

Am I missing something here? I Frequently have to use the "OF" as when my Sansa is using "RBF" I am unable to load unload files hence my interpretation of not having USB support. Are you saying you never use the OF or just that you rarely do? When I was talking about the problems I had, I was referring to the file skip problem that has since been fixed. Also the charge feature that was implemented at that time locked up my Sansa when I used it, it seams to have been removed when they fixed the skip problem. So as I said before I will certainly install this once the implement Full Working USB, then I will have no need for the "OF" as i really don't like it and as I said i only use it out of necessity to charge and transfer files. I don't exactly understand how this will work as I believe I will still need the "OF" to update rockbox other than that after USB support is added that will be the only reason I will need to use "OF". With my understanding this will just bypass the "OF" boot loader so only using the rockbox boot loader I would still be able to boot into "OF" by pressing the "«" key while loading. Am I correct? As i may try this sooner as if it works like I think it would then there really is no need for the "OF" boot loader. I do not quite understand this yet I suppose as I do not yet see any drawbacks although I believe you said there are 2 which I don't understand because I have never used the rescue mode nor do i know how to. Correct me if I am wrong. This patch removes the "OF" boot loader and updates the "RB" boot loader to raise the processor speed to 80mhz instead of 24mhz. Does the "OF" fun on 24mhz? So the basic concept is to make the boot time 2 seconds instead of the 8-10 it requires to load both boot loaders with the Sansa boot loader taking the longest it is removed?

Sorry for the long comment I think I am the one confusing myself thinking about it too hard.

Any objections to committing this patch? All it does is boost the cpu in the C200 and E200 bootloaders. It won't have any real affect until we start totally replacing the OF's bootloader.

Installed and working nicely on my Sansa. I think you should commit this.

I have a question about booting, USB, and current draw.

My apologies if I am asking in the wrong place.

Does the RB bootloader know whether or not the USB cable is plugged in? I suspect that part of the reason that the e200 is fussy about which USB ports it will talk to is that it draws more current then it is supposed to before negotiation with the host.

I am assuming that neither the OF BL nor the RB BL does any power negotiations, and that the processors draw significantly more power at 80 MHz than at 24 MHz.

Could the RB BL be made to boot at 80 MHz when booted without the cable connected but at only 24 MHz when the cable is connected?

A second best solution would be to have RB write a file called "USB_cable_detected" when a USB cable is detected, and remove the file when a normal shutdown is performed. The RB BL could then set the CPU speed depending on the presence or absence of that file.

On the other hand, I could be completely wrong. ;-)

Here are some current measurements that I made;

The thing is that the OF BL leaves the cpu running at 80MHz when it's finished anyway, so I don't see how that could be the cause the increased current draw when the RB BL starts.

Yes you are obviously right, if the OF BL leaves the cpus at maximum current drain the RB BL can not make that any worse. But that isn't exactly what I want to know about.

Something causes some e200s to misbehave with some USB ports even before RB is installed.

I was wondering if it is possible to make an e200 with RB more reliable and maybe standards compliant than a new e200 is out of the box.

My motherboard claims to be USB 2.0 compliant, but I can't find any such claim about the e200 by SanDisk.

CPU frequency is not causing the current drain to increase when the OF BL hands over to the RB BL, something else is (battery charging? display? <insert wild guess here>). I was wondering if it is sensible to compensate for whatever is increasing the current by decreasing the cpu frequency.

Sorry if I am just wasting your time here, I'm a bit ignorant about what is going on.

Should the sansapatcher overwrite work from Windows?

I'm using sansapatcher v6 Windows binary from the Rockbox website. It runs, detects and re-writes the bootloader correctly as per 'normal' operation, but the -bl switch seems to cause a failure:

Below is the output from the command:
M:\Rockbox>sansapatcher -bl bootloader.bin
where bootloader.bin is in the same directory as sansapatcher, but I get the same error with:
M:\Rockbox>sansapatcher -bl M:\Rockbox\bootloader.bin

[INFO] Scanning disk devices… [INFO] e200 found - disk device 6
[INFO] Part Start Sector End Sector Size (MB) Type
[INFO] 0 600 15667199 7649.7 W95 FAT32 (0x0b)
[INFO] 1 15667200 15708159 20.0 OS/2 hidden C: drive (0x84)
[WARN] PPBL installation will overwrite your bootloader. This will lead to a

     Sansa that won't boot if the bootloader file is invalid. Only continue if
     you're sure you know what you're doing.
     Continue (y/n)?  y
   Error writing to disk: The parameter is incorrect.

[ERR] Short write in sansa_update_ppbl
[ERR] –update-ppbl failed.

It should but I don't think it does, so I had to use a linux machine.


Available keyboard shortcuts


Task Details

Task Editing