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>
Add API to switch the Rp pull-up value on CC dynamically at runtime.
This is a preparatory work for boards having a more complex maximum
source current policy (eg 2 ports sharing a common pool of power).
For fusb302, update the voltage thresholds for open/Rd/Ra as they depend
on the Rp (was missing from the previous change).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=make buildall
Change-Id: Id3c24a31a16217075a398ec21ef58ee07187a882
Reviewed-on: https://chromium-review.googlesource.com/373501
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cr50 needs to connect to the AP phy when not in ccd so cr50 can be
updated and used as a gnubby. This change uses the strapping options
to detect when it is on reef and modifies the ccd behavior to
initialize usb on the AP phy when ccd is disabled. On gru the cr50
behavior is unchanged.
In RDD this change removes the checks that the current_map is the
correct one based on the detected debug state. rdd_init calls
rdd_interrupt to set up the usb and ccd state correctly. Having that
check prevents that initial rdd_interrupt from calling rdd_detached.
Before rdd_detached just disabled usb and we knew during init it
would already be disabled. Now we want to make sure it is called if a
debug accessory is not attached to initialize usb on the AP PHY.
BUG=chrome-os-partner:56098
BRANCH=none
TEST=manual
verify ccd still works on gru
disconnect suzyq and reset reef.
run lsusb on the AP and verify it shows cr50 as a device.
connect suzyq and check that the AP no longer sees cr50.
disconnect suzyq and verify the AP sees it again
Change-Id: I3c1ccc54895835bce12302f3ea43fc2e751b4c97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372920
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add tests for CBC, CFB and OFB AES modes.
Also convert tests to use word unligned
input parameters, to ensure that the api's
are unalignment agnostic.
Also add the program used for generating
test vectors.
BRANCH=none
BUG=chrome-os-partner:56413
TEST=tpmtest.py passes
Change-Id: I92c9ffece797aa7134d9cdad6ea32e6fe50feef1
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/374663
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
when TCPC takes a longer time to update its CC status upon
connection, a legacy C-to-A charger or certain Type-C charger
that presents 5V VBUS by default, TCPM could be mistaken the
charger as a debug accessory.
BUG=chrome-os-partner:55980
BRANCH=none
TEST=Manually tested on Reef. PD, Type-C, BC1.2, non-BC1.2,
DP, HDMI are working on both C-ports.
Change-Id: Ic3b0ecd3d14109239d8c0ff0064476595b7f93a0
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/367950
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Nothing has used this config option since Spring and Skate, back
in early 2014. There's nothing in ToT that uses it at all. I want
to add something similar for other purposes, and having two
similar-sounding options will just cause confusion.
NOTE: Although the comments in include/system.h said that the two
functions
system_get_console_force_enabled()
system_set_console_force_enabled()
were only useful when CONFIG_CONSOLE_RESTRICTED_INPUT is defined,
they were being used in chip/stm32/system.c. But since the
bkpdata registers are only accessible to the EC, there was no way
to initialize or modify the one relevant bit that those functions
cared about, so they almost certainly had no effect.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: Id41541193d4559f5c507bdd0268b049166af4497
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374525
Due to what appaers to be a leakage issue, this patch drives the
SYS_RST_ODL (aka PMU_RSTBTN_N) pin low for 1sec while the power
state transitions from S3 to S0.
This is a workaround for a proto board issue that prevents the SoC
from booting.
BUG=chrome-os-partner:53791
BRANCH=none
TEST=SoC boots with CL:347754 applied on proto and EVT boards
Change-Id: I88c3ccf18280acf5dfe3b99f99483dc4e4e27873
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372044
Reviewed-by: Martin Roth <martinroth@chromium.org>
This changes the ordering of rail/PMIC init slightly so that the
3.3V rail comes up before the PMIC, which follows the ordering
in the PMIC datasheet for cold booting.
The way we did it earlier was to avoid interrupt storms caused by
powering the SoC's GPIO block with SLP signals before powering the
PMIC. However the PMIC ignores the SLP signals when it's first
enabled, so while the suprious interrupts were visible on the scope
it's unlikely that the software was affected. OTOH, as Kevin pointed
out in CL:358913 enabling the PMIC before the 3.3V causes a race
condition whereby the PMIC may fault.
BUG=chrome-os-partner:51323
BRANCH=none
TEST=built and booted on EVT
Signed-off-by: Rachel Nancollas <rachelsn@chromium.org>
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I6eb734f0600daa5de0d970ce228cf3e7ec97d01d
Reviewed-on: https://chromium-review.googlesource.com/372344
Commit-Ready: David Hendricks <dhendrix@chromium.org>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The code should be compiled with -O0 for gdb use, otherwise various
optimizations make it very difficult to follow the execution flow.
With this patch adding DEBUG=1 to the environment or make command line
causes the usb_updater utility built with -O0 instead of -O3. The
debug flag is being changed to -g from -g3 as this code is not going
to be able to benefit from the g3 features, especially when built
inside chroot.
BRANCH=none
BUG=none
TEST=verified that gdb can properly control execution when make is
invoked with DEBUG=1
Change-Id: I50d8df46a7dd04d4d253b34146dde95f5388287d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374758
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Added MACRO for specifying row size of flash device.
* Set chip/g specific values for flash row size.
The flash API for g/chip will segment large write operations into a
maximum of 32 word blocks for batch writes to flash memory. Prior to
the change in this commit, the segmentation will adhere to avoiding
crossing page boundaries (2048B) but will not respect row boundaries
(256B). The flash controller will reject any write op that crosses a
row boundary and set a row boundary violation code on its error
register.
BRANCH=none
BUG=b:30819377
TEST=make BOARD=haven_dev
Change-Id: I489122ec0f0db6374dd373a1385c3012bdface20
Reviewed-on: https://chromium-review.googlesource.com/371003
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Johnnie Chan <johnniec@google.com>
Tested-by: Johnnie Chan <johnniec@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When the charger is detached, the host event would sometimes be
sent before the charge info was updated, resulting in the host
thinking that the charger was still connected.
BUG=chrome-os-partner:55584
BRANCH=none
TEST=Connected charger to kevin 15 times and verified that the
icon was removed in 2-seconds or less.
Change-Id: I1a4e4e0f7cc23010210570fc261da8308d8e8070
Reviewed-on: https://chromium-review.googlesource.com/367809
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
BMP280 driver API is designed to work with motion
sensor task. The sensor sampling parameters are
configured optimally for handheld device in accordance
with BMP280 spec recommendation.
BUG=None
BRANCH=master
TEST=Tested on amenia; with appropriate .odr in board file
test command "accelread 4" returns raw pressure
value in Pa; accelinfo on 4000 shows Pa value.
Change-Id: I3f4c0c33a77dd317aa1425624d3cc7f4ec6b45a1
Signed-off-by: Divya Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/351660
Commit-Ready: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Add math_util, as matrix and vectors are used in this file.
BRANCH=none
BUG=none
TEST=compile when caller does not include math_util.
Change-Id: Ic8f6ada4f24a0f9d3c91dbf14bea98546089a08f
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373039
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Rotation by identity matrix from a to b fails if a != b.
BUG=none
BRANCH=none
TEST=Use identity matrix in test motion_lid.c, check test passes.
Change-Id: I852132ee8cd67063921077cd0b7d848d10a730e0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373722
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Do not power-on the AP unless battery can provide sufficient power
or the charger is negotiated to sufficient power.
BUG=chrome-os-partner:56494
BRANCH=none
TEST=Manually tested on Reef. Device can boot to OS without the
battery & cut-off battery.
Change-Id: Ib22bad81a29ccbb2fecc8e835148b627dd722988
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/374023
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
rk3399 doesn't use AP-controlled wireless power state and
CONFIG_WIRELESS isn't defined, so wireless_set_set() is in fact an empty
useless function.
BUG=None
BRANCH=None
TEST=Verify basic EC functionality on Kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6e3631012ca1f356555a847793050ebdef8eee52
Reviewed-on: https://chromium-review.googlesource.com/373643
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add Sensor FIFO, set the sensors in force mode since we haven't enabled
their FIFO.
BRANCH=kevin
BUG=b:27849483
TEST=Check kernel load cros-ec-ring.
Check ARC++ get accel info with AIDA64.
Change-Id: I1c4d5c1291d2c778fdabd8b8f4e6b6a370f37b04
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373140
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
