Rockbox

  • Status Closed
  • Percent Complete
    100%
  • Task Type Patches
  • Category Bootloader
  • Assigned To No-one
  • Operating System Gigabeat F/X
  • Severity Low
  • Priority Very Low
  • Reported Version
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Rockbox
Opened by shoora - 2007-05-05
Last edited by BigBambi - 2010-06-05

FS#7113 - Gigabeat F really fast restart (resume)

This patch enables fast resume from sleep mode.
Currently Rockbox just put Gigabeat to sleep. But firmware uses permanent GSTATUS3 register for return address. On coldstart this register set to linux loader in firmware. This address is 0×10300.
Good thing is - stack is set to boot RAM, so all content of RAM is untouched. There is only only one problem - at this point none of hardware (including MMU) is initialized. So I had to put some additional initialization which is normally done by linux loader.
Instead of full implementation of ‘suspend’ function I just made shortcut directly to to gigabeat RTL initialization (0×30000100) bypassing linux loader and Rockbox bootloader. This saves a few seconds.
We can continue work on this implement instant resume! Then you may consider this as proof of concept.

Closed by  BigBambi
2010-06-05 23:21
Reason for closing:  Rejected

I just tested this on my gigabeat… seems to work nicely. But the backlight is set to minimum brightness at first and comes completely on only once the menu is shown. Is this normal ?

This is how it works on my device.
I have some problems dealing with LED driver. May be somebody Markun will help us?

Needs a resync for today's commit dealing with the buttonlights. I'm looking forward to testing this out.

At last hey fixed this build. I need to look again. May be I can remove some steps. But, at least, this patch work for me.

Just as a note: When you switch back to an SVN build, you should probably do a real power cycle (unplug, turn off the battery, wait, turn it back on), as there are apparently some quirkinesses with switching back to an SVN build after using this (I haven't tried it yet, personally).

We can add Reset item in Debug menu.

Alex,

I like this patch and I would be interested in committing this, but there are a couple of bugs that need to be worked out.

First we need to get rolo working before this patch is committed. Development a pain if work is being done on the core and we can't update the code without power cycling.

Second, I get strange problems with the hard drive after using this patch for about a day where the drive takes forever to spin down on startup and consequently takes a while to turn off.

I don't think that you need the modifications to the backlight-meg-fx.c file anymore with my latest commit. I have been trying to make this patch work smoother in the process of fixing the various button/backlight bugs in the code. I didn't check with my last few changes before commit, but I will look later today hopefully.

Finally, we should flip these bits in a more appropriate section if they are necessary: GPGDAT = (GPGDAT & ~(1 « 12)) | (1 « 11); I will check into those bits as well though, we currently don't know where GPG12 connects (I suspect it enables/disables usb charging), GPG11 should be initialized (GPGCON, GPGUP) in power-meg-fx under the ide_power_enable section (and this may fix the ide spinning problems). Specifically gpg11 enables/disables the 3.3 volt line to the hard drive.

Also, what is the purpose of the changes to thread.c?

Here's a sync against the latest SVN. I pulled out the bit flipping of GPG11 and 12 as well as the changes to thread.c. I have not been getting the long spin times since the commit I did on the IDE power initialization, but I don't know if the problem is gone.

I can predict one problem with this patch. In C language, initialization of variables done by linker. So, on next start some initialized global variable may have unexpected values. I have some other tasks to do. After that I will try to complete sleep function for Gigabeat.
We don't need to patch new backlight-meg-fx.c.

I needed change in thread.c to compile it with ARM-GCC 4.1.1.

Just a suggestion, but it would be nice to have an entry in the debug menu to reset this value. I use a bootloader that loads another build at the press of a button, and I need to power cycle for it to use the rockbox bootloader, resetting the RTC.

1. Some code optimizations.
2. Debug menu item "Restart" for cold restart.
3. Simple implementation of rolo_load. Now after question "Reboot now?" system will actually reboot.

I've tried this version on my gigabeat and I've noticed a slow shutdown and also some suspicious disk accesses and slowness in the main menu. I'm going back to the SVN version for now but I'll be happy to test any improvement :)

I've committed the LCD initialization portion of this patch. Rolo can still be fixed so that it actually loads up the new rockbox version. If we copy the reset code to the 4K of IRAM (thanks markun) and run from there rolo should work properly. As a note: I am working on making the bootloader run from flash, so if that goes well we can add this fast start functionality to the rockbox bootloader. Hopefully eventually we will be able to do a full resume of the player without having to restart rockbox.

Hi Alex, I just tried your resume patch and it works really great.

I changed the tabs into spaces, removed the LCD init code and moved your gcc fix and fake rolo to seperate files.

jac0b commented on 2007-08-30 00:56

The GCC fix was giving hunk errors so instead of fixing just that file I resynced all the files.

jac0b commented on 2007-09-22 20:36

Resynced resume patch file

jac0b commented on 2007-10-01 20:44

The gcc patch is giving hunk errors, I tried to find the problem but there must have been some code changes in thread.c and I can't find where it should go.

jac0b commented on 2007-10-24 19:40

I think I found where and when the change happened that cause the GCC patch to fail.

http://svn.rockbox.org/viewvc.cgi/trunk/firmware/thread.c?r1=14878&r2=14879

It looks like the above change removed the lines (line 100) that the GCC patch was replacing.
Then added this in its place

static inline void store_context(void* addr)

if I knew how to program I would fix the patch but I don't :( (but I am getting a book on C)
Can someone look into this?

jac0b commented on 2008-01-17 11:54

Is there anyone who could look into this one?

jac0b commented on 2008-02-15 02:27

I tried to get this patch working again but now when I power on the player the bootloader progress bar goes half stays there. If anyone wants to help out and take a look I the files.

Please keep this project going… booting as fast as this let us is reason enough to stick with an older build.

I'm pretty sure this patch is dead, but some devs are using parts of it to develop a full bootloader that goes into flash. Just give it some time, it's not that much faster than the OF bootloader and stripped OF files.

jac0b commented on 2008-02-26 22:45

I think it is faster than OF or stripped OF, but I can't be for sure because I lost the build that I had with this patch.

I do not think any developers will be maintaining this patch. It leaves the player in an unknown state due to the way the data sections are handled. This patch effectively reboots rockbox, but leaves the initialized values at their state prior to rebooting. Since there may be a number of unforeseen consequences to doing this I would not typically recommend that this patch be run by users. If anyone would like to stay with an older build that is fine - no one is forcing an upgrade. To do this patch properly a number of rockbox's subsystems need to be modified to handle a suspend state. To my knowledge no one is actively working on this.

There are plans to completely replace the toshiba firmware in flash as Oleh mentioned - this does speed up the startup of rockbox by a few seconds and also gives way to adding some other features. Currently, flash replacement is being tested and bugs are being ironed out, but do not expect a user release anytime soon due to the real possibility of bricking your gigabeat with no method to recover without some special equipment (see GigabeatJTAG in wiki).

It is somewhat faster, but also much more buggy. I've experienced side button light issues, the player refusing to turn on, refusing to turn off, there's probably more but I can't remember anything else.

Should someone close this? Karl's flashwriter plugin works and gives much faster boot time when loading the Rockbox bootloader from flash.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing