Bill Richardson bfb16961c7 Samus: Enable manual control of TOUCHSCREEN_RESET_L
The charger task was holding this either on or off in S3, no matter what we
wanted. We really only need to set it at S3->S0 or S3->S5, or when the
lid opens or closes. The rest of the time we should be able to turn it off
and on with gpioset, for testing purposes.

BUG=chrome-os-partner:26502
BRANCH=ToT
TEST=manual

Check the state with

  gpioget TOUCHSCREEN_RESET_L

Open and close the lid, suspend the AP with powerd_dbus_suspend, etc. The
touchscreen should be on when the lid is open and the AP is in either S3 or
S0, off when the lid is closed or the AP is off.

Then

  gpioset TOUCHSCREEN_RESET_L 1
  gpioget TOUCHSCREEN_RESET_L
  gpioset TOUCHSCREEN_RESET_L 0
  gpioget TOUCHSCREEN_RESET_L

The change should persist as long as nothing else changes.

Change-Id: If7b6f809b1b28ae2699d0fbc6c9b2305fc57cbff
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/188869
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2014-03-06 17:51:38 +00:00
2014-02-06 19:27:18 +00:00
2012-05-11 09:11:52 -07:00
2013-12-19 00:12:24 +00:00

In the most general case, the flash layout looks something like this:

  +---------------------+
  | Reserved for EC use |
  +---------------------+

  +---------------------+
  |     Vblock B        |
  +---------------------+
  |  RW firmware B      |
  +---------------------+

  +---------------------+
  |     Vblock A        |
  +---------------------+
  |  RW firmware A      |
  +---------------------+

  +---------------------+
  |       FMAP          |
  +---------------------+
  |   Public root key   |
  +---------------------+
  |  Read-only firmware |
  +---------------------+


BIOS firmware (and kernel) put the vblock info at the start of each image
where it's easy to find. The Blizzard EC expects the firmware vector table
to come first, so we have to put the vblock at the end. This means we have
to know where to look for it, but that's built into the FMAP and the RO
firmware anyway, so that's not an issue.

The RO firmware doesn't need a vblock of course, but it does need some
reserved space for vboot-related things.

Using SHA256/RSA4096, the vblock is 2468 bytes (0x9a4), while the public
root key is 1064 bytes (0x428) and the current FMAP is 644 bytes (0x284). If
we reserve 4K at the top of each FW image, that should give us plenty of
room for vboot-related stuff.
Description
No description provided
Readme 1.4 GiB
Languages
C 64.7%
Lasso 20.7%
ASL 3.6%
JavaScript 3.2%
C# 2.9%
Other 4.6%