Suspend/Resume from RAM

[wmb@…]

David Woodhouse: Do we also have some attempt at a resume-from-RAM path?

Jim Gettys: Not yet; Mitch will work on this right after Cafe' bringup.

#31, #60, #2237, #1339, #1420, #1555, #1687, #1710, #1730, #1733, #1735, #1745, #1752, #1755, #2353, #2401, #2426, #2488, #2621, #2660 #2679.

This is now a tracker bug to keep track of suspend/resume related bugs.

[hai]

Do we need VSA support for that?

[wmb@…]

We hope we won't need additional VSA support - but we will find out...

[cjb]

Resolving this bug involves having enough resume code in LinuxBIOS for us to be able to start on driver suspend/resume testing; that testing isn't needed by BTest-1, though.

[wmb@…]

Patch to enter Linux quickly after wakeup from suspend-to-RAM

[wmb@…]

The wakeup.patch attachment shows a proposed change to the LinuxBIOS startup that will reenter Linux after a wakeup. It compiles, but is otherwise untested; I'm posting it early in case someone wants to get started early while I'm in Taiwan.

Notes: a) This is probably not the right place to put the code. It should be in a separate file that is included in auto.inc . If someone could show me how to do it that way, I'd appreciate it.

b) For fast wakeup, you need to eliminate early startup messages. The first step is to dial down the loglevel - see *_LOGLEVEL in targets/olpc/rev_a/config.*.lb . 3 seems to be a good choice to eliminate the early messages.

c) The other message that needs to be removed is print_err("done cpuRegInit\n"); in src/mainboard/olpc/rev_a/auto.c

[wmb@…]

What Linux needs to do to use the wakeup-via-LinuxBIOS patch:

During the suspend-to-RAM sequence, Linux should:

* Save any important data at locations 0 and 4 * Write the wakeup entry point address to location 4 (long) * Write 0x51ee4129 to location 0.

When LinuxBIOS comes out of reset upon waking up, it will turn on the memory controller and check for that signature at location 0. Upon seeing it, LinuxBIOS will jump to the address that is stored at location 4. LinuxBIOS doesn't set any of the other registers to specific values. The only guarantee is that the system is in 32-bit protected mode with 4GB identity-mapped code and data segments.

[jg]

We think B3 is a good target for real working resume... So putting this on its realistic milestone. Feel free to delight us, of course!

[jg]

Resume is working on GX, but we still have LX problems.

[wmb@…]

The firmware aspect of this problem is mostly under control; most of the work now is OS-related. Several individual OS engineers are involved, so it appears that the overall responsibility for this omnibus task is in the management domain. Therefore I am reassigning it back to management.

[jg]

SD resume will come in after BTest-4 with the update to Master.

[kimquirk]

Need SCI's on keyboard, SD to work properly, wireless firmware fixes on resume, and so on, still. This should all happen by Trial-2, it says here.

[jg]

As a collector bug, this has items that we're not doing until after Trial-2. So I'm moving it out.

[gregorio]

Is this really a blocker for 8.2.0?

If so, can we get a design proposal and lead customer ASAP?

If not please reset the target release and add it to the 9.1.0 tracking page at: <br> http://wiki.laptop.org/go/9.1.0#Priorities_from_Engineering

[wmb@…]

(In #2237) Removed the "Blocking" reference to ticket 60, which I am about to close because it's a collector ticket for only two bugs; we no longer need the collection function.

[wmb@…]

I'm closing this because it's only purpose now is as a collection point for two other bugs. At this point it is pointless.