This patch defines CONFIG_DATA_RAM_SIZE, which indicates the size
of the RAM used for data, thus can be marked as non-executable.
If it's not defined, it defaults to CONFIG_RAM_SIZE. Thus, other chips
are not affected.
BUG=b:36037354
BRANCH=none
TEST=buildall. Run 'sysjump disable' on Reef and verify mpu_protect_ram
is successful.
Change-Id: I54d74fd1dabff7e1013fff2542fd02c3646803d1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/596518
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
In all states other than STATE_NONE, ensure that there is a deferred
call set after DEBUG_TIMEOUT so that debug mode exits if there is no
user activity.
BUG=b:64436180
BRANCH=None
TEST=make -j buildall. Also, verified following:
1. All combos still work fine
2. No user input for 10 seconds after entering debug mode:
++[42.318691 DEBUG MODE: Active!]
++[53.288057 DEBUG MODE: Exit!]
3. No user input for 10 seconds on sysrq path:
++[95.675863 DEBUG MODE: Active!]
+[97.200743 Button 'Volume Down' was pressed]
[97.526162 Button 'Volume Down' was released]
[107.528069 DEBUG MODE: Exit!]
4. No user input for 10 seconds on warm reset path:
+[149.374805 DEBUG MODE: Active!]
[150.863902 Button 'Volume Up' was pressed]
[151.193353 Button 'Volume Up' was released]
[161.199244 DEBUG MODE: Exit!]
5. Volup+Voldn still held down 10 seconds after entering debug mode:
+[213.704770 DEBUG MODE: Active!]
[223.705368 DEBUG MODE: Exit!]
Change-Id: I8a0aa448d31b4a746c7af2519ac6f61838bc9b99
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/603991
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When resuming from S3, it may take a while for the bus to become
alive again, so let's increase the timeout. 3 seconds is probably
a bit too long, but should work for our purpose: we just do not
want to be stuck in that state forever.
BRANCH=none
BUG=b:35587173
TEST=Use powerd_dbus_suspend to put poppy in S3. Press key, see
that hosts sometimes takes ~90ms, but sometimes up to 1.5s
to resume.
Change-Id: Ic800481b2b500fb68a8d1de16b11cbe77a4013d4
Reviewed-on: https://chromium-review.googlesource.com/569523
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the previous version of the code, we were counting ESOF (every
ms) to figure out when to clear the resume bit, and then using ESOF
counts again to wait for the USB interface to resume.
This missed the fact that ESOF (expected SOF) interrupts are not
triggered when SOF are actually received.
Somehow, this worked fine in most cases, except that sometimes the
last ESOF would race with the RXDP/RXDM going to state 2, and we
would not know that the resume completed successfully.
Let's also count SOF interrupts, and also take a received SOF as an
indicator of a successful resume.
While we're at it, trim down USB debugging messages, and add a line
when resume is successful.
BRANCH=none
BUG=b:35587173
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Add debugging in hammer code, make sure that usb_wake_done goes
back to 1 after resume succeeds.
Change-Id: I206c9c6b3066a3a337b6bd2370c9d0c6a9e2396c
Reviewed-on: https://chromium-review.googlesource.com/569522
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This commit enables the use of the TI BQ24932 charger detector.
Additionally, the charge ramping config option is turned on as the
ISL9238 supports HW based charge ramping.
BUG=none
BRANCH=none
TEST=`make -j buildall`
TEST=Flash modified version on npcx7_evb and verify no panics or asserts
are hit.
CQ-DEPEND=CL:601533
Change-Id: Ia6e132fc86b00b70f5d88894c34565be862f84b1
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601532
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Especially when PWM is active, base detection pin value can
vary widely: values from 138 mV to 270mV were measured. Let's
increase the detection interval to help with this.
Also, add reverse detection ADC values, for a possible future
implementation.
BRANCH=none
BUG=b:64193554
BUG=b:64370797
TEST=Plug/unplug staff a few times, look at BASE_DET values after
sideband pulse in DS3, check that detection always falls within
120-300 range.
TEST=Plug/unplug staff in reverse, see that value is about ~480 mV.
Change-Id: I226930572dfe583941b772f2037c3c4b7ef54e14
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601627
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The variable is_high_power was only used if a board was using charge
ramping. However, we can get rid of the variable entirely.
Additionally some of the intermediate gpio_signal variables can be
removed as well.
BUG=none
BRANCH=none
TEST=Build a board that uses the bq24392 but does not charge ramp.
Verify that there are no compliation errors.
Change-Id: I7edaa74f5029c08662d8c4a15c973beae9729fdf
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601533
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We need to ensure that the NVMEM variable containing the seed is properly
saved to flash, so we can restore it later whatever happens.
Add a call to writevars() which triggers the NVMEM commit rather than
accidentally waiting for it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=run twice 'trunks_send --u2f_cert --crt=/tmp/mycert.crt' and
hard-reboot the cr50 in between and see both certificates are
fully identical.
Change-Id: Iea4f9fdede4c0a2eeae1c59633caa16dbf70a66f
Reviewed-on: https://chromium-review.googlesource.com/602241
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In the function bd9995x_battery_charging_profile_settings, the current
values for trickle, precharge, and fastcharge were being set. Fastcharge
current level was being set via
charger_set_current(PD_MAX_CURRENT_MA). By calling this function with
a non-zero parameter, charging will always be enabled. In addition,
PD_MAX_CURRENT_MA is an input current limit and doesn't neceassrily
apply to the fastcharge current level which would be read from the
fuel gauge. The other side effect is that by enabling charging, VSYS
is being set to battery->voltage_min which reverts VSYS being set to
battery->voltage_max in the init routine.
Per Rohm, all charging profile registers should be set prior to
enabling charging. On Coral, enabling charging at this point was
leading to VSYS collapse when no battery was connected or a fully
depleted battery case. I also believe that enabling charging here
exacerbates other issues we've been running into with low battery
startup cases.
BUG=b:64388515
BRANCH=eve
TEST=On Coral tested both no battery a fully depleted battery
cases. Verified that without the call to charger_set_current() that
VSYS consistently collapses and that after removing this call, the
start up was stable and the battery begins charging.
Change-Id: Ice20ed5d8147fe9ad8faa754286a2ec8a784f8d8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/602493
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This commit adds support for the two board LEDs conforming to the Chrome
OS LED behaviour specification.
BUG=none
BRANCH=none
TEST=Flash a modified image on npcx7_evb with some LEDs connected. Fake
out chipset transitions and charge state states. Verify that LEDs
behave as expected.
Change-Id: If6d7a48cc4a363452fad172fa8efa0c5e603f6d7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601428
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Implement the RFC 6979 to get a deterministic integer k when doing the
ECDSA signing of the x.509 certificates used by U2F and particularly
individual attestation mechanism, rather than using the random generator
as per the original ECDSA algorithm.
So the generated certs have bit-for-bit identical signatures when the
content is identical.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and manually dump several individual attestation certs,
run the "rfc6779" console command when enabled.
Change-Id: I7b73eee6d5a863aae9a7eec49db884151bad5ab4
Reviewed-on: https://chromium-review.googlesource.com/558073
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If flash_ec was run without `servod` running and servod is needed, an
error message is printed out.
ERROR: Cannot communicate with servo. is servod running ?
However, in the case of flashing an stm32 without servod running,
execution would continue and would lead to claim_pty freezing and
thawing a bunch of unrelated processes. I believe the reason is that
the "die" was run in a subshell and therefore execution continued.
This commit now changes the way that servo_ec_uart_pty() works. If no
PTY is found, then flash_ec exits printing out the error message.
Additonally, claim_pty() will now warn if no arguments are passed to it
instead of finding random victims.
BUG=chromium:751386
BRANCH=maybe some fw branches.
TEST=Without servod running, try `./util/flash_ec --board hammer`;
Verify that flash_ec exists after the call to die.
Change-Id: I50784e0c43bbf0e32d408261cb83029377b576a0
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/598506
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
this adds CLI support for the new PD_CHIP_ON subcommand of
ec_pd_control_cmd.
TEST=rebuilt ectool to see if "ectool pdcontrol on" does something useful.
copied new build to electro:
ec> i2cxfer rlen 0 0x50 1 0x10
Unknown error
Usage: i2cxfer r/r16/rlen/w/w16 port addr offset [value | len]
ec>
ap$ /tmp/ectool pdcontrol on 0
ec> i2cxfer rlen 0 0x50 1 0x10
Data: aa2934ad000000000000010000050500
ec>
so, "pdcontrol on" had the desired effect of bringing the chip
out of sleep mode.
BRANCH=none
BUG=b:35586895
Change-Id: I5275254fe797dda921a352b72f1683e1967efe58
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/599361
Reviewed-by: Shawn N <shawnn@chromium.org>
add a subcommand to the PD_CONTROL message to power up a specific
TCPC. in practice, this typically just takes the TCPC out of sleep
mode for cases where sleep mode is controlled by the EC.
under the covers, board_set_tcpc_power_mode() gets a weak function
definition so we don't need to special case this everywhere.
TEST="make buildall" passes; "make tests" passes for reef.
BRANCH=none
BUG=b:35586895
Change-Id: Ib50e265d11eca10c3714049d8cfdf2657eff48c1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596796
Reviewed-by: Shawn N <shawnn@chromium.org>
One of the items that the presubmit check checks is that if any source
file has been modified, the unit tests are run again. However, flash_ec
is included in the list of files. This commit removes flash_ec from the
candidates because it's not run in any unit tests anyways and it's a
shell script that is not compiled.
Additionally, ignore changes to the presubmit_check.sh itself.
BUG=None
BRANCH=None
TEST=modify flash_ec, verify that presubmit check doesn't complain about
not running make buildall.
Change-Id: I473f269c7f0bba9be3216fcec39f266d896fb908
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/598505
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This code looks fine either inside or outside of the if clause. I chose
to keep it outside and just re-indent it since the previous test
didn't look at the cnt value, so the previous test could pass, and this
test could fail even if cnt wasn't updated.
BUG=None
TEST=build
Change-Id: I869af54f9093ee8a2f855d7a71ea6acf3d3e16f6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596490
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When an image with non-default board ID fields is released, the
generated tarball name should include the Board ID values to allow to
tell between images of the same version locked for different boards.
BRANCH=none
BUG=none
TEST=ran create_released_image.sh with and without specifying Board ID
fields, observed properly named file generated in both cases
Change-Id: I5f60a0e547d93c78caee34a9c307fc93f824b2ae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597121
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
We'd like to know touchpad vendor/product id, as well as currently
running FW version. This CL does that by adding a new
UPDATE_EXTRA_CMD_TOUCHPAD_INFO command.
We also make the interface more generic by adding a CONFIG_TOUCHPAD
configuration option, even though we only support Elan touchpads
currently.
BRANCH=none
BUG=b:63418037
TEST=Flash hammer, ./usb_updater -t
Change-Id: Icce3c785eb3235bcc50b2ae7c0227ce11cbc9f2b
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593000
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Leaving the I2C passthrough to the trackpad open causes security
issues, let's make sure we disable that in the field, whenever
the WP screw is on (and system is locked, which will be synonymous
for production firmwares).
BRANCH=none
BUG=b:37926507
TEST=- In board/hammer/board.h, uncomment CONFIG_SYSTEM_UNLOCKED
- Flash hammer (both RO and RW)
- Trackpad updating still works (touchpad_updater on DUT)
- Make sure WP is on
dut-control -p 9000 fw_wp_vref:pp3300 fw_wp_en:on fw_wp:on
- hammer console: flashwp true; reboot
- Trackpad updating fails (cannot read iap password.)
Change-Id: I247bb9c62ea00d6cb3631c919d27305f4d291d68
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/595290
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The new signer (version: 1.2 00840c1b6) allows hex values in the
manifest, which means there is no need to explicitly convert the
values before adding them to the manifest.
A nice side effect of this is the fact that there is no need to care
about the sign of the values any more, the signer does the right
thing.
BRANCH=none
BUG=none
TEST=built an image using the following invocation:
$ make BOARD=cr50 H1_DEVIDS='0x12009015 0x90e95664' -j
and successfully ran it on a device. Note that the old signer was
chocking on hex values exceeding 0x7fffffff, the new one handles
them properly.
Change-Id: I08c0339f922d287c82d56fb51570bfbf7107531e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598728
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Save a small amount of time when the USB resume is making the chip boot
from deep-sleep by removing the verbose serial traces in main and
increasing the usb initialization priority.
This brings us from borderline timings wrt the USB specification to a
reasonable margin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:38160821
TEST=run on hotelgolf, go to deep-sleep on USB-suspend.
On USB resume, measure the time from CPU boot to the end of usb_init
using the CPU cycle count. We are shaving 1.3ms.
Change-Id: Ia5bf69c0ca26748dec59a87f3908a5fe68296b36
Reviewed-on: https://chromium-review.googlesource.com/563206
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We can re-use our pd_log FIFO for other purposes, such as TPM logging.
Carve out event_log, a generic logging module which pd_log is compatible
with.
BUG=b:63760920
TEST=On kevin, verify PD logging is still functional and entries are
seen in dmesg.
BRANCH=None
Change-Id: I8e6ad6f93e9eebc676aca64652c60f81da471a94
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597314
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
There have been some new methods added to servod to retrieve the serial
numbers of the servos attached. Prior to this, with a servo micro
connected to a servo v4, retrieving the serial number would always
return that of the servo v4. This would cause flashing to fail. This
change updates the method to retrieve the serial numbers.
CQ-DEPEND=CL:597209
BUG=chromium:740026
BRANCH=maybe some fw branches.
TEST=With updated hdctools, flash a kevin using a servo micro connected
to a servo v4.
TEST=Flash kevin with a servo v2.
TEST=Attempt to flash a hammer and verify that the only issue is
stm32mon not being able to determine the startup of the monitor mode
(since I don't actually have a hammer).
Change-Id: I82c2907d689311fe65717a833390b8d0f6e15a94
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/597211
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Remove the code switching between PHY0 and PHY1. We now only use the CCD
PHY on all boards.
BUG=b:36488273
BRANCH=cr50
TEST=ccd works fine. cr50 usb doesn't show up on the AP. You cannot
switch the PHY on cr50.
Change-Id: I6ff641af9d7129daa8592f952f9df97c3862395b
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595201
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The script assumes that usb_updater is present in the PPATH, but it is
not guaranteed to be available.
Use the version from the ec tree or stop if it is not available.
BRANCH=none
BUG=none
TEST=verified that the script uses proper instance of usb_updater
Change-Id: I3b861953e8d5d509b99131685e86aaf7a0693d23
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597120
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Instead of invoking $(basename $0) multiple times, cache it in a
variable.
BRANCH=none
BUG=none
TEST=verified that the script still reports proper name when printing
error messages.
Change-Id: Iabdf40592cb4cecc975a48d93169f46614ce84c6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597119
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When the chip is used in the factory harness, the AP device state is
set to off, which prevents tpm reset from being invoked, which in turn
prevent the certificate from being copied into NVMEM.
Let's not wait for the AP to be up when running in chip factory mode.
BRANCH=cr50
BUG=b:63686091
TEST=running cert installation procedure produces SPI dummy byte of
c0c0c0c0... after the successful installation and of cbcbcbcb...
after repeated cert installation attempts.
Change-Id: Ibc4ff50511dccd8412a380ec03fc5ff8a14b0282
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/594953
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In the "make buildall", since no BOARD is defined, core/minute-ia
has to use whatever toolchain value set by previous board build.
"arm-none-eabi-" is used instead of "i686-pc-linux-gnu-" and causes
build failed.
BUG=none
BRANCH=None
TEST=Including Soraka ISH board, make buildall passed.
Change-Id: I2682e4b73f608756842870e584f559166354b00b
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/595221
Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Kyoung Il Kim <kyoung.il.kim@intel.com>
Add a pulldown to spi mosi and clk pins. The floating signals are
causing power issues with the spi buffer. This change adds pulldowns
to prevent the issues.
BUG=b:38509318
BRANCH=cr50
TEST=eve power drops to 2mW and reef power numbers are unchanged. Flash
the EC and AP on both boards using ccd.
Change-Id: I595920f461a67effcbdb52a4334683b6eca2b3b2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595213
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
AP and EC UART now use the CCD V1 capabilities to determine when
access is allowed. Transmit to AP and EC can be toggled independently
from read access to output from those UARTs.
Note that disabling read access disables both transmit and receive.
That is, it's not possible to set a UART where transmit is allowed but
receive isn't. Why would you want to do that, anyway?
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1
ccdoops
ccdset cr50fullconsole always -> so we can use ccd command for testing
ccd -> AP RX+TX, EC RX+TX
ccdset uartecrx unlesslocked
ccdset uartectx ifopened
ccdset uartaprx always
ccdset uartaptx unlesslocked
ccdunlock
ccd -> AP RX+TX, EC RX
ccdlock
ccd -> AP RX, EC disabled
ccdoops
ccdset cr50fullconsole always
ccd -> AP RX+TX, EC RX+TX
ccdset uartaprx ifopened
ccdlock
ccd -> AP disabled, EC RX
Change-Id: I55db5897bb52cd60658ab221eadf5c59fc86744a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595196
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add usb_i2c_board_is_enabled().
On Cr50, this is now also connected to the I2C CCD capability. The
USB-I2C bridge can only be used when the capability is available.
On other platforms (Servo V4, etc.) where usb_i2c_board_enable() is
a no-op, add a dummy implementation which always returns true.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1
Connect host PC to dev board USB port
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
dut-control pp3300_ec_shv_reg --> fail, error 0x8001
ccdoops --> reset I2C config
ccd i2c disable --> I2C disabled
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
dut-control pp3300_ec_shv_reg --> fail, error 0x0006
ccd i2c enable --> I2C enabled
ccdunlock --> I2C disabled
ccdoops --> I2C enabled
ccdset i2c unlesslocked
ccdlock --> I2C disabled
ccdunlock --> I2C enabled
Change-Id: Ia3df32e239a5f7c5915bc6c7e408ce0dc8b26c89
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590577
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In eSPI systems, when the Host performs a data read from the Shared
Memory space, the returned data may be corrupted. This is a result of
the Core-to-Host access enable bit being toggled (by toggling CSAE bit
in SIBCTRL register) during an eSPI transaction.
The workaround in this CL is to set CSAE bit to 1 during initialization
and remove the toggling of CSAE bit from other EC firmware code.
(i.e., let the CSAE bit be always 1.)
BRANCH=none
BUG=none
TEST=No build errors for make buildall. Flash poppy ec image, make sure
it can boot to OS. Run "ectool version" over 100000 times, no error
occurs.
Change-Id: I7aac6805ece64e8f77964d4acb026d9871cd2ebe
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/590396
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The primary purpose of the Pericom PI3USB9281 is for BC1.2 detection.
Therefore, move the driver to the bc12/ directory.
Additonally, rename the config option to match.
CONFIG_USB_SWITCH_PI3USB9281 => CONFIG_BC12_DETECT_PI3USB9281
BUG=None
BRANCH=None
TEST=`make -j buildall`
Change-Id: I02f17064c0625e62d6779f895e69899c24898f74
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/594710
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The BQ24932 is a dual single-pole single-throw USB 2.0 high-speed
isolation switch with charger detection capabilities. The device's
charger detection circuitry can support USB Battery Charging
Specification version 1.2 (BC1.2), Apple, TomTom, and other non-standard
chargers.
BUG=None
BRANCH=None
TEST=`make -j buildall`
TEST=Enable support for the BQ24392 on a board. Verify that it
complies.
Change-Id: I82f426f1eedabdbb6b951a6ce0252135de3368db
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/592133
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
id only really needs 4 bits (16 touch events should be more than
enough), so we can steal 2 bits from that field.
We also reorder the fields to make sure that width/x are aligned
on 8-bit boundary.
BRANCH=none
BUG=b:63936194
TEST=Flash hammer, touchpad works, ABS_PRESSURE > 255 is reported
when a palm is pressed on the touchpad.
Change-Id: I1abf1bf53cc9dd998082cea5dc7cd3be17f99ec6
Reviewed-on: https://chromium-review.googlesource.com/583297
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: KT Liao <kt.liao@emc.com.tw>
This version will be bettter sutied for chip manufacturing environment
(no contention with the test rig GPIO settings and formal confirmation
of successful certificate installation).
BRANCH=cr50
BUG=b:63686091
TEST=none
Change-Id: I6d394493b824c9d79bca4785d3d44b33f322b899
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/583990
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When in factory mode, we should not be trying to figure out board
strapping options, just enable SPI interface so that the tester can
communicate with the chip.
Also, to close the loop with the tester, let's add indication of the
cert installation result, by setting the two top bits of the DUMMY
(aka underrun) character to 1 and the lower bits to the endorsement
operation result (0 means success, nonzero values communicate
different failure modes) and by preventing the TPM driver from sending
anything but underrun chars on the SPI interface.
BRANCH=cr50
BUG=b:63686091
TEST=pending
Change-Id: I1a22ed6988ad87dd929a393359c4604e6ecd3b58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578651
Reviewed-by: Nick Sanders <nsanders@chromium.org>
When installed in the factory test rig, the DIOB4 pin is set to high
by the moment the RW section starts.
Software behavior needs to change to comply with the factory test rig
requirements. Define the GPIO and add a function to report the factory
mode state.
BRANCH=cr50
BUG=b:63686091
TEST=tested along with the rest of the stack of patches.
Change-Id: I8c4158fc75138d717fc009496365c8e61b42a890
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/579584
Reviewed-by: Nick Sanders <nsanders@chromium.org>
