delta/coreboot/chrome-ec.git, branch release-R36-5841.B

ec_uartd: bugfix for buffer pointer on partial write to FD.

2014-05-09T22:04:12+00:00

Previously I neglected to increment the buffer pointer which would
allow double writing of same data and exclude tail if write didn't
complete in one call.

Also fixing bug with EAGAIN/EWOULDBLOCK to retry in those cases.
Previously we'd just have just failed for those errno values.

Signed-off-by: Todd Broch 

BRANCH=none
BUG=chromium:371147
TEST=still compiles

Change-Id: I30dbe56b2a4c735c487464349786a9db430130a8
Reviewed-on: https://chromium-review.googlesource.com/199052
Reviewed-by: Vincent Palatin 
Commit-Queue: Todd Broch 
Tested-by: Todd Broch

tegra: don't set auto_power_on if SYSJUMP

2014-05-09T08:26:22+00:00

The auto_power_on is set 1 unexpectedly while EC jumps. This has a
side effect that would turn on the AP unexpectedly after "power off".
See comment 43 of issue 28249

BUG=chrome-os-partner:28249
BRANCH=tot,nyan
TEST=on nyan:
> reboot
> sysinfo
// If EC is in RO, "sysjump RW"
> power off
// The AP keeps off.

Change-Id: I3c06e99383c06af7cd6c17dd65040e20f06d8e73
Signed-off-by: Louis Yung-Chieh Lo 
Reviewed-on: https://chromium-review.googlesource.com/198941

tegra: waits for battery stable before booting AP.

2014-05-09T08:26:13+00:00

This is a follow-up for CL 197990 and 197991. See issue tracker for
more details.

BUG=chrome-os-partner:28289
BRANCH=tot,nyan
TEST=Copy from https://chromium-review.googlesource.com/#/c/197990
Going battery shipmode and plug-in AC, See booting and expect EC log:
    "[... battery initialized]"
Disconnect battery, and plug-in and see booting and expect EC log:
    "[... battery not responding]"

Change-Id: Ic218414c21057a971b478ec60e406f1eb69dd379
Signed-off-by: Louis Yung-Chieh Lo 
Reviewed-on: https://chromium-review.googlesource.com/198412

tegra: reorder the "AP running" and "XPSHOLD seen".

2014-05-09T04:45:41+00:00

FAFT expects the "AP running" shows first, then "XPSHOLD seen".

BUG=chrome-os-partner:28316
BRANCH=tot,nyan
TEST=build only

Change-Id: Ic3e9d68b7727d62d3ccc2c037e7547f0276c2eae
Signed-off-by: Louis Yung-Chieh Lo 
Reviewed-on: https://chromium-review.googlesource.com/198766
Reviewed-by: David Hendricks

tegra: fixed a corner case that AP_OFF flag is not cleared.

2014-05-09T04:45:19+00:00

If we follow the TEST steps below, the power state machine in AP
and EC were out of sync -- due to the un-clear bit and wrong
initial power state.

BUG=chrome-os-partner:24835
BRANCH=tot,nyan
TEST=on big.
> reboot
> power off      // De-assert XPSHOLD
> reboot ap-off
> sysinfo        // This reset flags does NOT contain "ap-off".

> power on
% ectool reboot_ec RW // The following message is NOT observed.
                      // "system is on, but RESET_FLAG_AP_OFF is on".
> power               // This should show the AP is "on".

// ensure everything still works.
> reboot ap-off      // AP keeps off.
> reboot             // AP is on.

Change-Id: I51afed7201d16ebcd889ad12a7af90026591cc2d
Signed-off-by: Louis Yung-Chieh Lo 
Reviewed-on: https://chromium-review.googlesource.com/198587
Reviewed-by: David Hendricks

stm32: Re-enable spi transfers after a sysjump

2014-05-09T04:41:58+00:00

