Ticket #60 (closed enhancement: duplicate)

Opened 8 years ago

Last modified 6 years ago

Suspend/Resume from RAM

Reported by: wmb@… Owned by: jg
Priority: blocker Milestone: 8.2.0 (was Update.2)
Component: kernel Version:
Keywords: power Cc: gregorio
Action Needed: never set Verified: no
Deployments affected: Blocked By:
Blocking:

Description (last modified by jg) (diff)

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.

Attachments

wakeup.patch (0.9 kB) - added by wmb@… 8 years ago.
Patch to enter Linux quickly after wakeup from suspend-to-RAM

Change History

Changed 8 years ago by krstic

  • cc jg@… removed
  • priority changed from normal to high
  • description modified (diff)
  • milestone set to rev1 final

Changed 8 years ago by hai

Do we need VSA support for that?

Changed 8 years ago by wmb@…

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

Changed 8 years ago by cjb

  • milestone changed from FRS to BTest-1

Changed 8 years ago by cjb

  • description modified (diff)

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.

Changed 8 years ago by wmb@…

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

Changed 8 years ago by wmb@…

  • status changed from new to assigned

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

Changed 8 years ago by 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.

Changed 7 years ago by dwmw2

  • cc dwmw2@… added

Changed 7 years ago by jg

  • milestone changed from BTest-1 to BTest-2

Changed 7 years ago by jg

  • milestone changed from BTest-2 to BTest-3

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!

Changed 7 years ago by jg

  • keywords power added
  • verified unset

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

Changed 7 years ago by wmb@…

  • owner changed from wmb@… to jg
  • status changed from assigned to new
  • verified unset

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.

Changed 7 years ago by jg

  • priority changed from high to blocker

Changed 7 years ago by jg

  • milestone changed from BTest-4 to Trial-2

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

Changed 7 years ago by 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.

Changed 7 years ago by jg

  • description modified (diff)

Changed 7 years ago by jg

  • description modified (diff)

Changed 7 years ago by jg

  • cc dwmw2@… removed
  • milestone changed from Trial-2 to Trial-3

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

Changed 7 years ago by jg

  • description modified (diff)

Changed 7 years ago by jg

  • description modified (diff)
  • summary changed from Resume from RAM to Suspend/Resume from RAM

Changed 7 years ago by jg

  • description modified (diff)

Changed 7 years ago by jg

  • description modified (diff)

Changed 7 years ago by jg

  • milestone changed from Trial-3 to First Deployment, V1.0

Changed 6 years ago by coderanger

  • blockedby 2237 added

Changed 6 years ago by gregorio

  • cc gregorio added
  • next_action set to never set

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

Changed 6 years ago by wmb@…

  • blockedby 2237 removed

(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.

Changed 6 years ago by wmb@…

  • status changed from new to closed
  • resolution set to duplicate

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.

Note: See TracTickets for help on using tickets.