summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* usb_updater: when communicating over tpm treat upgrades differentlyv1.9308_25_B.0Vadim Bendebury2017-08-191-13/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All extension and vendor commands' payloads need to be passed to the processing functions the same way, whether they arrive over /dev/tpm0 or over USB. The upgrade PDUs sent over USB need to include two additional fields which are stripped off by the reassembly layer on the Cr50. This patch makes sure that none of other than EXTENSION_FW_UPGRADE commands sent over /dev/tpm0 by usb_updater have the extra encapsulation. BRANCH=cr50 BUG=b:62106898 TEST=verified that updates work the same way over TPM and USB (which includes sending the 'turn_update_on' commands. Before this patch the turn_update_on command sent by usb_updater over TPM was not processed properly (the timeout value was wrong). Change-Id: I3f4ab7330037f6eb1ce8bac7c63faa5d7c309c94 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/517416 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit bd0f74a6f49cd3dcbed81738e376a8b05868b4f5) Reviewed-on: https://chromium-review.googlesource.com/538561 (cherry picked from commit 43ec46b4ee1e63526a787479d38d92545e5a7466) Reviewed-on: https://chromium-review.googlesource.com/622209 Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Commit-Queue: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org>
* cr50: allow vendor command to turn update on even in prod imagesVadim Bendebury2017-05-231-1/+1
| | | | | | | | | | | | | We want to always be able to update cr50 image to a newer version, even if the AP is not cooperating. BRANCH=cr50 BUG=b:35580805 TEST=verified that update of a prod image is possible Change-Id: I3bbe2c4aca8bf0c3129f4495db0e76405a2ed189 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/511704
* cr50: prepare to release version 0.0.20Vadim Bendebury2017-05-232-2/+2
| | | | | | | | | | BRANCH=cr50 BUG=None TEST=built an image, observed version number. Change-Id: Iceec4cc72f0148966df0712d0b83a8680dbba686 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/511705
* usb_updater: /dev/tmp0 -> /dev/tpm0Brian Norris2017-05-121-1/+1
| | | | | | | | | | | | | | | | | | | That's a typo. BUG=none TEST=none BRANCH=none Reviewed-on: https://chromium-review.googlesource.com/470507 Reviewed-by: Andrey Pronin <apronin@chromium.org> (cherry picked from commit 6277174bff831f7fae8958dfdab131893cc43dcc) Change-Id: I4577a746c113b6c1d2c6745975272532909c8a8a Signed-off-by: Brian Norris <briannorris@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505257 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* usb_updater: only run send_done on usb transfersMary Ruthven2017-05-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | show_fw_ver runs send_done on both usb and tpm transfers. This changes usb_update, so it will only run send_done on usb transfers BUG=none BRANCH=cr50 TEST=copy to dut. stop trunksd. Run 'usb_updater -f -s && usb_updater -f && usb_updater -f' Reviewed-on: https://chromium-review.googlesource.com/470169 Commit-Ready: Mary Ruthven <mruthven@chromium.org> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 56e3c669e829993683199514b78d2497784d3766) Change-Id: I3a09c003ae41a4651c9961092552d7807656a68a Reviewed-on: https://chromium-review.googlesource.com/505256 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* usb_updater: do not filter out dev cr50 versionsVadim Bendebury2017-05-121-12/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The usb_updater code comparing versions to decide which one is newer filters out values in excess of 1000 to not consider dev build versions to be newer than the released versions. In fact this logic is flawed: with node locked RO it is possible to build dev (self signed) version, which can run on the device, and this version should take over the released version, if it is currently present on the device. If the RO is not node locked, the dev RW version will not verify, so it is safe to download it to the chip, it would be ignored. BRANCH=cr50 BUG=none TEST=with this patch applied it is possible to update self signed versions running on H1 (the updater considers them newer than 0.0.18 and sends the chip the vendor command to enable the downloaded image after download completes). Reviewed-on: https://chromium-review.googlesource.com/492087 Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 32eebe3c5f12c1963bf9bc921839de1168cd7396) Change-Id: Ibb5761e4bb24fcc7dee5cc10b2f26af7a8e9aa2e Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505451
* cr50: use 2048 bit key for autosigned imagesVadim Bendebury2017-05-121-37/+25
| | | | | | | | | | | | | | | | | | | | | | | | | The node locked ROs expect the RW image to be self signed with a 2048 bit key. The only case where loader-testkey-A.pem file is used is is building vanilla images which can't even run any more (they used to be good for old dev RO). Let's replace the 3072 bit key with a 2048 bit key generated by running 'openssl genrsa -3 2048 > util/signer/loader-testkey-A.pem' BRANCH=none BUG=none TEST=verified that RW signed with this key can be run by a node locked RO. Reviewed-on: https://chromium-review.googlesource.com/489434 Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> (cherry picked from commit 5acd520c00d106b5c465af374c29aba050360ffc) Change-Id: I74d189d03acb663fde7db48815e54748163c6399 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/505450
* usb_updater: post a reset during upstart on old versionsMary Ruthven2017-04-071-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If Cr50 does not have support for invalidating the RW header and restoring it, then upstart should still post a reset. This changes usb_updater to post a restart during upstart if the RW minor version is less than 19. BUG=none BRANCH=cr50 TEST=manual Copy new usb_updater onto the DUT. run 'sync' Build two cr50 debug images one with 0.0.19 and one with 0.1.12 verify update process works test_that $DUT_IP -b $BOARD firmware_Cr50Update --args="old_release_image=$PATH_TO_PROD_13 release_image=$PATH_TO_PROD_18 dev_image=$DBG_IMAGE_19" Build a firmware image with https://review.coreboot.org/#/c/18946/3 test_that $DUT_IP -b $BOARD firmware_Cr50Update --args="old_release_image=$PATH_TO_PROD_18 release_image=$DBG_IMAGE_19 dev_image=$DBG_IMAGE_1_12" Change-Id: I811977de26999b1d26bd2d4126b88b1c55a93931 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/470326 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit bcc4e087a13727755482b13b44f1ab7bfd361beb) Reviewed-on: https://chromium-review.googlesource.com/471929
* usb_updater: fix --fwverMary Ruthven2017-04-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit e69a10388476c963c52d99967d15362a5ce44064) Reviewed-on: https://chromium-review.googlesource.com/470487
* usb_updater: fix -b optionMary Ruthven2017-04-061-1/+1
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 24fd8060fd27f0306d5d3f91faa09d28ed892772) Reviewed-on: https://chromium-review.googlesource.com/470486
* cr50: add a function to read TPM NVMEM locationsVadim Bendebury2017-03-242-0/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 61f61b368eeacc3c4d4627bdfa8d81e9b6538675) Reviewed-on: https://chromium-review.googlesource.com/459225
* g: add code to corrupt new header until further notice and move rw to 0.0.19Vadim Bendebury2017-03-244-18/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 9e931878cad2e55094713d7c7da4867533e40f4b) Reviewed-on: https://chromium-review.googlesource.com/459224
* usb_updater: separate image updates and resets, add restore image optionVadim Bendebury2017-03-241-62/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 218f65dda650e775b9e28e5dee9704f6511e8a28) Reviewed-on: https://chromium-review.googlesource.com/459223
* cr50: add vendor command to restore corrupted headerVadim Bendebury2017-03-244-1/+145
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit dc66986d0a7fd182ddcafbee00045a25709edcb4) Reviewed-on: https://chromium-review.googlesource.com/459222
* g: expose API to unlock secondary RO areaVadim Bendebury2017-03-243-16/+21
| | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit a4f6a548d8f3e05d01563b52095b03cecb23fe28) Reviewed-on: https://chromium-review.googlesource.com/459221
* usb_updater: stop supporting protocol versions below 5Vadim Bendebury2017-03-241-107/+47
| | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit bd30d3f2cd5a0fb90ec72ed7ea47b3f29d114c7f) Reviewed-on: https://chromium-review.googlesource.com/459220
* cr50: use plt_rst_l low level as a sleep wake triggerVadim Bendebury2017-03-161-4/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an x86 based system is reset, a pulse on the plt_rst_l line is generated. This pulse is supposed to reset the system and the pulse' rising edge is an interrupt trigger for H1 to reset the TPM. If H1 is in sleep state at the time of the rising edge, the interrupt request could be lost. Luckily, the minimum plt_rst_l pulse duration is 1 ms, and the worst case max time to wake up from sleep for H1 150 us. Let's wake up on low level of plt_rst_l, this way by the time the rising edge comes along the H1 would be awake and ready to process the interrupt. BRANCH=cr50 BUG=b:35995492 TEST=verified that platform_KernelErrorPaths.CORRUPT_STACK passes hundreds of times on a system were it was failing after a few runs before this fix. - verified that suspend_stress_test still succeeds at least 300 iterations Change-Id: Ib9984efa08bdd185a95716dc9e48077cf4bb3c2a Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/455579 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 43abc6d9dec5fbea7f4f29f4b238bb21d5c8ea1f) Reviewed-on: https://chromium-review.googlesource.com/456047
* cr50: prepare to release rw 0.0.18Vadim Bendebury2017-03-162-4/+4
| | | | | | | | | | | | | | | | | | | Erase the first location in the manifest info map to ensure that the flash info state is updates and then the RO prevents booting earlier images (where the map is unaltered). BRANCH=cr50 BUG=none TEST=verified that once both RW_A and RW_B are programmed with the new image and the H1 is restarted, the first info map location is erased. Change-Id: Id48d8a2009f7cf9842b7a33f036dc98457dbeafc Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/455580 Reviewed-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> (cherry picked from commit 597a3bc943fd2517ec877bacf9357687fbffdc0b) Reviewed-on: https://chromium-review.googlesource.com/456046
* cr50: fix prod images timestampVadim Bendebury2017-03-151-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When sighing prod images it is important to be able to reproduce them bit for bit. Setting the manifest timestamp filed to a non-zero value makes sure that this value is used in the header as opposed to the current time. Setting the value to 1 guarantees that any dev image with the same epoch/major/minor field values will be preferred, as it would have a later timestamp. BRANCH=none BUG=none TEST=verified that two images built with this manifest are exactly the same (they used to differ before this change). verified that the header timestamp field is indeed set to 1: $ od -Ax -t x1 -vd d2/cr50.bin.prod | grep -A1 004350 $ 004350 ff ff ff ff ff ff ff ff ff ff ff ff 00 00 00 00 $ 004360 00 00 00 00 11 00 00 00 01 00 00 00 00 00 00 00 location 0x435c is the epoch_ field offset, 32 bit epoch/major/minor is set to 0/0/17 and 64 bit timestamp is set to 1. Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Change-Id: I6ea0e664fa3eab7917ca472d715824feec49eb51 Reviewed-on: https://chromium-review.googlesource.com/452956 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit 3d9c6052578758558f4cef73e473b0fb8d1f7b29) Reviewed-on: https://chromium-review.googlesource.com/455249 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* g: fix sps interrupt assertion logicVadim Bendebury2017-03-101-8/+15
| | | | | | | | | | | | | | | | | 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> (cherry picked from commit 2c0b6b7d3d354e636eacb6deaf2ebc6393f09550) Reviewed-on: https://chromium-review.googlesource.com/452648
* g: add a cli command to erase flash INFO1 spaceVadim Bendebury2017-03-101-0/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 69fda70a1bfcf144c88fbdb5a335ab8bef276c11) Reviewed-on: https://chromium-review.googlesource.com/452553
* cr50: add rollback information to the sysinfo command outputVadim Bendebury2017-03-103-0/+55
| | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 855ac132242cab78197463bdd7d11fa57c108d9a) Reviewed-on: https://chromium-review.googlesource.com/452552
* cr50: use empty rollback map when building debug imagesVadim Bendebury2017-03-101-2/+19
| | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 3c16e87eb4703d3eb029526965bb59d3ada9794d) Reviewed-on: https://chromium-review.googlesource.com/452551
* g: mark RW INFO rollback map space to match the header infomap fieldVadim Bendebury2017-03-105-10/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 46d6b0471231f8fc9549666acf75eb16334f593e) Reviewed-on: https://chromium-review.googlesource.com/452550
* cr50: Only drive CCD_MODE_L when in CCD mode.Aseda Aboagye2017-03-095-28/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit ffd1ee934f310a644c03b88fa2ae3e66ec847a04) Reviewed-on: https://chromium-review.googlesource.com/452700 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* cr50: enable utmi wakeupsMary Ruthven2017-03-093-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit f8e9a694f200f56ce7cb840184fa271b114ce32c) Reviewed-on: https://chromium-review.googlesource.com/452699 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* g: enable usb wakeup interruptsMary Ruthven2017-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 0de92e26167a858d7350d6bd2af75f2f0b73f960) Reviewed-on: https://chromium-review.googlesource.com/452001 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* cr50: prepare to release rw 0.0.17Vadim Bendebury2017-03-092-2/+2
| | | | | | | | | | | | | | | | | Update both prod and dev manifests. BRANCH=none BUG=none TEST=none Change-Id: I07b0c188cdc22539dc368900c0acade7c582a0eb Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/450956 Commit-Ready: Vadim Bendebury <vbendeb@google.com> Tested-by: Vadim Bendebury <vbendeb@google.com> Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 154868ed90bdcc7ed5850a4b5f367f961e935282) Reviewed-on: https://chromium-review.googlesource.com/452000
* common: Ensure print_build_string() prints short strings properly.Carl Hamilton2017-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | Pass "full_build_string" to ccprintf() as expected. I believe that this code only worked previosly due to blind luck; the compiler allocated "full_build_string" on the stack in such a way that it was available at the end of the call frame for ccprintf(). BUG=none BRANCH=none TEST=make -j buildall Change-Id: Ib307547a4c4d6300ccf018b33aee4db7a4f364f8 Reviewed-on: https://chromium-review.googlesource.com/451084 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Carl Hamilton <carlh@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit f23ca90aef4c2583821a6964e3a86af81ad76a59) Reviewed-on: https://chromium-review.googlesource.com/451999 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* cr50: make sys_rst_l wake on lowMary Ruthven2017-03-091-7/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue is with how we have the sys_rst_l wake pin setup. How it is now, the gpio controller never sees that sys_rst_l is asserted, so it can't tell when there is a rising edge. sys_rst_l is a rising edge wake pin. Cr50 would enter sleep with sys_rst_l high. While cr50 was asleep sys_rst_l would be asserted and then deasserted. The rising edge would wake cr50 up, and when cr50 woke up the gpio controller would see that sys_rst_l is still high, so it wouldn't think there was an edge and it wouldn't trigger the tpm reset interrupt. This change makes sys_rst_l wake low instead of wake rising. This means that cr50 will remain awake whenever sys_rst_l is asserted and it will be awake to see the rising edge on sys_rst_l. BUG=b:35774896 BRANCH=cr50 TEST=Turn off bob. Wait until cr50 enters regular sleep. Turn the device back on and make sure it doesn't boot to recovery. Change-Id: Ibee6c8112d32b3abb8953aa71d68e1f510932286 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/451998 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* cr50: change DEV to DBG in debug images version stringsVadim Bendebury2017-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are two types of signing of CR50 images - prod and dev. Designating images built with CR50_DEV variable set in the environment as DEV is confusing, as this has nothing to do with the signing type (dev vs prod), and is in fact indicating an image with many debug features enabled. This patch changes the string to "DBG". BRANCH=cr50 BUG=none TEST=verified that the modified image has correct string in the version field: > vers Chip: g cr50 B2-D Board: 0 RO_A: * 0.0.10/29d77172 RO_B: -1.-1.-1/ffffffff RW_A: 0.0.16/DBG/cr50_v1.1.6137-1624610+ RW_B: * 0.0.16/cr50_v1.1.6137-1624610+ Build: 0.0.16/cr50_v1.1.6137-1624610+ tpm2:v0.0.287-1a68fe6 cryptoc:v0.0.8-6283eee 2017-03-06 16:51:15 vbendeb@eskimo.mtv.corp.google.com > Change-Id: I06a97a6aff5418a4d02e71ca23813e6d2005da5c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/450903 Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 187d57f292725937b55e53b8c28b1b136c0c285b) Reviewed-on: https://chromium-review.googlesource.com/451542
* g: add deep sleep counter to idle.cMary Ruthven2017-03-082-12/+20
| | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 31a0130f595cc4d1142ef5d32ab4561a207e0790) Reviewed-on: https://chromium-review.googlesource.com/451541 Tested-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* init_chip: add comment document pmu scratch registersMary Ruthven2017-03-081-0/+21
| | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 0f2b3d0ca31f6a470d4f9e353c13d1e69c90d564) Reviewed-on: https://chromium-review.googlesource.com/451540 Tested-by: Vadim Bendebury <vbendeb@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
* usb_updater: fix command line options descriptionVadim Bendebury2017-03-081-1/+2
| | | | | | | | | | | | | | | | | | | The -b command line option should not be described as requiring a parameter, as the binary file is given to most of invocations of usb_updater. Also adding the missing -p command line option description. BRANCH=none BUG=none TEST='usb_updater -b <file name>' does not fail any more Change-Id: I6ceefa8c4dda841db63177d6134a611600a43078 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/448956 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit ee1ccf4fbe7edf9817cb1d64043dbbdc926b9be2) Reviewed-on: https://chromium-review.googlesource.com/451539
* g: enhance flash INFO apiVadim Bendebury2017-03-073-25/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit b1afdd76bc3f7b35a2cdca817684ebe224a4c9a9) Reviewed-on: https://chromium-review.googlesource.com/451538
* g: reformat signing manifestsVadim Bendebury2017-03-072-256/+38
| | | | | | | | | | | | | | | | | | | The json parser used by the signer is perfectly capable of parsing multiline contents. Let's reformat signer manifests to make it easier to see the entire file in one terminal window. BRANCH=none BUG=b:35774863 TEST=none Change-Id: I41d69ad11f07521f68a7a50227dc843872613127 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/447841 Reviewed-by: Marius Schilder <mschilder@chromium.org> (cherry picked from commit ef6f6c5edfe8817d31ee32e5acb1e687d60f23fd) Reviewed-on: https://chromium-review.googlesource.com/451537
* usb_updater: change command line option from --spi to --systemdevVadim Bendebury2017-03-021-19/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The command line option to trigger communicating with the cr50 over /dev/tpm0 has been set to 'spi' originally, as SPI was the interface to communicate with the TPM on first devices using cr50. This is not technically correct, as many devices use i2c for this purpose. Let's rename the command line option from 'spi' to 'dev' and correct names and comments to reflect this too. BRANCH=none BUG=none TEST=ran on a reef device: localhost tmp # ./usb_updater -f --systemdev Could not open TPM: Device or resource busy localhost tmp # initctl stop trunksd trunksd stop/waiting localhost tmp # ./usb_updater -f --systemdev start target running protocol version 6 offsets: backup RO at 0x40000, backup RW at 0x4000 keyids: RO 0xaa66150f, RW 0xb93d6539 Current versions: RO 0.0.10 RW 0.0.16 localhost tmp # ./usb_updater -f -s start target running protocol version 6 offsets: backup RO at 0x40000, backup RW at 0x4000 keyids: RO 0xaa66150f, RW 0xb93d6539 Current versions: RO 0.0.10 RW 0.0.16 Change-Id: Ifbdd3618209ad9930e0678cf50e82a789ae5e2cd Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/447781 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 6ceabb07e3ee571437cba34360701b73e83f5516) Reviewed-on: https://chromium-review.googlesource.com/448721
* cr50: Store console lock state in NvMem vars.Aseda Aboagye2017-03-029-25/+186
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit enables the use of the nvmem vars module. The console lock state is migrated from using the long life scratch register, to nvmem vars instead which will persist across power on reboots. BUG=b:35586145 BRANCH=None TEST=Flash a dev image. Lock the console. Remove all power from the system. Power on system and verify that console is still locked. Unlock the console, remove power from the system, power on the system, verify that the console is now unlocked. TEST=Repeat the above test, but using the nvtestvar console command instead. Change-Id: I03a2098bb0017cfca59889457a332eafb0e95db6 Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/445804 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/448720 Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
* g: usb_updater: fix option description and add post_resetVadim Bendebury2017-03-021-13/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new option allows the operator to explicitly request the post reset reboot instead of immediate reboot (which is now ignored by production cr50 images). Also sort option descriptions and move the colons where they belong (after command line arguments requiring additional parameters), BRANCH=none BUG=none TEST=running usb_updater with -b or -d without extra parameter causes the return error code and the help message printed. running $ ./extra/usb_updater/usb_updater -p build/cr50/ec.bin results in a proper image transfer, with the following reboot of the chromeos device triggering cr50 reset and the new downloaded image running. Change-Id: I64328973a2dfac1b78262f1ffacd677e52956d27 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/446939 Reviewed-by: Aaron Durbin <adurbin@chromium.org> (cherry picked from commit 31cfc63b80ea8f5b778e6c3f568f325a6064244a) Reviewed-on: https://chromium-review.googlesource.com/448719
* g: sps: add flow control signalingVadim Bendebury2017-03-021-0/+9
| | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 569b5e8f0f124f08e2c1e3cab27081dfff2e266c) Reviewed-on: https://chromium-review.googlesource.com/448718
* cr50: preapare to release 0.0.16Vadim Bendebury2017-03-022-2/+2
| | | | | | | | | | | | | | | BRANCH=none BUG=none TEST=none Change-Id: I69d46d25601ffedb68d3f87e873dc8c502f10810 Reviewed-on: https://chromium-review.googlesource.com/445874 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> (cherry picked from commit 3cf2d9047ab798de9eb74ac73dcb3cd7b612f455) Reviewed-on: https://chromium-review.googlesource.com/448717
* cr50: Make sure TPM wipe only clears TPM data.Aseda Aboagye2017-03-024-44/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously, wiping the TPM would wipe all of NvMem, however, it really should only clear the TPM's NvMem space. This commit adds a function to clear a given NvMem user's space and makes the TPM only clear its space. BUG=chrome-os-partner:61597 BRANCH=None TEST=Add code for using nvmem vars, create a test variable, add a user to snappy, unlock the console, verify that the user is no longer present on the system and the test nvmem var still exists. TEST=make -j buildall Change-Id: Ic98baa5166a1ef9ae76e910b1b9ab100300e947f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/445803 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> (cherry picked from commit d7303404a59a296fad9085db23fa18fe97f0f5c3) Reviewed-on: https://chromium-review.googlesource.com/448716 Commit-Queue: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* g: rate limit firmware updatesVadim Bendebury2017-03-023-1/+47
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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> (cherry picked from commit 5221d127e157240a1e3b2275190b2686dfafe6e5) Reviewed-on: https://chromium-review.googlesource.com/448335
* g: harden upgrade validity checks for prod imagesv1.9308_B.0Vadim Bendebury2017-03-022-2/+97
| | | | | | | | | | | | | | | | | | | | | | 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/448702 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* hammer: Switch to CONFIG_RWSIG_TYPE_RWSIGNicolas Boichat2017-02-221-1/+1
| | | | | | | | | | | | | | | | This is the recommended futility signature type for new boards. BRANCH=none BUG=chromium:690773 TEST=Flash hammer, RW image checked correctly TEST=futility show --type rwsig \ --pubkey build/hammer/key.vbpubk2 build/hammer/ec.RW.bin Change-Id: Id8648199891fdd4df63ecb599e0c5e927bc861d0 Reviewed-on: https://chromium-review.googlesource.com/441549 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* nvmem: do not prefer old partition over new one.Vadim Bendebury2017-02-221-16/+15
| | | | | | | | | | | | | | | | | | | | | | | | The code deciding which partition to choose properly determines which one is newer, but invariably populates the cache with the second one, when both partitions are valid. This is obviously wrong, on top of that there is no need to check both partitions' validity, if the newer one checks out. BRANCH=none BUG=chrome-os-partner:60555, chrome-os-partner:61972 BUG=chrome-os-partner:61716, chrome-os-partner:61234 BUG=chrome-os-partner:61167, chrome-os-partner:60555 TEST=successfully ran $ ssh 192.168.1.102 suspend_stress_test --suspend_min 10 \ --suspend_max 10 --wake_max 10 --wake_min 10 for more than 300 cycles (it still is going) Change-Id: I02d9bb062b9edbbb9787a95ba760872e09ff2761 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/445356 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Benson Leung <bleung@chromium.org>
* rwsig: Put key/signature at the end of RO/RW sectionsNicolas Boichat2017-02-221-4/+17
| | | | | | | | | | | | | | | | | | | | | | | Current code puts key at the end of the first half of flash, which may not match the actual RO section size (e.g., it might be PSTATE, not RO). This makes sure the key to be at the end of RO section, and signature at the end of RW section, no matter the actual layout being used. However, the (deprecated) usbpd1 image type assumes that flash is equally split between RO and RW, so we do not change that. BRANCH=none BUG=chrome-os-partner:61671 TEST=make BOARD=hammer -j && deploy TEST=make BOARD=hoho -j && \ futility show --type usbpd1 build/hoho/ec.bin Change-Id: Ia02e927f9128d6ec3d0b780c28312e0d18835d72 Reviewed-on: https://chromium-review.googlesource.com/426100 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* g: use H1_DEVIDS as a trigger to use the fob for signingVadim Bendebury2017-02-221-12/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Presently the CR50_DEV make variable is loaded: it enables debug extensions in the produced cr50 image AND requires that the image is signed with the key from the signing fob. In fact these are two independent requirements: it is possible to use an image built with CR50_DEV set for a dev H1 which does not require fob signing. A proper indication of the need to use the signing fob would be the fact that H1_DEVIDS is defined, as it means a that node locked image is being produced. Images built without H1_DEVIDS set can be used on H1s which run with the dev RO and as such do not need to be node locked, they are signed with a well known key from util/signer/loader-testkey-A.pem. This patch also tweaks passing the H1_DEVIDS variable to the shell when altering the manifest. Without this tweak H1_DEVIDS definition as make command line argument (as opposed to environment variable) was not making it into the subshell invoked by make. BRANCH=none BUG=chrome-os-partner:62457 TEST=ran the following: - built cr50 images with H1_DEVIDS defined in the environment and in the command line, observed that the properly signed prod image is produced (boots on a prod H1 in node locked mode). - verified that adding CR50_DEV=1 to H1_DEVIDS in either environment or the command line produces a properly signed DEV image. - verified that specifying CR50_DEV=1 alone in either environment of command line produces a DEV image which does not require fob signing. Change-Id: Ied65a0bc50926aa5b6fa65e51805c2368522dcf2 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/434926 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* mkbp: Support devices having buttons but no keyboardPhilip Chen2017-02-212-6/+4
| | | | | | | | | | | | | | | | | | | If we turn on CONFIG_KEYBOARD_PROTOCOL_MKBP on devices without keyscan task, we'll see a few compile errors due to dependencies on keyscan. This is the fix. BUG=chrome-os-partner:62987 BRANCH=none TEST=make buildall -j Change-Id: Ib0dd1570f0e1a2de084cf1c5f75b8e3ad1cb301a Reviewed-on: https://chromium-review.googlesource.com/443745 Reviewed-by: Shawn N <shawnn@chromium.org> Commit-Queue: Philip Chen <philipchen@chromium.org> Tested-by: Philip Chen <philipchen@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/444946 Commit-Ready: Philip Chen <philipchen@chromium.org>
* COMMIT-QUEUE.ini: add strago-no-vmtest-pre-cqNingning Xia2017-02-211-0/+1
| | | | | | | | | | | | BRANCH=None BUG=chromium:692659 TEST=None Change-Id: I8a7a822cfe57afbfc1d185ae6dfcadc879e342cb Reviewed-on: https://chromium-review.googlesource.com/443286 Commit-Ready: Ningning Xia <nxia@chromium.org> Tested-by: Ningning Xia <nxia@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
View Lorry Controller Status