Our USB buffers are just arrays of uint8_t in program RAM, so
let's treat them that way. The DMA descriptors are in normal RAM,
too.
BUG=chrome-os-partner:40693
BRANCH=none
TEST=make buildall
Change-Id: Ibafe1a557a328bbf8cf37ce113675fcd35bad376
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/273918
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Move parts of usb_pd_config.h that are not part of the phy layer
out of usb_pd_config.h and into board.h. This cleans up the
division between the TCPC and TCPM as only the TCPC needs to
use usb_pd_config.h.
Also cleans up the use of the CC detection voltage thresholds
by creating standard macros to use based on Rp strength for the
board.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I946cceb38bea8233095b8a4b287102bb8a3a296d
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270337
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Would be useful to expose more of the GProbe commands to developers
who have access to boards console (hoho, honeybuns). This CL adds
a console command and seeds it the 'mcdp info' command.
Signed-off-by: Todd Broch <tbroch@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:35939
TEST=manual, with CONFIG_CMD_MCDP defined in board/hoho/board.h
- Enter info console command multiple times and see correct
return value.
mcdp info
family:000e chipid:0001 irom:1.0.0 fw:0.0.0
Change-Id: Iaf2c088d5da1af7b2dab11abcfb6e32e289066ea
Reviewed-on: https://chromium-review.googlesource.com/272692
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Add config options for various parts of USB PD stack:
CONFIG_USB_POWER_DELIVERY: The use of this option has changed
slightly. It now represents whether or not to include the USB
PD protocol and policy layers of the software stack.
CONFIG_USB_PD_TCPC: Compile in type-C port controller module
which performs the phy layer of the PD stack.
CONFIG_USB_PD_TCPM_STUB and CONFIG_USB_PD_TCPM_TCPCI: If
CONFIG_USB_POWER_DELIVERY is defined, then one TCPM needs to
be defined to declare which port management module to use
to drive the TCPC.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I41aa65a478e36925745cd37a6707f242c0dfbf91
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/270171
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add CONFIG_LTO to use GCC Link-Time Optimizations to try to reduce the
flash footprint of the firmware.
Add additional protection to some functions/data to avoid removal by the
linker when their usage is not obvious.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall (with and without LTO enable on all boards)
Change-Id: I586b8c1eda4592b416c85383b65153c1d5ab0059
Reviewed-on: https://chromium-review.googlesource.com/271291
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Rename image geometry configs with a uniform naming scheme to make their
purposes more clear.
CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory
CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage
CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image
CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory
CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage
CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image
CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage
CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage
BUG=chrome-os-partner:39741,chrome-os-partner:23796
TEST=Set date / version strings to constants then `make buildall -j`.
Verify that each ec.bin image is identical pre- and post-change.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd
Reviewed-on: https://chromium-review.googlesource.com/270189
Reviewed-by: Anton Staaf <robotboy@chromium.org>
Add command that list supported features by the firmware.
Also let the firmware indicates if more features are expected in the RW
version.
This will help the cros_ec framework load the right driver(s) for
exposing information via sysfs.
BUG=chromium:428364
BRANCH=none
TEST=Test on samus on both ec and pd:
localhost ~ # ectool inventory
EC supported features:
1 : Flash support
2 : Direct Fan power management support
3 : Keyboard backlight support
4 : Lightbar support
6 : Motion Sensors support
7 : Keyboard support
9 : BIOS Port 80h access support
10 : Thermal management support
11 : Switch backlight on/off support
12 : Switch wifi on/off support
13 : Host event support
14 : GPIO support
15 : I2C master support
16 : Charger support
17 : Simple Battery support
18 : Smart Battery support
21 : Control downstream MCU support
localhost ~ # ectool --name cros_pd inventory
EC supported features:
1 : Flash support
14 : GPIO support
15 : I2C master support
22 : USB Cros Power Delievery support
Change-Id: Ib6eaac91fda86835e754c5316ecf81fbc27786e5
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263463
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Sameer Nanda <snanda@chromium.org>
The same code exists in four (soon to be five!) different power
sequencing drivers, so move it up to common.
BUG=None
TEST=Manual on Samus. Run "pause_in_s5 on" on EC console, verify that
system stops in S5 on shutdown. Run "pause_in_s5 off" on EC console,
verify that system again goes to G3 on shutdown.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaf05ef7ce017be4f9d173e83e985a7a879ba278c
Reviewed-on: https://chromium-review.googlesource.com/269566
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Our goal is to use include/config.h as the canonical list of all
CONFIG_ options. Several CONFIG_ options are in use in various
places in the code, but aren't mentioned in the header.
This CL adds these options:
CONFIG_ACCELGYRO_LSM6DS0
CONFIG_BATTERY_BQ27621
CONFIG_BATTERY_RYU
CONFIG_BATTERY_SAMUS
CONFIG_USB_RAM_ACCESS_SIZE
CONFIG_USB_RAM_ACCESS_TYPE
CONFIG_USB_RAM_BASE
CONFIG_USB_RAM_SIZE
And it changes this misspelled one:
CONIFG_USB_PD_CHECK_MAX_REQUEST_ALLOWED
to this:
CONFIG_USB_PD_CHECK_MAX_REQUEST_ALLOWED
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I1b4d7ca65efb356f6450a9bc94bb03c1923d933b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268778
Reviewed-by: Randall Spangler <rspangler@chromium.org>
These CONFIG_ options in include/config.h are not used or
referenced anywhere else in the code:
CONFIG_ADC_CLOCK
CONFIG_USB_PD_IDENTITY_HW_ID
CONFIG_USB_PD_IDENTITY_SW_ID
The first one is real, but the other two are just the wrong names.
They should be:
CONFIG_USB_PD_IDENTITY_HW_VERS
CONFIG_USB_PD_IDENTITY_SW_VERS
This CL removes the unused option and fixes the names of the
others.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I0f6279f362a7aa214ff9b17a2b24b776588a210e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/268791
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Change the EC_CMD_USB_PD_POWER_INFO host command to report the input
current limit and the max current theoretically possible given the
charger. The input current limit field is useful for logging purposes
and the max current field is useful to give to powerd to determine
if we have a low power charger connected.
The max current is determined by checking if the charge supplier is
allowed to ramp. If the charge supplier is allowed to ramp and has
not completed ramping yet, then max current is the max current that
we are allowed to ramp up to. Once the ramp has completed, then max
current is the stable charging current. If the charge supplier is not
allowed to ramp, then max current is simply the max current as
registered with charge_manager. The point here is to keep the max as
high as possible until we know for sure it is lower to avoid showing
the user the low power notification until we know for sure.
This CL also adds a new charger type, USB_CHG_TYPE_UNKNOWN. For a short
period after a charger is plugged in, the supplier type may change and
PD negotiation is still in process, and therefore we tell the host we
have an unknown charger type. This allows powerd to show the charging
icon, but delay determining if this is a low power charger until we
know for sure.
BUG=chrome-os-partner:38548
BRANCH=samus
TEST=tested with zinger, a DCP, an SDP, and a proprietary charger.
tested that low power notification never pops up with zinger, even
if you purposely wedge charge circuit with "charger voltage 7000" on
EC console. tested that the other chargers all pop up low power
notification once the supplier changes from UNKNOWN to the real
supplier. used "ectool --name=cros_pd usbpdpower" to check current
values.
Change-Id: If8a9a1799504cc2a13238f4e6ec917d25d972b22
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/265066
Reviewed-by: Sameer Nanda <snanda@chromium.org>
- Added config option CONFIG_USBC_SS_MUX_DFP_ONLY
- If this options is enabled, then the mux is set to
TYPEC_USB_MUX only is data role is DFP.
- If this option is not enabled, the mux is set for
both UFP and DFP (i.e. RYU)
BUG=chrome-os-partner:39059
TEST=Manual samus to plankton, switching between source and sink modes.
Forced data role swap via ec console command.
BRANCH=Samus
Change-Id: Ibc2fb0ad42d0fe415d3338d38da94ad4b041513b
Signed-off-by: Scott Collyer <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266916
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Alec Berg <alecaberg@chromium.org>
With mec1322's EMI set to decode IO 0x800, it does not have any other
interfaces to support POST code via IO 0x80.
This change is to enable Port80 POST code support via polling method.
Limitation:
- POST Code 0xFF will be ignored.
- POST Code frequency is greater than 1 msec.
BUG=chrome-os-partner:39386
TEST=Verified Port80 POST code is captured in EC console.
Verified "port80 task" console command will disable/enable Port80 task.
Verified "port80 poll" will get the last Port80 POST code.
BRANCH=none
Change-Id: I27e53e84b5be1fd98464a44407dd58b93d8c798d
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/266783
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Update the BQ2589x charger driver to configure properly the boost
used as a VBUS 5V source.
Define the bits used for I2C registers configuration.
Return success in unused charger callbacks to avoid blocking the
charge state machine.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38603
TEST=On Ryu P4 reworked with BQ25892, plug a C-A receptacle adapter and
see the 5V VBUS coming up, un-plug it and see VBUS going away,
try several PD/type-C charger and check the selected current limit.
Change-Id: I24b832b6d130ff6dfda1ce47f5e445d65279fa7d
Reviewed-on: https://chromium-review.googlesource.com/266063
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Currently, ECs with internal flash store the write protect state for
RO in a separate write/erase block of flash. This is wasteful on
chips where there are not many blocks of flash.
Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by
default. This is the old behavior, for compatibility. (And we're
calling it 'bank' because that's what the existing code does, even if
the terminology is somewhat etymologically... bankrupt.)
If that config is #undef'd, then store the write protect flag directly
inside the RO image. This uses only 4 bytes of the RO image, instead
of an entire erase block. The magic numbers for the pstate values are
chosen such that when protecting RO, bits are only transitioned away
from their erased state. Unprotecting RO once it's protected requires
reflashing RO; it's no longer possible to 'flashwp disable'. But
that's ok, because realistically, the only reason to unprotect RO is
if you're about to flash the RO firmware anyway.
BUG=chromium:476659
BRANCH=none
TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything
still works on samus and samus_pd. This ensures we didn't break the
existing functionality:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable
flashinfo -> no flags
Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test:
flashinfo -> no flags
flashwp enable
flashinfo -> ro_at_boot
reboot
flashinfo -> ro_at_boot
flashwp disable -> fails with access denied
flashinfo -> ro_at_boot
Then reflash to verify that clears the ro_at_boot flag:
flashinfo -> no flags
Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/266095
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Certain chips have I2C ports mapped to the same controller. In this
case, it's necessary to lock out access to the controller during use.
This configuration can be supported by adding CONFIG_I2C_MULTI_PORT_CONTROLLER,
which can be defined at the chip level, along with an API function to
map port index to controller index.
BUG=chrome-os-partner:38335,chrome-os-partner:38945
TEST=Manual with subsequent commit. Verify that i2cscan is functional on
strago.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I37ffa661a2ad6cd2235cef2ee77637cc3ab92523
Reviewed-on: https://chromium-review.googlesource.com/265942
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Support VCONN swap on samus and always accept VCONN swap when in
S0 or S3. In S5, we can't provide VCONN, so reject VCONN swap
requests.
BUG=chrome-os-partner:34978
BRANCH=samus
TEST=load on two samus' and use "pd 1 swap vconn" to swap which
side is source vconn. also run in S5 and verify swap request is
rejected.
Change-Id: I04be8d1d910a2d6c5ad8b27a790f8e33121c86ee
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264856
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The ADC watchdog is about 2/3 of the ADC code size and it is not
optimized out when not used because adc_read_channel() needs to
stop/restart the watchdog if somebody is using it.
The feature is enabled by default to keep the current behavior on
STM32F0 platform, and it is turned off on samus_pd :
This is saving 448 bytes of flash (and 8 bytes of RAM).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=make buildall and check the firmware size before and after.
when CONFIG_ADC_WATCHDOG is disabled, adc_enable_watchdog() is not
compiled if there is any user the build will fail.
Change-Id: Ie2450bc2a8fd97662322fd3ce87e93c3fece6c6f
Reviewed-on: https://chromium-review.googlesource.com/265303
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
MEC1322 KSO00~03 pin has an alternate JTAG function. For board that needs JTAG
function, this #define allows hardware to use a different set of KSO pins.
For example - Uses KSO04~16 instead of KSO00~KSO12.
BUG=none
TEST=Verified keyboard is functional with all keys detected
BRANCH=none
Change-Id: I1e3c1c2b6a4420cb6296b6bc921affa8c0ed5800
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264610
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously we defined separate functions to map registers to protect
ranges for each supported SPI ROM. This change instead adds a protect range
table + flags for each supported SPI ROM and adds common functions for
translation between ranges + registers. This makes supporting new parts
easier. Since we will never use most supported protection ranges, we can
even simplfy the tables.
The implementation is now similar to flashrom.
BUG=chrome-os-partner:37688
TEST=Manual on Glower.
flashwp disable + spi_flash_rsr --> 0
flashinfo --> shows no protection
spi_flash_prot 0 0x10000 + spi_flash_rsr --> 0x24
flashinfo --> shows 64KB protected
spi_flash_prot 0 0x20000 + spi_flash_rsr --> 0x28
flashinfo --> shows all 96KB protected
spi_flash_prot 0 0x40000 + spi_flash_rsr --> 0x2c
spi_flash_prot 0 0x80000 + spi_flash_rsr --> 0x10
spi_flash_prot 0 0 + spi_flash_rsr --> 0x00
spi_flash_prot 0 0x1000 --> error
spi_flash_prot 0x10000 0x10000 --> error
BRANCH=None
Change-Id: Ie5908ce687b7ff207b09794c7b001a4fbd9e0f5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259310
Reviewed-by: Randall Spangler <rspangler@chromium.org>
W25X40 uses a different protection register encoding than our existing
W25Q64 code. Move the SPI ROM option to a config, and add support for
the new part.
BUG=chrome-os-partner:37688
TEST=`make buildall -j`. W25X40 protection code tested in a subsequent
commit.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8
Reviewed-on: https://chromium-review.googlesource.com/258440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Change tap for battery lightbar sequence to not show the last segment
dimmed as a percentage of your battery.
BUG=chrome-os-partner:37335
BRANCH=samus
TEST=use battfake console command to test out every increment of 10%
and use "lightbar seq tap" to show tap.
Change-Id: I4f38d26a8cfbecfa6efc86fcc8751ca8cb34879b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/256191
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
All current boards in ToT place pstate at the end of the RO section.
Remove the unused option to place it at the end of the RW section;
we'll never do that again.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I0d279a4c9786bb33367a7387423481cc9b94e115
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253636
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, the flash module assumed it needed to emulate a SPI write
protect register using a bank of flash to hold the persistent flash
write protect state. This is not true for mec and ncpx chips under
development, which use external SPI flash. So, gate that code with
CONFIG_FLASH_PSTATE. For compatibility, leave it on by default (as we
do with CONFIG_FLASH_MAPPED).
There is no change to the behavior of currently supported chips, since
all of them already assume pstate is present. Removing this feature
from npcx will be done in a subsequent change.
BUG=chrome-os-partner:34346
BRANCH=strago
TEST=make buildall -j; verify flash wp and flashinfo work properly on samus
Change-Id: Ie044eb042863e4a7359ea540166ffd8d0089589d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/253632
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Depending on the hardware, each ADC channel may need a different
sampling time. To keep things simple, let's allow per-board ADC sampling
time configuration instead of per-channel configuration.
BRANCH=Ryu
BUG=None
TEST=Configure sampling time to 3 and measure IADP on Ryu P4 and check
it's more accurate.
Change-Id: I3c1eeea22439c0340f84fdeb3624fc84450358ca
Signed-off-by: Vic Yang <victoryang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/251701
Tested-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vic Yang <victoryang@chromium.org>
Add CONFIG_UART_INPUT_FILTER, which is undefined by default.
BUG=chrome-os-partner:36745
TEST=buildall for the case where it is not defined.
Added a filter function to the btle code on hadoken.
Tested reset, transmit test, receive test, test end, and test mode end.
BRANCH=None
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Change-Id: I3a9c067ffcb114449b61f468271a48491a8c7ec5
Reviewed-on: https://chromium-review.googlesource.com/250580
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Queue: Myles Watson <mylesgw@chromium.org>
This separates the configuration of the ARM core GPIOs from the
routing of internal peripherals to external pins. Both are still
described in the gpio.inc file, but are less dependent on each
other.
BUG=chrome-os-partner:33818
BRANCH=none
TEST=manual
Before this CL, running "sysjump rw" or trying to use more than 8
GPIOs caused hangs and reboots. Now it doesn't.
Change-Id: If962a7c5ad4136837b2ea00ae016a440f07d7e23
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/251015
Reviewed-by: Sheng-liang Song <ssl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Use the EC to check if PD MCU has crashed. The EC knows this
by checking the PD status bits: if PD MCU was in RW, and is
now in RO, AND it did not get to RO via a sysjump, then it
must have crashed. When the EC detects this, the EC will also
panic and reboot the entire system, so that we can software
sync to a known good state.
Also, when EC panics due to PD crash, it will log panic info.
BUG=chrome-os-partner:36636
BRANCH=samus
TEST=load onto samus EC and PD, try sysjump'ing back and forth
on PD MCU console and verify EC does not do anything. Crash
the PD MCU when in RW by reboot command and crash divzero command,
and make sure the EC panics with PD crash panic message. Crash
the PD MCU when in RO (before sysjumping to RW) and make sure
EC does not panic.
Change-Id: I57961028e6b23a878b8e477a9d8e180cb121a742
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250100
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Make non-exception "software" panics such as stack overflow and assert
failure save a panic log. Log the panic type in r4, and misc. panic data
in r5 so that panic reasons can be distinguished.
BUG=chrome-os-partner:36744
TEST=Manual on samus_pd. Run 'crash divzero' then 'panicinfo' after
reboot. Verify that panic info is printed with "r4 :dead6660". Trigger
stack overflow, verify that panic info is printed with "r4 :dead6661".
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5f7a8eb0a5c2ac5799d29bb241deb24fabf38f68
Reviewed-on: https://chromium-review.googlesource.com/249912
Tested-by: Alec Berg <alecaberg@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
This adds CONFIG_FAN_UPDATE_PERIOD to limit the frequency at which
the fan speeds are updated. Short version: the CPU core temp
fluctuates rapidly, causing the fans turn off and on annoyingly
often (assuming you have good hearing and are in a quiet room).
With this CL, we limit the speed changes to only once every N
seconds. N should be long enough to be less annoying, yet short
enough that the CPU doesn't overheat while we're not looking.
BUG=chrome-os-partner:34789
BRANCH=ToT,samus
TEST=manual
Let it sit quietly, then visit a busy webpage, then let it sit a
while. The fan speed should only change every 10 seconds or so,
not every second.
Change-Id: Id985350394f24d56dc4a1e51af09487ac643285b
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250501
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add new charge_ramp module which works with charge_manager to
slowly increase input current limit in order to find the optimal
charging current. To do this it looks for either VBUS drooping
too low or for the charger to over-current.
BUG=chrome-os-partner:34946
BRANCH=samus
TEST=tested with a variety of BC1.2 chargers, type-C only chargers,
and PD chargers to make sure we always stabilize charging at an
appropriate current limit.
Change-Id: Icc95aa2738ddb221f163f91c14a342a0674f9e0f
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/247304
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Some EC chips (mec1322) use external SPI flash which is not mapped
into the EC CPU's address space. These must explicitly read data from
flash when calculating the vboot hash or reading the version string of
the image which isn't currently loaded into code RAM.
To test this bug, I used a board with known working mapped flash, and
temporarily patched it to act like it didn't have mapped flash.
Also add a flashread console command, useful for manually testing.
BUG=chrome-os-partner:35308
BRANCH=glower,strago
TEST=manual
1. Apply this patch to samus
2. Check result for 'vboot hash RW'
3. Check result for 'version'
4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and
#define CONFIG_CMD_FLASH
4b. In chip/lm4/flash.c, add the following:
int flash_physical_read(int offset, int size, char *data)
{
const char *src;
if (offset > CONFIG_FLASH_SIZE ||
offset + size > CONFIG_FLASH_SIZE)
return EC_ERROR_INVAL;
src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset);
memcpy(data, src, size);
return EC_SUCCESS;
}
Steps 4a,4b will make the LM4 chip act like it doesn't have
memory-mapped flash.
5. From the dev system, util/flash_ec --board=samus --ro
6. Check result for 'vboot hash RW'. Should be same as 2.
7. Check result for 'version' for RW version. Should be same as in 3.
8. From the dev system, util/flash_ec --board=samus
9. sysjump rw
10. Check result for 'version' for RO version. Should be same as in 3.
11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results
should be the same (but endian-swapped, since flashread is byte
ordered and md is 32-bit ordered).
12. Revert changes from steps 4a-4b.
Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/246200
Reviewed-by: Shawn N <shawnn@chromium.org>
Occasionally the charge circuit on samus gets wedged and will not
charge. This change detects when the charge circuit has failed
and automatically recovers from it. It uses the BQ PROCHOT warning
to detect the failure by setting PROCHOT to trigger when the BQ
thinks input current is higher than the input current limit. When
the failure is detected, the EC disables charging and tells PD MCU
to disable CHARGE_EN, then a couple seconds later, it re-enables
charging.
This CL also adds more communication between EC and PD for the EC
to be able to set the charge state for the PD. Valid charge states
are: No charging allowed, 5V charging only, and max charging. The
EC uses this as such:
- When the EC gets AC present interrupt, it sets off a deferred
function to change charge state to max charging after some delay
to give time for the charge circuit to settle down.
- When the EC gets AC disconnect interrupt, it disables charging
briefly, enables learn mode, and then sets 5V charging allowed.
This allows for the same starting conditions in the charge circuit
for every AC attach.
- When the EC detects a wedged charge circuit, it disables charging
and waits a few seconds before re-enabling 5V only charging.
Additionally, this change moves the charging cutoff in S3/S5/G3 when
the battery is full to the EC. With the added control for the EC
to set the PD charging state, it is more convenient for the EC to
manage cutting off charging when battery is full.
BUG=chrome-os-partner:36081
BRANCH=samus
TEST=test the basics:
- connect/disconnect zinger a bunch of times
- connect and disconnect two zingers in different order
- connect two zingers and charge override between the two
test the automatic charge wedge recover:
- wedge the charge circuit by setting charger voltage under battery
voltage: "charger voltage 7000"
- wait a few seconds for the system to recover and check it is charging
with "battery" command
test full battery charge cutoff:
- added console command to change battery soc in board/samus/extpower.c:
static int cmd_battfake(int argc, char **argv)
{
char *e;
battery_soc = strtoi(argv[1], &e, 10);
batt_soc_change();
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(battfake, cmd_battfake, "", "", NULL);
- in S0, tested "battfake 100" does not disable charging.
- in G3, tested "battfake 100" disables charging and "battfake 99"
re-enables charging.
- set "battfake 100" and tested transitioning to S0 enables charging and
transitioning to S5 disables charging.
- attached two chargers and used charge override to select active port.
then toggled "battfake 100" to "battfake 99" back and forth and verified
charge override port is still the same.
test third-party 12V charger:
- plug in a bunch of times and make sure we stay at 5V for 500ms and then
transition to 12V
test with no battery:
- tested five different units with no battery and just zinger. 3/5 boot,
while the other 2 don't. But, the 2 that don't boot without battery also
can't boot w/o battery when this CL is reverted, so I don't think this
change is causing the problem, I think there is an electrical limitation.
test with EVT zinger:
- EVT zingers (P2 - C2) negotiate very quickly after connection, which
can cause INA problems w/o this CL. Tested an EVT zinger with samus and
did a bunch of connections and disconnections and verified that we always
wait at 5V for 500ms and that we don't wedge the INA circuit on connect.
test backwards compatibility:
- test new PD with old EC and make sure we can charge with zinger.
(note that if the charge circuit wedges, we won't be able to unwedge it).
- test old PD with new EC and make sure we can charge with zinger.
Change-Id: I7703b7a2ab1209d7f559b265b03517e79c74b16a
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/245253
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
More updates to connection state machine. Adds CONFIG option
for backwards compatible DFP (used on zinger), and change UFP
state machine to debounce CC while VBUS is not present.
BUG=chrome-os-partner:33680
BRANCH=samus
TEST=load on samus and zinger and connect a bunch of times. also
test samus to samus connection.
Change-Id: Ia967eb6a17b10aa0c05a30686235fbf8a24e9a7b
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240587
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Certain platforms may wish to have a longer shutdown timeout, so make
the timeout a config option.
BUG=chrome-os-partner:35188
TEST=Manual on Samus with subsequent CL. Set config option to increase
timeout, verify that timeout is extended.
BRANCH=Samus
Change-Id: I69feb0d31fdc53e533671dec1e88ba96cc4553c2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240815
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Add a FIFO to log important events on the PD MCU and coming from the PD
accessories.
The retrieval of the accessories log from the accessories by the PD MCU
is not implemented yet.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:32785
TEST=execute "ectool --name=cros_pd pdlog"
before and after plugging Zinger charger.
Change-Id: If96d73e711ff6ad64cfb99bd3e4d2d8f2643f19a
Reviewed-on: https://chromium-review.googlesource.com/238854
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Assuming the dut has red/green battery led and a single power led
CONFIG_LED_POLICY_STD implements the chromeos spec:
* power led on in S0
* power led off in S5
* power led pulsing in S3
* battery led amber when charging
* battery led green when fully charged with AC
* battery led off when discharging
* battery led pulsing red when battery error
BUG=chrome-os-partner:35355
TEST=The Charging led behavior should match the cros spec
BRANCH=None
Change-Id: I645a939ecc2d44d73d2f52b295f9c7e8c923f77b
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/240705
Reviewed-by: Randall Spangler <rspangler@chromium.org>
BUG=chrome-os-partner:35312
BRANCH=none
TEST=make buildall -j
I added a debug message to nrf51/hwtimer.c to show when the timer overflowed.
"forcetime 4 0xfffff000" overflows to 5.00000000 in 4096 microseconds.
Define CONFIG_CMD_FORCETIME to enable it.
Change-Id: I30835d038ef8cd639565ffb7a638979d95d0a684
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/239968
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
