This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#8642 - Improve boot time on Sansa
Attached to Project:
Rockbox
Opened by Barry Wardell (barrywardell) - Monday, 25 February 2008, 14:01 GMT+1
Last edited by Paul Louden (Llorean) - Wednesday, 23 April 2008, 03:51 GMT+1
Opened by Barry Wardell (barrywardell) - Monday, 25 February 2008, 14:01 GMT+1
Last edited by Paul Louden (Llorean) - Wednesday, 23 April 2008, 03:51 GMT+1
|
DetailsCurrently 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? 
bootloader_boost.patch
(1 KiB)
firmware/target/arm/system-pp502x.c | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) |
This task depends upon
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.
Sorry for the long comment I think I am the one confusing myself thinking about it too hard.
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;
http://forums.rockbox.org/index.php?topic=16263.0
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.
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.