delta/coreboot/vboot.git, branch stabilize-5500.26.B

set_gbb_flags: Aborts only if HW & SW WP are both enabled.

2014-02-14T15:29:59+00:00

Early proto devices (for testers and developers) may have hardware write
protection enabled and software disabled. They can still flash SPI ROM  in that
case, and no need to disable hardware WP switch.

BRANCH=none
BUG=chromium:341242
TEST=./set_gbb_flags.sh 0x39 # see WP messages.

Change-Id: Id320410795a162a009b80360c2225c7510337591
Reviewed-on: https://chromium-review.googlesource.com/186336
Tested-by: Hung-Te Lin 
Reviewed-by: Shawn Nematbakhsh 
Commit-Queue: Hung-Te Lin 
Reviewed-by: Randall Spangler

set_gbb_flags: Check write protection status before starting to flash.

2014-02-11T05:40:14+00:00

People trying to override GBB flags and not having write protection disabled may
corrupt whole RW section of firmware.

To avoid that, we should check write protection before starting to invoke
flashrom commands.

BUG=chromium:341242
TEST=./set_gbb_flags.sh 0x39 # Aborted on a write-protected system, as expected.
BRANCH=none

Change-Id: I6b2dcc75b87dc5ceace0d7caec62ded787b2b534
Signed-off-by: Hung-Te Lin 
Reviewed-on: https://chromium-review.googlesource.com/185653
Reviewed-by: Randall Spangler 
Commit-Queue: Hung-Te Lin

Fix jumping EC from RO to RW if disable-jump was called on previous boot

2014-02-11T05:30:34+00:00

It's possible for the AP to get updated and remove the RO-normal flag
without needing to update EC-RW firmware - for example, if it only
needs to update the BIOS.  In this case, the EC doesn't need update,
but does need to jump to its RW firmware.  But if the EC is already
booted RO-normal with jump disabled, it will refuse that request and
go to recovery mode.

The fix is simply to check if the request to jump to RW requires the
EC to cold-boot first, and pass through that error code to the caller.

BUG=chrome-os-partner:22617
BRANCH=none (affects all platforms, but only in this odd case, and this
       is a change to the RW portion of the code)
TEST=pass new unit test which triggers this condition

Change-Id: Ia8d64dff784a9135ef23f6eb26bbca4ad9df57c3
Signed-off-by: Randall Spangler 
Reviewed-on: https://chromium-review.googlesource.com/170168
Reviewed-by: Vadim Bendebury

tegra124: Add the tegra124 compatibility string to crossystem.

2014-01-29T11:07:31+00:00

Teach crossystem the tegra124 compatibility string so that it can identify the
platform for tegra124 based systems.

I called the platform Tegra5 to fit in with what seems to be the naming scheme
for the other Tegra SOCs.

BUG=chrome-os-partner:25355
TEST=Built and ran on nyan and saw the "platform_family" setting return Tegra5
instead of (error).
BRANCH=None

Change-Id: I1044f958ecdac37ad285fdc3d53e7bc36ca69315
Signed-off-by: Gabe Black 
Reviewed-on: https://chromium-review.googlesource.com/184051
Reviewed-by: Hung-Te Lin 
Reviewed-by: Randall Spangler 
Tested-by: Gabe Black 
Commit-Queue: Gabe Black

vboot: use recovery button as dev mode switch confirmation

2014-01-19T04:14:59+00:00

We don't allow ENTER from a USB keyboard as the confirmation
in the switch from normal to developer mode.

For devices that have a physical recovery button, we require
a recovery button press instead.  For other devices, we
require that ENTER be pressed on the internal keyboard.

This prevents an "evil keyboard" attack in which a USB keyboard
(or other USB device pretending to be a keyboard) sends a
control-D/ENTER sequence shortly after every boot (followed
by more evil keys).  In that situation, when users power-on in
recovery mode, they will be forced to dev mode even if it
was not their intention.  Further attacks are easy at
that point.

TESTING.  On a panther device:

1. powered on with recovery button pressed -> booted in recovery mode
2. pressed control-D on external USB keyboard -> got to ToDev? screen
3. pressed ENTER -> system beeped
4. pressed recovery button -> system rebooted in DEV mode

... all as expected

Also:

1. powered on with recovery button pressed and HELD recovery button
2. pressed control-D -> system beeped

BUG=chrome-os-partner:21729
TEST=manual (see commit message)
BRANCH=none
CQ-DEPEND=CL:182420,CL:182946,CL:182357

