Note: You can propose changes using the forum below.
Develop a hibernate-mode for the Open Pandora, similar to the current suspend-mode. These requirements can be fulfilled by either writing a complete hibernate solution for the Pandora or writing a wrapper around one of the many existing hibernation options (uswsusp, tuxonice, pm-hibernate and HAL, etc.). The second (wrapper) option is preferred. Deliverable requirements for the hibernator or wrapper follow:
1. A Batch 1 or 2 OpenPandora unit will be able to successfully hibernate and return from hibernation by running a single command, such as:
2. The hibernation program will write a RAM image to disk before turning off.
A. Unless overridden by program arguments, the program will intelligently pick the device to write to, preferring disks in the following order (picking the first with enough space to write the RAM image, which will be 256MB or less):
a. The SD Card in slot 1 (the left-side slot).
b. The SD Card in slot 2 (the right-side slot).
c. The NAND itself (only if no inserted SD cards have sufficient space to write the RAM image).
B. If none of the above options have sufficient space to write the RAM image, the program will error out and notify the user that an error occurred: that no writable device had sufficient space to store the RAM image. The system will attempt to suspend, unless overridden by program arguments.
C. If the kernel changes between hibernate and resume, the program will not allow the system to resume and will instead boot as if no RAM image existed.
3. The hibernation program will accept arguments, including, but not limited to:
--write-to (device) / -w (device): The device to write to (including the 3 devices mentioned in point 2, also possibly including attached USB drives).
--suspend-on-fail / -s: The program will suspend the OpenPandora unit if the hibernation process failed. Exclusive with "-c".
--cancel-on-fail / -c: The program will return the user to their system, the way it was, before they attempted to hibernate. Exclusive with "-s".
A. If the program is a wrapper around another hibernation system and that system already has its own arguments for these options, those will be preferred.
4. In case of a conflict between two exclusive options, the program will error out and not attempt to hibernate the system.
Creating a hybrid suspend-hibernate mode is not necessary to collect this bounty. Such a hybrid mode would be considered one or more of the following:
1. The system suspends until a specified amount of time has passed, when it then hibernates and turns off. The system would be in either suspend or hibernate mode, not both.
2. The system writes a RAM image to disk, as specified above, and then suspends, immediately after hibernating, remaining in suspended mode until awoken or the system runs out of power to continue the suspension. The system would be both suspended and hibernated; if the system resumes before battery power is lost, the system resumes from suspend; if the system loses power before resuming, the system wakes from hibernation.
3. The generalization of these two ideas is as follows: The system has separate "hibernate" and "shutdown" timers, both of which start from when the system suspends. When the hibernate timer expires, the system will write a RAM image, as specified above. If not specified, the system will never write a RAM image. When the shutdown timer expires, the system will power down. If not specified, the system will remain in suspension indefinitely. If the shutdown timer is less than the hibernation timer, the system will hibernate and shut down when the earliest timer expires.