summaryrefslogtreecommitdiff
path: root/chip/stm32/flash-f.c
Commit message (Collapse)AuthorAgeFilesLines
* drop unnecessary boards, chips and cts testsVadim Bendebury2020-01-071-769/+0
| | | | | | | | | | | | | | | | | | | | The only board which would be built from this branch is Cr50. bds, fizz and host boards are necessary for proper make infrastructure operation and tests. lm4 and npcx are chips used by the bds and fizz boards, so they are also kept around. BRANCH=cr50, cr50-mp BUG=b:145912698 TEST='make buildall -j' succeeds Change-Id: I937b2b8642c1fe91578fc9615438ae22c165b20f Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1986942 Reviewed-by: Namyoon Woo <namyoon@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* include: Move RESET_FLAG_* into ec_commands.h as EC_RESET_FLAG_*You-Cheng Syu2019-08-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | RESET_FLAGS_* are used when setting/reading the field ec_reset_flags of struct ec_response_uptime_info, which is defined in ec_commands.h. So it might be better to put those macros there. To be consistent with the other macros in the file, add "EC_" prefixes to them. BUG=b:109900671,b:118654976 BRANCH=none TEST=make buildall -j Cq-Depend: chrome-internal:1054910, chrome-internal:1054911, chrome-internal:1045539 Change-Id: If72ec25f1b34d8d46b74479fb4cd09252102aafa Signed-off-by: You-Cheng Syu <youcheng@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1520574 Tested-by: Yu-Ping Wu <yupingso@chromium.org> Commit-Ready: Yu-Ping Wu <yupingso@chromium.org> Legacy-Commit-Queue: Commit Bot <commit-bot@chromium.org> Reviewed-by: Yilun Lin <yllin@chromium.org> Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* hatch_fp: Add RDP (read protection) support to STM32F4Tom Hughes2019-07-241-1/+120
| | | | | | | | | | | | | | | | | | | BRANCH=none BUG=b:125419658 TEST=Remove "-U" flag in STM32MON_READ_FLAGS in flash_fp_mcu_common.sh flash_fp_mcu -r foo.bin => success hexdump foo.bin => valid data ectool --name=cros_fp flashprotect enable ectool --name=cros_fp reboot_ec flash_fp_mcu -r foo.bin => fails Add "-U" flag back to STM32MON_READ_FLAGS in flash_fp_mcu_common.sh flash_fp_mcu -r foo.bin => success hexdump foo.bin => all 0xFF Change-Id: Ic3ec18262e653b72baf239caa8db12186a63613c Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1692220 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* common: bit change 1 << constants with BIT(constants)Gwendal Grignou2019-03-261-1/+1
| | | | | | | | | | | | | | | | | Mechanical replacement of bit operation where operand is a constant. More bit operation exist, but prone to errors. Reveal a bug in npcx: chip/npcx/system-npcx7.c:114:54: error: conversion from 'long unsigned int' to 'uint8_t' {aka 'volatile unsigned char'} changes value from '16777215' to '255' [-Werror=overflow] BUG=None BRANCH=None TEST=None Change-Id: I006614026143fa180702ac0d1cc2ceb1b3c6eeb0 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518660 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* flash: Add CONFIG_FLASH_READOUT_PROTECTION config optionNicolas Boichat2018-09-141-1/+1
| | | | | | | | | | | | | | Instead of tying together CONFIG_WP_ALWAYS and RDP protection, separate the options. BRANCH=nocturne BUG=b:111330723 TEST=make buildall -j Change-Id: I905b573a900ef4dd0431666c525c951582143e09 Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1222093 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: Add proper flash erase timeoutShawn Nematbakhsh2017-12-081-3/+11
| | | | | | | | | | | | | | | | | stm32f0 / f3 can take up to 40ms to erase a single sector of flash. Also add a note about instruction fetch being blocked on flash operation completion. TEST=`make buildall -j` BUG=b:70193071 BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: Icb6c199a975b31f4fa7c73ceb6ad8ec06150abb1 Reviewed-on: https://chromium-review.googlesource.com/815276 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* chip/stm32/flash-f: Clear option byte write enable/erase operation when doneNicolas Boichat2017-07-071-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before 72afc55bd9d3 "stm32: cleanup flash-f by using constant from register.h" lock() function would simply do: STM32_FLASH_CR = FLASH_CR_LOCK; which would clear all other bits in STM32_FLASH_CR, including FLASH_CR_OPTER and FLASH_CR_OPTWRE. This allow preserve_optb to work, as it does: 1. erase_optb a. unlock() b. Set FLASH_CR_OPTER c. lock() (clears FLASH_CR_OPTER!) 2. write_optb a. unlock() b. Set FLASH_CR_OPTPG c. Write option byte d. Clear FLASH_CR_OPTPG e. lock() After the patch, we now have: STM32_FLASH_CR |= FLASH_CR_LOCK; which seems more correct. However, 1.c. does not clear FLASH_CR_OPTER, and 2.b. ends up with both FLASH_CR_OPTPG and FLASH_CR_OPTER set, and the programming operation does not do anything. This patches does 3 things: - Rename FLASH_CR_OPTSTRT to FLASH_CR_OPTER, as that's the correct register name for STM32F0 and STM32F3. - Fix the above by clearing FLASH_CR_OPTER in erase_optb - Also clear FLASH_CR_OPTWRE in lock(). Not strictly necessary, but this seems to be the right thing to do. BRANCH=none BUG=chromium:739608 TEST=On hammer, type flashwp true; reboot; flashwp all; reboot flashinfo => All flash is protected Change-Id: Ic276545ae3c0bdb685c7b117a7f896ec341731bb Reviewed-on: https://chromium-review.googlesource.com/562839 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* chip/stm32/flash-f: Fix incorrect WP computationNicolas Boichat2017-07-061-3/+0
| | | | | | | | | | | | | | | | PSTATE is already included in WP_BANK_OFFSET + WP_BANK_COUNT, so this change is not only unnecessary, but also harmful. BRANCH=none BUG=chromium:739608 TEST=Flash hammer, flashwp true; reboot; flashinfo => RO is protected Change-Id: I31048c0156eff354fbcc6ae5828a6ef313b56b97 Reviewed-on: https://chromium-review.googlesource.com/561037 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* stm32f4: fix flash_physical_protect_now behaviorWei-Ning Huang2017-06-281-10/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | flash_physical_protect_now(), which is called when EC_FLASH_PROTECT_ALL_NOW is set, should protect the entire flash temporarily until reboot. Current behavior enable flash protect on all region permanently. The correct implementation should be writing an invalid key to the flash controller to disable flash flash only temporarily until reboot. Since the implementation of flash-stm32f3 and flash-stm32f4 is almost the same after restoring the changes made in commit 35f4d8acaa40050f10158459a04e0bf9b24149c6, we merge to file by creating a symlink from flash-stm32f3.c to flash-stm32f4.c to reduce code duplication. BRANCH=none BUG=b:37584134 TEST=on eve: 1) `ectool --name=cros_tp flashprotect` Flash protect flags: 0x00000008 wp_gpio_asserted 2) `flashrom -p ec:type=tp --wp-enable 3) `ectool --name=cros_tp reboot_ec` 3) `flashrom -p ec:type=tp --wp-status` WP: status: 0x80 WP: status.srp0: 1 WP: write protect is enabled. WP: write protect range: start=0x00000000, len=0x00040000 4) `ectool --name=cros_tp flashprotect`, all_now should present Flash protect flags: 0x0000000f wp_gpio_asserted ro_at_boot ro_now \ all_now 5) `ectool --name=cros_tp reboot_ec; sleep 0.3; \ ectool --name=cros_tp rwsigaction abort` to stay in RO. In EC console, `flashinfo`, should show that only RO is actually flash protected: Protected now: YYYYYY.. 6) `flashrom -p ec:type=tp -w ec.bin -i EC_RW` works 7) `make BOARD=ryu -j` works (for testing flash-stm32f3.c) Change-Id: Ia7a60ae8b3084198abb468e4fc8074b4445d6915 Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Reviewed-on: https://chromium-review.googlesource.com/549681 Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org> Tested-by: Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
* Add flash command support to boards with STM32F4Gwendal Grignou2017-06-031-14/+128
| | | | | | | | | | | | | | | | | | | Add support to write and erase all flash with flashrom. Add support to use all the memory. Note that PSTATE must not used its own page, as the STM32F4 use big pages. BUG=b:38018926 BRANCH=none TEST=With flashrom, write all, RO, RW regions. Use flash command on the console, including flashwp Change-Id: I4f0aee1b3a4f342bdf4ca97bf5d8e8bcc153fd9c Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264032 Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org> Tested-by: Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32: cleanup flash-f by using constant from register.hGwendal Grignou2017-06-021-62/+86
| | | | | | | | | | | | | | Use constants from registers.h, to easily support other ECs. Fix indentation in registers.h BRANCH=none TEST=compile + following patches tested on STM32F411 BUG=None Change-Id: Iecb3ce759a5c4ff13463e7df1cb7e03fc1ce6f69 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264030 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* flash: Add ROLLBACK flash region, that can be protected separatelyNicolas Boichat2017-02-251-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* flash: Add EC_FLASH_PROTECT_RW_[AT_BOOT|NOW] flagsstabilize-9313.BNicolas Boichat2017-02-231-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* flash: Pass more precise parameter to flash_[physical_]protect_at_bootNicolas Boichat2017-02-121-10/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In preparation for adding the rollback protection block, pass EC_FLASH_PROTECT_RO/ALL_AT_BOOT to flash_[physical_]protect_at_boot, instead of an enumeration no protection/RO/ALL. This will later allow us to protect/unprotect the rollback region only, by adding a EC_FLASH_PROTECT_ROLLBACK_AT_BOOT flag. BRANCH=none BUG=chrome-os-partner:61671 TEST=Build hammer with CONFIG_CMD_FLASH command, so that write protection can be checked with flasherase/flashwrite. TEST=On hammer (stm32f072): flashinfo => RO+RW not protected flashwp true; reboot => only RO protected flashwp rw; reboot => RO+RW protected flashwp norw; reboot => only RO protected TEST=On reef (npcx): deassert WP, flashwp false; flashinfo => RO+RW not protected flashwp true => only RO protected reboot => only RO protected flashwp rw => RO+RW protected reboot => only RO protected Change-Id: Iec96a7377baabc9100fc59de0a31505095a3499f Reviewed-on: https://chromium-review.googlesource.com/430518 Commit-Ready: Nicolas Boichat <drinkcat@chromium.org> Tested-by: Nicolas Boichat <drinkcat@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32f446e-eval: add support for stm32f446Nick Sanders2016-08-171-5/+11
| | | | | | | | | | | | | | | | | | This adds basic support for the stm32f446. This consists of: * New DMA model for stm32f4 * New clock domain support. * MCO oscillator gpio export support. * Flash support for irregular blocks. BUG=chromium:608039 TEST=boots w/ correct clock, stm32f0 also boots. BRANCH=None Change-Id: I1c5cf6ddca09009c9dac60da8a3d0c5ceedfcf4d Signed-off-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/363992 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* cleanup: Rename geometry constantsShawn Nematbakhsh2015-09-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Rename and add geometry constants to match spec doc - https://goo.gl/fnzTvr. CONFIG_FLASH_BASE becomes CONFIG_PROGRAM_MEMORY_BASE CONFIG_FLASH_MAPPED becomes CONFIG_MAPPED_STORAGE Add CONFIG_INTERNAL_STORAGE, CONFIG_EXTERNAL_STORAGE and CONFIG_MAPPED_STORAGE_BASE where appropriate. This CL leaves chip/npcx in a broken state -- it's fixed in a follow-up CL. 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 Change-Id: Idb3c4ed9f7f6edd0a6d49ad11753eba713e67a80 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/297484 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* stm32: fix flash write protect check for STM32F3Vincent Palatin2015-09-141-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the STM32 flash write protection was re-factored between STM32F0 and STM32F/F3, the common STM32 flash code checks whether the chip needs a reboot to synchronize its write protection state (as this can be done only with an OBL_LAUNCH triggered reset on STM32F0) but for platforms able to set immediatly the full write-protection (STM32F/STM32F3 with Cortex-M3 core using the bus fault interception code) where there is no EC_FLASH_PROTECT_ALL_AT_BOOT flag, this might trigger a reset loop in the RO code when the flash is write-protected. Make the check conditional to the existence of EC_FLASH_PROTECT_ALL_AT_BOOT. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=smaug BUG=chrome-os-partner:45288 TEST=On a smaug board with hardware write protect enable, enable software write protect from the AP command line: flashrom -p ec --wp-range 0 0x20000 flashrom -p ec --wp-enable ectool reboot_ec RO reboot -p then, go to fastboot mode : adb reboot-bootloader and see the machine booting properly. Change-Id: I93f78cb8e9e918c8efe374bd757b79bc87243e2c Reviewed-on: https://chromium-review.googlesource.com/299555 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> (cherry picked from commit 39a0feb45b0c14ea5eb008329f2b8ea7a9b17c8a) Reviewed-on: https://chromium-review.googlesource.com/299762 Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
* cleanup: Use appropriate image geometry CONFIGsShawn Nematbakhsh2015-05-151-6/+5
| | | | | | | | | | | | | | | | - Use CONFIG_*_MEM when dealing with images in program memory. - Use CONFIG_*_STORAGE when dealing with images on storage. - Use CONFIG_WP when dealing with the entire WP RO region. BUG=chrome-os-partner:39741,chrome-os-partner:23796 TEST=Manual on Cyan with subsequent commit. Verify that FMAP matches actual layout of image. Verify flashrom succeeds flashing + verifying EC image using host command interface. BRANCH=None Change-Id: Iadc02daa89fe3bf07b083ed0f7be2e60702a1867 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/270269
* hoho/dingdong: support unprotected RO partitionVincent Palatin2015-01-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | If the RO firmware has a different view of the protection than the RW copy, we should not change the option bytes (write protection settings) in RW else we will trigger a reboot loop : RW protects and reset, then RO unprotects, resets and jump to RW, RW protects and reset again ... Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:35383 TEST=craft a firmware image whose RO partition doesn't include commit 42d0104 (no virtual WP, no RDP set) and RW partition has everything including this patch, see that HoHo no longer reboots in a loop. Change-Id: I4cbdbf25a96cb6fb7cbabc7f2d1dc76d3a2a9e36 Reviewed-on: https://chromium-review.googlesource.com/240561 Reviewed-by: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Alec Berg <alecaberg@chromium.org>
* pd: dingdong/hoho: Enable flash write-protectionVincent Palatin2015-01-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These USB type-C accessories don't have a write-protect GPIO. Add a configure flag (CONFIG_WP_ALWAYS) to force the flash write-protection on the dongles. Also set the read protection (by elevating RDP to level 1), so trying to unprotect the flash will trigger a full erase. Signed-off-by: Vincent Palatin <vpalatin@chromium.org> BRANCH=samus BUG=chrome-os-partner:35088 TEST=boot Hoho, check the flash OBR and WRPR registers: "rw 0x4002201c" / "rw 0x40022020" and the option bytes write-protect bits: "rw 0x1FFFF808" dump the logical state with "flashinfo" command. > rw 0x4002201c read 0x40022020 = 0xffff0002 > rw 0x40022020 read 0x40022020 = 0xffff0000 > rw 0x1FFFF808 read 0x1ffff808 = 0xff00ff00 > flashinfo Physical: 128 KB Usable: 128 KB Write: 2 B (ideal 2 B) Erase: 2048 B (to 1-bits) Protect: 4096 B Flags: wp_gpio_asserted ro_at_boot ro_now Protected now: YYYYYYYY YYYYYYYY ........ ........ Change-Id: I45bbc0bce40ecc174b6b8a1ebacf4f53d2fd372d Reviewed-on: https://chromium-review.googlesource.com/238893 Trybot-Ready: Vincent Palatin <vpalatin@chromium.org> Commit-Queue: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org> Reviewed-by: Todd Broch <tbroch@chromium.org> Tested-by: Todd Broch <tbroch@chromium.org>
* Write protect support for STM32F0Vic Yang2014-10-151-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | On STM32F0, we cannot work around the hard fault triggered when trying to protect the whole flash. Therefore, we need to go with the ALL_AT_BOOT approach. When write protect is enabled, instead of setting ALL_NOW flag to immediately lock down the entire flash, we need to set ALL_AT_BOOT and then reboot to have the protection take effect. BUG=chrome-os-partner:32745 TEST=Along with the next CL. On Ryu: 1. Enable HW WP. Check the output of 'ectool flashprotect' and see correct flags. 2. 'flashrom -p ec --wp-range 0 0x10000'. Check RO_AT_BOOT is set. 3. Reboot EC and check RO_NOW is enabled. 4. Boot the system and check ALL_NOW is set. 5. Update BIOS and reboot. Check software sync updates EC-RW. 6. 'flashrom -p ec --wp-disable' and check it fails. 7. Disable HW WP and reboot EC. Check RO_NOW and ALL_NOW are cleared. 8. 'flashrom -p ec --wp-disable' and check RO_AT_BOOT is cleared. TEST=Enable/disable WP on Spring. Check RO_AT_BOOT/ALL_NOW can be set properly. BRANCH=samus Change-Id: I1c7c4f98f2535f1c8a1c7daaa88d47412d015977 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222622 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Factor out common flash code for STM32F and STM32F0Vic Yang2014-10-151-0/+448
This is a preparatory work for the following change for write protection support on STM32F0. BUG=chrome-os-partner:32745 TEST=make buildall BRANCH=samus Change-Id: Ic4deea06e26c4a6ac024a5388e1a5783b40e9876 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222660 Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status