Previously, there was no way to identify which flash chip was used by
the EC, for ECs using an external SPI flash. Now, 'ectool flashinfo'
will print more information about the SPI flash chip in these cases.
BUG=chrome-os-partner:56765
BRANCH=any EC with MEC1322 or NPCX still going through factory
TEST=define CONFIG_HOSTCMD_FLASH_SPI_INFO, then
'ectool flashspiinfo' on samus indicates no SPI flash info,
and prints additional info on chell and kevin. Without
the config defined, all platforms report no spi flash info.
CQ-DEPEND=CL:386368
Change-Id: I3c162f7ad12ed4b30ab951c03f24476683382114
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385702
Reviewed-by: Shawn N <shawnn@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When EC receives many flash write requests from host and
PDCMD, CHARGE and USB_CHG_P0 tasks are all ready to run, the
HOOK task may not get scheduled in time to pet the watchdog
resulting in an EC reset.
BUG=chrome-os-partner:51438
BRANCH=None
TEST=Manual on lars, determine two EC versions that have enough
differences so that replacing one image with the other will
require all or most of the flash pages to be updated. Alternate
between flashing the two images with flashrom using a script.
Atleast 1000 iterations should pass.
Change-Id: I8b5c8b680a2935b945f3740e371dee2d218ec4c5
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/334457
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit a537d1ac44c40e7f6e1131e8cc852b030ccdba52)
Reviewed-on: https://chromium-review.googlesource.com/334903
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
A single erase host command may erase an arbitrarily large region of
storage, which may lead to our watchdog firing.
BUG=chrome-os-partner:50587
BRANCH=glados
TEST=Manual on glados, flash RW EC / PD FW while plugging + unplugging
zinger. Verify that watchdog doesn't fire.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I90dc85306aec43326c11c794861f68c6e12686e4
Reviewed-on: https://chromium-review.googlesource.com/329987
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When flashrom performs a flash read following an erase and we do not
wait in between for the erase to complete, we read 0x00 instead of
0xFF. Flashrom detects this and does not proceed further. Inserting
a wait after erase solves this issue.
Also added a wait following a flash write operation to preempt future
issues, and moved spi_flash_wait() calls from Host Command APIs to
lower level spi_flash_* functions.
BUG=chrome-os-partner:43160
BRANCH=none
TEST=Manually tested on Kunimitsu FAB3.
flashrom -p ec -w ec.bin is successful
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Change-Id: I00925aa2da3709a6f3e73a40543b079112906e0a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/302683
Reviewed-by: Shawn N <shawnn@chromium.org>
Since there is no more concept of a flash region belonging only to the
EC, we only need one FLASH_SIZE config, which represents the actual
physical size of flash.
BRANCH=None
BUG=chrome-os-partner:23796
TEST=With entire patch series, on both Samus and Glados:
- Verify 'version' EC console command is correct
- Verify 'flashrom -p ec -r read.bin' reads back EC image
- Verify software sync correctly flashes both EC and PD RW images
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I18a34a943e02c8a029f330f213a8634a2ca418b6
Reviewed-on: https://chromium-review.googlesource.com/297824
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Allow more than one SPI master.
Add CONFIG variables to address the system SPI flash.
To have SPI master ports, spi_ports array must be defined.
BRANCH=smaug
TEST=compile
BUG=chrome-os-partner:42304
Change-Id: Id43869f648965c1582b7be1c7fb3a38f175fda95
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/288512
Commit-Queue: David James <davidjames@chromium.org>
* Fixes cyan/board.h to use correct SPI part
* Adds new flash protection regions in spi_flash_reg.c
* Sets SRP register in flash_physical_protect_at_boot()
* Fixes a bug in COMPARE_BIT macro
* Makes spi_flash_set_status() fail only when both HW pin is asserted
AND SRP(s) are set
* Makes sure set_flash_set_status() completes before returning
BUG=chrome-os-partner:40908
BRANCH=master
TEST=on Cyan:
With WP pin de-asserted:
flashrom -p ec --wp-enable
flashrom -p ec --wp-status, make sure it is enabled
flashrom -p ec --wp-disable
flashrom -p ec --status, make sure it is disabled
flashrom -p ec --wp-enable
Assert WP pin (either with screwdriver or dut-control)
flashrom -p ec --wp-disable
make sure it failed
Change-Id: I338cc906b73e723fdbb37f7c2fd0c4da358b6c8e
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/276671
Reviewed-by: Shawn N <shawnn@chromium.org>
Tested-by: Divya Jyothi <divya.jyothi@intel.com>
Commit-Queue: Divya Jyothi <divya.jyothi@intel.com>
Page Boundary.
If SPI Flash write is at an offset within the page and the length
is greater than remainder of the page, the Flash page gets
corrupted as addressing wraps to the beginning of page and
previously written data gets overwritten. This change splits SPI
Flash writes in such cases into two operations in different pages.
BUG=None
BRANCH=None
TEST=During Software Sync, Depthcharge sends Flash write chunks that
cross page boundary. With this change, the RW parition does not get
corrupted. This can be confirmed by executing a successful
"sysjump RW" after a Software Sync.
Change-Id: I46349eea0d8e927353de7cb55a61e9960291adb6
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/275760
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>
The latest gcc picked up a couple out-of-bounds issues, so
"make buildall" was failing. This fixes them.
BUG=none
BRANCH=ToT
TEST=make buildall -j
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Idcd6a3358ecbb0e0d2a610e1cd28c2f138ce520b
Reviewed-on: https://chromium-review.googlesource.com/231156
Reviewed-by: Randall Spangler <rspangler@chromium.org>
