| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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
|
|
|
|
|
|
|
|
|
| |
Also fix a couple places where that makes it fail.
BUG=none
TEST=none
Change-Id: I3b434b4bfa547a579193aac67c1a9d440a2c4e51
|
|
source files mainly done by Randall.
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Change-Id: Iaff83a842b17f3350fb6f2a3f1597ad4c29bd12a
|