Change-Id: Ib986d00d4567c2d447f8bbff0e5ccfec94596aa7
Reviewed-on: https://chromium-review.googlesource.com/182241
Reviewed-by: Luigi Semenzato 
Tested-by: Luigi Semenzato 
Commit-Queue: Luigi Semenzato

x86: Stop building the vboot library using regparm=3.

2014-01-10T03:20:25+00:00

This complicates things in a number of ways, including making GDB not work
properly because it assumes the standard ABI in some places. Measurements
show that it doesn't really make much difference performance wise.

BUG=None
TEST=Built and booted with coreboot and depthcharge on link.
BRANCH=None

Change-Id: I7f004f8cf83b7c1a78ab12f814477504a5a5c28c
Signed-off-by: Gabe Black 
Reviewed-on: https://chromium-review.googlesource.com/180874
Reviewed-by: Randall Spangler 
Reviewed-by: Stefan Reinauer 
Tested-by: Gabe Black 
Commit-Queue: Gabe Black

VbBootRecovery: Make second check for 'remove' devices if none found

2013-12-16T22:57:58+00:00

There is some inherent latency between the time the USB root hub is
initialized and the time USB devices are detected. This can lead to a
situation where USB media is attached, yet not found when we do our
initial device poll. The device may be detected in subsequent polls, so
the media can be booted and no 'remove' screen will be displayed.

With this change, if no media to remove is initially found, a second
poll will be made after a 500ms delay. This will be enough time for USB
devices to be correctly detected in our test cases.

Also, it is necessary to change the unit test due to the fact that we
now call VbExDiskGetInfo twice before actually displaying any screen.

TEST=Manual on Monroe. Insert USB media and trigger recovery boot.
Verify 'remove' screen is seen, 'insert' screen is seen after removing
media, and system boots after re-inserting media. Also passes
vboot_reference unit tests.
BUG=chrome-os-partner:23840
BRANCH=Panther, Monroe

Signed-off-by: Shawn Nematbakhsh 
Change-Id: Ia902c3a126588cd7ea618f2dbbca6b38d35d6ea0
Reviewed-on: https://chromium-review.googlesource.com/179757
Reviewed-by: Randall Spangler

crossystem: handle BayTrail gpios

2013-12-11T19:50:39+00:00

BayTrail systems have 3 banks of gpios. Therefore,
the Linux kernel exposes these 3 banks as 3 gpiochip
entries. The kernel driver expects the 3 banks to be
exposed with specific UIDs associated with a specific
banks. ChromeOS firmware maps gpios within a given
bank using the bank's MMIO offset. In summary:

Bank Type | UID | Offset
----------+-----+-------
 SCORE    |  1  | 0x0000
 NCORE    |  2  | 0x1000
 SUS      |  3  | 0x2000

BUG=chrome-os-partner:24408
BUG=chrome-os-partner:24324
BRANCH=None
TEST=Built. 'crossystem wpsw_cur' works correctly.

Change-Id: I251f86285ce9733f7ca90ed1ebef536f4fe5c07c
Signed-off-by: Aaron Durbin 
Reviewed-on: https://chromium-review.googlesource.com/179513
Reviewed-by: Duncan Laurie

crossystem: add GpioChipset sturcture for x86

2013-12-11T19:50:35+00:00

Up until recently the x86 systems had a single contiguous
set of gpio numbers exported through /sys/class/gpio
as /sys/class/gpiochip values. BayTrail systems have
3 sets of gpio numbers. Therefore, there needs to be a
translation/look-up function based on chipset. The existing
chipsets have a 1:1 mapping, but this patch lays the ground-
work for chipset-specific translation.

BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BUG=chrome-os-partner:24408
BRANCH=None
TEST=Built. Ran on Rambi.

Change-Id: I32bcd975aea421f86a0220ee30332f48fe727656
Signed-off-by: Aaron Durbin 
Reviewed-on: https://chromium-review.googlesource.com/179512
Reviewed-by: Duncan Laurie

crossystem: make BayTrail a valid platform_family

2013-12-11T19:50:31+00:00

BayTrail is a valid chromeos platform. Therefore, allow
it to be returned for 'platform_family'.

BUG=chrome-os-partner:24324
BUG=chrome-os-partner:24440
BRANCH=None
TEST=Built. 'crossystem platform_family' reports 'BayTrail'.

Change-Id: I8d0b835f5f40e7f34adb4f91bd974c428bbaf6da
Signed-off-by: Aaron Durbin 
Reviewed-on: https://chromium-review.googlesource.com/179511
Reviewed-by: Duncan Laurie