Pin rename only; no functional changes. See also b/72426192 for
earlier functional changes.
BUG=b:77301519
TEST=make -j buildall
BRANCH=none
Change-Id: I18e71118e584a5b36ba001bac24951929d2c93ff
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1087207
Reviewed-by: Edward Hill <ecgh@chromium.org>
This patch configures the GPIO pin connected to the reset pin of
Anx7447 as push-pull low. When the EC start up from reset, it
pulls it high, waits for 1 msec, then pulls it low. This allows the
tcpc to recover from a hang and guarantees it to start from a known
state.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:79868559
BRANCH=none
TEST=Verify Anx7447 port charges on Nami with a rework.
Change-Id: Ib7683e20160edf0f320a8c6af25f5f74d4f74538
Reviewed-on: https://chromium-review.googlesource.com/1077015
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
we do not need to configure alt function on GPIOC2 to get PWM1
functionality. alt function here actually means I2C6_SCL0 and that
also affects the function of GPIOC1/I2C6_SDA0 which is definitely not
what we want.
BUG=b:94613023
BRANCH=none
TEST=able to power-off the AP
Change-Id: I68abfb7e8c64faffbe0cea0a2cc8ca6a4a620ba3
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1086469
Commit-Ready: caveh jalali <caveh@chromium.org>
Tested-by: caveh jalali <caveh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This is just a dead code elimination; no functional changes. See also
b/72426192 for functional changes.
BUG=b:77301519
TEST=power cycle on grunt EVT
BRANCH=none
Change-Id: Id9f60d14eb2a7df9013f779b05a54638ad62971f
Signed-off-by: Jonathan Brandmeyer <jbrandmeyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1083317
Reviewed-by: Edward Hill <ecgh@chromium.org>
IIN_DPM register reflects the actual input current limit programmed
in the register, either from host or from ICO. After ICO, the current
limit used by DPM regulation may differ from the IIN_HOST register
settings.
BUG=b:80279932
BRANCH=none
TEST=Manually tested on BIP
Used BC1.2 DCP charger 'charger' command yield 900mA while
charge ramp set to 2.4A.
Change-Id: I6389205bd70d7729e9dd810fef3dfbf83a7d8c65
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/1080343
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Add support to enable the architectural D-cache on ARMv7-M CPU
supporting it.
Update the MPU code in order to be able to declare an 'uncached' RAM
region (e.g. to store the DMA buffer).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=poppy
BUG=b:78535052, b:75068419
TEST=with the following CL, on ZerbleBarn, boot and capture a finger
image.
Change-Id: I275445e7c0b558cedc3e7d6fc6840ff9b4b76285
Reviewed-on: https://chromium-review.googlesource.com/1032776
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With the Cortex-M7 core on STM32H7, the imprecise bus abort triggered by
the flash permission check might be propagated rather than ignored as we
might have gone through the ignore_bus_fault(0) before the exception
actually happens.
Add a barrier to avoid this case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=poppy
BUG=b:75068419
TEST=On ZerbleBarn with MPU on and caches enabled, verify that the
flash_set_protect() in rwsig_jump_now() no longer triggers an imprecise
abort.
Change-Id: I8ed4f13cb7a379964919bf389542221517a34c17
Reviewed-on: https://chromium-review.googlesource.com/1080809
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Set the GPIO output driving the PCH interrupt as push-pull as the other
side has a 100K pull-down.
No longer modify the GPIO config in S3, the PCH doesn't seem to work
this way, but needs to be confirmed.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=poppy
BUG=b:78613978
TEST=On Meowth, monitor /proc/interrupts before and after suspend/resume
cycle, no more interrupt storm on Int 46 / chromeos-ec.
Change-Id: I6198412d791ed9810ffa208fffbb8f378421decd
Reviewed-on: https://chromium-review.googlesource.com/1032775
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
It matches the SS path, in which both port-0 and port-1 connect to the
hub.
BRANCH=none
BUG=b:74395451
TEST=Tried plugging USB 2.0 disk to port-0 and port-1, both bootable.
Change-Id: Ic0264657fbe126242a419ef33ce07bc2599375ee
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1082981
Reviewed-by: Douglas Anderson <dianders@chromium.org>
The EC needs to enable/disable the NVMe power rails on bootup and
shutdown. This commit just adds these controls in during chipset
startup and shutdown.
BUG=b:73258414
BRANCH=poppy
TEST=Flash nocturne, verify that rails come up on boot up and are turned
off on shutdown.
Change-Id: I3dc8c17255294c0bbf8638ea3ee3fcfaa321929b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1067947
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
these changes reflect the hardware changes made between version 0 and
version 1 of the atlas board.
note: these changes are not backward compatible - version 0 of atlas
is no longer supported.
BUG=b:78309559
BRANCH=none
TEST=works fine on atlas version 1
Change-Id: Ia519f161c66066e02e9ddce7560a8fe2b7e74882
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1045730
Commit-Ready: Caveh Jalali <caveh@google.com>
Tested-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
There was a recent change to save the manual setting of charge current
and voltage, however it was done so assuming that the parameters were
set via the host command interface. (CL:922069) However, there are times
where the charge voltage/current would like to be manipulated without
booting the AP. This commit simply makes the EC console command work
again.
BUG=None
BRANCH=None
TEST=make -j buildall
TEST=Flash nocturne, `chgstate idle on; charger current 256; charger
voltage 7400`; verify that the charge voltage and current is actually
changed.
Change-Id: Id250d9704f8509162518495556603950248fb267
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1081120
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Currently, the power LED pulses in sleep state on Pantheon. This patch
makes it blink with 25% duty. That is, the LED turns on for 1 sec then
turns off for 3 sec.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:79733195
BRANCH=none
TEST=make BOARD=nami
Change-Id: I0ebd2778b9b6551f2313ea8f8648c69324e02368
Reviewed-on: https://chromium-review.googlesource.com/1069337
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Split battery info between baseboard and board, following the
Octopus example. This will allow Grunt and Careena to define their
own lists of supported battery types.
This also adds CONFIG_BATTERY_REVIVE_DISCONNECT support, and
checks the charge/discharge FET status.
BUG=b:79704826,b:74018100
BRANCH=none
TEST=Grunt still boots ok.
Change-Id: I6e82ac5e48f9aabf59b63add253108513f0a6b60
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1072039
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
The default setting of the ROP PMIC's V085A output voltage is incorrect
for our application. This commit changes the output voltage to actually
be 0.85V.
BUG=b:80271678
BRANCH=poppy
TEST=Flash nocturne and verify that V085A is ~0.85V.
Change-Id: I3c6c7396bc8b896620aab7e4719f8a14b4a46e4a
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1077085
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
An ADC conversion requires ~10 msec. However, if the bq25703 is in low
power mode, then this conversion time jumps to ~55 msec. This CL adds
a method to exit/enter low power mode and adds a call to exit low
power mode prior to starting the ADC conversion. Following the
conversion, low power mode is entered again.
BRANCH=none
BUG=b:79771760
TEST=Connected AC power and verified that EC console error message
'Could not read input current limit ADC' is no longer shown. In
addition, had instrumented this the ADC conversion with GPIO signals
and verified the conversion times before/after exiting low power mode.
Change-Id: I13f36e6261e219adbc8624f71bf7916bbc631b10
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069768
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
We added a cr50 vendor command to control factory mode. This change adds
gsctool support for using the command.
gsctool -F [enable|disable] can be used to set factory mode. You can't
use it to get the factory mode setting, because factory mode is
indistinguishable from other forms of ccd. The regular ccd info can be
used instead gsctool -I.
BUG=b:77543904
BRANCH=cr50
TEST=none
Change-Id: I715e296c323be20bab0b54a2f94a380b61f74cd2
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069370
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The factory reset command can be used to enable ccd factory mode. The
command can open ccd if write protect is removed and ccd hasn't been
restricted. Right now we check FWMP and the ccd password before allowing
factory reset. Factory reset cannot be used to get around anything that
disables ccd.
This adds 72 bytes.
BUG=b:77543904
BRANCH=cr50
TEST=Try enabling factory mode using factory reset. Verify setting write
protect, setting the FWMP disable ccd bit, or setting a ccd password
prevents factory reset from enabling factory mode.
Change-Id: I6e203bf6068250f009881aa95c13bc56cb2aa9e7
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069369
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, console_init calls cflush() twice, once before
"Console is enabled" string is printed, once afterwards.
The reason is that firmware_ECBootTime looks for that string,
and it may get corrupted/interleaved with others if the EC
is busy during initialization.
The problem here is that the CONSOLE task may have higher
priority than other tasks (for good reasons), but, on boot,
there are other more critical tasks that need to run (e.g.
RW image verification), rather than busy-looping waiting for
the console to be flushed.
By fixing firmware_ECBootTime to not look for the string anymore,
we do not need those 2 console flush.
BRANCH=poppy
BUG=b:35647963
BUG=chromium:687228
CQ-DEPEND=CL:1075832
TEST=Flash staff, see that RW verification starts at 0.001037
instead of 0.028087 (=> 27 ms faster).
TEST=test_that -b $BOARD $IP firmware_ECBootTime
Change-Id: I794e48eb69cc647c4595fd80265adee4a434d566
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1073180
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We need to control the console channels for cr50 testing, so we need
access to chan even if the console is restricted. Make chan a safe
command so it is always accessible.
BUG=b:80319784
BRANCH=cr50
TEST=on cr50 make sure the command is accessible no matter the console
state
Change-Id: Ia392f32c319c1acf9bb97b97d7f72c7e56427ce3
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1079452
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch makes Sona follow the standard LED pattern for single LED
systems. Sona has two LEDs but both are connected to the same pin.
This increases userbility because LEDs are visible from each side
and users don't have to learn two different sets of patterns (i.e.
one for left LED and onother for right LED).
* Charging Amber on (S0/S3/S5)
* Charging (full) White on (S0/S3/S5)
* Discharge in S0 White on
* Discharge in S3/S0ix Alternate pulse (up-down-off-off)
* Discharge in S5 Off
* Battery Error Amber on 1sec off 1sec
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:80135370,b:74940319
BRANCH=none
TEST=Verified LED behaviors in S3, S0, charge, discharge on Sona
Change-Id: I1bd53c7c60529a8b813eabc338876af6d089ec82
Reviewed-on: https://chromium-review.googlesource.com/1074226
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jack Huang <jachuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Grunt and Careena hardware does not support sourcing 3A over USB-C
so reduce what we advertise to 1.5A.
BUG=b:78908554
BRANCH=none
TEST=Grunt advertises 1.5A Source Cap on both ports
Change-Id: Ifd3ddf45445ae69c5988dee4f66f21056b4b0f96
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1077096
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
We're doing a bit of refactoring to break out factory mode into its own
file. Now factory reset and rma reset will be two methods of entering
factory mode. Factory mode can be disabled with the disable_factory
vendor command.
Factory mode means all ccd capabilities are set to Always and WP is
permanently disabled. When factory mode is disabled, all capabilities
are reset to Default and WP is reset to follow battery presence.
This adds 56 bytes.
BUG=none
BRANCH=cr50
TEST=verify rma reset will enable factory mode.
Change-Id: I21c6f7b4341e3a18e213e438bbd17c67739b85fa
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1069789
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Using the p256 curve is beneficial, because RMA feature is currently
the only user of the x25519 curve in Cr50, whereas p256 support is
required by other subsystems and its implementation is based on
dcrypto.
The p256 public key is 65 bytes in size, appropriate adjustments are
being made for the structure storing the server public key and the key
ID.
The compact representation of the p256 public key requires 33 bytes,
including the X coordinate and one extra byte used to communicate if
the omitted Y coordinate is odd or even.
The challenge structure communicated to the RMA server allows exactly
32 bytes for the public key. To comply, the generated ephemeral public
key is used in compressed form (only the X coordinate is used).
For the server to properly uncompress the public key one extra bit is
required, to indicate if the original key's Y coordinate is odd or
even. Since there is no room for the extra bit in the challenge
structure, a convention is used where the generated ephemeral public
key is guaranteed to have an odd Y coordinate.
When generating the ephemeral key, the Y coordinate is checked, and if
it is even, generation attempt is repeated.
Some clean up is also included: even with debug enabled, generated
challenge is displayed only once as a long string, convenient for
copying and pasting.
The new feature is not yet enabled, p256 support on the RMA server
side is not yet available.
Enabling p256 curve for RMA authentication saves 5336 bytes of the
flash space.
BRANCH=cr50, cr50-mp
BUG=b:73296606
TEST=enabled CONFIG_RMA_AUTH_USE_P256 in board.h, generated challenge
and verified matching auth code generated by the rma_reset
utility.
Change-Id: I857543c89a7c33c6fc2dc00e142fe9fa6fc642cf
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1074743
Reviewed-by: Randall Spangler <rspangler@chromium.org>
ID pins are considered additional KSOs while keycode scanning works
for the existing KSI0 ~ KSI7. While diriving ID pins, the state of
interconnection between ID pins and KSI pins could be used for
identifiers to tell keyboard itself. (e.g. US, Japan,and UK keyboard)
BRANCH=master
BUG=b:80168723
TEST="make -j buildall"
TEST=Verified 5 distinct keyboard samples w/ different Language ID values
on the same reworked Coral, which VOL_UP and VOL_DOWN were reworked
for ID pins. crrev.com/c/1053617 is my experimental patch on top of
this for further verification
Change-Id: I1d6e647df74c50d60bc1264c045b2587d0bf23d8
Signed-off-by: paris_yeh <pyeh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1068951
Commit-Ready: Paris Yeh <pyeh@chromium.org>
Tested-by: Paris Yeh <pyeh@chromium.org>
Reviewed-by: Paris Yeh <pyeh@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The ec_boot_mode is used for flashing EC on STM32 and NPCX chips.
The ec_boot_mode pin is an open-drain GPIO. Doing save/restore is
destructive. For example, if DUT is unpowered (ec_boot_mode is "on"),
doing save/restore will force it outputting to "on". We should not
put it to the save/restore list. Instead, set it back to "off" on
exit.
BRANCH=none
BUG=b:80305869
TEST=Ran flash_ec when DUT is unpowered -> failed as expected.
Reran again when powered. Checked EC UART showed-up afterward.
Change-Id: Iecf4b663fe9ae75a673a29a66505a4121d29888c
Signed-off-by: Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1073646
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We have determined the checks to run for board_is_first_factory_boot.
This change updates cr50 to check for those conditions and enable ccd
when the system determines that it is first boot in the factory. This
will check that the board id is erased and the inactive image is a GUC
image.
The factory updates Cr50 from the GUC image, because those GUC images
don't have support for everything they need to do in the factory. To
determine that cr50 just recovered from that factory update, it will
check that the GUC image is still in the inactive region and no board id
is set.
There are 2 images installed in GUC 0.0.13 and 0.0.22, so cr50 will
check these versions. Future GUC images will have a field in the header
declaring that they are a GUC image. I still need to create the GUC
field in the header and check that in inactive_image_is_guc_image.
Factory mode can't be enabled on deep sleep resume. It is only enabled
after power-on reset or hard reset.
This change also moves factory stuff into a factory_mode file instead of
keeping it in board.c
This adds 200 bytes.
BUG=b:77543904
BRANCH=cr50
TEST=Verify factory mode is only enabled when cr50 recovered from
reboot not deep sleep resume, 0.0.13 or 0.0.22 are in the inactive
region, and the board id is erased.
Change-Id: Ibece878049658493e8ad159121ada63d7a6f6b79
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1059864
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is a potential loop:
(1) We throttle AP when we see under-voltage.
(2) VBAT bumps because throttling starts. From our experiment,
AP throttling saves ~1A, and thus VBAT increases by ~80mV.
(3) VBAT hasn't hit BAT_LOW_VOLTAGE_THRESH for BAT_UVP_TIMEOUT_US,
so we stop throttling.
(4) VBAT again drops below BAT_LOW_VOLTAGE_THRESH.
(5) Go back to (1).
So let's introduce a hysteresis to under-voltage throttling.
We stop throttling only when we are confident that even if we stop
throttling, the battery voltage will stay above BAT_LOW_VOLTAGE_THRESH.
BUG=b:73050145, chromium:838754
BRANCH=scarlet
TEST=manually test on scarlet
Change-Id: Ic0c17a7d37d5d6ee38c7b19f9b65d17421e55cbc
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1070568
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
we normally try to find out a few things about a battery (like charge
level) before actaully applying charging power to it. when the
battery is completely discharged, the controller on the battery can't
respond as it is not self-powered. so, we have to avoid all
operations that depend on the battery responding in the battery
discovery/initialization path.
as long as we report that a battery is present and it is not
responsive, the charger task will enter ST_PRECHARGE which means it'll
provide a "precharge" current to the battery to try to talk to it.
this allows the battery's controller to report battery parameters
allowing our charger task can do the right thing.
BUG=b:79354967
BRANCH=none
TEST=atlas now discovers the discharged battery reliably
Change-Id: I5e5a3abda07508eb791b712fb2f9b9f5fe383e07
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065492
Commit-Ready: Caveh Jalali <caveh@google.com>
Tested-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Caveh Jalali <caveh@google.com>
Use a queue now for sync events, this will allow multiple interrupts to be
called before the motion sense task executes. The events (including
timestamps) get stored in a small queue. 8 events for the queue size should
be plenty, most applications will have latency concerns anyway once we
get a couple of queued up events.
Also changed the init function to be a little bit more robust to race
conditions. Added count argument to the "sync" simulation command to test
the queue behavior.
BRANCH=master
BUG=b:73551961, b:67743747
TEST="sync 4" yields 4 events on the AP, whereas before it would only
give the AP the last event.
Change-Id: I9fcb1fb8b35eb5f8ffcc21afbfcb0f0d9bc33804
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1065149
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Decreases verification time from 923ms to 785ms.
Optimized version do not really help in RW, as they just increase
the image size (which also increases verification time).
BRANCH=fizz
BUG=b:77608104
TEST=make BOARD=fizz -j, flash fizz, check timing.
Change-Id: Ia8c36c35c0321c1995dc1cede7b27f7636037795
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1075908
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Some devices have GPIO pins that control USB port power connected to
the EC, so they cannot be toggled by ACPI. This patch adds a memory
map between the EC and ACPI that can be used on such devices. It can
hold the power state of up to 8 USB ports. Currently, only dumb power
ports are supported.
BUG=chromium:833436
BRANCH=fizz
TEST=On a fizz that runs BIOS with EC_ACPI_MEM_USB_PORT_POWER mapped,
check that both reads and writes are propagated.
Change-Id: I413defcb9e4d234fea7f54d46b6b8a1a10efa31e
Signed-off-by: Emil Lundmark <lndmrk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069273
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Since the PS8751 is now driving the EN_SNK GPIO on the PPC, we cannot
reset without a battery otherwise we will brown out the board.
BRANCH=none
BUG=b:78896495,b:78021059
TEST=verified with reworked board.
Change-Id: Ibadf46de922c49f5fdd08c43991e71f852ff7600
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1067711
In RSA, we often need to actually compute (a*b)+c+d: provide some
assembly optimized functions for that.
With -O3, 3072-bit exponent, lower verification time from 104 ms to
88 ms on STM32F072 @48Mhz.
BRANCH=poppy
BUG=b:35647963
BUG=b:77608104
TEST=On staff, flash, verification successful
TEST=make test-rsa, make test-rsa3
TEST=make BOARD=hammer test-utils test-rsa3, test on board
Change-Id: I80e8a7258d091e4f6adea11797729ac657dfd85d
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1071411
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Dumb USB ports do not have the same notion of charge mode as smart
ports. However, the header common/usb_charge.h declares a function for
changing charge mode that the dumb USB port power implementation does
not define. Instead, it defines a similar function with a different
name, albeit with other allowed values for its second parameter.
This patch makes the names the same so the function can be used by
simply including the aforementioned header file.
BUG=none
BRANCH=fizz
TEST=emerge-fizz chromeos-ec
Change-Id: I87863f87f32f538cc1c723d9299afcc7353e1852
Signed-off-by: Emil Lundmark <lndmrk@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069272
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