If we sysjump to EC-RW, that sets enabled=0.  enabled is only set back
to 1 when the chipset resumes.  But on an AP-requested sysjump, the
chipset is already on, and so the resume hook never gets called.

So, in spi init, check if the AP is already on.  If it is, enable spi
transfers right away.

This probably also affects Pit/Pi.  That may need an additional fix in
power/gaia.c, if it returns an incorrect chipset state after a sysjump
(I didn't test that.)

BUG=chrome-os-partner:28249
BRANCH=nyan,pit
TEST=Power+Refresh boot system with RONormal disabled, so that the AP
     tells the EC to jump to EC-RW.  Confirm EC communication still works
     after that.

Change-Id: I588ef6d841040cf05d5527f645f122d5708b16ad
Signed-off-by: Randall Spangler 
Reviewed-on: https://chromium-review.googlesource.com/198869
Reviewed-by: Yung-chieh Lo 
Reviewed-by: David Hendricks 
Commit-Queue: Yung-chieh Lo 
Tested-by: Yung-chieh Lo 
Tested-by: Gabe Black

tegra: fix bug that apshutdown cannot shut down the AP.

2014-05-09T02:49:44+00:00

The power_request variable is not clear in apshutdown case. Thus,
the AP comes up again by the "power up" request. Clear this variable
only when apshutdown command to avoid affecting the regular power
states.

BUG=chrome-os-partner:28621
BRANCH=tot,nyan
TEST=see below
> reboot  // or other methods to turn on the AP.
> power on
> apshutdown
// The AP should remain off.

Change-Id: Icfc8a50db95aba656168f5b10dabd9443d75338d
Signed-off-by: Louis Yung-Chieh Lo 
Reviewed-on: https://chromium-review.googlesource.com/198770
Reviewed-by: David Hendricks

Wait for battery boot-up

2014-05-08T08:35:41+00:00

Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.

BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log

Change-Id: I9b62266132d5322366265afe03adbe0db1f9ae75
Signed-off-by: Wonjoon Lee 
Reviewed-on: https://chromium-review.googlesource.com/197991
Reviewed-by: Randall Spangler 
Tested-by: Doug Anderson

Adding waiting function when battery boot-up

2014-05-07T21:43:04+00:00

Some battery uses clock stretching feature, and this could disturb
PMU communication before battery going stable.
AP does not know and will attempt PMU setting, and could get fail
For various battery indicates usually 1s for stable
(even if it is much less in real world 200ms~700ms)
Let's checking 'battery is ready' when first pump-up power.

BRANCH=ToT
BUG=chrome-os-partner:28289
TEST=Going battery shipmode and plug-in AC, See booting and EC log
Disconnect battery, and plug-in and see booting and EC log

Change-Id: Idd8ae2ab4ec164b11fe67413bbf647cad18bc481
Signed-off-by: Wonjoon Lee 
Reviewed-on: https://chromium-review.googlesource.com/197990
Reviewed-by: Randall Spangler 
Commit-Queue: Doug Anderson 
Tested-by: Doug Anderson

CHROMIUM: ec: Add Port 80 history access from ectools

2014-05-07T03:41:27+00:00

While debugging reboot issue, it was difficult to get POST code from failing
boards. Currently POST code is only accessible from EC console. Not all boards
are fitted with servo board.

This patch adds Port 80 history access from ectool. Reuse command code 0x48,
EC_CMD_PORT80_LAST_BOOT with version 1.

Signed-off-by: Wenkai Du 

BUG=chrome-os-partner:28514
BRANCH=rambi
TEST=manually test on rambi to confirm port 80 history match EC console

Change-Id: If204d8fb457d8d8d18055f8282a406a35c03305e
Reviewed-on: https://chromium-review.googlesource.com/198012
Reviewed-by: Randall Spangler 
Reviewed-by: Wenkai Du 
Commit-Queue: Wenkai Du 
Tested-by: Wenkai Du