Sweetberry specifies UART pins as GPIOs, however
this is not necessary for uart use. Let's remove these.
UART4 is also dup'd with sweetberry's signal gpios, which
is fixed with this CL.
BUG=chromium:608039
TEST=boots
BRANCH=None
Change-Id: I81ee2351c0191ff5ec3d5fad37fe10866bf1ad32
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380439
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This change introduces a larger range of tests
for bn_modinv_vartime. The tests are designed
to run on a host, and compare results against
openssl.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=bn_test passes
Change-Id: I2d6ea4824fa82f78f8797c0cfc2cf0dce03e8923
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/365232
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If both e, and MOD are even, then no modular
inverse exists. This change adds handling
for this set of inputs. Adding this change
for completeness (there are no dcrypto library
call paths that generate both e and N as even).
BRANCH=none
BUG=chrome-os-partner:47524
TEST=bn_test passes
Change-Id: Ide64f980501175e9b6078efff92086d12bc1ae2d
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/376180
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Before P3 (long time ago), the PI3USB9281 has an I2C requiring a
workaround using the GPIO C15.
The workaround has been removed when we switched to PI3USB9281A
on P3 and the GPIO has been re-used since.
Remove the old GPIO definition to avoid conflicts with its new usage.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=smaug
BUG=chrome-os-partner:31526
TEST=make BOARD=ryu
Change-Id: Ieb7071b7ca27f3e9a4719592441b6a0b4c455b27
Reviewed-on: https://chromium-review.googlesource.com/380555
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If the firmware was just updated clear the reset counter before
rebooting. This will ensure that the update can complete even if the TPM
isn't being used.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=Set the reset counter to 7 by running 'rw 0x40000128 1' and
'rw 0x4000012c 7'. Then make sure cr50 can still be updated
Change-Id: Ic304fc7a20a4f2af7792f80e970d28e0eb10967e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380235
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This is for boards on which AC_PRESENT can be expected to fluctuate
over a much longer period than the code was originally designed for.
Specifically, USB-PD systems may require several hundred milliseconds
for the state machine to settle before making decisions based on
AC_PRESENT status, for example, changing LED state.
BUG=chrome-os-partner:56471
BRANCH=none
TEST=Tested on Reef with follow-up patch
Change-Id: I370048cb79d1593a14077563ec8db8e8282afb16
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378755
LID_ACCEL_INT_L is a push / pull interrupt pin which is currently unused
by EC FW. Remove the PU to prevent leakage when PP1800_sensor is powered
down.
BUG=chrome-os-partner:56646
BRANCH=None
TEST=On kevin, verify LID_ACCEL_INT_L is consistently logic 0 in S5.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6c748a18bcd183f799b78b4ad9098fff7a7d6567
Reviewed-on: https://chromium-review.googlesource.com/380236
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
SPIP is only used in S0, so keep the module disabled in lower power
states. Disabling SPIP through spi_enable() will also restore our CS pin
to ODR_HIGH.
BUG=chrome-os-partner:56860
BRANCH=None
TEST=Verify SPIP is functional on initial power-up, sysjump, and on
apshutdown / re-power-on. Also verify GPIO_SPI_SENSOR_CS_L goes low in
S5.
Change-Id: I14d845895a43700d2133a532cff63d08f0e64018
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380215
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
BC1.2 detection may still occur on multi-purpose ports which we are
currently sourcing. Don't charge from such ports, and don't incorrectly
indicate that external power is present.
BUG=chrome-os-partner:55907
BRANCH=None
TEST=Manual on kevin, plug Apple charge-thru accessory with no charger
attached, verify we don't charge from it.
Change-Id: I9a74f1123fc51c7fc622f985bd528e96b9526946
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378595
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
To support hibernate called from console commands, ectool commands
and key sequence added code to shutdown the AP before hibernating.
BUG=chrome-os-partner:56490
BRANCH=none
TEST=Using console command, ectool command & key sequence verified
both EC and AP are hibernated.
Change-Id: I7708377596d7d4175a44c202ae2385a239ca3d01
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/379157
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The high speed clock does not run when cr50 is in sleep. The low speed
timers do run in sleep and deep sleep. This change modifies the hwtimer
to use the low speed timers instead of the high speed ones.
With this change the system timer frequency is reduced and will only
tick once every 4 mircoseconds. Now the system will resume from sleep
whenever an event is scheduled, but still wont resume from deep sleep.
BUG=chromium:635620
BRANCH=none
TEST=manual
Disable sleep
add a function that prints something every second.
Verify the rollover works at ~4295s.
Change the system time using force_time.
Re-enable sleep and reduce the sleep delays in
board/cr50/board.c and chip/g/idle.ci so cr50 will go to
sleep more quickly. Verify the rollover and changing system
time works.
check that cr50 can go into deep sleep and that the print
statement wont wake it up.
Put the system into deep sleep. Use a wake pin to make it
resume. Verify it can be put back into deep sleep without the
wakepin interrupt constantly triggering.
Change-Id: I70bbc9312cd172661de53334d256949ebab6b5e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376800
Record what current limit we set when we act as a source
and when we are changing it.
The change should be backward-compatible as older EC will return 0 in
`current_max` when their role is PD_ROLE_SOURCE while newer firmware
will set the actual limit.
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2
ports, and dump the values with 'ectool usbpdpower'.
Change-Id: I8e78663f3196b1b81c2235ed8642da0638bed649
Reviewed-on: https://chromium-review.googlesource.com/375918
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a new source policy to provide 3A if there is only one port used
as a source.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2 ports,
while measuring the type-C pull-up with Twinkie.
Change-Id: Ic3dfda7b69d0edeb6b3a9218e723e2c3e0232a51
Reviewed-on: https://chromium-review.googlesource.com/373819
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
CONFIG_POWER_TRACK_HOST_SLEEP_STATE has a dependency on
CONFIG_POWER_COMMON, so remove it from test builds that don't have a
chipset task, rather than heavy-handedly removing it from all test
builds.
BUG=chrome-os-partner:56197
BRANCH=None
TEST=`make BOARD=gru tests`
Change-Id: I86e20b4dccbb01ee285054a47093d6f60abc2166
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378119
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
stm32f446 uses a synopsys designware USB block
rather than the typical ST one. This change adds driver support
for the new block, including usb console support.
BUG=chromium:608039
TEST=usb console works
BRANCH=None
Change-Id: I0e143758ae0b5285f1c94ea2ec5aee159e22e00c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365448
Reviewed-by: Randall Spangler <rspangler@chromium.org>
No need to do set_range in motion_sense_shutdown(), already done at init.
Besides, this is an error if the sensor is not powered in S5.
BUG=b:27849483
BRANCH=cyan, minnie, samus
TEST=Check sensor range is set correctly.
(cherry picked from commit 1018eac30db86dd1d78d5b84b7651edd6aca9225)
Reviewed-on: https://chromium-review.googlesource.com/379097
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Change-Id: Id0b9c2e4988ffc8b55b21258f60b1efa26156dbb
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/379542
During removing primary power of CPU, EC also needs to handle VW event
of SUS_WARN# in espi driver. Modify the MIWU trigger mode of it from
EDGE_RISING to EDGE_ANYING to solve it.
Modified sources:
1. espi.c: Handling VW event of SUS_WARN# in both edge.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; test power sequence on espi POC of wheatley.
Change-Id: I9e45115f3c274d08cdc694911d38599bc8da70c5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/377780
Reviewed-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The SHI lines connected from the EC to the AP and the AP might not be
turned on. We should have a pull down on these lines to avoid them
glitching when the AP is in S3 or S5.
BRANCH=None
BUG=chrome-os-partner:56683
TEST=Verify S3/S5 power is decreased, and SHI interface is still
functional in S0 and on sysjump.
Change-Id: I3a9b018e6e8a5eddb1f23e004f1af3da3e503709
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376360
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
DUT_HUB_USB_RESET_L was set to input as part of power sequencing
but servod would like to write to it. We'll allow this.
BUG=chromium:571476
TEST=dut-control dut_hub_usb_reset:on
BRANCH=None
Change-Id: I39997e7f7875b833a64f95a1e2ea9434f3523762
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378395
Reviewed-by: Kevin Cheng <kevcheng@chromium.org>
Some target's gcc will detect the address is unaligned and then
expand to byte load sequence, make the address to volatile can
prevent gcc optimize it.
BUG=none
BRANCH=none
TEST=make buildall;
Verified that "crash unaligned" causes a panic on it83xx.
Change-Id: Ieb4f5f8fc65854aefe307fa675fe87d7581452ed
Signed-off-by: Kito Cheng <kito.cheng@gmail.com>
Reviewed-on: https://chromium-review.googlesource.com/374281
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a policy to handle the case where the device can source the
`CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT` over one of its type-C port if
there is no sink connected on the other ones.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2 ports,
while measuring the type-C pull-up with Twinkie.
Change-Id: Id5961f04d0a1b1073f5ab340068efd9079918209
Reviewed-on: https://chromium-review.googlesource.com/373818
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
UART0 RX only needs to be disabled on reef. This change uses a system
property instead of a #define to disable UART0 RX that way it can just
be done on Reef not Gru or the dev board.
BUG=chrome-os-partner:55510
BRANCH=none
TEST=manual
rw 0x4060000c shows a value of 1 for reef and 3 for gru
gru kevin and reef still boot.
Connect DIOA13 to DIOA1 on the dev board and verify the console
can be used.
Change-Id: I5ee3559c2b35f959c0d67f233d1dfa40743b4064
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378336
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
If there was an error getting the capacity or page size, don't update
the values with an incorrect/unknown/uninitialized value.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: I907f14f219f721ec9e9753a38e4bf998bbc16324
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370665
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ewout van Bekkum <ewout@chromium.org>
There is leakage on SYS_RST_ODL from the internal pullup cr50 has on
DIOM0. This change removes the internal pullup.
Without the internal pull up SYS_RST_ODL is asserted when the EC is off.
This change modifies how sys_rst_asserted is handled so cr50 will ignore
the sys_rst interrupt whenever rbox asserts EC_RST to make sure cr50
doesn't reset itself every time it resets the EC. If the EC resets
itself and sys_rst_l is no longer pulled up, it is fine if cr50 resets.
BUG=chrome-os-partner:53544
CQ-DEPEND=CL:377504
BRANCH=none
TEST=manual
'rw 0x40550010 1' causes the EC to reset but not cr50
On the development board verify DIOM0 is not pulled up.
Test cr50 boots normally on reef, gru and kevin dvt1
Change-Id: Id8e8f6f7bb91741da34bdd6fec89eb841dd94f35
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376886
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On boards using cr50 as the TPM there needs to be a pullup on SYS_RST_L
BUG=chrome-os-partner:56701
BRANCH=none
TEST=verify SYS_RST_L is pulled up on DVT1 and earlier.
Change-Id: Ib87ef48bafe1dad1329678f9a80c34c7adc2df01
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377504
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to disable the restricted console lock, the user has to
poke the power button repeatedly for some time. This CL
implements the logic to tell when this is happening, and whether
it is successful or not.
With this CL, unlocking only takes 10 seconds. This period will
be extended for production use. Right now we're just testing.
BUG=chrome-os-partner:55322
BUG=chrome-os-partner:55510
BRANCH=none
TEST=make buildall; test on cr50 hardware
At the console, run the "lock" command to see if it's already
disabled. If it is, run "lock enable" to lock it.
To unlock it, run "lock disable". A countdown will appear, after
which you will need to poke the Power button every 2 seconds for
10 seconds. If you do so, the console will be unlocked.
Change-Id: Ib5a94172080e627f3268d50d2587ec58bf8d9473
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377621
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Even when CONFIG_RESTRICTED_CONSOLE_COMMANDS is enabled, there
are many commands that can't do anything dangerous. This marks
some of those commands as safe to use, even when restrictions are
enforced.
I'm only marking commands that are used by the Cr50, since that's
the only board that has restrictions.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
Change-Id: I6289d332830175b6adcb6b20cb4c21d01d27a25e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376188
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This enables restricted console commands, meaning that only the
"help" command would be available when the Cr50 console is locked.
To get out of (or into) the locked state, this also adds a "lock"
command. Of course, it will be available in locked mode.
For now, the lock state is disabled, so all commands continue to
work as before. Even after enabling the lock, it's trivial to
disable it again. Future CLs will build on this framework.
BUG=chrome-os-partner:55322,chrome-os-partner:55510
BRANCH=none
TEST=make buildall, test on Cr50 hardware
Try these commands:
lock
help
gpioget
lock enable
help
gpioget
lock disable
help
gpioget
Change-Id: I42c9bd63e17612dcff78c9f45054e53d96adcd5b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376187
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This adds support for CONFIG_RESTRICTED_CONSOLE_COMMANDS. If the
appropriate options are configured, restricted commands can be
prevented from running.
Nothing in this CL actually uses that, but it works if you turn
it on.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
I also tested it manually. If you add this to board.h:
#define CONFIG_CONSOLE_COMMAND_FLAGS
#define CONFIG_RESTRICTED_CONSOLE_COMMANDS
#define CONFIG_CONSOLE_COMMAND_FLAGS_DEFAULT CMD_FLAG_RESTRICTED
and this to board.c:
static int restricted_state;
int console_is_restricted(void)
{
return restricted_state;
}
static int command_lock(int argc, char **argv)
{
int enabled;
if (argc > 1) {
if (!parse_bool(argv[1], &enabled))
return EC_ERROR_PARAM1;
restricted_state = enabled;
}
ccprintf("The restricted console lock is %s\n",
restricted_state ? "enabled" : "disabled");
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND_FLAGS(lock, command_lock,
"[<BOOLEAN>]",
"Get/Set the restricted console lock",
0); /* no restrictions */
then you can use the "lock" command to enable and disable every
other console command except for it and "help".
Change-Id: Ic9517f9ea7a9867f15e5d14b302246070163d558
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376186
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we add a .flags field to the console commands data structure,
we can use it to distinguish some commands from others, for
example to mark some commands as safe and others as dangerous.
This just adds the undefined CONFIG_ options. They aren't used
anywhere, so there's no behavioral difference yet.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: I17fdf177dcb4324c77565bd95344da1405ea15ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376185
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commit adds a board level hibernate call which will place both of
the TCPCs into a low power state. When the EC wakes up from hibernate,
we will reinitialise the TCPCs back to full power.
BUG=chrome-os-partner:55631
BRANCH=None
TEST=make -j buildall
TEST=Flash kevin; Boot up, shutdown. Enter `hibernate` at the console.
Verify G3 power is less than prior to this patch.
Change-Id: I9d71495358c16268352bf3820318ec151836c5de
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/376864
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If a TCPC fails to initialize then the PD task probably won't
function as expected when put in its default state and the console
will likely get spammed with errors. Fall back to the suspended
state instead.
BUG=none
BRANCH=none
TEST=booted on Reef EVT without TCPC1 connected, console is
no longer spammed with errors.
Change-Id: I94577c065e53bc6076c507b50c5bec22dbd8bdce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376182
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Setting the higher limit of input current for BC1.2 & nonstandard
BC1.2 devices than their maximum current rating results in an
anti-collapse. BD99955 does not have a way to do hardware charge
ramp or to detect the anti-collapse for these chargers. Hence added
code to support software charge ramp for BC1.2 & nonstandard BC1.2
so that the input current is set to maximum of the respective
charger.
BUG=chrome-os-partner:54990, chrome-os-partner:55517
BRANCH=none
TEST=Manually tested on Amenia & Reef. BC1.2 & nonstandard BC12
devices can negotiate their respective maximum current rating.
Change-Id: I0033b3662362bd7822ad01cf4360d18caabd5249
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/358106
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Holding SYS_RST low will keep the TPM in reset, and prevent a
reset-too-soon-after-power-on case that put the TPM into a bad state.
BUG=chrome-os-partner:56414
BRANCH=None
TEST=Manual on kevin rev5, verify board still seqences from G3->S0 and
back, S0->S5 and back, S0->S3 and back.
Change-Id: I07671079deedb757314679608d848b1620aa67d6
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374899
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Catherine Xu <caxu@google.com>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Set the EC_WIRELESS_SWITCH flags in Board file. This signals the
common code to maintain the ON or OFF state of the power rails for
the Wifi/Bluetooth chip when chipset enters suspend state.
BUG=chrome-os-partner:56305
BRANCH=none
TEST=Boot the system with a Bluetooth Mouse paired. Open a Linux
shell and type powerd_dbus_suspend. When the system enters
sleep state, click the mouse. System should wake up.
Change-Id: I261ca03d34bc8a05d3a2aa5fcb777f714fe30572
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/374164
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
It is sometimes necessary to find out headers' version of a cr50
binary blob. This patch adds this ability.
BRANCH=none
BUG=none
TEST=build the new tool image and try it:
$ ./extra/usb_updater/usb_updater -b /build/kevin-tpm2/opt/google/cr50/firmware/cr50.bin
read 524288(0x80000) bytes from /build/kevin-tpm2/opt/google/cr50/firmware/cr50.bin
RO_A:0.0.8 RW_A:0.0.4 RO_B:0.0.8 RW_B:0.0.4
$
Change-Id: I367ca94346484410f785fb56a941c8558ab57634
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374085
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Version 4 of the update protocol provides the host with version
numbers of currently running RO and RW.
Another enhancement is that flash erase is postponed til the moment
the first chunk of data for the section arrives. This allows to quiry
running firmware versions in a non-destructive fashion.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=ran usb_update on a Reef with an old cr50 image on it. Observed
it complete once with exit code of 2 (RO could not be updated),
ran it again, observed it succeed, and verified that both RO and
RW on the Reef got updated.
Change-Id: I27841c464cd0a414fa8959b686b59d8f07765387
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trying to use usb_updater in the upstart script made its shortcomings
very obvious: it is difficult to tell if the cr50 needs to have both
RO and RW updated, and if so - if it is even capable of updating RW.
Also, it is not clear that the target should erase its backup sections
as soon as it receives the transfer originating PDU. It is not known
in advance if the host has a newer RW section, of if the host is even
going to transfer the RO section.
These issues are addressed by version 4 of the image transfer
protocol.
The target now reports versions of its currently active RO and RW
sections back to the host. The host compares versions running on the
target with the versions retrieved from the image prepared for the
update and decides which sections, if any, need to be transferred.
The host also takes into account protocol version currently running by
the target's RW: versions below 3 do not allow RO updates.
In the development environment USB transfer ends with the target
reset. This is not desirable when the update is happening on a
Chromebook running production code. Also, in the development
environment there could exist multiple versions of the image with the
same signer header version fields, with only difference in the
timestamp. We want to be able to update using these images in
development environment, but in production we want to rely to the
header version fields.
These two mode (dev versus production) are now controlled by the
-u/--upstart command line flag.
The updater now can return four different exit values:
- 0 means that the update was not required, the device is already
running the current code.
- 1 means update was completed, the target must be reset for the
update to kick in.
- 2 means that the RW transfer was completed, but the RO transfer
could bot be attempted, because the target is running an early
protocol version and is not capable of the RO updates.
This exit value is the indicator that the utility needs to be run
again after target restated, so that the new RW version can accept
an RO update.
- 3 means the update failed due to some internal error.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=updates of targets running earlier protocol version still work
fine.
Change-Id: Ia56f63072eaf88dcdefebf621b7341535748c7d7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374759
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The console command "sleepmask" refers to another, nonexistant
command, "dsleepmask". We shouldn't refer people to look for
things that don't exist.
BUG=none
BRANCH=none
TEST=make buildall
Before:
> help sleepmask
Usage: sleepmask [ on | off | <sleep_mask>]
Display/force sleep mask.
See also 'dsleepmask'.
>
After:
> help sleepmask
Usage: sleepmask [ on | off | <sleep_mask>]
Display/force sleep mask
>
Change-Id: Ia95b48fc1e27315895e431b88ab39179a08d34cf
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376078
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Addition to 4523735d: We can use the BMI160 internal FIFO, so set only
the Lid accel in forced mode.
Set EC rate for BMI160 accel as needed.
BRANCH=kevin
BUG=b:27849483
TEST=Check sensor parameters with accelrate. Check rotation is working.
Change-Id: I86f50e019db25837894036c4f27b255a65d2f894
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374918
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
