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>
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>
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>
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>
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>
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>
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>
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>
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>
Let's split the usb headers in 3 different parts, instead of having
usb_descriptor.h pull in usb_hw.h and usb_api.h.
- usb_api.h: EC functions related to usb (e.g. connect/disconnect)
- usb_descriptor.h: common USB names and structures
- usb_hw.h: Functions required for interactive with EC's USB HW
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
Change-Id: I37ead61e3be5e7ae464f1c9137cf02eaab0ff92e
Reviewed-on: https://chromium-review.googlesource.com/454861
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As advised by Daisuke makes the new API slightly better:
- remove the useless rxlen assignment.
- keep the normal asynchronous behavior of the function by skipping the
last dma wait.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, use the FP sensor with the passthru.
Change-Id: Iedb8e77cb1af58c273ab5ae6f0a670ce93dfde5a
Reviewed-on: https://chromium-review.googlesource.com/454699
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Master chip/g FW still needs to support deprecated RO, so re-add support
for the old version_struct. This CL can be reverted once we no longer
need to support deprecated RO on master.
BUG=chromium:698881,chromium:698882
TEST=Flash old FW (f51fdf2) to RW_B slot and updated FW to RW_A. Verify
cr50 boots into RW_A, and "version" on the console prints RW_B version,
not "Error".
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3c255afcd12da5694ca128960de8d2abe41686dc
Reviewed-on: https://chromium-review.googlesource.com/450860
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Extend the SPI master API to be able to do fancier transactions:
- allow to read the incoming bits while transmitting.
If SPI_READBACK_ALL is set in 'rxlen' when calling spi_transaction(),
then the received data during transmission is recorded in rxdata buffer
and the function assumes that the real 'rxlen' is equal to 'txlen'.
- add spi_transaction_wait() which is similar to spi_transaction_flush()
but without de-asserting the chip select, so we can chain several
transfers in a single transaction.
Implement them for STM32.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, use the FP sensor with the passthru.
Change-Id: Iebff617acd3230277d36a4f565766b7748721a1d
Reviewed-on: https://chromium-review.googlesource.com/452898
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Enable properly the SPI slave command interface to drive the FP MCU from
the main CPU using the EC SPI protocol V3.
Fix the SPI slave driver on STM32L4 along the way:
- the STM32L4 family has the same FIFOs as STM32F0
- on STM32L4, we need to map the DMA requests
- set explicitly the data size (rather than setting an invalid value
which defaults to 8-bit).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:36025702
TEST=On Eve, use the kernel cros_ec_spi driver to communicate with the
FPMCU using the Cros EC SPI protocol V3.
Change-Id: Ib641c141808aa60b3a74611319e18e7a6c3736f0
Reviewed-on: https://chromium-review.googlesource.com/452373
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
The SPI initialization interrupt needs to be generated only when there
was actual data received while CS was asserted and after transaction
finished (i.e. CS is de-asserted).
BRANCH=cr50
BUG=b:35774896
TEST=verified on a bob with updated AP firmware
Change-Id: Ifc4b11870d511d47e9607a2001d845ee1e153f7f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/452792
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This command is handy in debug images when rollback protection needs
to be reset.
Manufacturing data stored in the last quarter of the INFO1 space is
preserved across the erase session.
BRANCH=cr50
BUG=b:35774863
TEST=built a non-debug image with the first map location in the
manifest set to zero, booted the new image. Then built and booted
a debug image with this patch included. Using sysinfo command
verified that the info map has one location zeroed, then ran
eraseflashinfo command and checked sysinfo output again. The info
map shows no more zeroed locations, and tpm still reports statues
as "manufacutred"
Change-Id: I58e2a6f6371b6ce656c1d6cc373dfdc6f9d9f5be
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450906
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
With enabling INFO1 map based rollback protection it is important to
be able to tell the state of the flash map and the currently installed
images' infomap header field.
The new function counts number of zero words in the info map and zero
bits in both RW headers, and returns them in a string printed out by
the sysinfo command.
BRANCH=cr50
BUG=b:35774863
TEST=built images with different manifest info field contents and
verified that the string printed by the sysinfo command makes sense.
Change-Id: If633a6c678dc34197b2dad116b6180b2d549e089
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450905
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Debug images should run on any H1 device, no matter what its INFO mask
is set to. This is achieved by emptying the info {} section of the
manifest when building images with nonempty CR50_DEV in the
environment.
BRANCH=cr50
BUG=b:35774863
TEST=built images with and without CR50_DEV=1, verified that the
manifest has the info{} section emptied when CR50_DEV is set.
Verified that the RW images boot fine.
Change-Id: Ied314c175d5c02f4108b7af85c244b6da8547616
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450904
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The cr50 RO image compares INFO rollback map space against the
contents of the RW image's infomap field.
To ensure that no rollback is possible, the RW should verify that the
INFO space state is consistent with the current RW and RW_B headers,
and if not, update the INFO state to comply.
This should happen only when running prod images, so that debug images
could be rolled back if so desired.
Also fixed the bug in functions enabling read and write access to the
INFO1 region. Write access is now a superset of read access setting.
BRANCH=cr50
BUG=b:35774863
TEST=as follows:
- built and ran a new image, observed it start successfully;
- modified the manifest to erase the first map location, built and
ran a new image, observed it start successfully
- restored the manifest, built and tried running a new image,
observed that the earlier version is starting.
Change-Id: I62253c3e98cd24ed24424b8bb9de22692a262d89
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447966
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
To make sure cr50 usb works, we need to disable sleep immediately
after the usb controller detects that usb has resumed. The usb WKUPINT
is asserted on usb resume, but cr50 doesn't currently respond to that.
This change umasks the usb wakeup interrupt, so that USB ISR will
disable sleep on resume.
BUG=b:35774906
BRANCH=none
TEST=Run 100 'usb_updater -f' 100 times sleeping 20 seconds in between
each run. Verify there are no failures and cr50 still goes to sleep
between each run.
Change-Id: I1819deaa3988bcf2a85686d1b9d57092ba264c4d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450900
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This is required so that the kernel can enable/disable remote wake-up
capabilities, and in particular for the kernel to enable autosuspend.
Also, properly implement GET_STATUS.
BRANCH=none
BUG=b:35579996
TEST=echo auto > /sys/bus/usb/drivers/usb/X-Y/power/control, device
autosuspends after 2 seconds, and wakes on keypress.
Note that this introduces other bugs, where keys are missing,
repeated, see b/35775048.
Change-Id: I7ddd257ac3877d27fb2da813f20583a614a0169b
Reviewed-on: https://chromium-review.googlesource.com/450826
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This commit changes the behaviour of handling the CCD_MODE_L pin. When
Cr50 is not in CCD mode, it will stop driving the pin and turn it into
an input. This allows the pin to be driven by the EC. Cr50 will then
poll the CCD_MODE_L pin to see when it is pulled low and then enter CCD
mode. Once the pin is deasserted, CCD mode is disabled.
However, when Cr50 itself makes the decision to enter CCD mode, it
changes the pin from an input to an output and drives the pin low.
NOTE: The rdd interrupt does not directly trigger CCD mode, but now
drives the pin low. A side-effect of the pin going low is that CCD is
enabled. Once Cr50 decides to leave CCD mode, it then reconfigures the
pin to be setup as an input again.
CQ-DEPEND=CL:448988
BUG=b:35804738
BRANCH=cr50
TEST=Flash dev board, use `ccd` console command to both enable and
disable CCD. Verify that when CCD is enabled, the state of DIOM1 does
not disable CCD. Verify that when CCD is disabled, pulling DIOM1 low
enables CCD. Letting it float disables CCD.
TEST=Verify that CCD mode is reflected in the device state.
Change-Id: I44645f28b362977ca6a502b646e4f4ff1a7430c7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/448161
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We had disabled wakeups on the AP phy when we were running on gru,
because the AP phy was not in use. We never changed that for reef, so
UTMI wakeups were disabled even when the AP USB was supposed to be
enabled. After Cr50 went to sleep any usb transactions would drop bits,
because Cr50 wouldn't notice anything was happening until it woke up on
one of the HOOK_TICK events.
This change reenables UTMI wakeups on boards with AP usb. It writes 1 to
USB_PCGCCTL_STOPCLK. This makes the controller disable the PHY clock
whenever it detects a usb suspend. When it resumes out of suspend, this
bit has no effect.
BUG=b:35774906
BRANCH=cr50
TEST=Boot up reef. Wait until cr50 goes to sleep run 'usb_updater -f'
and verify that it runs successfully. Make sure deep sleep still works
Change-Id: I54bd866111b5c9b5738575f23757e0cbe4907ec4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448988
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This counter will count the number of times the system enters deep
sleep. This is mainly for debugging purposes. With access to the deep
sleep count you can start a s3 suspend stress for hundreds of iterations
and verify that cr50 entered and resumed from deep sleep the right
number of times.
BUG=none
BRANCH=cr50
TEST=Wait until cr50 enters deep sleep. Wake it up and verify the
counter increased. Run 'idle C' and verify it is reset to 0.
Change-Id: Icb70a2fefedd82ea10934093f4c917da16b8d4ea
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448334
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If we are using more PWRDN or LONG_LIFE scratch registers we want to
make sure we don't clobber any existing uses. The use for each scratch
register is not documented anywhere. This change adds a comment to
init_chip with listing the uses for each long life and pwrdn scratch
register.
BUG=none
BRANCH=cr50
TEST=make buildall
Change-Id: I1e7d5b1f86dfa1a996671e864fe768976987a85e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448819
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Once ec receives LRESET/PLTRST on eSPI mode, both WUI57 of table 0 and
WUI15 of table 2 will be issued at the same time. We don't need two WUI
sources to indicate LRESET/PLTRST event on eSPI mode. This CL removes
initialization of LRESET/PLTRST of WUI57 of table 0 in lpc_init() for eSPI.
BUG=b:35954584
BRANCH=None
TEST=Verified that no more watchdog resets are seen on poppy.
Change-Id: Ib35b574d937c40d417ac707296ec080fd0244cf8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450022
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Since the interrupts of MIWU group E/F/G/H of table 0 are the same
(interrupt 11), we need to handle LPCs' and GPIOs' events at the
same ISR. But we also found there is a leak that ec has the chance
to skip the other events which don't belong to GPIOs unexpectedly.
(For example, LRESET and eSPI Reset) This CL fixed this issue by
only clearing pending bits belong to GPIOs in their ISRs.
BRANCH=none
BUG=b:35648154
TEST=passed warm-reset testing on pyro over 12 hours.
Change-Id: Ie626db00b54cff566798b4a593f6b0267a6fadc2
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/449472
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Flash INFO access API presently is hardcoded to access the endorsement
space. To enable INFO map based rollback protection one needs to be
able to access different areas of the INFO.
The FLASH REGION3 register used by the API is in fact used for NVMEM
flash accesses too, so it is better to leave it alone and use REGION6
for the purpose of accessing of the INFO space.
The API now requires the user to specify flash offset and region size,
the size must be power of 2, the offset must be aligned at size, and
the region must not spill beyond the INFO space address range.
BRANCH=cr50
BUG=b:35774863
TEST=with the rest of the patches applied it is possible to erase the
base word in the info map segment;
reading of the endorsement space at startup still works fine.
Change-Id: I008165ee9e11a7b49985d2b30683509cf6699431
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447965
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently if an interrupt is pending before it is enabled the interrupt
will fire immediately. In most cases this is fine, but if we want to
use the interrupt to trigger something like waking the AP it should be
sure that it won't immediately fire once enabled.
For example: on the Eve board we have the trackpad interrupt run to the
AP and the EC in order to support wake from Deep S3 (magic AP state that
only the EC can wake it from). This interrupt is used in S0 by the AP
while ignored by the EC, and then enabled on the transition to S3 in
order to be able to wake. Since it has been active the interrupt may
be pending in the EC (depending on the chip), which can result in the
interrupt firing immediately and waking the AP.
BUG=chrome-os-partner:62224
BRANCH=none
TEST=This has been functionally tested on npcx only as that is what I
have a use case and system for, the others compile and look right but
have not been directly tested.
Change-Id: I9e0877d99e7f09f4c30bf9861fbad81c12c059ad
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446962
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Any call to flash_execute_cmd() can interfere with UMA / mapped read
access, so grab the mutex first.
BUG=b:35587287,b:35848370
BRANCH=reef
TEST=Verify SW sync completes 8 hour stress test on kevin. Also verify
'ectool flashspiinfo' succeeds.
Change-Id: Ib1b04371546c27517c1b1ac860e9afbc1fed435e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447905
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
USB uses a special mode the trigger remote wake-up during host
suspend, by setting the K-state on the data differential pair,
and setting a bit in the USB config descriptor attributes field.
Let's enable that so that hammer can wake up host from S3.
BRANCH=none
BUG=chrome-os-partner:62325
TEST=Connect hammer to chell, put chell in S3. Press a key (or use
("kb 3 3 1; kb 3 3 0" in console), or touch trackpad =>
host wakes.
Change-Id: Ib7b1e9047e01869f07ddd771c9c9bc640eef10d6
Reviewed-on: https://chromium-review.googlesource.com/446240
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This follows the basics of what is decribed in
RM0091 Reference Manual 30.5.5 Suspend/Resume events .
We call enable/disable_sleep at suspend/resume, to make
sure the EC stays awake when USB is connected and active.
We also call clock_enable/disable_module, which is stubbed on
stm32f0, but can be used on other devices in the family.
This also fixes interrupt handling in usb_interrupt, by only
clearing interrupt bits that were handled instead of resetting
them all, which is racy, and can potentially lead to issues
if reset comes soon after a resume event.
BRANCH=none
BUG=chrome-os-partner:62325
TEST=build and flash hammer, connect to chell, suspend/resume,
and see that hammer prints USB suspend and USB resume lines.
Change-Id: Ie9d02fd4a114add3ebc98dc9393680bc9a64a522
Reviewed-on: https://chromium-review.googlesource.com/446239
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
STM32F091VC has 32 flash protection sectors (31 x 4KB + 1 x 132KB),
which doesn't fit the layout requirement in config_std_internal_flash.h.
This CL hardcodes the layout and flash bank mapping.
BUG=chrome-os-partner:62372
BUG=chromium:694972
TEST=load on elm and manually enable write protect using flashrom
# flashrom -p ec:dev=0 --wp-enable
check ec console write protect option bytes, bank 31 is writable
> rw 0x1ffff808
read 0x1ffff808 = 0xff00ff00
> rw 0x1ffff80c
read 0x1ffff80c = 0x7f80ff00
BRANCH=oak
Change-Id: I23dcf87bfbcd2f37e97a87e94847dce1ea1d343c
Signed-off-by: Rong Chang <rongchang@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446176
Our previous idea to cut Rd for many reset cases cannot work if cr50
consistently resets the EC by asserting the reset pin shortly after
power-on. Therefore, make a decision based upon whether battery-backed
memory indicates we previously negotiated a PD power contract as a sink.
If we previously did not negotiate a contract, or if power was removed
from the device (causing battery-backed memory to wipe) then we can
assume that we don't have an active power contract.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, run "cutoff" on the console, reattach AC, and verify
device successfully wakes. Also verify Rp is dropped on console 'reboot'
and F3 + power from RW.
Change-Id: Ie300b9589cac6be7a69b77678bea6b1b6b25578c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/443356
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ROLLBACK region will be used to store rollback information, and
can be protected independently of RW (it can only be protected when
RO is protected, though).
This is only supported on stm32f0 currently.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=on hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW+RB protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => only RO+RW protected
flashwp rb; reboot => RO+RW+RB protected
flashwp norb; reboot => RO+RW protected
flashwp all; reboot => RO+RW+RB protected
flashwp norw; reboot => RO+RB protected
TEST=on reef, rb/norb commands not available
Change-Id: I45ffc66d91cf3699ecff025e5114c59a73dc8274
Reviewed-on: https://chromium-review.googlesource.com/430519
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add generic routines to read or write a byte to battery-backed RAM, and
implement vbnvcontext get/set using these routines.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, with subsequent commit, run "cutoff" on the console,
reattach AC, and verify device successfully wakes. Also verify Rp is
dropped on console 'reboot' and F3 + power from RW.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I14691923f2e5198e901b6b5199e92c58c68cd18d
Reviewed-on: https://chromium-review.googlesource.com/444444
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The GPIOs on npcx are handled in banks of 8, and when processing
an interrupt for a particular bank the ISR is executed for each
GPIO in the bank that has a pending bit set.
If an interrupt in a bank is not enabled (but has fired before so
the pending bit is set) but another one in the same bank is enabled
and asserts, then the ISR both of the GPIOs will be executed because
they both have pending bits set.
This results in the ISR for a disabled interrupt getting executed
when it should not and leads to unexpected behavior.
Masking the GPIOs that are not enabled means only the ISR for the
explicitly enabled GPIOs in that bank will be executed.
Example: With the Eve board we have PCH_SLP_SUS_L on GPIO(6,2) which
is enabled at init time and is in the same WKINTG_1 bank as
TRACKPAD_INT_L on GPIO(7,1) which is not enabled, but I am working
on a patch to enable it. When going into suspend PCH_SLP_SUS_L asserts,
and that is causing the ISR for both PCH_SLP_SUS_L and TRACKPAD_INT_L
to be executed. If I try to use TRACKPAD_INT_L as a wake source from
DeepS3 this means the system immediately wakes after going to sleep.
BUG=chrome-os-partner:62224
BRANCH=none
TEST=With an additional patch to enable trackpad wake from S3 on Eve,
observe that the system can enter S3 and stay there instead of immediately
waking up due to the TRACKPAD_INT_L ISR firing when it is not enabled.
Change-Id: Idc66e22c93756faf6c4319980cfb8dfe63e0dfaa
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/446524
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The idea of this flag is to be able to protect/unprotect only the
RW portion of the flash. In the (usual) case where ALL=RO+RW, with
no other region, this makes no difference compared to the existing
EC_FLASH_PROTECT_ALL_* flag, and this flag may not be supported.
This is necessary for futher work, where a ROLLBACK region is added,
so that RW/ROLLBACK can be protected/unprotected individually.
Only support for stm32f0 is added, as this is the target for hammer.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw/norw not available
TEST=enable CONFIG_FLASH_PROTECT_RW
build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=build and flash reef (npcx)
flashinfo => RO+RW not protected
flashwp true => RO protected
flashwp all; flashinfo => all_now displayed
reboot => RO protected
flashwp rw/norw not available
Change-Id: Ica6f499cf2e8a9345b08ef52c915655a983ffe3c
Reviewed-on: https://chromium-review.googlesource.com/442265
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the option to use the PLL connected the 16Mhz HSI oscillator.
Fix the system timer pre-scaling when changing frequency:
- we need to generate an update event immediately as on a 32-bit timer it
might take a very long time before going an actual update event.
- we need to ensure that the OS timestamp is monotonic and sensible
across the frequency jump.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:62893
TEST=manual, on STM32L4 console, do several gettime and compare against
wall time, switch to 80Mhz with 'clock pll', verify again gettime
against wall clock.
Change-Id: Ibddbd46173b7594d16fb07e4b57660a50c636568
Reviewed-on: https://chromium-review.googlesource.com/445776
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The TPM SPI protocol adds flow control capability, but it is
impossible to enforce it by software, software implementations need
additional means of informing the master about the slave status.
Let's follow the i2c slave driver example and use the interrupt line
from the H1 to the SOC to generate a low level pulse every time
receive data processing is completed.
BRANCH=none
BUG=none
TEST=to benefit from this patch some changes on the SOC side will be
required.
Change-Id: I576233598e98e01a007dff6b973fd96ea5ea551c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446048
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch introduces a delay between accepted cr50 firmware upload
attempts. The next attempt to write into the same or lower address in
flash would be accepted no sooner than in 60 seconds after the
previous attempt.
This would prevent a rogue user from wearing the flash by repeated
uploads to the same address.
This limitation is not imposed by dev images (those compiled with
CR50_DEV=1).
BRANCH=none
BUG=chrome-os-partner:63098
TEST=verified that attempts to update soon after the previous update
result in the following error message issued by usb_updater:
sending 0x2d8b8 bytes to 0x4000
Error: status 0x9
Modified usb_updater to send one random pdu twice. Observed the
same error message.
Change-Id: Idca55ad091d09daaddd0a4cad5b1f871af1ede93
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445496
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Let's not allow downloading older images when in prod mode.
When the received chunk is destined into RO or RW header, verify that
the chunk's version is not lower than the current running version.
Also, if the chunk is not properly aligned with the header, verify
that it does not overlap with the header in any way.
BRANCH=none
BUG=chrome-os-partner:63098
TEST=verified that older images are rejected by prod images, and newer
and current level are accepted.
Verified that dev images still allow to downgrade.
Change-Id: I19c74f1d1bb5469cc935293a5841405149a968f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/444831
Reviewed-by: Randall Spangler <rspangler@chromium.org>
