summaryrefslogtreecommitdiff
path: root/include/flash.h
Commit message (Collapse)AuthorAgeFilesLines
* flash: allow programming larger EC imagesKeith Short2020-08-131-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some ECs, the EC image size is limited by the amount of code RAM instead of 1/2 the total flash size. In this instance, there is unused flash that can be used for single use data objects. To support linking data objects into the unused flash area, increase the region size that can be programmed for RW images. Analysis of chips that are impacted by this change: Chip EC image limit New RW size limit mec1701h 188 KiB 256 KiB mec17xx_2E00 188 KiB 256 KiB npcx5m5g 96 KiB 128 KiB npcx5m6g 224 KiB 256 KiB npcx7m6f 192 KiB 256 KiB npcx7m6fb 192 KiB 256 KiB npcx7m6fc 192 KiB 256 KiB npcx7m6g 192 KiB 256 KiB npcx7m7wb 256 KiB 512 KiB npcx7m7wc 252 KiB 256 KiB Boards using other chips verified that CONFIG_RW_SIZE is the same as CONFIG_EC_WRITABLE_STORAGE_SIZE. EC_FLASH_REGION_RO isn't used by depthcharge, only EC_FLASH_REGION_WP_RO which is already set to the correct size. BUG=b:160330682 BRANCH=none TEST=make buildall Signed-off-by: Keith Short <keithshort@chromium.org> Change-Id: I84b9dc84568273e1ab1473e301d27ffd2b07ba7f Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2325764 Reviewed-by: Abe Levkoy <alevkoy@chromium.org> Reviewed-by: caveh jalali <caveh@chromium.org> Commit-Queue: caveh jalali <caveh@chromium.org>
* Servo: Adds persistent storage of MAC addressBrian J. Nemec2020-02-211-0/+19
| | | | | | | | | | | | | | | | | | | | | | | Adds a field to the persistent storage to store the MAC address of the device. This is enabled on ServoV4 in order to store the MAC address for the integrated ethernet port. Added a console command to set and load this value. BUG=b:149506580 TEST=Verified setting and loading the MAC address using: 'macaddr set 12:34:56:78:90:ab' and 'macaddr' or 'macaddr load' Verified that MAC addresses over 19 characters long return an error response and not update the MAC. Verified no set serial number will return the uninitialized string. Verified that the MAC address can be updated independently of serialno Verified that the persist_state fields restore during firmware updates Change-Id: I8425ce9e13322e99a4f59df444ea0dc73821aa6b Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/2063330 Tested-by: Brian Nemec <bnemec@chromium.org> Reviewed-by: Wai-Hong Tam <waihong@google.com> Commit-Queue: Brian Nemec <bnemec@chromium.org>
* rollback: Add rollback support for chips with varying flash bank sizesTom Hughes2019-07-031-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BRANCH=none BUG=b:124996507 TEST=In hatch_fp and nocturne_fp console with CONFIG_RWSIG_JUMP_TIMEOUT increased to large value and console_task stack size increased to 4096: > rollbackinfo rollback minimum version: 0 RW rollback version: 0 rollback 0: 00000000 00000000 0b112233 [00..00] * rollback 1: ffffffff ffffffff ffffffff [ff..ff] > rollbackupdate 1 > rollbackinfo rollback minimum version: 1 RW rollback version: 0 rollback 0: 00000000 00000000 0b112233 [00..00] rollback 1: 00000001 00000001 0b112233 [00..00] * > rollbackaddent 1234 > rollbackinfo rollback minimum version: 1 RW rollback version: 0 rollback 0: 00000002 00000001 0b112233 [e5..8c] * rollback 1: 00000001 00000001 0b112233 [00..00] TEST=test_that --board=nocturne <IP> firmware_Fingerprint.ObeysRollback firmware_Fingerprint.ObeysRollback [ PASSED ] firmware_Fingerprint.ObeysRollback/firmware_Fingerprint [ PASSED ] Change-Id: I90b524138ca1125e2c1b62936b9f6fbe00e957d4 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1681379 Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
* LICENSE: remove unnecessary (c) after CopyrightTom Hughes2019-06-191-1/+1
| | | | | | | | | | | | | | | | Ran the following command: git grep -l 'Copyright (c)' | \ xargs sed -i 's/Copyright (c)/Copyright/g' BRANCH=none BUG=none TEST=make buildall -j Change-Id: I6cc4a0f7e8b30d5b5f97d53c031c299f3e164ca7 Signed-off-by: Tom Hughes <tomhughes@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1663262 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* EFS: Switch active slot when current slot is invalidDaisuke Nojiri2017-09-211-25/+0
| | | | | | | | | | | | | | | | | | | | | | | When EFS finds the active slot is invalid, it tries the other slot. This patch makes the other slot active so that the following boots will try the other slot first. This patch also replaces enum flash_rw_slot with system_image_copy_t. The new APIs are therefore renamed from *_slot to *_copy. Basically, this makes vboot see slots as a conceptual place instead of physical spaces bound to flash storage. BUG=b:65028930 BRANCH=none TEST=On Fizz, verify: 1. RW_B is old and updated by soft sync. RW_B is activated and executed after reboot. System continues to boot to OS. 2. RW_A is old and updated by soft sync. RW_A is activated and executed after reboot. System continues to boot to OS. Change-Id: Icf97da13e651e7a931b9d507052b9422566eb16c Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/648449
* EFS: Add support for early firmware selectionDaisuke Nojiri2017-09-121-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Chromebox ECs performs EFS: verifying firmware before the AP boots. This patch updates host commands which are required for the EFS. The change includes: * Update EC_CMD_FLASH_REGION_INFO to accept EC_FLASH_REGION_UPDATE * Update EC_CMD_VBOOT_HASH to accept EC_VBOOT_HASH_OFFSET_UPDATE When EC_FLASHS_REGION_UPDATE is specified, EC_CMD_FLASH_REGION_INFO returns the slot which currently is not hosting a running RW copy. When EC_VBOOT_HASH_OFFSET_UPDATE is specified, EC_CMD_VBOOT_HASH computs the hash of the update slot. This hash covers the entire region, including the signature at the end. This patch undefines CONFIG_CMD_USBMUX and CONFIG_CMD_TYPEC for gru to create space. BUG=b:65028930 BRANCH=none CQ-DEPEND=CL:648071 TEST=On Fizz, verify: 1. RW_B is old and updated by soft sync. RW_B is activated and executed after reboot. System continues to boot to OS. 2. RW_A is old and updated by soft sync. RW_A is activated and executed after reboot. System continues to boot to OS. Change-Id: I9ece907b764d07ce94054ba27996e048c665a80a Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/648448
* Add OTP supportGwendal Grignou2017-07-281-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One Time Programmable memory can be used to store permanent data like serial numbers. Reorganize the code to support writing serial number to OTP, in addition to pstate (if using its own memory bank) or autogenerate from unique id (hammer). + Add CONFIG_OTP to enable OTP code + Add CONFIG_SERIALNO_LEN to indicate the size of the serial number string. Currently set to 28, when USB serial number is needed. + Expose flash_read|write_pstate_serial and add otp_read|write_serail, remove more generic flash_read|write_serial. + Make board_read|write_serial generic, declared outside of USB subsystem. Priority order to read|write serial string: - board definition (like hammer) - pstate location, if stored in its private memory bank - otp area If none of these methods are available, a compilation error is raised. BUG=chromium:746471 BRANCH=none TEST=compile Change-Id: I3d16125a6c0f424fb30e38123e63cf074b3cb2d3 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/580289 Reviewed-by: Nick Sanders <nsanders@chromium.org>
* flash: add flash selection supportWei-Ning Huang2017-07-271-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Some chips require special operations before flash can be accessed (read, write, erase), without it the flash operations could be corrupted. The chip that requires this should enable the CONFIG_FLASH_SELECT_REQUIRED config, which exposes EC_FLASH_INFO_SELECT_REQUIRED in flashinfo flags. Before any flash operations is executed on the chip, EC_CMD_FLASH_SELECT should be issued to notify the chip to prepare for the flash operations. BRANCH=none BUG=b:63685022 TEST=with depended CLs, touchpad interrupt should be disabled when flashrom is in progress. CQ-DEPEND=CL:*416548 Change-Id: I96455adbe739d5f924edf382a2752404a7c5ad04 Signed-off-by: Wei-Ning Huang <wnhuang@google.com> Reviewed-on: https://chromium-review.googlesource.com/582374 Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org> Tested-by: Wei-Ning Huang <wnhuang@chromium.org> Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
* common: Add support for flash with regions of different sizeRong Chang2017-06-021-5/+51
| | | | | | | | | | | | | Add support to handle devices with flash regions of different sizes. BRANCH=none TEST=compile BUG=b:38018926 Change-Id: I8f842abaa50de724df60dd7e19f9e97cb9660367 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/264031 Reviewed-by: Alexandru M Stan <amstan@chromium.org>
* stm32f09x: fix flash protection offsetRong Chang2017-02-271-0/+8
| | | | | | | | | | | | | | | | | | | | | STM32F091VC has 32 flash protection sectors (31 x 4KB + 1 x 132KB), which doesn't fit the layout requirement in config_std_internal_flash.h. This CL hardcodes the layout and flash bank mapping. BUG=chrome-os-partner:62372 BUG=chromium:694972 TEST=load on elm and manually enable write protect using flashrom # flashrom -p ec:dev=0 --wp-enable check ec console write protect option bytes, bank 31 is writable > rw 0x1ffff808 read 0x1ffff808 = 0xff00ff00 > rw 0x1ffff80c read 0x1ffff80c = 0x7f80ff00 BRANCH=oak Change-Id: I23dcf87bfbcd2f37e97a87e94847dce1ea1d343c Signed-off-by: Rong Chang <rongchang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/446176
* flash: Add ROLLBACK flash region, that can be protected separatelyNicolas Boichat2017-02-251-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-11/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* flash: Call lock function prior to mapped external readShawn Nematbakhsh2016-09-161-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Mapped read access to external flash may conflict with direct access through SPI commands, so call a chip-level function to lock access prior to doing such reads. BUG=chrome-os-partner:55781 BRANCH=Gru TEST=Verify 'ver' still works fine on kevin, and vboot hashing completes successfully. Change-Id: I009d6d5ee61c83260fb49ad4ee137fa3f4cd625a Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/385165 Tested-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mulin Chao <mlchao@nuvoton.com> (cherry picked from commit a7f3e3fa376731709f4823a0c1d464b4d1deae14) Reviewed-on: https://chromium-review.googlesource.com/386446 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* servo_micro: add programmable serial numberNick Sanders2016-05-261-0/+16
| | | | | | | | | | | | | | | | This change provides a console command for setting, and loading a usb serial number from flash. This feature adds CONFIG_USB_SERIALNO, and currently only has a useful implementation when PSTATE is present. BUG=chromium:571477 TEST=serialno set abcdef; serialno load; reboot BRANCH=none Change-Id: I3b24cfa2d52d54118bc3fd54b276e3d95412d245 Signed-off-by: Nick Sanders <nsanders@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/337359 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Remove superfluous #definesBill Richardson2015-09-251-4/+2
| | | | | | | | | | | | | | | This just removes a couple places where a perfectly good CONFIG macro is simply renamed to something else. BUG=none BRANCH=none TEST=make buildall Change-Id: I97a4abe95736504fe97c468336426d0ecc48d62c Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/302597 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cleanup: Remove redundant FLASH_SIZE CONFIGsShawn Nematbakhsh2015-09-161-1/+1
| | | | | | | | | | | | | | | | | | | | Since there is no more concept of a flash region belonging only to the EC, we only need one FLASH_SIZE config, which represents the actual physical size of flash. BRANCH=None BUG=chrome-os-partner:23796 TEST=With entire patch series, on both Samus and Glados: - Verify 'version' EC console command is correct - Verify 'flashrom -p ec -r read.bin' reads back EC image - Verify software sync correctly flashes both EC and PD RW images Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I18a34a943e02c8a029f330f213a8634a2ca418b6 Reviewed-on: https://chromium-review.googlesource.com/297824 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Mulin Chao <mlchao@nuvoton.com> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Change meaning of storage offset CONFIGsShawn Nematbakhsh2015-09-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | In order to support architectures with non-contiguous writable and protected regions, change storage offsets to be relative to writable and protected regions, rather than relative to "the start of the region of storage belonging to the EC". Spec doc available at https://goo.gl/fnzTvr. BRANCH=None BUG=chrome-os-partner:23796 TEST=With entire patch series, on both Samus and Glados: - Verify 'version' EC console command is correct - Verify 'flashrom -p ec -r read.bin' reads back EC image - Verify software sync correctly flashes both EC and PD RW images Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I796f8e7305a6336495bd256a78774595cb16a2e4 Reviewed-on: https://chromium-review.googlesource.com/297823 Commit-Ready: Shawn N <shawnn@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cleanup: Rename geometry constantsShawn Nematbakhsh2015-09-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cleanup: Use appropriate image geometry CONFIGsShawn Nematbakhsh2015-05-151-7/+3
| | | | | | | | | | | | | | | | - 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
* cleanup: Rename image geometry CONFIGsShawn Nematbakhsh2015-05-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | Rename image geometry configs with a uniform naming scheme to make their purposes more clear. CONFIG_RO_MEM_OFF (was CONFIG_FW_RO_OFF) - RO image offset in program memory CONFIG_RO_STORAGE_OFF (was CONFIG_RO_SPI_OFF) - RO image offset on storage CONFIG_RO_SIZE (was CONFIG_FW_RO_SIZE) - Size of RO image CONFIG_RW_MEM_OFF (was CONFIG_FW_RW_OFF) - RW image offset in program memory CONFIG_RW_STORAGE_OFF (was CONFIG_RW_SPI_OFF) - RW image offset on storage CONFIG_RW_SIZE (was CONFIG_FW_RW_SIZE) - Size of RW image CONFIG_WP_OFF (was CONFIG_FW_WP_RO_OFF) - Offset of WP region on storage CONFIG_WP_SIZE (was CONFIG_FW_WP_RO_SIZE) - Size of WP region on storage BUG=chrome-os-partner:39741,chrome-os-partner:23796 TEST=Set date / version strings to constants then `make buildall -j`. Verify that each ec.bin image is identical pre- and post-change. BRANCH=None Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Change-Id: I6ea0a4e456dae71c266fa917a309b9f6fa4b50cd Reviewed-on: https://chromium-review.googlesource.com/270189 Reviewed-by: Anton Staaf <robotboy@chromium.org>
* flash: Add option to move pstate inside RO imageRandall Spangler2015-04-171-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, ECs with internal flash store the write protect state for RO in a separate write/erase block of flash. This is wasteful on chips where there are not many blocks of flash. Add a new CONFIG_FLASH_PSTATE_IN_BANK option which is defined by default. This is the old behavior, for compatibility. (And we're calling it 'bank' because that's what the existing code does, even if the terminology is somewhat etymologically... bankrupt.) If that config is #undef'd, then store the write protect flag directly inside the RO image. This uses only 4 bytes of the RO image, instead of an entire erase block. The magic numbers for the pstate values are chosen such that when protecting RO, bits are only transitioned away from their erased state. Unprotecting RO once it's protected requires reflashing RO; it's no longer possible to 'flashwp disable'. But that's ok, because realistically, the only reason to unprotect RO is if you're about to flash the RO firmware anyway. BUG=chromium:476659 BRANCH=none TEST=Without undefining CONFIG_FLASH_PSTATE_IN_BANK, make sure everything still works on samus and samus_pd. This ensures we didn't break the existing functionality: flashinfo -> no flags flashwp enable flashinfo -> ro_at_boot reboot flashinfo -> ro_at_boot flashwp disable flashinfo -> no flags Then recompile with #undef CONFIG_FLASH_PSTATE_IN_BANK and test: flashinfo -> no flags flashwp enable flashinfo -> ro_at_boot reboot flashinfo -> ro_at_boot flashwp disable -> fails with access denied flashinfo -> ro_at_boot Then reflash to verify that clears the ro_at_boot flag: flashinfo -> no flags Change-Id: Ie794b8cfed2a10c50b0e36dcf185884070b04666 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/266095 Reviewed-by: Alec Berg <alecaberg@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org> Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
* Add CONFIG_FLASH_PSTATE option to enable persistent flash WP stateRandall Spangler2015-02-261-0/+2
| | | | | | | | | | | | | | | | | | | | | | | Previously, the flash module assumed it needed to emulate a SPI write protect register using a bank of flash to hold the persistent flash write protect state. This is not true for mec and ncpx chips under development, which use external SPI flash. So, gate that code with CONFIG_FLASH_PSTATE. For compatibility, leave it on by default (as we do with CONFIG_FLASH_MAPPED). There is no change to the behavior of currently supported chips, since all of them already assume pstate is present. Removing this feature from npcx will be done in a subsequent change. BUG=chrome-os-partner:34346 BRANCH=strago TEST=make buildall -j; verify flash wp and flashinfo work properly on samus Change-Id: Ie044eb042863e4a7359ea540166ffd8d0089589d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/253632 Reviewed-by: Shawn N <shawnn@chromium.org> Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
* Support vboot hash and system version if flash isn't memory-mappedRandall Spangler2015-02-051-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some EC chips (mec1322) use external SPI flash which is not mapped into the EC CPU's address space. These must explicitly read data from flash when calculating the vboot hash or reading the version string of the image which isn't currently loaded into code RAM. To test this bug, I used a board with known working mapped flash, and temporarily patched it to act like it didn't have mapped flash. Also add a flashread console command, useful for manually testing. BUG=chrome-os-partner:35308 BRANCH=glower,strago TEST=manual 1. Apply this patch to samus 2. Check result for 'vboot hash RW' 3. Check result for 'version' 4a. In board/samus/board.h, #undef CONFIG_FLASH_MAPPED and #define CONFIG_CMD_FLASH 4b. In chip/lm4/flash.c, add the following: int flash_physical_read(int offset, int size, char *data) { const char *src; if (offset > CONFIG_FLASH_SIZE || offset + size > CONFIG_FLASH_SIZE) return EC_ERROR_INVAL; src = (const char *)((uintptr_t)CONFIG_FLASH_BASE + offset); memcpy(data, src, size); return EC_SUCCESS; } Steps 4a,4b will make the LM4 chip act like it doesn't have memory-mapped flash. 5. From the dev system, util/flash_ec --board=samus --ro 6. Check result for 'vboot hash RW'. Should be same as 2. 7. Check result for 'version' for RW version. Should be same as in 3. 8. From the dev system, util/flash_ec --board=samus 9. sysjump rw 10. Check result for 'version' for RO version. Should be same as in 3. 11. Compare 'flashread 0x100 0x100' with 'md 0x100 0x40'. The results should be the same (but endian-swapped, since flashread is byte ordered and md is 32-bit ordered). 12. Revert changes from steps 4a-4b. Change-Id: I951d6f5603a84e326740936e4e84dfe6296a0f59 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/246200 Reviewed-by: Shawn N <shawnn@chromium.org>
* Fix incorrect valid and writable flash flagsVic Yang2014-10-151-0/+15
| | | | | | | | | | | | | | | | The valid and writable flags the EC sends back to the AP are incorrect. They are a little bit different on differnt chips, so let's move it to flash physical layer. This is not any causing problem, but we should fix this. BUG=chrome-os-partner:32745 TEST=make buildall BRANCH=samus Change-Id: Ibcda5ae770f5ea02cde094490997a5bc447df88f Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/222661 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Write protect support for STM32F0Vic Yang2014-10-151-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-3/+17
| | | | | | | | | | | | | | 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>
* Clean up flash section defines and increase lm4 image sizeRandall Spangler2013-06-031-8/+8
| | | | | | | | | | | | | | | | | | | | | | | The firmware defines had two almost-identical sets. Coalesce into one consistent set. Link had 256 KB flash, but only allowed 2 80KB images. Future LM4-based platforms (slippy/peppy/falco/etc) will now use the entire flash, with RO=124KB, pstate=4KB, RW=128KB. This matches what the STM32 platforms do, where pstate is contiguous with the RO firmware. No functional change to STM32-based platforms. BUG=chrome-os-partner:19176 BRANCH=none TEST=build all platforms and dump_fmap ec.bin. - stm32-based platforms should report RO=61440@0, RW=65536@0x10000 - link should report RO=81920@0, RW=81920@0x14000 - slippy should report RO=129024@0, RW=131072@0x20000 Change-Id: I20b1d95c16250d9a5d228ead06eef03d96548823 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56655
* More low-level flash interface cleanupRandall Spangler2013-05-241-34/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting at-boot protection always used the same start/range (RO+PSTATE), so no point in passing that to the physical layer as params. flash_dataptr() should take a pointer to const data. No functional changes; just rearranging code. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) Change-Id: Ifd6553dc907fa6fafce81b56af0c648ac6d6bee1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56628
* Move flash_get_protect() and flash_set_protect() to flash_common.cRandall Spangler2013-05-241-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Much more flash code is now common between platforms, for more consistent behavior and easier testing. Also change STM32L to use pstate, the same way LM4 and STM32F do. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring; do - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) Change-Id: Iccd098786454ad9b72b4e5f9f312d86819a0c8eb Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56109
* Move write protect GPIO handling to flash moduleRandall Spangler2013-05-231-0/+5
| | | | | | | | | | | | | | | | | Write protect signal naming is now consistent across boards. New CONFIG_WP_ACTIVE_HIGH is present on systems where the write protect signal is active-high (e.g. Link). This will be used in the next CL, which moves flash_get_protect() to flash_common.c BUG=chrome-os-partner:15613 BRANCH=none TEST=flashinfo properly reports WP signal status Change-Id: I502ab033c3eb36661cc3ee97320874b3fbf6fc0d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56087 Reviewed-by: Vic Yang <victoryang@chromium.org>
* Move flash persistent state to flash_commonRandall Spangler2013-05-231-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Persistent state is needed by all platforms to hold the protect-ro-at-boot flag. STM32F100 and LM4 implementations were near-identical, and are now common code (with one #ifdef to handle the single place where they weren't). STM32L doesn't use pstate yet, but it'll need to. I can't simply store the protect-ro-at-boot flag inside the WRP registers themselves because they're still writable in EC-RW. The change to STM32L to use pstate is coming next. BUG=chrome-os-partner:15613 BRANCH=none TEST=build pit, link, spring; on link and spring, do - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now (and possibly ro_now) - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - reboot ap-off - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot - flashwp disable - flashinfo -> (no flags) (Note that on Spring you'll need to 'forceen on' before enabling WP, or the console will be disabled once you enable ro_at_boot and reboot.) Change-Id: I415388b98ec8bf1d149803aaaa7fe8c7f3076c36 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/56064
* Support flash write protect on STM32LRandall Spangler2013-05-221-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for write protecting the RO code at boot, and the entire flash on demand. Implementation if WP# is not asserted is currently a little different than STM32F and LM4; RO is still protected at boot if ro_at_boot, but can be unprotected and the change will commit on the next reboot. This saves the bank of flash which we use for pstate on LM4 and STM32F. I think I can use one of the unused option bits (WRP2 bit 0) to hold the RO-at-boot flag, in which case I can more closely match the behavior of the other chips, but I'd like to do that (or give up and implement pstate) in a separate CL so it's clearer what I'm doing. BUG=chrome-os-partner:15613 BRANCH=none TEST=manual - flashinfo -> (no flags) - enable WP (via screw or dut-control) - flashinfo -> wp_gpio_asserted - flashwp enable - flashinfo -> wp_gpio_asserted ro_at_boot - flashwp now - flashinfo -> wp_gpio_asserted ro_at_boot all_now - flashwp disable -> fails - flashinfo -> wp_gpio_asserted ro_at_boot all_now - flasherase 0x1fc00 0x400 -> fails - reboot - flashinfo -> wp_gpio_asserted ro_at_boot ro_now - flasherase 0xfc00 0x400 -> fails - flasherase 0x1fc00 0x400 -> succeeds - disable WP (via screw or dut-control) - reboot - flashinfo -> ro_at_boot ro_now - flashwp disable - flashinfo -> ro_now - reboot - flashinfo -> (no flags) - flasherase 0xfc00 0x400 -> succeeds - flasherase 0x1fc00 0x400 -> succeeds Change-Id: Id1b6b099a44a1985a5ab9387feb882a8f26e3aa1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/55594
* Use uintptr_t when converting integer from/to pointerVic Yang2013-05-071-1/+1
| | | | | | | | | | | | | | | Perviously we use uint32_t for this, but this doesn't compile for 64-bit environment (and likely doesn't for 16-bit either.) Use uintptr_t so that we don't get size mismatch errors. BUG=chrome-os-partner:19257 TEST=Run host emulated tests BRANCH=None Change-Id: I3cd66a745fa171c41a5f142514284ec106586acb Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/50358 Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Cleanup: flash moduleRandall Spangler2012-10-251-1/+0
| | | | | | | | | | | | | No functional changes; just clean up comments and remove dead code BUG=chrome-os-partner:15579 BRANCH=none TEST=code compiles Change-Id: Id006ae18f2b26cea1720196f696f937811b6ba5b Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/36448 Reviewed-by: Simon Glass <sjg@chromium.org>
* flash: Only erase flash block that contain dataSimon Glass2012-08-231-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It wastes time to erase blocks that are already erased and it is faster on stm32 to check first. Add a check in flash_physical_erase() on all chips, using a common flash_is_erased() function. BUG=none BRANCH=snow,link TEST=manual Do software sync in U-Boot and see that it succeeds. This tests that we can still erase and then boot a written image. It typically saves a second on a full sync over i2c. SMDK5250 # cros_test swsync -f SF: Detected W25Q32 with page size 4 KiB, total 4 MiB Flashing RW EC image: erasing, writing, done Flashing RO EC image: erasing, writing, done Full software sync completed in 22.949s SMDK5250 # Also see that second erase is faster: SMDK5250 # time mkbp erase rw time: 0.952 seconds, 952 ticks SMDK5250 # time mkbp erase rw time: 0.054 seconds, 54 ticks SMDK5250 # Change-Id: I3699577217fdbb2f212d20d150d3ca15fdff03eb Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/30851 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Refactor flash moduleRandall Spangler2012-07-231-40/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a significant rewrite of the flash module, since it turns out that much less of the flash logic is actually common between stm32 and lm4. BUG=chrome-os-partner:11699 TEST=on link, (enable hardware wp) flashinfo -> wp_gpio_asserted flashwp enable flashinfo -> wp_gpio_asserted ro_at_boot reboot flashinfo -> wp_gpio_asserted ro_at_boot ro_now flashwp disable -> error 7 flashwp now flashinfo -> wp_gpio_asserted ro_at_boot ro_now rw_now reboot flashinfo -> wp_gpio_asserted ro_at_boot ro_now (disable hardware wp) reboot flashinfo -> ro_at_boot flashwp disable flashinfo -> (no flags) Change-Id: If22b02373946ce1c080d49ccded4f8fa3e380115 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/28200 Reviewed-by: Vic Yang <victoryang@chromium.org>
* stm32f: Fix some error in flash write protectVic Yang2012-07-211-1/+2
| | | | | | | | | | | | | | | | | | And also add a fake write protect pin command for futher development and testing. BUG=chrome-os-partner:11595 TEST=Enable pstate read/write for stm32f. 1. 'flashinfo' -> WP pin deasserted. No blocks protected. 2. 'flashwp enable' -> Nothing changes. 3. 'fakewp 1'; 'flashinfo' -> WP pin asserted. No blocks protected. 4. 'flashwp enable'; 'flashinfo' -> RO protected. Change-Id: Id5b1997442d9104d9cb254a295e0bd2f8c83bc78 Signed-off-by: Vic Yang <victoryang@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/28062 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add EC flash protect command to ectoolRandall Spangler2012-07-181-22/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:11150 TEST=manual Enable WP GPIO. Then from a root shell localhost ~ # ectool flashprotect Flash protect flags: 0x00000008 wp_gpio_asserted Writable flags: 0x00000005 ro_at_boot rw_now localhost ~ # ectool flashprotect enable Flash protect flags: 0x0000000b wp_gpio_asserted ro_at_boot ro_now Writable flags: 0x00000004 rw_now localhost ~ # ectool flashprotect enable Flash protect flags: 0x0000000b wp_gpio_asserted ro_at_boot ro_now Writable flags: 0x00000004 rw_now localhost ~ # ectool flashprotect now Flash protect flags: 0x0000000f wp_gpio_asserted ro_at_boot ro_now rw_now Writable flags: 0x00000000 localhost ~ # ectool flashprotect now Flash protect flags: 0x0000000f wp_gpio_asserted ro_at_boot ro_now rw_now Writable flags: 0x00000000 localhost ~ # ectool flashprotect disable Flash protect flags: 0x0000000f wp_gpio_asserted ro_at_boot ro_now rw_now Writable flags: 0x00000000 Unable to set requested flags (wanted mask 0x00000001 flags 0x00000000) Which is expected, because writable mask is 0x00000000. Then disable WP GPIO and reboot localhost ~ # ectool flashprotect Flash protect flags: 0x00000001 ro_at_boot Writable flags: 0x00000001 ro_at_boot localhost ~ # ectool flashprotect disable Flash protect flags: 0x00000000 Writable flags: 0x00000001 ro_at_boot Change-Id: Idc5de3b3033521467aca8fb0ba9b7c378d0ad2a1 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27799
* Use config values for flash protect/erase/write sizesRandall Spangler2012-07-181-16/+26
| | | | | | | | | | | | Since they're config values anyway. Gets rid of an unneeded layer of function call. BUG=chrome-os-partner:11150 TEST=build link, snow, daisy; flashinfo returns same values Change-Id: I27fa007f64a446f1ec0fe22ae16c5c1ac667f8e9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27797
* Remove flash_read()Randall Spangler2012-07-181-47/+42
| | | | | | | | | | | | | | | | | | | Everything now uses flash_dataptr() to get at flash memory rather than calling the read function, since the read function adds a needless memcpy(). BUG=chrome-os-partner:11150 TEST=manual flashwp enable reboot flashinfo -> should show ro_at_boot flashwp disable reboot flashinfo -> should no longer show ro_at_boot Change-Id: I1830e2f036cf6777115c782c1737335ff2eb4ce0 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27796
* Continue refactoring flash write protectRandall Spangler2012-07-181-10/+20
| | | | | | | | | | | | | | | | | | | | | Now properly detects partially-protected flash banks. Also renames 'flashwp lock/unlock' to 'flashwp enable/disable' BUG=chrome-os-partner:11150 TEST=manual ww 0x400fe400 0x7fffffff flashinfo -> ro_now PARTIAL reboot ww 0x400fe404 0x7fffffff flashinfo -> rw_now PARTIAL flashwp now flashinfo -> ro_now rw_now (and NOT partial) Change-Id: I9266a024eee6d75af052cd47e3f54468ad959a12 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27795
* Continue simplifying flash write protectRandall Spangler2012-07-181-21/+8
| | | | | | | | | | | | Now that read-only code is protected iff the persistent state is locked, we don't need to track per-block in the persistent state. BUG=chrome-os-partner:11150 TEST=if it builds and boots, it's fine Change-Id: I80e6a85c0c72136b7ed8964ce02c8abdbaafe637 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27719
* Simplify flash protection, part 1Randall Spangler2012-07-181-20/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | 1. If the flash protection state is locked, RO firmware is explicitly locked. 2. Protecting flash now locks the entire flash. BUG=chrome-os-partner:11150 TEST=manual flashinfo -> nothing protected flashwp now flashinfo -> unlocked,applied; everything protected reboot flashinfo -> nothing protected flashwp lock -> flashinfo -> locked,applied; now has 40 Y's at start and 1 at end reboot flashinfo -> locked,applied; now has 40 Y's at start and 1 at end remove WP screw reboot flashinfo -> locked, not applied; nothing protected flashwp unlock flashinfo -> nothing protected Change-Id: I2cf0e8bfe82ab7a5bf88b9161b7a05b889cae71a Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27717
* Flash pre-init reboots if it needs to clear protection registersRandall Spangler2012-07-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:11171 TEST=manual 1. Clear some of the writable-bits in the flash registers > ww 0x400fe40c 0xffff1234 write 0x400fe40c = 0xffff1234 > rw 0x400fe40c read 0x400fe40c = 0xffff1234 2. Reset using power+refresh 3. Register should be clear again > rw 0x400fe40c read 0x400fe40c = 0xffffffff 4. Sysinfo should indicate reset-pin reason AND hard-reset reason > sysinfo Reset flags: 0x0000000a (reset-pin power-on) 5. Reset using power+refresh 6. Sysinfo should indicate reset-pin reason only > sysinfo Reset flags: 0x00000002 (reset-pin) 7. Clear writable-bits again > ww 0x400fe40c 0xffff1234 write 0x400fe40c = 0xffff1234 8. Jump to another image. This should NOT trigger a hard reset. > sysjump A > sysinfo Reset flags: 0x00000402 (reset-pin sysjump) Change-Id: Ie1d6af2acc68217bb82faae464798ee85d63d1ea Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/27540 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* Fix flash_dataptr() to support flash at zeroSimon Glass2012-07-031-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If flash starts at zero, then flash_dataptr() will return NULL for a valid region. Change the function around so that it can be used in this case. BUG=chrome-os-partner:10146 TEST=manual: Modify code it print out parameters and problems, then: Writing 256 bytes to 0x0... 0 256 64 ok 131072 Command returned error 1 > flashwrite 0 256 Writing 256 bytes to 0x0... 0 256 64 ok 131072 Command returned error 1 > flashwrite 0 255 Writing 255 bytes to 0x0... 0 255 64 Command usage/param invalid. Usage: flashwrite offset [size] Change-Id: I5683fc181ef780310ceff50f120735659e973784 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/26749 Reviewed-by: David Hendricks <dhendrix@chromium.org> Reviewed-by: Rong Chang <rongchang@chromium.org>
* flash: Provide direct flash access with flash_dataptr()Simon Glass2012-07-021-0/+37
| | | | | | | | | | | | | | | | | | | Sometimes it is useful to get access to the flash directly, without using flash_read(). Add a function to do this. Since the range checking is done in every function in flash_common, use the new function to do it for us. That way we get a slight (64 byte) code size reduction. BUG=chrome-os-partner:10146 TEST=manual: build and boot on snow with SPI flash emulation, in U-Boot: See that the 32KB of flash has been provided correctly. Change-Id: I6622a24234edaed371dd5b9bf43d1f3974d55e39 Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/26174
* Implement persistent flash write protect settingsRandall Spangler2012-04-021-51/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This uses the last bank of flash to hold persistent settings, and looks at the write protect GPIO to decide whether to protect the chip at boot (chrome-os-partner:7453). For ease of debugging, I've temporarily hacked this so flash uses the RECOVERYn signal (dut-control goog_rec_mode:on) to enable WP instead of the write protect signal; this works around chrome-os-partner:8580. Also note that if you write protect any blocks even temporarily, you'll need to do a power-on reset to clear them before you can reprogram the flash. See chrome-os-partner:8632. At the EC console, "hibernate 1" will do that, or you can just yank the power. This also fixes a bug in the flash write and erase commands, where they weren't properly detecting failure if you attempted to modify a protected block (missed an interrupt reason...) New "flashwp" console commands work. LPC commands need reworking. Signed-off-by: Randall Spangler <rspangler@chromium.org> BUG=chrome-os-partner:8448 TEST=manual Change-Id: I49c38cc25c793094ae3331a4586fda0761b4bac6
* More cleanup of board/chip configs and initializationRandall Spangler2012-03-191-2/+2
| | | | | | | | | | | | | | | | | More modules can be disabled individually through CONFIG_ defines. Reordered early module pre-init and init, and added comments to explain why things are ordered in main() the way they are. Fixed a few assorted init-related bugs along the way, like st32m keyboard scan double-initializing. BUG=none TEST=build link, bds, daisy Signed-off-by: Randall Spangler <rspangler@chromium.org> Change-Id: I04a7fa51d743adfab4be4bdddaeef68943b96dec
* Make all warnings into errors.Bill Richardson2012-02-271-2/+2
| | | | | | | | | Also fix a couple places where that makes it fail. BUG=none TEST=none Change-Id: I3b434b4bfa547a579193aac67c1a9d440a2c4e51
View Lorry Controller Status