summaryrefslogtreecommitdiff
path: root/chip/stm32/flash-f.c
Commit message (Collapse)AuthorAgeFilesLines
* 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