This reverts commit c58c01b14c.
Let's add time scaling back, but keep the default scale to 1. The
emulator behavior should be entirely the same. If a test need to be
speeded up, the scale can then be set for that test only.
BUG=chrome-os-partner:19235
TEST=Pass all tests.
BRANCH=None
Change-Id: I648780577a1ae2f964c30c71077ccf9bf38b9735
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51550
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The display rail is generated from the PP3300_DX rail, but it
is enabled by the EC_EDP_VDD_EN signal. Therefore, bring down
the EC_EDP_VDD_EN signal before bringing down the PP330_DX
rail. Additionally, always set the EC_EDP_VDD_EN signal based
on the PCH_EDP_VDD_EN in the x86 power interrupt. The reasoning
is so the signal doesn't indavertently remained set.
BUG=chrome-os-partner:19398
BRANCH=None
TEST=booted and resumed
Change-Id: I43c2306f05d144b7dea243bafb5922118be1fe39
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51524
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The PP3300_WLAN rail was not being controlled. Fix this by bringing
up the rail in S3->S0 transition and bring it down in S0->S3
transition. This current sequencing will not allow the WLAN to
wake from suspend at the moment. To do that we'd need to move this
sequencing to the S5<->S3 transitions.
BUG=chrome-os-partner:19507
BRANCH=none
TEST=Brought up board. Noted WLAN card in lsusb and lspci.
Change-Id: I48e7610fa4f0471a2869933f2df5d2c7c525b155
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51483
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When AP is off, turn off pullup on NSS, and set MISO to an input so
the SPI module won't drive it high if the last sent bit was a 1. This
reduces leakage when the AP is off.
This patch also fixes a bug where gpio_set_alternate_function() set
the wrong pins to normal-mode when func=-1; that didn't hit anything
else because that functionality wasn't used on STM32 until now.
BUG=chrome-os-partner:19304
BRANCH=none
TEST=boot pit
On EC console, with AP on, 'rw 0x40020000' returns
read 0x40020000 = 0x6569aa20 <- must have 0x____aa__
Then 'apshutdown' and 'rw 0x40020000' returns
read 0x40020000 = 0x65690020 <- must have 0x____00__
The 'power on' and AP turns back on. At u-boot prompt,
'sspi 2:0 256 9f00000000' returns
FDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFDFEEC010001
(some number of 0xFD's followed by FEEC...) This shows SPI
functionality is restored when AP is powered back on, and not
just at init time.
Change-Id: Ia3cd3e0bc222dc663d635509918fa3d383fd7971
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51182
Reviewed-by: Simon Glass <sjg@chromium.org>
It makes delay between 3.3V_EN and PMIC_ON
So we are now 5V EN -> 2ms Delay -> 3.3V EN -> 2ms Delay -> PMC3_ACOK
BUG=chrome-os-partner:19305
BRANCH=none
TEST=Using osiloscope, See until PMC3_ACOK is far from P3.3V_AUX as 5ms
Change-Id: I65bfece28f55edf4f5640fe411bd57caaaaa5e1d
Reviewed-on: https://gerrit.chromium.org/gerrit/50449
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
The current lm4 pwm module was using board-specific
pins during this configuration. Move the implementation
of configure_fan_gpios() to the board-specific files
so that the pin configuration policy isn't a part of the
common infrastructure.
BUG=chrome-os-partner:19504
BRANCH=none
TEST=successfully booted slippy with backlight turning on in OS.
Change-Id: I325f1ac4639b4a78d8b860df7a8b688ca385b71b
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51471
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When system is locked, the console is disabled. However, we need console
for debugging and testing. This CL uses a bit from back-up register to
indicate if the console should always be enabled. (This bit is currently
used by fake WP, which is removed in this CL.) With this, we can set
this bit with console command 'forceen 1' to ensure console is never
disabled.
To prevent device shipped in this state, the chip name is postfixed with
'-unsafe' so that the device is not able to pass HWID check.
BUG=chrome-os-partner:19293
TEST=Manual
BRANCH=spring
Change-Id: I88556e973ca542c1bdc27ba64988718291e01a26
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51086
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The 5V rail should be enabled on S5->S3 transitions and
disabled on S3->S5 transitions.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transitions: S0,S3,S5,G3
Change-Id: If9fd7ef16f015136238dd18f64602ecf33d9ec4a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51359
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The PROCPWRGD signal is not well documented. It's not known if
it is an input or an output. Emperically it was discovered that
driving this pin during the resume path causes resume to fail.
Therefore, ignore the pin by setting it to an input.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transition from S0 to S3 and back to S0
Change-Id: I55dc16c75c286af06806e2513197f0bb2c7b9d04
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51358
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Current timing constraints are too tight that the test sometimes fails
when it shouldn't.
BUG=chrome-os-partner:19236
TEST=Pass the test
BRANCH=None
Change-Id: Ib94ff44691ba36f14dbf02319d0371770b5ece5d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51250
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The current sense resistor has changed. Update constant here to reflect
the new values for DVT1.
BUG=None
TEST=Build Spring
BRANCH=Spring
Change-Id: Ib27c45cef569fa758db2fbb428150c8c2b6732ef
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49892
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
- pass through the eDP VDD enable from PCH
- Bring up suspend rail after DPWROK and before RSMRST,
as indicated for deep sleep sequencing
- de-assert CPU_PGOOD on S0->S3 transition, it was
getting left enabled
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transition from G3 to S0 and back to G3
Change-Id: Ie711275d6121edccff60b2de08b71575d2d035b7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51154
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
As our stack for the keyboard scanning task might be small (256 bytes on
STM32), we store the full keyboard state in a global instead of the
stack to avoid consuming 16 bytes there.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:19389
TEST=run on Spring with CONFIG_OVERFLOW_DETECT and see that the KEYSCAN task
is now consuming 248 bytes of stack instead of 264.
Change-Id: I2dd7815f36e6807e7b9e88d59f8fd8a14b1988ab
Reviewed-on: https://gerrit.chromium.org/gerrit/51028
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
This is useful for finding out which test runs for too long.
BUG=chrome-os-partner:19235
TEST=Run tests and see run time logged.
BRANCH=None
Change-Id: I5cb6727b2e1017fce1107e4892c1898e66598492
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51105
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If a test fails, redirect emulator output to stderr so that it shows up
even when V=1 is not set.
BUG=chrome-os-partner:19235
TEST=Manual
BRANCH=None
Change-Id: I6d8e05eaa222ebe043556bfcd3f63ca7e27c2721
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51097
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Still some work to do here but this now works.
NOTE: This makes the system behave like a normal
cros device where the power is applied automatically.
For some (other, unknown) reason the "reboot ap-off"
is not passing flags correctly to keep it off.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=successful state transition from G3 to S0
Change-Id: I694136b9611e18ac8fb7b1e960bd10caa258ce28
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51077
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The timer is the only source of timing for the emulator. This means we
can make it go faster without breaking the tests. This CL sets the
default scale to be 3x faster than normal time.
BUG=chrome-os-partner:19235
TEST=Pass all tests. Check the tests run faster.
BRANCH=None
Change-Id: Ib9035884b34f41c4e9aa2206284b5f1ec8fc0d1f
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50956
If the user unplug video dongle before it is detected and handled, we
may be stuck with ID_MUX=1 and interrupt from TSU6721 disabled. This
essentially breaks charging.
BUG=chrome-os-partner:18997
TEST=Build and check charging port still works.
BRANCH=spring
Change-Id: I93e69287d07947fef743b4674857e52c26513835
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50969
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We cannot know how much current we can pull from video dongle, so let's
just try to pull as much as possible up to 2A.
BUG=chrome-os-partner:19324
TEST=Plug in video dongle and see 3.3V output.
TEST=Plug in video dongle with supplied charger, and see 50% PWM duty
cycle.
TEST=Plug in video dongle with normal charger, and see 70~80% PWM duty
cycle.
BRANCH=spring
Change-Id: I8b503f886fcafaa11e6757a5059ce673a8ed53cc
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50963
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The recovery pin input from servo is open drain and needs
an internal pullup enabled so it is not always low.
BUG=chrome-os-partner:19398
BRANCH=none
TEST=manual: ensure rec_mode can be turned off
$ dut-control rec_mode:off rec_mode
rec_mode:off
Change-Id: I387a53eb5b64bb0bf3a87fc47b5cca9b2063f6a9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50993
The help text says to pass 0 or 1 for the mode but
the code only accepts "on" or "off".
Fix up the help text to match and have the display
output for the port status also use on/off so it is
consistent with the input.
BUG=chrome-os-partner:18825
BRANCH=none
TEST=manual: verify "usbchargemode 0 on" works as
it is explained in the help text.
Change-Id: Ib32dc68af93989d277aa84a1cb53ae9b66a8b595
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50838
Slippy uses UART2 instead of UART1 and so the EC needs
to be able to tolerate having the host use a different
interface. There are of course many ways to accomplish
that but this approach adds two config variables to specify
the host uart and the host uart irq.
The UART port setup is split out to allow them to be
configured separately rather than needing to be adjacent
in a for loop.
The interrupt functions were renamed (to ec and host) in
order to indicate which interface they are responsible for.
BUG=chrome-os-partner:19356
BRANCH=none
TEST=boot slippy and see host serial output
Change-Id: I1913ff3d650f329224c9654eee7bb7412fae5402
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50837
SPI is always enabled on pit, so remove #ifdefs
SPI1_CLK was aliased to AC_STATUS, which is left over from snow and
doesn't exist on pit. That caused it to be driven high briefly during
EC boot.
Also set SPI pins for 40MHz speed so we can try faster SPI clock.
BUG=chrome-os-partner:19304
BRANCH=none
TEST=boot system; sspi 2:0 256 9f prints a bunch of FDs then FEEC010001
Change-Id: I10352cff3669d6a087939d9d8e302d70708e9ee3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/51023
Reviewed-by: Doug Anderson <dianders@chromium.org>
This is causing the host to reset because this pin is
going low when it is left as open drain, despite having
a 3.3V pullup.
BUG=chrome-os-partner:19355
BRANCH=none
TEST=manual: boot on slippy without RCIN# causing reset
Change-Id: I59e9316e85ce618edc84c7dd988d70ea4de1e71a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50836
This commits the hacks made during board bringup. Bugs can be filed and
fixed based on this starting point.
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Try it and see.
Change-Id: Ia663eaf9a357633873b1b5d5cc6dbdda63513082
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50875
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Several test utility macros have been duplicated across tests. Let's put
them in a single place.
BUG=chrome-os-partner:19236
TEST='make runtests', 'BOARD=spring make tests'
BRANCH=None
Change-Id: Ib0c9f829715425cc23e33b8ef456b17dfadab13c
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50513
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The current delay is unnecessarily long. This CL shortens the delay.
BUG=chrome-os-partner:19236
TEST='make runtests'
BRANCH=None
Change-Id: Ica07458e7ae15cf28c3482b6df96df66c0d45182
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50487
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The spec suggests we cannot reliably go over 1.5A and gracefully
recover. Let's avoid going over that limit.
BUG=chrome-os-partner:19267
TEST=Build spring
BRANCH=spring
Change-Id: I07411ff3ce4107e0289c5af5365ef5a23fd23e4e
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50321
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The i2cdetect command on Linux likes to probe by doing a write of 0
bytes. Rather than always returning success because there was nothing
to write, let's actually implement this command.
At the moment we only implement for the stm32l. We also don't try to
implement the "read of 0" bytes since I don't think anyone uses that.
BUG=chrome-os-partner:18778
BRANCH=none
TEST=i2cdetect -y -a 20 now detects the right devices
Change-Id: Ia159ce9b8c957d5cd11f187f1a179ca5967bf96f
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50009
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
The STM32L manual has a whole section on i2c master reads and
describes the correct method for receiving exactly 2 bytes and more
than 2 bytes. We weren't following those instructions and thus larger
transfers weren't working.
BUG=chrome-os-partner:19265
BRANCH=none
TEST=i2cxfer r16 0x90 0
...doesn't fail
TEST=i2cxfer r 0x90 0
...doesn't fail
TEST=Use pydevi2c and test some commands:
>>> tps = I2CDevice(20, 0x48)
>>> [hex(x) for x in tps.Get(0, 20)]
['0x1e', '0x0', '0x3e', '0x0', '0x12', '0x20', '0x4b', '0xbf',
'0xff', '0xff', '0x20', '0x12', '0x1e', '0x1e', '0x1e', '0x1f',
'0x1f', '0x1f', '0x1f', '0x1f']
Change-Id: Ifaab6d8b700e099bcd9c374c70fca0983858ed3f
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50229
Reviewed-by: Simon Glass <sjg@chromium.org>
Tested-by: Simon Glass <sjg@chromium.org>
On 64-bit platform, arrays should be aligned to 8 bytes. Also, change
the order of host_command fields so that it's packed on both 32-bit and
64-bit platforms.
BUG=chrome-os-partner:19257
TEST=Pass all tests. Print out and check the content of host commands.
BRANCH=None
Change-Id: I350a903bc11562d6d205c402548942f8967b75a5
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50467
This includes:
- Increase overcurrent retry count from 1 to 2.
- Mark overcurrent event regardless of what current PWM duty cycle is.
- PWM duty cycle settles faster.
- PWM duty cycle starts from ~100%.
BUG=chrome-os-partner:19001, chrome-os-partner:19037
TEST=Manual
BRANCH=spring
Change-Id: Idf007fb589fde3baef6c8975dfa1f2fc1ec6e95d
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50262
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Perviously we use uint32_t for this, but this doesn't compile for 64-bit
environment (and likely doesn't for 16-bit either.) Use uintptr_t so that
we don't get size mismatch errors.
BUG=chrome-os-partner:19257
TEST=Run host emulated tests
BRANCH=None
Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50358
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
If an ADC read fails and EOC bit is somehow never set, we will be stuck
in the read function holding mutex lock forever, which is really bad.
Let's set a timeout for this.
BUG=chrome-os-partner:18997
TEST=Boot Spring. Check ADC works.
BRANCH=spring
Change-Id: I19b108326f34f380497606fe92eabfaf0a778bb4
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50338
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There was an off-by-one error in bounds checking the reply. You could
trigger it with pydevi2c with:
>>> tps = I2CDevice(20, 0x48, force=True)
>>> tps.Get(0, 249)
The EC would show:
ASSERTION FAILURE 'msg_len < sizeof(out_msg)' in reply() at
chip/stm32/spi.c:184
BUG=chrome-os-partner:18778
BRANCH=none
TEST=Run the above commands and see no error.
Change-Id: I9789405a9d70c5dc3fa237504fea8f46a139386c
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50254
Reviewed-by: Simon Glass <sjg@chromium.org>
I've simplified the SPI module, since we only ever use SPI1 (and there
were already a number of places which assumed this was true).
Somewhere along the way I fixed a number of problems keeping the code
from compiling and working on STM32L. The code isn't currently used
anywhere else, but should still work there (that is, I don't think I
broke it working on STM32F if you re-enable it on some STM32F
platform).
BUG=chrome-os-partner:19073
BRANCH=none
TEST=from u-boot console, sspi 2:0 64 9f0000
u-boot prints: FDFDFDFDFDFDFDFD
ec prints: [193.740912 HC 0x9f][193.741141 HC err 1]
[sjg: gpio optimization back in for now]
[dianders: add comment as rspangler requested; update SOBs]
Change-Id: Ib9419403e4e44dadc1f17681e48401882cb49175
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49684
This is needed for non-volatile register emulation. Also, this can be
used to implement system jump or reset flags.
BUG=chrome-os-partner:19235
TEST=Run utils test. Check persistent storage file exists.
BRANCH=None
Change-Id: I699f95718ef6f5de6c3bbb4e37619ee015fb6c4a
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50313
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is the first version of pthread-based RTOS emulator. With this, we
will be able to test high-level modules entirely on the host machine.
BUG=chrome-os-partner:19325
TEST='make runtests' and see tests passing.
BRANCH=None
Change-Id: I1f5fcd76aa84bdb46c7d35c5e60ae5d92fd3a319
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/49954
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A test that check keyboard MKBP module using keyboard scanning module and
host commands.
BUG=chrome-os-partner:19236
TEST=Pass the test
BRANCH=None
Change-Id: Ic22a2c8f3069d8e72c1222882073d428b733bca3
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50132
The EC currently assumes the AP only provides USB power during S0, which
is incorrect. This CL adds S3 so that it behaves when the device is
suspended.
BUG=chrome-os-partner:19190
TEST=Suspend and unplug power. Doesn't hear clicking sound.
BRANCH=Spring
Change-Id: Ice1421bda55b2fee408ba062ed3de7a697ccd0c8
Signed-off-by: Vic Yang <victoryang@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50093
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This specifies the Slippy GPIOs. Because the power controls are completely
different from Link, we have to gut the power sequencing task to do nothing.
For bringup and test, we'll just manually set and get the GPIOs until we
know exactly what we need to do.
This is where the fun starts...
BUG=chrome-os-partner:18825
BRANCH=slippy
TEST=manual
Built everything, Link still works.
Change-Id: Ic1ce1d4085298f49dd98d99e81e04835eca5f11c
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/50004
