Right now there is no way to verify cr50 is asleep just by looking at
the UART output. You can check by running taskinfo and seeing that the
GC_IRQNUM_PMU_INTR_WAKEUP_INT irq count has increased or by measuring
cr50 power.
In the past we have had Cr50 issues that we think are related to sleep.
Devices like poppy will have the Cr50 uart connected to servo, so we can
capture the Cr50 console output. It would be helpful if there was an
easy way to tell that cr50 is asleep from the UART output to more easily
confirm issues might be related to sleep. This change will print '.'
every time Cr50 resumes from sleep. Cr50 wakes up every half second for
HOOK_TICK, so with this change '.' prints every half second while cr50
is asleep.
BUG=none
BRANCH=none
TEST=boot a device, wait a while, and verify cr50 starts printing '.'
every half second. Turn off the device and verify the '.'s stop.
Change-Id: I94a82db00076062dbba2c3bc273cbe0731430520
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463990
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Implement actual rollback protection. First, we add a new field
in the version structure, which is an incrementing integer
(we'll start by shipping images with version 0, and gradually
increase the number as required). This allows us to release
new versions of the EC without necessarily bumping the rollback
protection.
For the rollback protection block itself, it contains 2 sub-blocks
of equal size (normally, 2k), that are individually erasable.
The rollback code looks at both, and takes the most restrictive one
to determine the desired rollback minimum version. The blocks
are also allowed to be erased (full of 1's), in which case the
rollback minimum version is assumed to be 0.
We also add an FMAP entry, in case we later decide to allow the
signer to increment the rollback version.
Also note that, like any version_data struct change, this change
breaks compatibility between old and new RO/RW.
Follow-up code will take care of auto-updating the rollback block
as required, and properly manage block protection.
BRANCH=none
BUG=b:35586219
TEST=Flash hammer
rollbackinfo => 1 version 0 block, 1 empty block, RW verifies
correctly.
rollbackupdate 0; rollbackinfo => No change
rollbackupdate 1; reboot => RO refuses to jump to RW
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
Change-Id: Ia969afb481a93deb912b9153bdd95ace01ad8fa7
Reviewed-on: https://chromium-review.googlesource.com/452815
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The accelerometer sensors are not needed in S5, and having them get
enabled early in boot is causing issues on a subset of boards.
Similarly, the magnatometer is supposed to be disabled in S3/S5.
BUG=b:36919184
BRANCH=none
TEST=successfully boot on board that was previously failing
Change-Id: I3c079a83b21b2f1875330ac16ef8d3f9da267f9f
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/468686
Reviewed-by: Todd Broch <tbroch@chromium.org>
When a USB PD connection is made, servo_v4 senses the polarity of the
SBU signals and sets the SBU mux for the deteted polarity. If the DUT
is reset, the SBU mux needs to retain the same state so the H1 console
USB endpoint is not disrupted.
Modified the CCD_MODE_DISABLED case to no longer disable the SBU
mux. In addition, removed the static variable ccd_mode as it was being
set, but not ever being checked, so wasn't serving any purpose.
BUG=b:36561120
BRANCH=servo_v4
TEST=Connect servo_v4 to Electro. On Electro EC console enter 'reboot'
verify the H1 USB console remains connected.
Change-Id: I4f0f5167221c04314ca5be063411f200896bbdf6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/464068
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This change adds a send_done call at the end of show_fw_ver. With this
change Cr50 will set the state to rx_idle after every usb_update -f
call.
Cr50 cannot process any vendor commands unless the updater state is
idle. After a vendor command is sent cr50 wont set the state to idle
unless it receives a send_done call. It will also reset the state if it
sees that it has been more than 5 seconds since the last transfer.
In the current state you cannot use usb_updater -f back to back because
usb_updater doesn't call send_done through the -f path. If you wait 5
seconds between calls, then it will work. If the call fails and you keep
retrying waiting less than 5 seconds between calls, then it will fail
forever. The last transfer time will get reset with each call and Cr50
will never reach the timeout to reset the usb_update state to idle.
BUG=none
BRANCH=cr50
TEST=run 'sudo ./usb_updater -f && sudo ./usb_updater -f'. Verify both
calls succeed.
Change-Id: I5daca8e03ece840288abb61e02a528a9af0ada30
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/465491
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables the entry/exit model for S0ix based on host
commands. The kernel will send host events on kernel freeze/thaw exit;
EC will initiate the S0ix entry based on host command and exit via
another host command from kernel.
BRANCH=none
BUG=b:36630881
TEST=Build/flash EC and check 'echo freeze > /sys/power/state'
command in OS shell. Verify EC goes to S0ix state, and on wake
it comes back to S0 state.
Change-Id: I22405021aead8488a5a1f166400cbde76faac59b
Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
Signed-off-by: Archana Patni <archana.patni@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/446219
Commit-Ready: Archana Patni <archana.patni@intel.corp-partner.google.com>
Tested-by: Archana Patni <archana.patni@intel.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This will eventually be used for debug mode.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I56b3a1f8f4b32d3ead91b83d474546356b65d221
Reviewed-on: https://chromium-review.googlesource.com/462757
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
On keyboard-less design, we will implement a special debug mode,
based on button sequences, to transmit sysrq events to the AP.
This implements the new MKBP event to send sysrq, and a console
command to test it. Later CL will implement debug mode itself.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I71d3f77497baf8cc7fac65cd040ce20513b507bc
Reviewed-on: https://chromium-review.googlesource.com/456520
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
We want the -b option to be parsed the same way as the -u option,
because usb_updater should handle reading the file the same way. This
changes binver hasarg to be 0, so that it doesn't eat the filename.
BUG=none
BRANCH=cr50
TEST=usb_updater --binver $IMAGE
Change-Id: I0b868bc5d316e5fb42fc34bc746bbee868d20630
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/465490
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When Cr50 resumes from hibernate, it should use the WP state that was
stored in the long life scratch registers. All other boots should
simply follow the state of the BATT_PRES_L pin.
BUG=b:36659750
BRANCH=master,cr50
TEST=Power on Cr50 via battery, verify that WP_L remains asserted.
Change-Id: I516d43b6540d7c543e7629f8709ce63515bb7f76
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/464258
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When releasing the PINMUX hold, some of the output levels may change.
Therefore, it's probably best to let those outputs stabilize before
letting the EC out of reset and sample them.
BUG=b:36659750
BRANCH=master,cr50
TEST=Flash Cr50. Verify that WP_L is stable before EC is released from
reset.
Change-Id: Ie2967c5e97f28240e1724b4531655c5dd08a3f29
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/464257
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The BIOS had the tablet mode device enabled in CL:439308, however
the corresponding change to the EC never was done. Therefore, powerd
was monitoring the tablet mode device which always reported tablet
mode because it wasn't reading the real state. As such the keyboard
and trackpad were never being unhibited by powerd. Ensure the EC
config matches the BIOS changes so that the correct state is properly
reported.
BUG=b:36788342
TEST=Booted device. keyboard and trackpad work as expected.
BRANCH=reef
Change-Id: Ie76007bc0e2ced046ebe1c241150f300efd3bb82
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/464026
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
When the charge ramp task starts, it starts up in the DISCONNECTED
state. From this state, it's possible to set the input current limit to
0 mA. However, upon task start, we shouldn't take any action until we
have valid values from a new charge supplier or a supplier leaving.
This commit changes the charge ramp task to not touch the input current
limit until the charge ramp state changes or the desired input current
changes at least once.
BUG=b:36468002
BRANCH=gru,master
TEST=Flash kevin EC RW or build AP FW that contains the fix that will by
sync'd by EC SW sync. Make sure WP is asserted to prevent PD
communications in RO. Unplug battery. Plug in AC, verify that system
can boot up to UI on AC alone.
TEST=make -j buildall
Change-Id: I351917bce7902c49d1bb842a0cc83dd161d75b6f
Reviewed-on: https://chromium-review.googlesource.com/461382
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463927
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This change includes
- Configuring the HPET timer based on the spec
(IA-PC HPET (High Precision Event Timers) Specification 1.0a)
- Two timers used:
HPET Timer0 (free running periodic timer)
HPET Timer1 (event based non-periodic timer)
- HPET interrupts are routed to ISH via IOAPIC
- Both the timers are functional
BUG=None
BRANCH=None
TEST=`Build ISH and verify the timer interrupt via various console cmds`
Change-Id: Ib5ca24d05790868430a2cfa72ca73f5bd6a5fea3
Signed-off-by: Divagar Mohandass <divagar.mohandass@intel.com>
Signed-off-by: Kyoung Kim <kyoung.il.kim@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/453858
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The derivatives development should be done in the firmware branch.
(here it is firmware-reef-9042.B)
They are way too many 'follow reef settings' CLs, either all derivatives
should be updated at the same time or we have to cut the rotten fruits.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:36192920
TEST=make buildall
Change-Id: I20cbc4897c7e6e3355ca0a4ed0e856d6b1d17eff
Reviewed-on: https://chromium-review.googlesource.com/452459
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The default for servo_v4 DUT port is to be SRC to charge the DUT, but
a UFP data role so that the DUT's usb mux gets connected.
BUG=b:35586526
BRANCH=servo
TEST=Connect to Electro and verify that servo_v4 data role is that of
UFP and that electro is getting an IP address from the enet port on
servo_v4.
Change-Id: I8f2e4242777bf879598852004096f683d68c091c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452725
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previous boards that implemented tcpc layer on chip didn't support
variable Rp values. However, servo_v4 can present any of the 3
possible Rp values and therefore the voltage thresholds that are used
to determine a no-connect or Ra attach status need a way to be set
based on the Rp value that's current attached to a given CC line.
- Added port and cc line selection to both the CC_NC and CC_RA macros
and now check if they are already defined before being defined in
usb_pd_tcpc.c.
- Defined each of these macros in board.h to use a function that's
able to select the threshold based on the current Rp configuration.
BUG=b:35586526
BRANCH=servo
TEST=Tested with servo_v4 against Electro and verified that it
connects when a charger is and is not connected to CHG port which
exercises the differnt Rp combinations that servo_v4 presents.
Change-Id: I1a31e430c0f290486f0fa8a50bdafdddf20d23ca
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/451962
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This CL adds support for the DUT port to advertise different current
levels via the Rp resistor selection. The default setting is USB (500
mA).
The board_manage_chg_port function relies on the off->on transitions
only occurring when the CHG port is in a steady state condition. When
the charger being used supports PD messaging, the entry point
pd_set_input_current_limit() which is called after receiving a PS_RDY
message. For TypeC only chargers, the entry point is
typec_set_input_current_limit() which is called from SNK_DISOVERY
after only after the max number of hard reset attempts have been
attempted. This is intended to prevent this entry point from being
called when a USB PD charger is connected and the CHG port enters
SNK_DISCOVERY.
When the CHG port Vbus transitions from off->on, a src_pdo is updated
to reflect the current contract on the CHG port and this src_pdo can
then be used by the DUT port when either a new connection is done or
to update it's existing contract.
BUG=b:35586526
BRANCH=servo
TEST=Manual
Connected servo_v4 DUT port to Reef with no charger
connected. Verified that it connects, and CCD mode in Reef is enabled
(H1 console is available) and that only 500 mA charging current is
advertised. Then connected a 20V and 15V USB PD charger to the CHG
port. In each case verified that the DUT renegotiates to the 20 and
15V level respectively. Repated the test with Guppy and verifed that
VBUS is at 5V 3A. When Guppy is removed, then the DUT connection
reverts back to the host as the VBUS source.
Change-Id: I1a5eb346bbe1f0d586cb8b7bb24d77ff713fbf3c
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/449954
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a flash driver for the STM32L4 family.
For write and erase, the code is very similar to other variants
excepted the 'normal' writes need to be perform 2 aligned
32-bit words at a time.
Option bytes are a sligthly easier business since the hardware deals
with the option bytes page preserving and erasing for us.
For the write-protection, the STM32L4 is slightly different from the
other variants. The write-protection granularity is still a 2-kB block
(2kB here) but instead of having a 'bitmap' of the protected blocks, it
defines 2 write-protection ranges (WRP1AR and WRP1BR).
For the EC code base, we are using WRP1AR to protect the Read-Only
regions and WRP1BR to protect the Rollback and RW regions (if they
exist).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648258
TEST=On Eve, run 'flashrom -p ec:type=fp -w /tmp/ec.bin'
and 'flashrom -p ec:type=fp --wp-enable --wp-range 0x0 0x20000'
Change-Id: Iaa98c1b4d3b07de2923ac076624bd4601c31a600
Reviewed-on: https://chromium-review.googlesource.com/456711
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The pstate structure is written using the low-level
flash_physical_write() function. As a consequence, it is supposed to
meet the CONFIG_FLASH_WRITE_SIZE alignment constraint.
Add a build-time assertion to avoid silent failures.
Slightly decrease the maximum size of the serial number string, so the
structure has a natural 32-byte alignment which is compatible with a
large number of platforms (including STM32L4 which requires 64-bit
alignment).
Of course, this change is not fully backward-compatible.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:571477 b:35648258
TEST=on STM32L442, build and run 'flashrom --wp-enable' without failure.
Change-Id: Ia8f82790a61a6c7d2cf9bfeb95bfdaf7b8c52d11
Reviewed-on: https://chromium-review.googlesource.com/458201
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Setting PWM IO type in gpio driver seems not a proper way. This
CL moves this functionality to pwm driver and introduces a new
flag PWM_CONFIG_OPEN_DRAIN to achieve it when user declared it
in board driver.
BRANCH=none
BUG=none
TEST=test pwm functionality on npcx_evb.
Change-Id: I90c60445d1fb10902244ddf0f635d8304e72f4ab
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/458043
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The cr50 code might need access to certain variables stored in the TPM
NVMEM. In particular the upcoming FWMP support will require reading
the NVMEM FWMP space.
This patch adds a generic function which allows to access TPM NVMEM
spaces. The implementation was borrowed from NV_REad.c in the tpm2
tree, the only difference being that the location, if present, is read
unconditionally, without checking access controls.
The API accepts the NVMEM index in Chrome OS scope and maps it into
TPM2 specification's NVMEM index space based at HR_NV_INDEX. The
definitions are included straight from the tpm2 tree.
BRANCH=none
BUG=chrome-os-partner:62489, chrome-os-partner:62205
TEST=this code is not yet even being compiled, tested with the next
patch.
Change-Id: I8bcfd8637c192249780634491f30e4a28229984f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457823
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch disables IADP immediately after the EC boots. We
observed noise on IADP/RESET pin causing SEL_ILIM_VAL to
randomly change. This seems the cause of b:35648317.
We enabled IADP to fix b:35647661 initially and also followed
the vendor's recommendation. However, the issue is only
reproducible on the particular board which was used for power
measurement and we did not see the issue on other boards with
IADP disabled.
Also the vendor assumed our EC doesn't control IBUS_LIM_SET
and ICC_LIM_SET. (I think they assumed like other thier customers
our EC controls ILIM by DAC connected to IADP/RESET pin.) If ILIM
is not set by EC and IADP is disabled, the system would brownout
because ILIM stays at 128mA. Therefore, it was (mistakenly)
recommended that our EC should keep IADP enabled.
Cros EC configures IBUS_LIM_SET and ICC_LIM_SET dynamically thus
the above concern does not apply.
We also found that we have too much noise on IADP/RESET pin. The
noise is not big enough to cause the chip to reset but it's big
enough to cause ILIM to fall in 128mA zone. We think this is why
the boards fail to boot from battery cutoff or no battery.
(Contrary to the vendor's explanation, it seems IADP/RESET pin
continusouly affects ILIM not only in the early chip power-up
period.)
BUG=b:35648317
BRANCH=none
TEST=Booted two Electro and two Snappy from 1) dead battery 2) no
battery 3) battery cutoff.
Change-Id: Ic675f1354b9ef222ceec8ce112b19713812d2752
Reviewed-on: https://chromium-review.googlesource.com/458676
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We are still building two images - for prod and dev fused H1 chips.
This requires different pairs of RO images and calls for using
different keys when signing RW images.
Each produced image is of 512K bytes in size, the ROs are paced at
offsets 0 and 0x40000, the RWs at offsets 0x4000 and 0x4000.
The signed ROs come from their respective source, their processing is
limited to converting into binary format and verifying that their key
signatures match image designation (prod vs dev).
The RWs binaries are derived from RW elf files which are the result of
running 'make BOARD=cr50'. The elves are converted into binary format
and signed, the bs script is used for that.
The bs script is modified to accept the destination file name from the
shell variable, to detect signing failures (resulting in zero sized
binaries), and to fix error reporting.
The new script create_released_image.sh expects exactly six command
line parameters:
<prod RO A>.hex <prod RO B>.hex <dev RO A>.hex <dev RO B>.hex \
<RW.elf> <RW_B.elf>
and generates two cr50 binary images.
The generated images are placed in the directory named cr50.r<ro
vers>.w<rw vers> (the versions are retrieved from the binaries using
usb_updater), and then placed in the tarball with the same base name.
This naming convention is imposed by the ebuild pulling in the tarball
from the binary component server (BCS).
On the successful completion the script prints out commands which can
be used to upload the new tarball to the BCS.
BRANCH=none
BUG=b:35587234
TEST=ran the script to generate the r0.0.10.w0.0.18 release, verified
that all components of both imagea are properly signed (are
bootable and the key signature matches the prod/dev convention).
Change-Id: I87be1d44a721c979bdeeabf986d717e3a382db45
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439907
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
If we go to sleep with a lid close event, the trackpad is immediately
waking the system. Since we don't want to accidentally wake if the
trackpad got input while the lid is closed anyway this change will
disable trackpad wake when the lid is closed.
BUG=b:35587072
BRANCH=none
TEST=manual testing on Eve P1b:
1) enter suspend by closing lid and ensure it stays in suspend
2) enter suspend by idle, and then close the lid, and ensure
it stays suspended
Change-Id: Ied73dde61e99231f057504ca56c473432aa30e4b
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/457865
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Remove unused wui sources of GPIO96/A0/A2/A4 since we don't
support them in 128/132-pins packages of npcx5mng. This CL also
removes wui source of GPO66 in case developer declares it as
GPIO_INT.
BRANCH=none
BUG=none
TEST=test gpio functionality on npcx_evb, reef and poppy.
Change-Id: I363813128d02be0fc642e82ca0b463971af22a90
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/458238
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
After running an update, we used to be dangerously close to
exhausting stack space, let's increase its size.
1 HOOKS 00000000 39.906350 476/488
BRANCH=none
BUG=b:35587171
TEST=Update FW using usb_updater2, 3 times in a row, without reboot,
no more panics.
Change-Id: Ia1559d7c4097b8d3179a6fa2f38bef126cb8055e
Reviewed-on: https://chromium-review.googlesource.com/458319
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
With the rest of support in place, this patch adds code which would
corrupt the headers received during firmware updates.
The VENDOR_CC_TURN_UPDATE_ON vendor command will be required to enable
the new images.
Care should be taken that other commands operating on the inactive
image header do not do anything with it before it was enabled, some
code is being added for that.
The minor RW version is being bumped up to 19 to clearly indicate that
the device is expecting the vendor command to enable the new image
(this is used by usb_updater when downloading the image without the -p
or -u command line options).
BRANCH=cr50
BUG=b:35580805
TEST=verified that the new image can be installed and started by the
new usb_updater.
- the inactive header after uploading with the -p option (the
image_size field's offset is 0x32c):
> md 0x84320 4
00084320: 00000000 00000000 80033800 00084000
rebooting the device does not start the new image.
- the inactive header after uploading without the -p option:
> md 0x84320 4
00084320: 00000000 00000000 00033800 00084000
the device running a DBG image reports the following in the end of
the image update:
[64.176780 FW update: done]
turn_update_on: rebooting in 100 ms
Change-Id: I4d763eb89c8b1a43a13697033201066779826e85
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457678
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With the upcoming availability of the downloaded header corruption,
there needs to be a mechanism for usb_updater to restore the corrupted
header, so that the downloaded code can run right away.
This patch separates image download and reset functionality. Download
happens as before, and the UPGRADE_DONE PDU is sent immediately once
image transfer completes. This puts the receive state machine into the
idle state and allows to send other commands.
The reset function is different for the target supporting protocol
versions 5 and above. The only command version 5 recognizes is the
indirect reboot command (the UPGRADE_DONE PDU sent the second time in
a row). For protocol version 6 and above the reset could be immediate
or posted, and for targets running RW version 19 or above the command
to restore the corrupted header is required.
When running on the target the command to restore the corrupted header
would be generated by the AP firmware on the reboot.
BRANCH=cr50
BUG=b:35580805
TEST=with the next patch of the series applied observed the corrupted
header properly restored and the device rebooted.
Change-Id: If87c12fe8578cd6f1b4beed6d113471356f6b6c2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457677
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The upcoming move of the Cr50 firmware update to the background
requires postponing the activation of the newly uploaded Cr50 image to
a later point in time, when the AP is ready to switch to start using
the new Cr50 image.
The suggested way of achieving it is as follows: when downloading the
new image, the current Cr50 code modifies the header's 'image_size'
field, setting its top bit to 1. This both makes the size invalid and
guarantees that the new image would not verify on the following Cr50
restarts.
When the AP is ready to switch to running the new Cr50 image, it will
send a vendor command, which would trigger the currently running Cr50
image to restore the other image's size field. This vendor command
would also communicate the timeout for the Cr50 to wait before
rebooting, if there has been at least one header (ro or rw) restored.
Rebooting the Cr50 would trigger rebooting the AP, resulting in the
entire system running the updated firmware.
Response sent to the AP will indicate if there has been a header
restored and the reboot is indeed upcoming, this would allow the AP to
quiesce the state of the device to handle the reboot gracefully.
BRANCH=cr50
BUG=b:35580805
TEST=with the rest of the patches applied observed the system properly
after the new header version was restored.
Change-Id: Ia1edee67b6aa8f458810d5dc2931477cfaab1566
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is no reason to reject the incoming USB packet if its
size equals the amount of space in the queue.
BRANCH=none
BUG=b:35587171
TEST=usb_updater2 works fine, even with 64-byte USB packets.
Change-Id: I2e54f1a758dd8a370dacdc8c2519bbd91e9cb4e5
Reviewed-on: https://chromium-review.googlesource.com/458042
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rowan uses BMI160 as g-sensor and gyro sensor.
This change removes KX022 settings and adds BMI160 settings.
The LID_ANGLE config is also removed.
BRANCH=none
BUG=chrome-os-partner:62673
TEST=check the values of the sensors are correct:
run ectool motionsense while the machine is flat on the table, raised on
its left side and raised on its front edge. With these 3 measurements
the accel data along the Z, X and Y axis are showing + 1G.
Change-Id: I03c84f143bbfc3037fd5232398d15e9c2a511291
Signed-off-by: Yidi Lin <yidi.lin@mediatek.com>
Reviewed-on: https://chromium-review.googlesource.com/427566
Commit-Ready: Rong Chang <rongchang@chromium.org>
Tested-by: Rong Chang <rongchang@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
By generating the wui mapping table for GPIO pins which have interrupt
handler like CL 451366 did, we needn't browse all items in original
gpio_wui_table to find the MIWU info. It saves code space and improves
interrupt lantency.
BRANCH=none
BUG=none
TEST=Test gpio functionality on npcx_evb, reef and poppy.
Change-Id: I77e9ad439ecf6a501a7976fe5099dd309dba81ee
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/449514
For the upcoming header restore vendor command implementation there is
a need to allow rw access to the alternative RO area.
A static function for this is available in upgrade_fw.c, let's make it
available to other users.
BRANCH=cr50
BUG=b:35580805
TEST=verified that it is still possible to update the RO.
Change-Id: I879804ff180c5d00cf6860ce5669f2fe48731832
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457501
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
There are no early H1 chips left in circulation, all released chips
(starting with RW 0.0.10) support update protocol version 5.
This patch drops all technical debt associated with supporting earlier
protocol versions.
BRANCH=cr50
BUG=b:35580805
TEST=downgraded an H1 test board to ro 0.0.8 rw 0.0.9. Updated it to
the latest image (ro 0.0.10 rw 0.0.18).
Change-Id: I28c9b0c597122c7aa602a88fb56f9c7bf04b9984
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457500
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
tigertail allows muxing a usb-c port onto two different
passthough targets. This allows for automated switching
between USB host and device without DUT or endpoint knowledge.
tigertail also routes SBU lines to stm32 UART, and has INAs on
VBUS and VCONN to measure power.
BUG=b:35849284
BRANCH=None
TEST=Muxing power, muxing USB, uart works, INAs work.
Change-Id: I5bf2ba038aa78e59352ad99cd71efb0f0d0fbec9
Reviewed-on: https://chromium-review.googlesource.com/438677
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In order to enable toggling on/off of LTE based on chipset power state
transitions, define WIRELESS_GPIO_WWAN that would allow the common
wireless component to take care of the gpio toggling.
BUG=b:36447195
BRANCH=None
TEST=Verified that PP3300_A drops down from 0.9V to 0.63V when
apshutdown is done on EC console and system transitions to fake G3.
Change-Id: Id46bcbdffde06e4929910b6ab87a6d9a96d18a23
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457402
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Jerry Parson <jwp@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When invoking ectool fan commands on older ECs not supporting
EC_CMD_GET_FEATURES, the tool is choking on the lack of the command at
the beginning of get_num_fans() and not going further.
The regression was introduced by
https://chromium-review.googlesource.com/c/359069/, let's go back to the old
behavior for machines without feature bits and skip the
EC_FEATURE_PWM_FAN check.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35575890
TEST=on Buddy, run 'ectool pwmgetnumfans' and 'ectool pwmgetfanrpm all'
and get results.
Change-Id: Ie9255d4afc9fa95a55807c310e9593a28c2aadc1
Reviewed-on: https://chromium-review.googlesource.com/456598
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
