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>
Because that's what it means. That is, it reports the state of
uartn_tx_connect(), not uartn_enable().
No functional changes; just a rename.
BUG=none
BRANCH=cr50
TEST=make buildall -j
Change-Id: Ie2273b277bd73a40307be7ec215417c1225cd567
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590859
SPI access now depends on CCD_CAP_AP_FLASH and CCD_CAP_EC_FLASH.
usb_spi_state.enabled_host and .enabled_device are now bitfields which
depend on which SPI interface is enabled. This was implied before by
a single & comparing enabled_host to enabled_device, but is now
explicit so that the device can decide to enable just a subset of
buses.
BUG=b:62537474
BRANCH=cr50
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
In test protocol below, (test EC) means this command:
sudo flashrom -p raiden_debug_spi:target=EC --wp-status
And (test AP) means this command:
sudo flashrom -p raiden_debug_spi:target=AP --wp-status
"pass" means no console warning about "SPI access denied"
"fail" means console warnings about "SPI access denied"
To get even more confirmation, in chip/g/usb_spi.c temporarily
put this debug statement at the end of usb_spi_deferred():
CPRINTS("SPI res=%d", (int)res);
Pass is res=0, fail is res=5.
ccdoops
(test AP) --> pass
(test EC) --> pass
ccdunlock
(test AP) --> fail
(test EC) --> fail
ccdoops
ccdset flashap unlesslocked
ccdunlock
(test AP) --> pass
(test EC) --> fail
ccdoops
ccdset flashec unlesslocked
ccdunlock
(test AP) --> fail
(test EC) --> pass
Change-Id: I3d37d088b748832f164f2ca0ff29a93d6532ebed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590858
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add support for OTP memory: if needed store serial number in first bank.
BUG=chromium:746471
BRANCH=none
TEST=On sweetberry, check we can write serial number with serialno
command. Check serial number survive a firmware update.
First, check without write protect, check we can write 0s (but not 1s)
serialno
Serial number: NNNNNNNNNNNNNNNNNNNNNN
>
> serial set MMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Saving serial number
Serial number: LLLLLLLLLLLLLLLLLLLLLL
After lock enabled, check we can not overwrite.
> serial set AMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Saving serial number
Serial number: LLLLLLLLLLLLLLLLLLLLLL
Access Denied
Check that serialno returns "Uninitialized" if it was never set.
Change-Id: I9ab08486a7c3e1958e964649640d69b5b70947e3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580290
Reviewed-by: Nick Sanders <nsanders@chromium.org>
One Time Programmable memory can be used to store permanent data like
serial numbers.
Reorganize the code to support writing serial number to OTP, in
addition to pstate (if using its own memory bank) or autogenerate from
unique id (hammer).
+ Add CONFIG_OTP to enable OTP code
+ Add CONFIG_SERIALNO_LEN to indicate the size of the serial number
string. Currently set to 28, when USB serial number is needed.
+ Expose flash_read|write_pstate_serial and add otp_read|write_serail,
remove more generic flash_read|write_serial.
+ Make board_read|write_serial generic, declared outside of USB subsystem.
Priority order to read|write serial string:
- board definition (like hammer)
- pstate location, if stored in its private memory bank
- otp area
If none of these methods are available, a compilation error is raised.
BUG=chromium:746471
BRANCH=none
TEST=compile
Change-Id: I3d16125a6c0f424fb30e38123e63cf074b3cb2d3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580289
Reviewed-by: Nick Sanders <nsanders@chromium.org>
board.h and config-chip.h should only be called from config.h, otherwise
some #define may not be set properly.
BUG=chromium:746471
BRANCH=none
TEST=Found a bug while compiling OTP changes (c/580289/)
(https://luci-milo.appspot.com/buildbot/chromiumos.tryserver/
no_vmtest_pre_cq/81548)
The size of the serial number string is set in config.h when
CONFIG_USB_SERIALNO is needed.
Compile with ec-utils with cr50_onboard USE flag set.
Change-Id: I5a2306bd0dc1dea29265226f2986829b768cfb61
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/581887
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
For boards with POWER_SEQUENCING_VERSION = 2 (and likely future
versions), allow the host to request "wakeable suspend", which will
leave rails enabled to allow wake-on-usb.
BUG=b:63037490
BRANCH=kevin
TEST=With subsequent commit, compile on scarlet w/ power sequencing
version = 2.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaadd371b1d1509d185c8c8306b72760dcfe9989f
Reviewed-on: https://chromium-review.googlesource.com/572211
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Allow host to request a higher-power S3 variant, "wakeable S3", in which
more wakeup sources will be enabled by the EC. The actual implementation
and list of wake sources is left up to the chipset power driver and/or
board code.
BUG=b:63037490
BRANCH=gru
TEST=With subsequent commit, compile on scarlet w/ power sequencing
version = 2.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I469f0cd969052f173cb176196bb6d05f6f76fdb5
Reviewed-on: https://chromium-review.googlesource.com/572210
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
LTE_GPS_OFF_L and LTE_BODY_SAR_L are both currently configured as
push-pull output, but they should be OD. Let's also set the default
value to high.
BRANCH=none
BUG=b:64126879
TEST=Flash poppy.
Change-Id: I2e9297c567e74f7d2656557c306337e90a4410c1
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/590908
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Turns out PCH_RTCRST is never used, and its location is either
GPIOE7 (rev 0-3), or GPIO27 (rev 4-).
- Leaving this pin configured as input (default) for rev0-3 should
be fine as there is an external pull-down.
- We still drive it low from rev4, for consistency.
Also, LED_YELLOW_C0 only moved from GPIO32 to GPIO24 (not GPIO27)
from rev5.
BRANCH=none
BUG=b:63048710
TEST=Boot poppy/soraka
Change-Id: I1c474fe8abb97c75210b81662ba1d1af0a7ee82e
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/588428
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
