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>
Make sure all public and private host commands starting with
EC_CMD_ and EC_PRV_CMD_ are properly formed
BUG=chromium:681240
TEST=manual.
Added following host commands and verified that they were flagged
#define EC_CMD_TESTA 1234
#define EC_CMD_TESTB 0xabcd
#define EC_CMD_TESTC 0x1ABCD
#define EC_CMD_TESTD 0xXEF01
#define EC_PRV_CMD_TESTA 1234
#define EC_PRV_CMD_TESTB 0xabcd
#define EC_PRV_CMD_TESTC 0x1ABCD
#define EC_PRV_CMD_TESTD 0XEF01
These were also flagged by the script
include/ec_commands.h:#define EC_CMD_ACPI_READ 0x80
include/ec_commands.h:#define EC_CMD_ACPI_WRITE 0x81
include/ec_commands.h:#define EC_CMD_ACPI_BURST_ENABLE 0x82
include/ec_commands.h:#define EC_CMD_ACPI_BURST_DISABLE 0x83
include/ec_commands.h:#define EC_CMD_ACPI_QUERY_EVENT 0x84
CQ-DEPEND=CL:445809
BRANCH=none
Change-Id: I4630d6a887ed289a68178e8f1a8f07f5141c80bc
Reviewed-on: https://chromium-review.googlesource.com/445811
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
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>
Should be close to the STM32L476 in the STM32L4 family.
Slightly different flash/RAM.
It's currently running from the internal clock (HSI) at 16Mhz,
we need to upgrade to 80Mhz (or 48Mhz if this is fast enough to save us
the PLL locking time).
The internal flash write/erase/protection is still not implemented for
the whole STM32L4 family.
Upgrade the SPI master support and verify that the TX works.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:62893
TEST=make BOARD=eve_fp
run it on Nucleo-L432KC (STM32L432KC is mostly the same MCU without AES)
Change-Id: I87be7d4461aedfbd683ff7bb639c3a6005ee171e
Reviewed-on: https://chromium-review.googlesource.com/442466
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Use the motion sensor to manage ALS as well.
The current interface (via memmap) is preserved, but
we can also access the sensor via cros ec sensor stack and
send the ALS information to ARC++.
BUG=chrome-os-partner:59423
BRANCH=reef
CQ-DEPEND=CL:424217
TEST=Check the sensor is working via ACPI sensor and
cros ec sensor. Check ARC++ sees the sensors.
Change-Id: Iaf608370454ad582691b72b471ea87b511863a78
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424323
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This change adds an option to pdchipinfo command to force ec to get
the version from the chip instead of the cache (if it's available).
This option will be used after firmware update, which makes the cache
value stale.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=Run ectool as follows:
localhost ~ # /tmp/ectool pdchipinfo 0 on
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # /tmp/ectool pdchipinfo 1 on
EC result 2 (ERROR)
Change-Id: Icefe96d7fc1208b991a4caa13aaf4f04052edba7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441271
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The firmware version formats may vary chip to chip. fw_version field is
changed to a union of a 8 byte string and an 64-bit integer.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1 on Electro
Change-Id: Id51e66c44338a09ed897ee61f54cd6a394400e63
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441270
When --raiden is passed as a command line parameter, do not proceed
programming as if it were not present, alert the user and refuse to
proceed instead.
Need to jump though a couple of extra hoops to avoid printing the
error message twice.
BRANCH=none
BUG=none
TEST=tried running with boards supporting and not supporting
programming over CCD.
$ ./util/flash_ec --board=oak --raiden --image rowan.ec.bin
INFO: Using ec image : rowan.ec.bin
ERROR: raiden mode not supported on oak
$ ./util/flash_ec --board=kevin --raiden --image rowan.ec.bin
INFO: Using ec image : rowan.ec.bin
INFO: Flashing chip npcx_spi.
INFO: Using raiden debug cable.
...
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: Ia40f348e6dde57fc2f4c49719bc2a0947036dcc1
Reviewed-on: https://chromium-review.googlesource.com/440051
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch adds a host command to get PD chip info.
For PS8751, tcpci_get_chip_info will fail if the chip is in
low power mode. It can be woken up by reading a random register
first then wait for 10ms.
This code doesn't have the wake-up read to avoid 10ms delay.
Instead, we call this function immediately after the chip is
initialized because it'll gurantee the chip is awake.
Once it's called, the chip info will be stored in cache, which
can be accessed by tcpc_get_chip_info without worrying about
chip states.
localhost ~ # ectool pdchipinfo 0
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # ectool pdchipinfo 1
vendor_id: 0x1da0
product_id: 0x8751
device_id: 0x1
fw_version: 0x37
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1. make buildall
Change-Id: I3f1667d00ce1826936d90882ada1df6ed6b0ea37
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433166
We get a lot of these errors when running the EC Makefile from an ebuild.
They are not useful since of course there is no git repo when the source
code is built from a copy. An empty date (as produced in this case) is
presumably good enough.
Suppress these errors by redirecting stderr.
BUG=chromium:680243
BRANCH=none
TEST=V=0 emerge-reef chromeos-ec; See that the git output is gone
Change-Id: Ia3d1e2046c87e0ca88d0c18e432467f9d23b7e9f
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428156
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commit adds a "spoof" mode feature to the motionsense stack. It
allows the user to arbitrarily set the outputs of the sensor in order to
"spoof" the readings of the sensor. This can be useful in emulating
tablet mode or device rotations. A command is available from the EC
console named `accelspoof` and there is a corresponding motionsense
command in ectool called `spoof`.
The usage is as follows:
- EC console
> accelspoof [id] [on/off] [X Y Z]
- ectool
# ectool motionsense spoof -- [id] [0/1] [X Y Z]
If on or off(or 0/1) is not specified, the current spoof mode status of
the sensor is returned. If on is specified, but no components are
provided, the sensor will lock the current values and provide those as
the spoofed values. If the components are provided, those will be used
as the spoofed values.
BUG=chromium:675263
BRANCH=cyan,glados,gru,oak
TEST=Flash a DUT with accels. From AP console, run `ectool motionsense
lid_angle` in a loop, use 'accelspoof' EC console command to set spoofed
values. Verify that the angle is fixed regardless of the actual angle
of the DUT.
TEST=Flash a DUT with accels. From AP console, use `ectool motionsense
spoof` to spoof values and verify that `ectool motionsense` reflects the
spoofed values. Test with both provided component values and no
component values.
Change-Id: Ie30688d22f38054e7243b1af493a3092b2cdfb72
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/421280
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
In preparation to a new release let's bump up minor versions of both
prod and dev images to 12.
BRANCH=none
BUG=none
TEST=built images and verified version number
Change-Id: I55979374f5e3e21fedde128410c4861e4c2ad9c4
Reviewed-on: https://chromium-review.googlesource.com/417883
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
This is a 'semi official' utility script which re-signs previously
generated CR50 RW images.
By default the script uses ec.RW.elf and ec.RW_B.elf in build/cr50/RW
as inputs and util/signer/ec_RW-manifest-dev.json as the manifest, and
places the newly signed images into build/cr50/ec.bin.
The only outside dependency of this script is the signing utility itself,
which is expected to be available as $HOME/bin/codesighner.
The following command line options are accepted:
b1 - generate signature for the b1 version of the H1 chip
elves <elf1> <elf2> - sign the supplied elf files instead of the
default ones. Handy if the builder generated files need to be
signed
help - print this message
hex - generate hex output instead of binary
prod - sign with prod key (no debug image will be signed)
When invoked with 'hex' as a command line parameter, the script just
re-signs the supplied elf files and places them in 0.signed.hex and
1.signed.hex in the current directory.
This script also allows to sign dev images for running on prod RO. To
do that invoke this script as follows:
H1_DEVIDS='<dev id0> <dev id1>" ${progname} [other options, if any]
where <dev id0> <dev id1> are values reported by sysinfo command in the
DEV_ID: line when ran on the CR50 for which the image is built.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=manual
tried signing dev and prod images, including sighing a dev image to
run on a prod device. All cases succeeded.
Change-Id: I879c4a08503a19a0c440b141aa1fd6b29cc70bf7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417221
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The manifest used for signing in dev mode was originally used for
kevin evt 1, but now it is a common dev mode manifest. Rename the fie
appropriately and modify the makefile using it.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=verified that it is still possible to build cr50 with CR50_DEV=1
Change-Id: If744406a83a7045cd34c76c941fdef209bef51ac
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The latest released images are 0.0.11, let's update the manifests such
that images built in dev environment can override released images.
BRANCH=none
BUG=none
TEST=verified that new images are built with RW version 0.0.11
Change-Id: I4db82abd3eb725849b656259f675b32a8314942c
Reviewed-on: https://chromium-review.googlesource.com/415601
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
BRANCH=none
util/ectool.c:1158 merror: taking address of packed member 'size' of class
or structure 'ec_params_usb_pd_fw_update' may result in an unaligned
pointer value [-Werror,-Waddress-of-packed-member]
For this case, the pointer is always aligned but clang complains.
Workaround using double pointer casts to char and uint.
uint32_t *data = &(p->size) + 1;
BUG=chromium:665240
TEST=Builds now
Change-Id: Ibccf0f6e409b9724fc9e5acf28dde570e9d341e3
Reviewed-on: https://chromium-review.googlesource.com/411384
Commit-Ready: Manoj Gupta <manojgupta@chromium.org>
Tested-by: Manoj Gupta <manojgupta@chromium.org>
Reviewed-by: Yunlian Jiang <yunlian@chromium.org>
The firmware provision job running in the lab calls the flash_ec
script with the --chip parameter, instead of the --board parameter.
So only check if the board name is in the raiden list if it is a
non-empty board.
BRANCH=none
BUG=chrome-os-partner:58039
TEST=Manually triggered the flash_ec command:
$ flash_ec --chip=npcx_spi --image=${IMAGE} --port=9999 --raiden
Change-Id: I25fef906d93803a94c544f7699ce494a84c46bd8
Reviewed-on: https://chromium-review.googlesource.com/410162
Commit-Ready: Wai-Hong Tam <waihong@google.com>
Tested-by: Wai-Hong Tam <waihong@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
make build=lucid fails if there is an uncommitted change in the tree
because '-dirty' is appended to version strings, which causes the image
to exceed the flash size limit.
BUG=chromium:654549
BRANCH=none
TEST=make buildall -j
Change-Id: Ie4a7b4c7dc70846108aed953215f79dc30a10fca
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396617
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Match ec_commands.h, adding new type and sensors.
BUG=none
BRANCH=reef
TEST=Check on Reef that barometer sensor info is displayed properly.
Change-Id: I257f5161e5f57be562a2b3a29442b49f47f3fc89
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394749
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Due to an error in ms_command_sizes, fifo_info command
would fail when lost vectors are present:
packet too long (16 bytes, expected 10)
Reorder ms_command_sizes commands properly.
Get the number of sensors present before printing the number of lost
vectors per sensor.
BUG=none
BRANCH=none
TEST=On cave (with broken MKBP support), check fifo_info
is returning the lost vectors count.
Change-Id: Ic745eb762563705372d8a670ce34eab15e188bf9
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391887
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In preparation to the new CR50 image release bump up the minor version
number to trigger autoupdate on the devices in the field.
BRANCH=none
BUG=none
TEST=none
Change-Id: I7744b8cb8436d9134ee5900b352487a1cdddcd28
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392447
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>
We no longer depend on this directory, so there's no need to
include its sha1sum in the version string.
BUG=chrome-os-partner:54101
BRANCH=none
TEST=make buildall; try on Cr50 hardware
Before
> version
Chip: g cr50 B2
Board: 0
RO_A: * 0.0.9/0088a3eb
RO_B: 0.0.3/8fe06b9e
RW_A: * 0.0.6/DEV/cr50_v1.1.5333-cca986c
RW_B: 0.0.6/DEV/cr50_v1.1.5334-115b338
Build: 0.0.6/DEV/cr50_v1.1.5333-cca986c
private-cr51:v0.0.87-24457f2
tpm2:v0.0.264-5e5aaa3
cryptoc:v0.0.4-5319e83
2016-09-16 21:59:31 wfrichar@wintermute.mt
>
After
> version
Chip: g cr50 B2
Board: 0
RO_A: * 0.0.9/0088a3eb
RO_B: 0.0.3/8fe06b9e
RW_A: 0.0.6/DEV/cr50_v1.1.5333-cca986c
RW_B: * 0.0.6/DEV/cr50_v1.1.5334-36b2cee
Build: 0.0.6/DEV/cr50_v1.1.5334-36b2cee
tpm2:v0.0.264-5e5aaa3
cryptoc:v0.0.4-5319e83
2016-09-19 17:48:17 wfrichar@wintermute.mtv.corp.google.com
>
Change-Id: I785dff86e6b970219da87c8674f2a324fa074987
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387238
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We often find it handy to build test images that are unlocked or
have special powers. To avoid confusing these with production
images, this adds a "DEV/" to the version string:
"make BOARD=cr50" looks like this:
> version
Chip: g cr50 B2
Board: 0
RO_A: * 0.0.9/0088a3eb
RO_B: 0.0.8/710d4375
RW_A: * 0.0.6/cr50_v1.1.5261-4848d7e
RW_B: 0.0.6/cr50_v1.1.5261-4848d7e
[...]
"CR50_DEV=1 make BOARD=cr50" looks like this:
> version
Chip: g cr50 B2
Board: 0
RO_A: * 0.0.9/0088a3eb
RO_B: 0.0.8/710d4375
RW_A: 0.0.6/cr50_v1.1.5261-4848d7e
RW_B: * 0.0.6/DEV/cr50_v1.1.5261-4848d7e
[...]
BUG=chrome-os-partner:55557
BRANCH=none
TEST=make buildall; also..
Build both with and without the CR50_DEV=1 environment variable.
Observe that the version string differs even if nothing else
does.
Change-Id: Ifee9fbf922c2bbb40a1a9d0a716d2d11aa0d3ec2
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382851
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We don't really have the ability to build the latest signer yet, but
this should not stop us from being able to build a properly signed
image using the ec makefiles.
As a stopgap measure the suggestion is to keep the latest signer
binary in ~/bin/codesigner in chroot, then with this patch applied
invoking make with CR50_DEV=1 will cause the proper sighner used and
proper signing procedure followed.
The signed targets need to be built in series to avoid concurrent use
of the signer fob, an addition dependency is being added to enforce
that.
BRANCH=none
BUG=chrome-os-partner:55557
TEST=ran make as follows:
CR50_DEV=1 make BOARD=cr50
touched the fob when requested, uploaded the generated
build/cr50/ec.bin on a kevin-tpm2 using usb_updater, and observed
it boot properly with the new version.
Change-Id: Ia9494bdc60b4bd3b8e5e09cbcbd8b27409c739d2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376885
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
To be able to parse binary panicinfo from feedback reports, we need
a host tool:
- Move panicinfo generic parsing functions to a separate C file
- Create a new host utility to parse panicinfo
BRANCH=none
BUG=chromium:643062
TEST=base64 -d | ec_parse_panicinfo
Change-Id: Idd8560a2894f270d0ab3a9f654c333135759e57f
Reviewed-on: https://chromium-review.googlesource.com/379639
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Record what current limit we set when we act as a source
and when we are changing it.
The change should be backward-compatible as older EC will return 0 in
`current_max` when their role is PD_ROLE_SOURCE while newer firmware
will set the actual limit.
BRANCH=none
BUG=chrome-os-partner:56110
TEST=manual: on Kevin, plug and unplug various devices on the 2
ports, and dump the values with 'ectool usbpdpower'.
Change-Id: I8e78663f3196b1b81c2235ed8642da0638bed649
Reviewed-on: https://chromium-review.googlesource.com/375918
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
