chromiumos/platform/saft.git
23 months agoAdd firmware vblock sha and method to modify firmware factory-2985.B factory-2993.B factory-3004.B factory-3536.B factory-4128.B factory-4290.B factory-4455.B factory-pit-4280.B factory-pit-4390.B factory-pit-4471.B factory-spring-3842.B factory-spring-4131.B factory-spring-4262.B firmware-falco_peppy-4389.B firmware-leon-4389.26.B firmware-pit-4482.B firmware-spring-3824.4.B firmware-spring-3824.55.B firmware-spring-3824.84.B firmware-spring-3824.B firmware-spring-3833.B firmware-wolf-4389.24.B master release-R25-3428.B release-R26-3701.B release-R27-3912.B release-R28-4100.B release-R29-4319.B release-R30-4537.B stabilize-3428.110.0 stabilize-3428.149 stabilize-3428.149.B stabilize-3428.193 stabilize-3658.0.0 stabilize-3701.30.0 stabilize-3701.30.0b stabilize-3701.46.B stabilize-3701.81.B stabilize-3881.0.B stabilize-3912.79.B stabilize-4008.0.B stabilize-4035.0.B stabilize-4068.0.B stabilize-4100.38.B stabilize-4255.B stabilize-4287.B stabilize-4443.B stabilize-4512.B stabilize-bluetooth-smart stabilize-spring-4100.53.B stabilize2 toolchain-3428.65.B toolchain-3701.42.B toolchainA toolchainB
ctchang [Wed, 5 Sep 2012 02:53:36 +0000 (10:53 +0800)]
Add firmware vblock sha and method to modify firmware

To backup firmware, add firmware vblock sha (firmware body sha is already
exist) and associated method to get these sha. Some methods to set and get
firmware body and vblock are needed.

BUG=chromium-os:33641
TEST=After merging faftsequence.py, use backup_firmware() and restore_firmware()

Change-Id: I8c96acba8872ab191fec8a9f84750e3761f3dc78
Reviewed-on: https://gerrit.chromium.org/gerrit/32503
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agosaft: Fix the argument and the return value of get_internal_disk() factory-2846.B factory-2848.B factory-2914.B release-R23-2913.B stabilize stabilize-daisy stabilize-link stabilize-link-2913.278
Tom Wai-Hong Tam [Thu, 30 Aug 2012 14:11:00 +0000 (22:11 +0800)]
saft: Fix the argument and the return value of get_internal_disk()

The get_internal_disk() doesn't work on ARM platform. The argument should
be a device with a partition and the return value should be a device without
a partition.

BUG=chrome-os-partner:13323
TEST=Run a FAFT test on ARM platform without error.

Change-Id: Ib02df7a277bf17755d96370689255f2bf4a96d2f
Reviewed-on: https://gerrit.chromium.org/gerrit/31850
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agosaft: Modify ecbin size field on the DTB blob
Tom Wai-Hong Tam [Thu, 30 Aug 2012 11:10:25 +0000 (19:10 +0800)]
saft: Modify ecbin size field on the DTB blob

The new updated ecbin may have a different size. The ecbin size field on the
DTB blob should be updated. Otherwise, the software sync may be failed.

BUG=chrome-os-partner:12997
TEST=After merging some EC update test changes, run:
run_remote_test.sh -a "new_ec=ec_autest_image.bin" firmware_UpdateECBin/control$

Change-Id: I9eebb3b4c885d8276d48650e78a7ca775280595d
Reviewed-on: https://gerrit.chromium.org/gerrit/31842
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoFetch internal disk when using removable disk
ctchang [Wed, 29 Aug 2012 06:06:15 +0000 (14:06 +0800)]
Fetch internal disk when using removable disk

It always uses the current boot kernel now. In kernel_handler, add an argument
"internal_disk" to decide which disk to retrieve. Therefore, it can use
internal kernel disk when using removable disk. In chromeos_interface, add a
method to get internal disk for arm or x86.

BUG=chrome-os-partner:13323
TEST=Boot with removable disk, check kernel_handler fetch whick disk device.

Change-Id: Ie8e2f2e9e3b1f72dc8551da37ad26f51a96299b1
Reviewed-on: https://gerrit.chromium.org/gerrit/31692
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Chun-Ting Chang <ctchang@chromium.org>
Tested-by: Chun-Ting Chang <ctchang@chromium.org>
2 years agosaft: Write the modified firmware body to flashrom after updating ecbin
Tom Wai-Hong Tam [Wed, 29 Aug 2012 13:48:16 +0000 (21:48 +0800)]
saft: Write the modified firmware body to flashrom after updating ecbin

The original code has an issue that we don't write the firwmare body back
to the system via flashrom. So any change doesn't take effect. This CL
fixes this issue.

BUG=chrome-os-partner:12997
TEST=After merging some EC update test changes, run:
run_remote_test.sh -a "new_ec=ec_autest_image.bin" firmware_UpdateECBin/control$

Change-Id: I40c83f5bd2c4774e02341ac21f4b6167e713638f
Reviewed-on: https://gerrit.chromium.org/gerrit/31705
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agosaft: Fix bug that the offset of the ecbin should be 4-byte aligned
Tom Wai-Hong Tam [Wed, 29 Aug 2012 14:29:57 +0000 (22:29 +0800)]
saft: Fix bug that the offset of the ecbin should be 4-byte aligned

The main firmware RW body is concatenated from u-boot, dtb, and ecbin.
They are all 4-byte aligned. This CL is to fix this bug.

BUG=chrome-os-partner:12997
TEST=After merging some EC update test changes, run:
run_remote_test.sh -a "new_ec=ec_autest_image.bin" firmware_UpdateECBin/control$

Change-Id: Ie906e191d37c743b9a28a1b55b4879c963648828
Reviewed-on: https://gerrit.chromium.org/gerrit/31708
Reviewed-by: Vic Yang <victoryang@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoAdd methods to support update kernel version and data key verison
ctchang [Wed, 22 Aug 2012 02:25:00 +0000 (10:25 +0800)]
Add methods to support update kernel version and data key verison

This is to enable retrieve kernel data key version, and also add
method to resign kernel with specific keys.

BUG=chrome-os-partner:12442
TEST=Check if we can retrieve kernel data key version, and resign
kernel.

Change-Id: I77c1f14aabbd8629ad378a3321d27c48b66aa4d7
Reviewed-on: https://gerrit.chromium.org/gerrit/31202
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Chun-Ting Chang <ctchang@chromium.org>
Tested-by: Chun-Ting Chang <ctchang@chromium.org>
2 years agosaft: Export get_section_body and set_section_body methods on flashrom_handler firmware-stout-2817.B
Tom Wai-Hong Tam [Fri, 24 Aug 2012 08:04:37 +0000 (16:04 +0800)]
saft: Export get_section_body and set_section_body methods on flashrom_handler

These 2 methods will be used for EC Software Sync update test. So this
change exports them and does a bit refactoring.

BUG=chrome-os-partner:12997
TEST=After merging some EC update test changes, run:
run_remote_test.sh -a "new_ec=ec_autest_image.bin" firmware_UpdateECBin/control$

Change-Id: Ibde6f3e42669f1847b32c5dd42c5de59c21a4651
Reviewed-on: https://gerrit.chromium.org/gerrit/31326
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agosaft: Add EC binary getter and setter methods on flashrom_handler
Tom Wai-Hong Tam [Fri, 24 Aug 2012 04:02:39 +0000 (12:02 +0800)]
saft: Add EC binary getter and setter methods on flashrom_handler

According to the EC Software Sync design, The EC binary is now embedded
in the BIOS image. On AP startup, AP verifies the EC by comparing the
hash of the current EC with the hash of the embedded EC image.

For testing this design, some FAFTs need to update the EC binary. This
change add the support of getting and setting the EC binary on the BIOS
image.

BUG=chrome-os-partner:12997
TEST=After merging some EC update test changes, run:
run_remote_test.sh -a "new_ec=ec_autest_image.bin" firmware_UpdateECBin/control$

Change-Id: Ic05a53b8b8040016991259f9d9ff8a9eb9a1ba49
Reviewed-on: https://gerrit.chromium.org/gerrit/31325
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoAdd method to retrieve version in firmware preamble firmware-butterfly-2788.B
ctchang [Thu, 9 Aug 2012 02:19:41 +0000 (10:19 +0800)]
Add method to retrieve version in firmware preamble

This is to enable retrieve firmware version, firmware datakey version,
kernel subkey version

BUG=chrome-os-partner:12442
TEST=Check we can retrieve firmware version, firmware datakey version,
  kernel subkey version

Change-Id: Ia116fafd9279eb7d367f20ce85bade5594ed37a3
Reviewed-on: https://gerrit.chromium.org/gerrit/29721
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Chun-Ting Chang <ctchang@chromium.org>
Tested-by: Chun-Ting Chang <ctchang@chromium.org>
2 years agoAdd method to read SHA-1 hash of firmware section in flashrom handler factory-2717.B factory-2723.14.B firmware-link-2695.2.B firmware-link-2695.B firmware-snow-2695.90.B firmware-snow-2695.B release-R22-2723.B
Vic Yang [Tue, 31 Jul 2012 09:15:56 +0000 (17:15 +0800)]
Add method to read SHA-1 hash of firmware section in flashrom handler

This is to enable checking if firmware section has changed.

BUG=chrome-os-partner:11980
TEST=Check we can read SHA-1 hash.

Change-Id: I35ecf0a3faf43c70c9ec7dc2e6d5f8b9276adeb3
Reviewed-on: https://gerrit.chromium.org/gerrit/28790
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>

2 years agoModify flashrom handler to match new EC FMAP
Vic Yang [Tue, 31 Jul 2012 08:09:34 +0000 (16:09 +0800)]
Modify flashrom handler to match new EC FMAP

EC no longer has VBLOCK and RW-B. Let's make it a single 'rw' section.

BUG=chrome-os-partner:11980
TEST=Check we can modify EC image.

Change-Id: I243becd8b4e759a2d2e0aca0961ffdb9b62c0ee0
Reviewed-on: https://gerrit.chromium.org/gerrit/28786
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
2 years agoUpdate firmware when only preamble changes
Vic Yang [Tue, 31 Jul 2012 08:06:47 +0000 (16:06 +0800)]
Update firmware when only preamble changes

Currently when set_firmware_version is called, firmware is only updated
when version changed. Let's change this to also update on flags change.

BUG=chrome-os-partner:11980
TEST=Tested we can clear RO-normal flag.

Change-Id: If24d399ea3f5761e602207d4df70201926277522
Reviewed-on: https://gerrit.chromium.org/gerrit/28785
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
2 years agosaft: Skip checking EC is in RO or not when running CGPT state test firmware-parrot-2685.B
Tom Wai-Hong Tam [Fri, 27 Jul 2012 06:30:44 +0000 (14:30 +0800)]
saft: Skip checking EC is in RO or not when running CGPT state test

The 3rd element of a boot vector indicates EC is in RO or RW. In the CGPT
state test, we don't care about the EC state. So mark it wildcard (*) to
skip this check. And also use cmp_boot_vector() to compare instead of a
string comparison.

BUG=chromium-os:26953,chromium-os:32871
TEST=run FAFT firmware_CgptState on Link passed.

Change-Id: If69458a631c963fab51fce25d96b4ebc70c072ba
Reviewed-on: https://gerrit.chromium.org/gerrit/28576
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agosaft: Move cmp_boot_vector() to ChromeOSInterface class
Tom Wai-Hong Tam [Fri, 27 Jul 2012 06:02:02 +0000 (14:02 +0800)]
saft: Move cmp_boot_vector() to ChromeOSInterface class

Make it reusable from other places.

BUG=chromium-os:26953,chromium-os:32871
TEST=run FAFT firmware_TryFwB/control.normal on Link passed.

Change-Id: I53456b583389e1672feb844f98ef6334d0258d24
Reviewed-on: https://gerrit.chromium.org/gerrit/28575
Reviewed-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoAdd an option to corrupt all bytes in a firmware section factory-2569.B
Vic Yang [Fri, 29 Jun 2012 05:58:26 +0000 (13:58 +0800)]
Add an option to corrupt all bytes in a firmware section

Current flashrom handler only provide an interface to corrupt a single
byte in a firmware section. Let's extend this to be able to corrupt all
bytes in order to improve test coverage.

BUG=chrome-os-partner:10265
TEST=Tested we can corrupt and restore firmware this way.

Change-Id: I20c56272440e393fa298561bd3c4c2f5ec9fe374
Reviewed-on: https://gerrit.chromium.org/gerrit/26396
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
2 years agoAdd flashrom EC support factory-2338.B factory-2368.B factory-2394.B factory-2460.B factory-2475.B firmware-link-2348.B release-R21-2465.B
Vic Yang [Fri, 18 May 2012 09:12:42 +0000 (17:12 +0800)]
Add flashrom EC support

Current flashrom module only support reading/writing BIOS. To enable EC
FAFT, let's add flashrom EC support.

BUG=chrome-os-partner:9188
TEST=Run firmware_CorruptFwBodyA and it still works.
     Manual test it can corrupt and restore EC.

Change-Id: I6e20e0e1b00749b5448490f841f9e1ae6a9c6ec4
Reviewed-on: https://gerrit.chromium.org/gerrit/23031
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Vic Yang <victoryang@chromium.org>
Commit-Ready: Vic Yang <victoryang@chromium.org>

2 years ago[saft] add OWNERS factory-2268.16.B factory-2305.B release-R20-2268.B
Elly Jones [Fri, 6 Apr 2012 19:30:55 +0000 (15:30 -0400)]
[saft] add OWNERS

TEST=None
BUG=chromium-os:22007

Change-Id: Id479f0d075136c47dab760f573eaf1ab15beb541
Signed-off-by: Elly Jones <ellyjones@chromium.org>
Reviewed-on: https://gerrit.chromium.org/gerrit/19775
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoAccept different path of keys in SAFT kernel handler library. factory-1987.B release-R19-2046.B
Tom Wai-Hong Tam [Wed, 8 Feb 2012 08:58:39 +0000 (16:58 +0800)]
Accept different path of keys in SAFT kernel handler library.

When running FAFT test cases, the keys are not in the current directory.

BUG=chromium-os:19710
TEST=run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
         servo_serial=$SERIAL" firmware_RollbackKernel/control$

Change-Id: Ice9868166579da87aeb26784983ae5cd54cc75b7
Reviewed-on: https://gerrit.chromium.org/gerrit/15479
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>

2 years agoSAFT accepts specifing a full path of log file. release-R18-1660.B
Tom Wai-Hong Tam [Fri, 30 Dec 2011 01:14:30 +0000 (09:14 +0800)]
SAFT accepts specifing a full path of log file.

When initializing the SAFT chromeos_interface library and specifing a
full path of log file (starts with '/'), use it directly.

BUG=chromium-os:19710
TEST=run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
         servo_vid=0x18d1 servo_pid=0x5001" firmware_TryFwB/control.normal

Change-Id: Ic84a1c289fb2ae1b5e65be10fc91bb95c7b23e6d
Reviewed-on: https://gerrit.chromium.org/gerrit/13574
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>

2 years agoAdd a method to get the GBB flags of the current firmware.
Tom Wai-Hong Tam [Wed, 28 Dec 2011 06:39:56 +0000 (14:39 +0800)]
Add a method to get the GBB flags of the current firmware.

This method will be used on firmware_DevScreenTimeout test to differentiate
normal timeout and short timeout on developer screen.

BUG=chromium-os:19710
TEST=run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
         servo_vid=0x18d1 servo_pid=0x5001" firmware_DevScreenTimeout

Change-Id: I2dec1f89017affaa43fdc4efc9db0db03c367a2c
Reviewed-on: https://gerrit.chromium.org/gerrit/13549
Reviewed-by: Rajesh Chenna <rchenna@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoSupport corrupting firmware body on SAFT.
Tom Wai-Hong Tam [Mon, 12 Dec 2011 07:04:59 +0000 (15:04 +0800)]
Support corrupting firmware body on SAFT.

Add the methods of corrupting firmware body instead of corrupting firmware
signature.

BUG=chromium-os:19710
TEST=run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
        servo_vid=0x18d1 servo_pid=0x5001" CorruptFwA/control.both

Change-Id: Ied40c51dff3910e37217f403c82a00cc3e5abee5
Reviewed-on: https://gerrit.chromium.org/gerrit/12730
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoCorrupt the firmware signature instead of the body. factory-1412.B release-R17-1412.B
Tom Wai-Hong Tam [Mon, 5 Dec 2011 08:03:58 +0000 (16:03 +0800)]
Corrupt the firmware signature instead of the body.

Since in the RO-normal boot presented firmware, only corrupting the firmware
body is not enough. It is still able to boot its RO-normal firmware without
verifing the RW-firmware body. So corrupting the signature seems a better
solution.

BUG=chrome-os-partner:6882, chrome-os-partner:6683
TEST=run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
        servo_vid=0x18d1 servo_pid=0x5001" CorruptFwA/control.both
     run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
        servo_vid=0x18d1 servo_pid=0x5001" CorruptFwB/control.both
     run_remote_tests.sh --remote=$REMOTE_IP -a "xml_config=$OVERLAY_XML \
        servo_vid=0x18d1 servo_pid=0x5001" CorruptBothFwAB/control.both

Change-Id: Id6ce3352f3bc117c1ca51e1566c1e582a6e04db9
Reviewed-on: https://gerrit.chromium.org/gerrit/12431
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Commit-Ready: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
2 years agoAdd the missing crossystem vector mapping. factory-1235.B factory-1284.B firmware-kiev-2.112.B firmware-uboot_v2-1299.B release-R16-1193.B
Tom Wai-Hong Tam [Wed, 31 Aug 2011 01:26:22 +0000 (09:26 +0800)]
Add the missing crossystem vector mapping.

Add the missing crossystem vector mapping as the comments said.
  first vector position
    2 - developer mode boot
    3 - recovery initialed by pressing the recovery button
    4 - recovery from developer mode warning screen
  second vector position
    rewritable firmware is not required a normal firmware

BUG=chromium-os:19451
TEST=manual

Import chromeos_interface.py and call boot_state_vector to verify the results.
Tests on both Kaen and Alex.

Change-Id: I60207e945183a6bc0c62ac078c54bd08d2a62219
Reviewed-on: http://gerrit.chromium.org/gerrit/7153
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2 years agoRemove hardcoded root device and handle ARM partition stripping and joining.
Tom Wai-Hong Tam [Tue, 23 Aug 2011 09:42:23 +0000 (17:42 +0800)]
Remove hardcoded root device and handle ARM partition stripping and joining.

Remove all hardcoded root device and APIs changes in chromeos_interface:
 - Rename get_root_dev to get_root_part, which contains partition number.
 - Add a real get_root_dev, which doesn't contain partition number.
 - Add strip_part to strip the partition number from a full device filename.
 - Add join_part to join the partition number to the device name.

BUG=chromium-os:19451
TEST=manual

Ran saft on an ARM device and runtest.sh script succeeded.
But after reboot, still needs some fixes to make it work.

Change-Id: Ia5b0b6355d887b4034d7d56cac8dbc7fc345b2dd
Reviewed-on: http://gerrit.chromium.org/gerrit/6485
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2 years agoFix SAFT to support zero-sized FMap section.
Tom Wai-Hong Tam [Mon, 22 Aug 2011 10:16:01 +0000 (18:16 +0800)]
Fix SAFT to support zero-sized FMap section.

Since ARM firmware has no recovery section so a zero-sized section appears.
It was failed the check in line 122 of check_layout():
    if section_base < base or section_end < section_base:

Because layout_data[name] = (offset, offset + size - 1), so the check should be:
    if section_base <= base or section_end + 1 < section_base:
to make it work as intended.

The second if condition is < if we accept zero-sized; otherwise <= if we don't
accept it.

BUG=chromium-os:19451
TEST=manual

Ran saft on both ARM and x86 devices. Ran /usr/sbin/firmware/saft/runtest.sh
and wasn't failed in check_layout() check.

Change-Id: I2986be5740c917f9b9007aa960e478524c2bcf11
Reviewed-on: http://gerrit.chromium.org/gerrit/6395
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2 years agoFix SAFT to support ARM device/partition naming convention.
Tom Wai-Hong Tam [Mon, 22 Aug 2011 10:02:21 +0000 (18:02 +0800)]
Fix SAFT to support ARM device/partition naming convention.

On x86, device/partition is something like /dev/sdb3. On ARM, the internal disk
is something like /dev/mmcblk0p3 but the flash device is something like
/dev/sda3. So this CL is to make it work on both x86 and ARM.

BUG=chromium-os:19451
TEST=manual

Ran saft on an ARM device. Ran the unittest test_chromeos_interface.py success.

localhost / # /usr/sbin/firmware/saft/runtests.sh
32768+0 records in
32768+0 records out
16777216 bytes (17 MB) copied, 0.607159 s, 27.6 MB/s
32768+0 records in
32768+0 records out
16777216 bytes (17 MB) copied, 0.959958 s, 17.5 MB/s
1+0 records in
1+0 records out
1 byte (1 B) copied, 0.002065 s, 0.5 kB/s
starting as /tmp/tmp_saft.V6pa/usr/sbin/firmware/saft/runtests.sh
......
----------------------------------------------------------------------
Ran 6 tests in 0.196s

OK

Change-Id: Id37624946c0ac3226fa313c7a55f986f6fda7d22
Reviewed-on: http://gerrit.chromium.org/gerrit/6394
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
2 years agoHandle USE_RO_NORMAL preamble flag correctly. factory-1020.B release-1011.B
Tom Wai-Hong Tam [Tue, 23 Aug 2011 02:33:47 +0000 (10:33 +0800)]
Handle USE_RO_NORMAL preamble flag correctly.

USE_RO_NORMAL is a new preamble flag available in preamble header version 2.1.
When this flag is presented, it notices bootstub firmware to boot its RO normal
path instead of loading and verifying the RW firmware body.

So this CL is to fix some behaviors of existing tests in SAFT correctly.
- test_image_re_sign in test_flashrom_handler.py:
    It increses the original firmware version 1 and resign it. The fix is to
    pass the original preamble flags to the new one.
- test_image_corrupt_restore in test_flashrom_handler.py:
    It corrupts the firmware body and expects an assertion. When USE_RO_NORMAL
    presented, should expects no assertion as no firmware body verification.

This CL is not intended to test the usages of USE_RO_NORMAL. It is just for
fixing the original behaviors. A special USE_RO_NORMAL test will come later
for this purpose.

BUG=chromium-os:19451
TEST=manual

Ran saft on an ARM device and firmware with USE_NO_NORMAL presented.
Ran the unittest test_flashrom_handler.py succeeded.

localhost / # /usr/sbin/firmware/saft/runtests.sh
32768+0 records in
32768+0 records out
16777216 bytes (17 MB) copied, 0.623775 s, 26.9 MB/s
32768+0 records in
32768+0 records out
16777216 bytes (17 MB) copied, 0.926702 s, 18.1 MB/s
1+0 records in
1+0 records out
1 byte (1 B) copied, 0.01432 s, 0.1 kB/s
starting as /tmp/tmp_saft.LntH/usr/sbin/firmware/saft/runtests.sh
......
----------------------------------------------------------------------
Ran 6 tests in 0.181s

OK
....
----------------------------------------------------------------------
Ran 4 tests in 19.150s

OK

Change-Id: I531ae8f6689ec87809d9d20c4b576062a7ca50f6
Reviewed-on: http://gerrit.chromium.org/gerrit/6464
Reviewed-by: Tom Wai-Hong Tam <waihong@chromium.org>
Tested-by: Tom Wai-Hong Tam <waihong@chromium.org>
3 years agoUpgrade SAFT to support newer firmware. 0.13.558.B 0.13.587.B 0.14.811.B 0.15.877.B 780.B factory-980.B firmware-881-u-boot-v1 firmware-u-boot-v1 test-982.B
Vadim Bendebury [Tue, 24 May 2011 18:25:29 +0000 (11:25 -0700)]
Upgrade SAFT to support newer firmware.

The most recent x86 firmware provides much more verbose
information about the recovery reasons than before (see the
document mentioned in the bug entry). SAFT chokes observing
recovery reason values it is not familiar with.

This CL extends the boot_vector generation facility to accept all
possible recovery reasons, which is a quick solution mapping
several recovery paths into the same boot vector value. This
'many to one' mapping creates an opening for the test missing the
cases when the BIOS reports recovery reasons incorrectly, but
still within the acceptable set. This will have to be addressed
in a separate CL.

BUG=chromium-os:15564
TEST=manual

Run SAFT on the ZGB image built off the top of the tree. Watch it
succeed.

Change-Id: I966696efb064154683c18837656e268f448f4144
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/1465
Reviewed-by: Randall Spangler <rspangler@chromium.org>
3 years agoMake SAFT work again under 2.6.38 kernel.
Vadim Bendebury [Fri, 20 May 2011 21:13:26 +0000 (14:13 -0700)]
Make SAFT work again under 2.6.38 kernel.

This CL fixes the issue where SAFT fails to determine that it is
running on a Chrome platform. The problem is due to the fact that
the file /proc/version_signature does not exist anymore in the
new kernel.

Another way of determining the platform is used now: looking for
the appropiate string in /etc/lsb-release. Also, both places
where this information is required are using the same function to
determine if the test is running on a host or on a target.

BUG=hromium-os:15551
TEST=manual

execute runtests.sh on the host and on a target running under
2.6.38, it succeeds on both platforms.

Change-Id: I32a919858d701ba933c40bb058eabcc81e18ab12
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://gerrit.chromium.org/gerrit/1321
Reviewed-by: Randall Spangler <rspangler@chromium.org>
3 years agoFix SAFT to work on all x86 platforms using crossystem. 0.12.433.B 0.12.433.B109 0.12.433.B62 0.13.434.B 0.13.509.B
Vadim Bendebury [Tue, 19 Apr 2011 23:02:13 +0000 (16:02 -0700)]
Fix SAFT to work on all x86 platforms using crossystem.

This is the second and final CL restoring SAFT functionality
on X86 platforms. The first one was

http://codereview.chromium.org/6849042/

This change

- builds up the VECTOR_MAP to cover all legacy boot vector
  values

- adds the provision to modify the map at run time on Mario
  (because Mario firmware always reports the recovery switch
  state as 'ON' if booted in recovery mode)

- adds test cases to verify this map adjustment on Mario
  and to verify proper reporting of failed shel commands

Change-Id: I9982f53ba8a5cc286eb8767686e714e22140f892

BUG=chrome-os-partner:2617
TEST=manual

- run SAFT on Mario, Alex and ZGB, follow the directions
  (unplug and plug back in the USB flash stick a required).
- Observe SAFT complete successfully (the /tmp/saft.log file
  contains 'We are done!' as the last line.

Review URL: http://codereview.chromium.org/6881019

3 years agoIntroduce crossystem wrapper for SAFT.
Vadim Bendebury [Mon, 18 Apr 2011 20:53:04 +0000 (13:53 -0700)]
Introduce crossystem wrapper for SAFT.

There has been an effort under way to abstract platform
specific information through the 'crossystem' utility, which
is capable of discovering information in platform specific
fashion and representing it in a unified way on all
platforms.

The BIOS ACPI on some platforms has been modified to support
this, which of course broke SAFT completely.

This CL introduces a wrapper for crossystem to derive all
necessary information in a target independent way and
emulate information previously read directly from ACPI.

The actual SAFT fix will come in the next CL.

The 'crossystem' wrapper is a class which runs the
crossystem utility to retrieve or set the crossystem
parameters..

The __getattr__() method override is used to get the
value of an arbitrary crossystem parameter, so that
crossystem.name causes the shell command

'crossystem name'

invocation to retrieve the value of parameter 'name'.

The __setattr__() method override is used to set the
crossystem parameters, such that assigning

crossystem.name = value

causes a shell command

'crossystem "name=value"'

to be invoked. The only name not passed to the shell
command, but set directly is 'cros_if',  which is a
member of the crossystem wrapper class.

Change-Id: I59b547d899598501185a443cf2cffcc00330b37c

BUG=chrome-os-partner:2617
TEST=on the workstation:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
es^o: home/vbendeb/projects/1repo/src/platform/saft 119 > ./runtests.sh
....
----------------------------------------------------------------------
Ran 4 tests in 0.032s

OK
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Review URL: http://codereview.chromium.org/6849042

3 years agoA few recent changes broke SAFT operation. 0.11.257.B 0.11.257.B90 0.12.362.B 0.12.369.B 0.12.392.B
Vadim Bendebury [Wed, 9 Mar 2011 20:58:14 +0000 (12:58 -0800)]
A few recent changes broke SAFT operation.

- the BIOS image now contains different firmware flavors
- the mosys utility now deploys locking and can fail to run
  if other programs are running.

To address the issue SAFT determines if firmware sections
are not the same and copies firmware B into firmware A.

A `-f' flag is being added to mosys command line to avoid
locking attempts (it operates on a separate file anyways).

Change-Id: I37d14696a7370bdc23abd1add67814ce8fe156dd

BUG=chrome-os-partner:2617
TEST=see below

. build the test image
. install it on DUT
. copy a new firmware image into /var
. run the test
 localhost saft # /usr/sbin/firmware/saft/runtests.sh /var/<new firmware>
. follow the prompts (unplugging/plugging back the USB stick)
. After the test ends observe test results:

localhost saft # grep 'modify firmware A' /var/fw_test_log.txt
02:36:23 PM: modify firmware A to match B
localhost saft # tail -1 /var/fw_test_log.txt
03:00:09 PM: we are done!
localhost saft #

Review URL: http://codereview.chromium.org/6649008

3 years agosaft: update 'flashrom_util' to use new syntax 0.11.241.B 11.1.241.B
Hung-Te Lin [Thu, 3 Mar 2011 07:10:14 +0000 (15:10 +0800)]
saft: update 'flashrom_util' to use new syntax

Using 'iotools' to control flashrom target is obsoleted.
The new parameter provided by 'flashrom' utility is better and prevents potential
race condition, so all scripts using flashrom should apply the new syntax.

BUG=chromium-os:11339
TEST=passed SAFT on CR48 (by josephsih)

Change-Id: Ia5f7d7ea3bc087b4506a101407a21087b4e278b7

Review URL: http://codereview.chromium.org/6594114

3 years agosaft: update flash map names definition for new section naming
Hung-Te Lin [Tue, 1 Mar 2011 02:23:13 +0000 (10:23 +0800)]
saft: update flash map names definition for new section naming

We need to update the SAFE definition to work with new BIOS section names.
NOTE: we should refine this script to use official names in the future.

BUG=chrome-os-partner:2158
TEST=cherry-picked from http://codereview.chromium.org/6484031

Change-Id: I1bf6a1f49839798fd8b1ffebbc76c067824e83eb

Review URL: http://codereview.chromium.org/6596063

3 years agoChange realpath to readlink -f
Randall Spangler [Tue, 8 Feb 2011 22:57:20 +0000 (14:57 -0800)]
Change realpath to readlink -f
Add inherit-review-settings-ok

BUG=chrome-os-partner:2259
TEST=manually verified 'readlink -f' and 'realpath' provide the same output

Review URL: http://codereview.chromium.org/6420002

Change-Id: I571dccf6be29e914d8070036b187a736cdf3655b

3 years agoFixed bug in cmp_boot_vector
Joseph Hwang [Wed, 17 Nov 2010 06:18:25 +0000 (14:18 +0800)]
Fixed bug in cmp_boot_vector

Fixed a bug in cmp_boot_vector of saft_utility.py. And added unit test cases for it.

Change-Id: Ie213d6743765bfa8062ad6255be9bf9fb134066f

BUG=chromium-os:8964
TEST=Follow SAFT standard test

Review URL: http://codereview.chromium.org/5145001

3 years agoAdding cgpt tests in SAFT
Joseph Hwang [Thu, 11 Nov 2010 02:16:41 +0000 (10:16 +0800)]
Adding cgpt tests in SAFT

What are changed:

  Adding a cgpt test loop function in cgpt_state.py. To create a new cpgt test
  case, you need to add a cgpt test tuple in cgpt_state_seq. It takes one reboot
  for each cgpt test. There are 12 steps in current cgpt_state_seq.

  cpgt test has its own state machine. All cgpt steps are seen as the same step
  number from the view of firmware test object. We can add a sub-step number to
  it later if required.

  The expected boot vector in FST's TEST_STATE_SEQUENCE is set as '*:*:*:*:*' as
  the boot vectors during the test loop of all cgpt tests will be examined
  inside cgpt state machine rather than FST.

Change-Id: Idf29d31386de133cc4a606d06485ffd55b08f9bd

BUG=
TEST= Follow SAFT standard test procedure. Check '/var/fw_test_log.txt'
for 'we are done'.

Review URL: http://codereview.chromium.org/4106012

3 years agoEnable TPM firmware rollback testing
vbendeb [Tue, 2 Nov 2010 04:01:05 +0000 (21:01 -0700)]
Enable TPM firmware rollback testing

This change introduces SAFT firmware rollback testing. It is
implemented similar to kernel rollback testing.

For the new tests to succeed the latest firmware is
required, because the test is modifying TPM stored firmware
version value while in recovery mode. Until recently to be
able to do that the firmware required to be in developer
mode.

Flashrom image initialization is now done in one place
instead of being scattered around the module. It is not
required during all steps, but this makes the code much
cleaner.

Change-Id: Iefc9d2085487e581d345c39841804f5143d34bf2

BUG=chromium-os:6806
TEST=Ran SAFT on a mario testing G4 firmware.

The test iterates through 21 steps and reports success in
the end.

Also observed that the kernel and firmware versions and the
TPM contents  stay where they were at the beginning of the
test.

Review URL: http://codereview.chromium.org/4100015

3 years agoThis CL builds upon previous SAFT enhancements and
vbendeb [Fri, 22 Oct 2010 22:22:26 +0000 (15:22 -0700)]
This CL builds upon previous SAFT enhancements and
introduces support for TPM kernel rollback testing.

The test as introduced checks the following:

- kernels with version below the current TMP version
  do not get booted.

- if there is no kernel with the version equal or exceeding
  the TPM kernel version value - boot in recovery mode.

- if both kernels's versions exceed the current TPM kernel
version value - verify that the BIOS bumps up the TPM kernel
version to the lowest of the two available kernels. (as of
now in this test both kernels have the same version number)

A new module is being introduced to support TPM testing.

There are two TPM NvRam spaces defined for CromeOs devices,
one for the BIOS and another one for the kernel. The spaces,
among other things, contain version numbers to prevent
rollback attempts.

The new module allows to read the spaces' contents and to
write into them.  Writing into the kernel space requires
the machine to be booted in recovery mode, writing into the
 BIOS  space (not yet tested) requires the machine to be
booted in developer mode.

On top of booting in these special  modes, the TPM lock
needs to be disabled for the write operation to succeed.
This requires editing of the TPM  upstart config file
(done in  tpm_handler:TpmHandler:enable_write_access()),
which in turn requires the root file system to be writable
when booting in recovery mode. Hence the modifications in
runtests.sh which first enable read/write mount of
the USB flash hosted the root file system and then modify
the kernel command line to mount it rw when booting off
the USB device.

Change-Id: I3a44ae51830f3525f51f03611d8b72a7039c9169

BUG=chromium-os:1976
TEST=manual

- build packages and the image as modified
- install the new image on the device and restart it
- place an alternative firmware image in /tmp
- run the SAFT as follows:
  /usr/sbin/firmware/saft/runtests.sh /tmp/<new firmware>.fd
- follow the prompts (unplug and plug the flash device as
  required
- observe SAFT to pass all 17 steps
- look for 'we are done' in /tmp/saft.log after test
  completes
into

Review URL: http://codereview.chromium.org/3781016

3 years agoProvide the means of changing the firmware/kernel versions.
vbendeb [Mon, 18 Oct 2010 23:36:43 +0000 (16:36 -0700)]
Provide the means of changing the firmware/kernel versions.

This CL introduces the ability to modify kernel and firmware
versions to support TPM rollback prevention testing.

Both firmware and kernel handlers are being expanded to
allow changing the appropriate images' versions and re-
signing.

The unit tests are being modified to verify the new added capability.

Change-Id: I2891c3ff50a76af29923f7f9d963d7eb2e017e4d

BUG=chromium-os:1976,chromium-os:6806
TEST=manual

The unit tests pass. The system is still bootable after
changing the versions back and forth.

Review URL: http://codereview.chromium.org/3861001

3 years agoProvide some means of displaying the current SAFT status.
vbendeb [Mon, 18 Oct 2010 17:25:43 +0000 (10:25 -0700)]
Provide some means of displaying the current SAFT status.

Different means of displaying information on the target
screen were attempted, they all failed because the main X
server takes over the screen and prevents any access to it
until the user is authenticated.

Eventually the approach used by autotest (see
client/site_tests/graphics_GLBench/graphics_GLBench.py in
the autotest repository) was implemented.

Running SAFt causes the text "SAFT's performing step #<num>"
displayed after every restart. It takes a while before he
text shows up (the SAFT startup script needs to detect the
Flash device first and then to start the separate instance
of the X server). It helps on the long phases (when the
flashrom is reprogrammed).

This framework could be enhanced to display text specific
messages, or use a simpler windowing method, but it is
a good enhancement of SAFT usability even as is.

A simple window control module is introduced in window.py,
it allows to start a thread which generates a window with
the text passed in to the display_text() method.

The saft.sh startup file is being modified to start the
alternative X server using the provided rudimentary config
file (saft.xorg.conf).

saft_utility.py is modified to handle the window module
properly, especially making sure that the window is shut
down on any abnormal termination. Also some typos and pylint
warnings are being fixed.

runtests.sh is being modified to make the saft script
runnable (recent security enhancements change /tmp mounting
options to noexec, it needs to be worked around now.

BUG=chromium-os:7846
TEST=manual:

Ran the test, observed the progress messages displayed after
every restart.

Review URL: http://codereview.chromium.org/3770005

Change-Id: I1c43348645bc66c0438bd84bb2789b612ffdbcb5

3 years agoIntroduce gpt tests in SAFT.
vbendeb [Thu, 16 Sep 2010 19:24:22 +0000 (12:24 -0700)]
Introduce gpt tests in SAFT.

This CL introduces infrastructure which allows SAFT to
access gpt (GUID partition table) information using the
cgpt utility.

There are may aspects of gpt management which can and should
be tested, this CL just creates a module which provides
a means of retrieving gpt information and changing it for
the test purposes, and adds one gpt test as an example.

A new module (cgpt_handler.py) is introduced along with the
unit test (test_cgpt_handler.py). See module docstrings
for details of operations.

saft_utility.py is being cleaned up as follows:

- imported modules arranged alphabetically, global then
  local

- if an attempt to execute a step results in a failure, call
finish_saft(False)to remove the saft 'follow up' script.
This is needed because gpt tests are more involved and can
not be reduced to checking of the boot vector value.

The target comes up with the proper boot vector, but the
cgpt reported values could still be wrong. In case cgpt
output does not match expected values, the test terminates.

- in case of error, do not call chros_if.shut_down(). This
will prevent moving the log file into /var directory and
removal of the test temp directory (/var/.fw_test on the
flash device). This will allow to examine the state of the
failed test in more details. The last step error messages
are still available in /tmp/saft.log

Also, a gpt related test case is being added:

- set the kernel tries attribute to 15 and observe it to
be changed to 14 after the reboot.

More gpt test can be added following this example.

Change-Id: Idc5a36baed8a8a0241dbeca8f62abe75e2136ba1

BUG=chromium-os:1994
TEST=see below

A new image was built and the test was run several times.
All test pass, the following section is included in the log file:

06:17:03 PM: calling <bound method FirmwareTest.cgpt_test_start of <__main__.FirmwareTest object at 0x6f69c62c>>
06:17:03 PM: Executing cgpt show /dev/sda
06:17:03 PM: Executing cgpt add -i 2 -S 0 -P 10 -T 15 /dev/sda
06:17:03 PM: Executing cgpt add -i 4 -P 9 -T 15 /dev/sda
06:17:03 PM: Executing reboot
06:17:16 PM: Executing cgpt show /dev/sda
06:17:16 PM: Executing rootdev -s
06:17:16 PM: Rebooted into state 1:1:0:0:3 on step 10
06:17:16 PM: startup log contents:
06:17:16 PM: Found sdc after 2 seconds
06:17:16 PM: calling <bound method FirmwareTest.cgpt_test_1 of <__main__.FirmwareTest object at 0x6f71762c>>
06:17:16 PM: Executing cgpt show /dev/sda
06:17:16 PM: Executing reboot
06:17:30 PM: Executing cgpt show /dev/sda
06:17:30 PM: Executing rootdev -s
06:17:30 PM: Rebooted into state 1:1:0:0:3 on step 11

Review URL: http://codereview.chromium.org/3385007

3 years agoFix typo: formware -> firmware
Duncan Laurie [Tue, 14 Sep 2010 22:13:37 +0000 (15:13 -0700)]
Fix typo: formware -> firmware

BUG=
TEST=docstring change only

Change-Id: I3525921f6fe299d5a4355461204c79454c86106e

Review URL: http://codereview.chromium.org/3386002

3 years agoMove the utils module and use the qualified rootdev command.
vbendeb [Mon, 13 Sep 2010 17:38:04 +0000 (10:38 -0700)]
Move the utils module and use the qualified rootdev command.

This CL completes SAFT modifications required due to recent
ChromeOS system changes (verified Boot on Flash drive and
programming just one of the two main storage partition
pairs). `rootdev -s' is used instead of 'rootdev' to avoid
nonzero exit status and make sure that the actual device
name is reported instead of the virtual one (/dev/dm-0)

This change also moves flashrom_util.py into the saft/
subdirectory renaming it into saft_flashrom_util.py, to
avoid confusion with the autotest version of this file.

Another modification is adding code to runtest.sh
to create the proper SAFT environment (where both file
systems are populated).

See http://sites.google.com/a/chromium.org/dev/for-testers/saft
which describes SAFT implementation and usage.

Change-Id: I9dcc2f052b629e1bc64db2fad4515a3e8526ec84

BUG=chromium-os:6345
TEST=manual

Ran saft on the target, had it run to completion reporting
success. Then used a flawed frimware, ran SAFT again, observed it to stop on error. Checked that in both cases
appropriate results were reported in /var/fw_test_log.txt.

Review URL: http://codereview.chromium.org/3347020

3 years agoMake SAFT use layout retrieved from the BIOS image.
vbendeb [Wed, 8 Sep 2010 01:23:21 +0000 (18:23 -0700)]
Make SAFT use layout retrieved from the BIOS image.

This CL modifies x86-generic/fashrom_util.py to use the
mosys tool to retrieve the flashrom memory map from the
BIOS image and use it unless explicitly overridden by the
caller.

flashrom_handler.py is being modified not to pass layout
on most flash read/write operations. Only in case the whole
flash write is requested - a custom map is used.

A cllass (LayoutScraper) is introduced in flashrom_util.py
to retrieve the text map from the image (using mosys) and
convert it into a layout dictionary. Default maps, ec
support and layout compiler are being deleted from this
file, as it is not used by any other package, and SAFT does
not require these features. The upcoming CL will move
 flashrom_util.py into saft subdirectory.

Change-Id: Ifcdc59e4c2567b2d815de9f64fb41c30f0f83c97

BUG=chrome-os-partner:920
TEST=manual. Ran SAFT on a target, it still fails complaining
about wrong BINF values when both firmware images are
corrupted. Once this issue is fixed by the vendor full log
will be posted here.

Review URL: http://codereview.chromium.org/3328008

4 years agoRework SAFT to operate in verified rootfs environment.
vbendeb [Thu, 2 Sep 2010 22:09:08 +0000 (15:09 -0700)]
Rework SAFT to operate in verified rootfs environment.

With the advent of verified rootfs SAFT became unusable, as
it is remounting the root file system in rw mode to install
an upstart script.

The solution is to have an immutable upstart script (as
being done under ttp://codereview.chromium.org/3330005/show)
and to modify the SAFT framework to support that, which is
being done by this CL.

The immutable script tries to find the shell script
installed during SAFT initialization. The shell script is
installed on the flash drive's stateful partition. in
/var/saft.sh.

To make sure that the file names used by the immutable
upstart script and SAFT stay in sync, the upstart script is
 defining the vital file names through <name>=<value>
statements, and SAFT parses the upstart script to retrieve
 these values.

A few bugs were uncovered while testing these changes, they
are being fixed too.

Since the names of the
Change-Id: I687512794ac5e5533fc5e993312dff80cce04892

BUG=chromium-os:6345
TEST=manual

The tests pass, the actual test log will be added after
finalizing the upstart script changes.

Review URL: http://codereview.chromium.org/3297002

4 years agoImprove SAFT robustness.
vbendeb [Sun, 29 Aug 2010 05:09:21 +0000 (22:09 -0700)]
Improve SAFT robustness.

This CL borrows from investigation and implementation of
http://codereview.chromium.org/3071024/show.

Indeed in certain cases instantiation of flash devices takes
a while. This change accomplishes the following:

- allow to override default flash device (sdb) using
  environment variable FLASH_DEVICE

- wait for the device to show up before trying to mount it.
  Terminate with error if the device does not show up
  after 15 seconds.

- allow 30 seconds for ACPI to settle. It is somehow taking
  a long tome to get its act together when running off the
  flash card on certain platforms. Report time taken in the
  log.

- do not remount the flash device if it is already mounted
  and use "/" as the mount point when the flash device is
  hosting the root file system.

- if the startup script generates output - add it to the
  log file in the beginning of every test step.

- rearrange test steps to group them logically.

Change-Id: If2d7034ee8f89974ccc2477e2fbc5b62fea07443
BUG=chromium-os:5424
Test=see below

The entire test completes successfully, the delayed flash
device mounts and ACPI device initializations are reported
in the log as follows:
.
.
07:33:26 PM: Detected USB device after 5 retry(ies)
.
07:37:02 PM: ACPI took 11 cycles
.
.
07:40:51 PM: we are done!

Review URL: http://codereview.chromium.org/3112038

4 years agoAdd test step that corrupts both firmware
Che-Liang Chiou [Mon, 23 Aug 2010 03:38:08 +0000 (11:38 +0800)]
Add test step that corrupts both firmware

BUG=chromium-os:1858
TEST=manual

This patch set implements a test step that invalidate both firmware.

Test Procedure:
1. Copy saft to a USB key
2. Boot test machine from USB key and execute saft_utility.py
3. saft_utility.py will reboot the machine and carry on subsequent tests
   automatically
4. Test result will be stored on USB key following the path
   /var/.fw_test/fw_test_log.txt

Test Result:
The following is a excerpt of /var/.fw_test/fw_test_log.txt:
...
02:15:41 PM: Executing cgpt show /dev/sda
02:15:41 PM: Executing rootdev
02:15:41 PM: Rebooted into state 1:1:0:0:3 on step 6
02:15:41 PM: calling <function <lambda> at 0x6f7bd87c>
02:15:41 PM: Corrupting firmware a
02:16:21 PM: Corrupting firmware b
02:17:00 PM: Executing reboot
09:21:35 PM: Executing cgpt show /dev/sda
09:21:35 PM: Executing rootdev
09:21:35 PM: Rebooted into state 1:0:0:1:3 on step 7
09:21:36 PM: calling <function <lambda> at 0x6f758c6c>
09:21:36 PM: Restoring firmware a
09:22:17 PM: Restoring firmware b
09:22:57 PM: Executing reboot
...
02:24:10 PM: we are done!

The SAFT successfully executes all test (while ignoring boot state
vector at step 7).

Review URL: http://codereview.chromium.org/3135004

4 years agoWrap up SAFT to provide default startup environment.
vbendeb [Mon, 16 Aug 2010 18:38:45 +0000 (11:38 -0700)]
Wrap up SAFT to provide default startup environment.

This CL does the following:

- introduce a shell script which can be used to start
  SAFT from a standard released image

- add code to retrieve the root public key from the
  firmware running at the beginning of the test (needed
  since the keys are not available in /etc/devkeys anymore)

- add a test case to test key retrieval code

Change-Id: I94d03d7bc2e37d6a43f84cccee2a6acb36d00c31

BUG=chromium-os:4801
TEST=see below:

- install the new generated ChromeOS image on a ZGA
- leave the flash drive plugged in
- restart the machine
- once it comes up place a new firmware image into
  /tmp/ZGA_010b.fd
- invoke SAFT as follows:
  sudo /usr/sbin/firmware/saft/runtests.sh /tmp/ZGA_010b.fd
- wait til the test finishes running

Expected results: right after the start the untitest success
reports are printed on the console. Then the machine resent several times. Once it settles, the following is found in /media/C-STATE/var/saft_log.txt:
localhost ~ # cat /media/C-STATE/var/saft_log.txt
11:27:26 AM: Automated firmware test log generated on Aug 13 2010
11:27:26 AM: Executing rootdev
11:27:26 AM: Original boot state 1:1:0:0:3
11:27:30 AM: Executing vbutil_firmware --verify /tmp/tmpOMbIY3/var/.fw_test/VBOOTA --signpubkey /tmp/tmpOMbIY3/var/.fw_test/root.pubkey  --fv /tmp/tmpOMbIY3/var/.fw_test/FVMAIN
11:27:31 AM: Executing vbutil_firmware --verify /tmp/tmpOMbIY3/var/.fw_test/VBOOTB --signpubkey /tmp/tmpOMbIY3/var/.fw_test/root.pubkey  --fv /tmp/tmpOMbIY3/var/.fw_test/FVMAINB
11:27:31 AM: Executing vbutil_firmware --verify /tmp/tmpOMbIY3/var/.fw_test/VBOOTA --signpubkey /tmp/tmpOMbIY3/var/.fw_test/root.pubkey  --fv /tmp/tmpOMbIY3/var/.fw_test/FVMAIN
11:27:31 AM: Executing vbutil_firmware --verify /tmp/tmpOMbIY3/var/.fw_test/VBOOTB --signpubkey /tmp/tmpOMbIY3/var/.fw_test/root.pubkey  --fv /tmp/tmpOMbIY3/var/.fw_test/FVMAINB
11:27:31 AM: Executing df /tmp/tmp.XhhtrzKqdA/usr/sbin/firmware/saft
11:27:31 AM: Executing blkid
11:27:31 AM: Executing rootdev
11:27:31 AM: Executing mount
11:27:31 AM: Handling //etc/init/fw_test.conf
11:27:31 AM: Executing rootdev
11:27:31 AM: Executing mount
11:27:31 AM: Handling /tmp/tmpF5QjlD/etc/init/fw_test.conf
11:27:31 AM: Executing rootdev
11:27:31 AM: Executing mount
11:27:31 AM: Handling /tmp/tmp.XhhtrzKqdA/etc/init/fw_test.conf
11:27:31 AM: program the new image
11:28:02 AM: restart
11:28:02 AM: Executing reboot
11:28:28 AM: Executing cgpt show /dev/sda
11:28:28 AM: Executing rootdev
11:28:28 AM: Rebooted into state 1:1:0:0:3 on step 0
11:28:28 AM: calling <bound method FirmwareTest.set_try_fw_b of <__main__.FirmwareTest object at 0x6f777dcc>>
11:28:28 AM: Requesting restart with FW B
11:28:28 AM: Executing reboot_mode --try_firmware_b=1
11:28:28 AM: Executing reboot
11:28:45 AM: Executing cgpt show /dev/sda
11:28:45 AM: Executing rootdev
11:28:45 AM: Rebooted into state 1:2:0:0:3 on step 1
11:28:45 AM: Executing reboot
11:29:02 AM: Executing cgpt show /dev/sda
11:29:02 AM: Executing rootdev
11:29:02 AM: Rebooted into state 1:1:0:0:3 on step 2
11:29:02 AM: calling <bound method FirmwareTest.corrupt_firmware of <__main__.FirmwareTest object at 0x6f6dedcc>> with parameter a
11:29:02 AM: Corrupting firmware a
11:29:44 AM: Executing reboot
11:30:02 AM: Executing cgpt show /dev/sda
11:30:02 AM: Executing rootdev
11:30:02 AM: Rebooted into state 1:2:0:0:3 on step 3
11:30:02 AM: calling <bound method FirmwareTest.restore_firmware of <__main__.FirmwareTest object at 0x6f732dcc>> with parameter a
11:30:02 AM: Restoring firmware a
11:30:44 AM: Executing reboot
11:31:00 AM: Executing cgpt show /dev/sda
11:31:00 AM: Executing rootdev
11:31:00 AM: Rebooted into state 1:1:0:0:3 on step 4
11:31:00 AM: calling <bound method FirmwareTest.corrupt_kernel of <__main__.FirmwareTest object at 0x6f6abdcc>> with parameter a
11:31:00 AM: Corrupting kernel a
11:31:00 AM: Executing dd if=/dev/sda2 of=/tmp/tmpqq9dif/var/.fw_test/kernel_header_dump bs=1 count=1
11:31:00 AM: Executing dd if=/tmp/tmpqq9dif/var/.fw_test/kernel_header_dump of=/dev/sda2 bs=1 count=1
11:31:00 AM: Executing reboot
11:31:17 AM: Executing cgpt show /dev/sda
11:31:17 AM: Executing rootdev
11:31:17 AM: Rebooted into state 1:1:0:0:5 on step 5
11:31:17 AM: calling <bound method FirmwareTest.restore_kernel of <__main__.FirmwareTest object at 0x6f7eddcc>> with parameter a
11:31:17 AM: restoring kernel a
11:31:17 AM: Executing dd if=/dev/sda2 of=/tmp/tmp5EgX7C/var/.fw_test/kernel_header_dump bs=1 count=1
11:31:17 AM: Executing dd if=/tmp/tmp5EgX7C/var/.fw_test/kernel_header_dump of=/dev/sda2 bs=1 count=1
11:31:17 AM: Executing reboot
11:31:35 AM: Executing cgpt show /dev/sda
11:31:35 AM: Executing rootdev
11:31:35 AM: Rebooted into state 1:1:0:0:3 on step 6
11:31:35 AM: calling <bound method FirmwareTest.revert_firmware of <__main__.FirmwareTest object at 0x6f658dcc>>
11:31:35 AM: restoring original firmware image
11:31:35 AM: Executing flashrom -w /tmp/tmpCDuPOS/var/.fw_test/flashrom.bak
11:32:08 AM: Executing reboot
11:32:26 AM: Executing cgpt show /dev/sda
11:32:26 AM: Executing rootdev
11:32:26 AM: Rebooted into state 1:1:0:0:3 on step 7
11:32:26 AM: Removing upstart scripts
11:32:26 AM: Executing df /tmp/sdb3/usr/sbin/firmware/saft
11:32:26 AM: Executing blkid
11:32:26 AM: Executing rootdev
11:32:26 AM: Executing mount
11:32:26 AM: Executing mount -o remount,rw /dev/root
11:32:26 AM: Handling //etc/init/fw_test.conf
11:32:26 AM: Executing rootdev
11:32:26 AM: Executing mount
11:32:26 AM: Executing mount /dev/sda5 /tmp/tmpQqJq_X
11:32:26 AM: Handling /tmp/tmpQqJq_X/etc/init/fw_test.conf
11:32:26 AM: Executing umount /tmp/tmpQqJq_X
11:32:28 AM: Executing rootdev
11:32:28 AM: Executing mount
11:32:28 AM: Handling /tmp/sdb3/etc/init/fw_test.conf
11:32:28 AM: we are done!

Review URL: http://codereview.chromium.org/3128006

4 years agoIntroduce Kernel corruption tests to SAFT.
vbendeb [Mon, 9 Aug 2010 21:26:08 +0000 (14:26 -0700)]
Introduce Kernel corruption tests to SAFT.

This CL introduces a module to support kernel modifications
in course of SAFT testing.

Some modifications were made to make unit testing easier
(namely, the chromeos_interface will now create its own
state directory if not given a path on init).

Another enhancement is to change the logic of determining
when to end the test. It makes it possible to have test
table entries with no actions associated with them.

While testing it was discovered that restoring firmware
partition A was not implemented properly. A fix is
incorporated in this CL (the image needs to be read from the
flashrom both before corrupting and restoring it).

A simple shell script is being introduced to facilitate
running the tests.

BUG=chromium-os:1994
BUG=chromium-os:4801

TEST=see below

All unit test and the actual SAFT were ran using
the new script, starting the script as follows:

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
localhost saft # ./runtests.sh ZGA_010b.fd
...
----------------------------------------------------------------------
Ran 3 tests in 0.050s

OK
..
----------------------------------------------------------------------
Ran 2 tests in 2.543s

OK
.
----------------------------------------------------------------------
Ran 1 test in 1.066s

OK
.
----------------------------------------------------------------------
Ran 1 test in 12.493s

OK
Executing df /tmp/sdb3/usr/bin/fw_test/saft
Executing mount
Executing mount /dev/sdb1 /tmp/tmphk_PLm
Executing cgpt show /dev/sda
Automated firmware test log generated on Aug 06 2010
Executing rootdev
Original boot state 1:1:0:0:3
Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTA --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAIN
Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTB --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAINB
Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTA --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAIN
Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTB --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAINB
Executing df /tmp/sdb3/usr/bin/fw_test/saft
Executing blkid
Executing rootdev
Executing mount
Handling //etc/init/fw_test.conf
Executing rootdev
Executing mount
Handling /tmp/sdb3/etc/init/fw_test.conf
Executing rootdev
Executing mount
Handling /tmp/tmpmQAuZn/etc/init/fw_test.conf
program the new image
restart
Executing reboot
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The SAFT ran to completion with the following present
in the log at the end of the test:
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
11:17:07 AM: Automated firmware test log generated on Aug 06 2010
11:17:07 AM: Executing rootdev
11:17:07 AM: Original boot state 1:1:0:0:3
11:17:12 AM: Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTA --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAIN
11:17:12 AM: Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTB --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAINB
11:17:12 AM: Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTA --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAIN
11:17:12 AM: Executing vbutil_firmware --verify /tmp/tmphk_PLm/var/.fw_test/VBOOTB --signpubkey /etc/keys/root_key.vbpubk  --fv /tmp/tmphk_PLm/var/.fw_test/FVMAINB
11:17:13 AM: Executing df /tmp/sdb3/usr/bin/fw_test/saft
11:17:13 AM: Executing blkid
11:17:13 AM: Executing rootdev
11:17:13 AM: Executing mount
11:17:13 AM: Handling //etc/init/fw_test.conf
11:17:13 AM: Executing rootdev
11:17:13 AM: Executing mount
11:17:13 AM: Handling /tmp/sdb3/etc/init/fw_test.conf
11:17:13 AM: Executing rootdev
11:17:13 AM: Executing mount
11:17:13 AM: Handling /tmp/tmpmQAuZn/etc/init/fw_test.conf
11:17:13 AM: program the new image
11:17:44 AM: restart
11:17:44 AM: Executing reboot
11:18:08 AM: Executing cgpt show /dev/sda
11:18:08 AM: Executing rootdev
11:18:08 AM: Rebooted into state 1:1:0:0:3 on step 0
11:18:08 AM: calling <bound method FirmwareTest.set_try_fw_b of <__main__.FirmwareTest object at 0x6f6f3c8c>>
11:18:08 AM: Requesting restart with FW B
11:18:08 AM: Executing reboot_mode --try_firmware_b=1
11:18:08 AM: Executing reboot
11:18:29 AM: Executing cgpt show /dev/sda
11:18:29 AM: Executing rootdev
11:18:29 AM: Rebooted into state 1:2:0:0:3 on step 1
11:18:29 AM: Executing reboot
11:18:49 AM: Executing cgpt show /dev/sda
11:18:49 AM: Executing rootdev
11:18:49 AM: Rebooted into state 1:1:0:0:3 on step 2
11:18:49 AM: calling <bound method FirmwareTest.corrupt_firmware of <__main__.FirmwareTest object at 0x6f7abc8c>> with parameter a
11:18:49 AM: Corrupting firmware a
11:19:32 AM: Executing reboot
11:19:51 AM: Executing cgpt show /dev/sda
11:19:51 AM: Executing rootdev
11:19:51 AM: Rebooted into state 1:2:0:0:3 on step 3
11:19:51 AM: calling <bound method FirmwareTest.restore_firmware of <__main__.FirmwareTest object at 0x6f758c8c>> with parameter a
11:19:51 AM: Restoring firmware a
11:20:34 AM: Executing reboot
11:20:54 AM: Executing cgpt show /dev/sda
11:20:54 AM: Executing rootdev
11:20:54 AM: Rebooted into state 1:1:0:0:3 on step 4
11:20:54 AM: calling <bound method FirmwareTest.corrupt_kernel of <__main__.FirmwareTest object at 0x6f638c8c>> with parameter a
11:20:54 AM: Corrupting kernel a
11:20:54 AM: Executing dd if=/dev/sda2 of=/tmp/tmpGLMiBa/var/.fw_test/kernel_header_dump bs=1 count=1
11:20:54 AM: Executing dd if=/tmp/tmpGLMiBa/var/.fw_test/kernel_header_dump of=/dev/sda2 bs=1 count=1
11:20:54 AM: Executing reboot
11:21:14 AM: Executing cgpt show /dev/sda
11:21:14 AM: Executing rootdev
11:21:14 AM: Rebooted into state 1:1:0:0:5 on step 5
11:21:14 AM: calling <bound method FirmwareTest.restore_kernel of <__main__.FirmwareTest object at 0x6f7c2c8c>> with parameter a
11:21:14 AM: restoring kernel a
11:21:14 AM: Executing dd if=/dev/sda2 of=/tmp/tmpnFSFDA/var/.fw_test/kernel_header_dump bs=1 count=1
11:21:14 AM: Executing dd if=/tmp/tmpnFSFDA/var/.fw_test/kernel_header_dump of=/dev/sda2 bs=1 count=1
11:21:14 AM: Executing reboot
11:21:38 AM: Executing cgpt show /dev/sda
11:21:38 AM: Executing rootdev
11:21:38 AM: Rebooted into state 1:1:0:0:3 on step 6
11:21:38 AM: calling <bound method FirmwareTest.revert_firmware of <__main__.FirmwareTest object at 0x6f63ac8c>>
11:21:38 AM: restoring original firmware image
11:21:38 AM: Executing flashrom -w /tmp/tmpJ8HUdC/var/.fw_test/flashrom.bak
11:22:12 AM: Executing reboot
11:22:32 AM: Executing cgpt show /dev/sda
11:22:32 AM: Executing rootdev
11:22:32 AM: Rebooted into state 1:1:0:0:3 on step 7
11:22:32 AM: Removing upstart scripts
11:22:32 AM: Executing df /tmp/sdb3/usr/bin/fw_test/saft
11:22:32 AM: Executing blkid
11:22:32 AM: Executing rootdev
11:22:32 AM: Executing mount
11:22:32 AM: Executing mount -o remount,rw /dev/root
11:22:32 AM: Handling //etc/init/fw_test.conf
11:22:32 AM: Executing rootdev
11:22:32 AM: Executing mount
11:22:32 AM: Handling /tmp/sdb3/etc/init/fw_test.conf
11:22:32 AM: Executing rootdev
11:22:33 AM: Executing mount
11:22:33 AM: Executing mount /dev/sda5 /tmp/tmp1QyQf5
11:22:33 AM: Handling /tmp/tmp1QyQf5/etc/init/fw_test.conf
11:22:33 AM: Executing umount /tmp/tmp1QyQf5
11:22:33 AM: we are done!

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Review URL: http://codereview.chromium.org/3086015

4 years agoInclude root fs information in the boot state vector.
vbendeb [Wed, 4 Aug 2010 19:09:15 +0000 (12:09 -0700)]
Include root fs information in the boot state vector.

This CL adds two elements to the boot vector describing the
ChromOS system boot state.

The second last element is number 1 or 0 (depending if the
root file system is mounted on a removable or non-removable
device, respectively). The last number is the digit of the
root fs device. The root FS device hardcoded to match the
device the kernel was loaded from, so the combinations of
the last two elements are as follows:

0:3 => non removable, kernel A
0:5 => non removable, kernel B
1:3 => removable, recovery kernel

BUG=BUG=chromium-os:4801
TEST=see http://codereview.chromium.org/2868098/show
for test decription

Review URL: http://codereview.chromium.org/3036039

4 years agoRefactor saft skeleton and add some unit tests.
vbendeb [Tue, 3 Aug 2010 19:05:50 +0000 (12:05 -0700)]
Refactor saft skeleton and add some unit tests.

This is a refactoring of the SAFT utility implementation
as discussed when the original submission
(http://codereview.chromium.org/3061012/show) was reviewed.

The refactoring involved the following:

- renaming saft_utility -> saft_utility.py (making unit
  testing more straightforward)
- separating test specific methods into a class
  saft_utility.py:FirmwareSelfTest
- separating OS related services into chromeos_interface.py
- adding a unittest for the new module

BUG=chromium-os:1994

Test=as described below:

At this time the user of this utility is expected to provide
the proper Python environment, namely add to PYTHONPATH the
location of the flashrom_util.py module (which currently is
in ../x86-generic).

The new firmware image used in testing is placed in ZGA_010b.fd in ./saft. Note that two out of three unit tests
can be run on either host or target, running on target make
sure that vbutil_firmware is in PATH.

1. (works both on host and on target)
localhost saft # ./test_chromeos_interface.py
..
----------------------------------------------------------------------
Ran 2 tests in 0.023s

OK

2.  (works both on host and on target)
localhost saft # PYTHONPATH=$(realpath ../x86-generic) ./test_flashrom_handler.py /etc/keys/root_key.vbpubk ZGA_010b.fd
..
----------------------------------------------------------------------
Ran 2 tests in 2.364s

OK

3.
localhost saft #  PYTHONPATH=$(realpath ../x86-generic) ./test_saft_utility.py
.
----------------------------------------------------------------------
Ran 1 test in 1.369s

OK

4.
PYTHONPATH=$(realpath ../x86-generic) ./saft_utility.py  --pub_ke=/etc/keys/root_key.vbpubk --ima=./ZGA_010b.fd

The target starts executing the SAFT, restarts a few times
in the process, at the end the following is stored in the log file in /var/.fw_test/fw_test_log.txt on the first
partition of the flash drive:

localhost saft # df  /dev/sdb1
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sdb1              1032088     43728    935932   5% /tmp/tmpMpCsNj

localhost saft # cat /tmp/tmpMpCsNj/var/.fw_test/fw_test_log.txt
04:04:26 PM: Automated firmware test log generated on Aug 02 2010
04:04:26 PM: Original boot state 1:1:0
04:04:32 PM: Executing df /tmp/sdb3/usr/bin/fw_test/saft
04:04:32 PM: Executing blkid
04:04:32 PM: Executing rootdev
04:04:32 PM: Executing mount
04:04:32 PM: Handling //etc/init/fw_test.conf
04:04:32 PM: Executing rootdev
04:04:32 PM: Executing mount
04:04:32 PM: Handling /tmp/sdb3/etc/init/fw_test.conf
04:04:32 PM: Executing rootdev
04:04:32 PM: Executing mount
04:04:32 PM: Executing mount /dev/sda5 /tmp/tmpiNgeWl
04:04:32 PM: Handling /tmp/tmpiNgeWl/etc/init/fw_test.conf
04:04:32 PM: Executing umount /tmp/tmpiNgeWl
04:04:33 PM: program the new image
04:05:04 PM: restart
04:05:04 PM: Executing reboot
04:05:44 PM: Rebooted into state 1:1:0 on step 0
04:05:44 PM: calling <bound method FirmwareSelfTest.set_try_fw_b of <__main__.FirmwareSelfTest object at 0x6f6d688c>>
04:05:44 PM: Requesting restart with FW B
04:05:44 PM: Executing reboot_mode --try_firmware_b=1
04:05:44 PM: Executing reboot
04:06:08 PM: Rebooted into state 1:2:0 on step 1
04:06:09 PM: calling <function <lambda> at 0x6f637e64>
04:06:09 PM: Executing reboot
04:06:44 PM: Rebooted into state 1:1:0 on step 2
04:06:44 PM: calling <bound method FirmwareSelfTest.corrupt_firmware of <__main__.FirmwareSelfTest object at 0x6f6b488c>> with parameter a
04:06:44 PM: Corrupting firmware a
04:07:24 PM: Executing reboot
04:07:45 PM: Rebooted into state 1:2:0 on step 3
04:07:45 PM: calling <bound method FirmwareSelfTest.restore_firmware of <__main__.FirmwareSelfTest object at 0x6f71788c>>
04:07:45 PM: Restoring to original firmware
04:07:45 PM: Executing flashrom -w /tmp/tmpChOG3T/var/.fw_test/flashrom.bak
04:08:17 PM: Executing reboot
04:08:35 PM: Rebooted into state 1:1:0 on step 4
04:08:36 PM: Removing upstart scripts
04:08:36 PM: Executing df /tmp/sdb3/usr/bin/fw_test/saft
04:08:36 PM: Executing blkid
04:08:36 PM: Executing rootdev
04:08:36 PM: Executing mount
04:08:36 PM: Executing mount -o remount,rw /dev/root
04:08:36 PM: Handling //etc/init/fw_test.conf
04:08:36 PM: Executing rootdev
04:08:36 PM: Executing mount
04:08:36 PM: Handling /tmp/sdb3/etc/init/fw_test.conf
04:08:36 PM: Executing rootdev
04:08:36 PM: Executing mount
04:08:36 PM: Executing mount /dev/sda5 /tmp/tmp4SJguO
04:08:36 PM: Handling /tmp/tmp4SJguO/etc/init/fw_test.conf
04:08:36 PM: Executing umount /tmp/tmp4SJguO
04:08:37 PM: we are done!

Review URL: http://codereview.chromium.org/2868098

4 years agoFixed indentation size in SAFT source code.
vbendeb [Sat, 31 Jul 2010 01:51:32 +0000 (18:51 -0700)]
Fixed indentation size in SAFT source code.

This is a result of passing the source code through a 'Python
beautifier' and then some manual tweaking. All tests pass
as described.

BUG=chromium-os:1994

TEST= all unit tests and actual testing on target pass
as described in http://codereview.chromium.org/3061012/show

Review URL: http://codereview.chromium.org/3046037

4 years agoReplace function names to comply with coding style.
vbendeb [Sat, 31 Jul 2010 00:12:19 +0000 (17:12 -0700)]
Replace function names to comply with coding style.

This was accomplished by automated processing of the source
files using a custom Python script.

BUG=chromium-os:1994

TEST= all unit tests and actual testing on target pass
as described in http://codereview.chromium.org/3061012/show

Review URL: http://codereview.chromium.org/2870078

4 years agoFirst draft SAFT implementation.
vbendeb [Wed, 28 Jul 2010 01:03:24 +0000 (18:03 -0700)]
First draft SAFT implementation.

This CL introduces the semiautomated firmware test (SAFT)
framework, as described in
https://docs.google.com/a/google.com/document/edit?id=1E1b_73IQjSiRsznSh_YDhv5i3mn__yDeZIGhXwY8rhA&hl=en#

The required parameters of ./saft_utility are
 --image_file - name of the file containing the firmware
   image which needs to be tested
 --pub_key - name of the file contaning public key block
   used to verify both currently running and new firmware
   images

saft_utility must run off the flash stick. On startup
in verifies integrity of both current and new FW images,
prepares the environment, and creates the upstart script
(/etc/init/fw_test.conf) on three partitions: both root
partitions on the hard drive/SSD and the recovery partition
on the flash stick.

Then the test restarts the machine.

The upstart script makes sure that saft_utility is invoked
after each reboot with the --next_step command line
parameter.

The expected test states are enumerated in
saft_utility:test_state_sequence table. On each step the
test verifies the proper state on the machine, performs
the necessary action and restarts the machine.

The test ends when there is no action in the current record
of the state machine table or in case an error happens.

The test progress is accumulated in the log file stored on
the stateful partition on the flash stick (in
/var/.fw_test/fw_test_log.txt)

BUG=chromium-os:1994

Test=see below

1. Unit test ran on the target:

localhost fw_test # ./test_saft_utility.py
...
----------------------------------------------------------------------
Ran 3 tests in 0.894s

OK
localhost fw_test # cd saft

localhost saft # ./test_flashrom_handler.py /etc/keys/root_key.vbpubk
..
----------------------------------------------------------------------
Ran 2 tests in 11.950s

OK
localhost saft #

2. The actual SAFT ran on the target:

Place the fwirmware/ directory contents on a flash stick, place the new flashrom image into a file in the local directory (./ZGA_010b.fd) and run the test:

./saft_utility  --pub_ke=/etc/keys/root_key.vbpubk --ima=./ZGA_010b.fd

The test causes the machine to restart several times, in the end the following is seen in the log file (/var/.fw_test/fw_test_log.txt on the first partition of the flash stick):

12:51:40 PM: Automated firmware test log generated on Jul 25 2010
12:51:40 PM: Original boot state 1:1:0
12:51:46 PM: Executing df /tmp/sdb3/usr/bin/fw_test
12:51:46 PM: Executing blkid
12:51:46 PM: Executing rootdev
12:51:46 PM: Executing mount
12:51:46 PM: Handling //etc/init/fw_test.conf
12:51:46 PM: Executing rootdev
12:51:46 PM: Executing mount
12:51:46 PM: Handling /tmp/sdb3/etc/init/fw_test.conf
12:51:46 PM: Executing rootdev
12:51:46 PM: Executing mount
12:51:46 PM: Executing mount /dev/sda5 /tmp/tmpuC0YjA
12:51:46 PM: Handling /tmp/tmpuC0YjA/etc/init/fw_test.conf
12:51:46 PM: Executing umount /tmp/tmpuC0YjA
12:51:46 PM: program the new image
12:52:18 PM: restart
12:52:18 PM: Executing reboot
12:52:44 PM: Rebooted into state 1:1:0 on step 0
12:52:44 PM: calling <function SetTryFwB at 0x6f744fb4>
12:52:44 PM: Requesting restart with FW B
12:52:44 PM: Executing reboot_mode --try_firmware_b=1
12:52:44 PM: Executing reboot
12:53:07 PM: Rebooted into state 1:2:0 on step 1
12:53:08 PM: calling <function <lambda> at 0x6f76d614>
12:53:08 PM: Executing reboot
12:53:28 PM: Rebooted into state 1:1:0 on step 2
12:53:29 PM: calling <function CorruptFirmware at 0x6f74717c> with parameter a
12:54:05 PM: Executing reboot
12:54:25 PM: Rebooted into state 1:2:0 on step 3
12:54:25 PM: calling <function RestoreFirmware at 0x6f6c70d4>
12:54:25 PM: Restoring to original firmware
12:54:25 PM: Executing flashrom -w /tmp/tmp_dbSPi/var/.fw_test/flashrom.bak
12:54:57 PM: Executing reboot
12:55:16 PM: Rebooted into state 1:1:0 on step 4
12:55:17 PM: Removing upstart scripts
12:55:17 PM: Executing df /tmp/sdb3/usr/bin/fw_test
12:55:17 PM: Executing blkid
12:55:17 PM: Executing rootdev
12:55:17 PM: Executing mount
12:55:17 PM: Executing mount -o remount,rw /dev/root
12:55:17 PM: Handling //etc/init/fw_test.conf
12:55:17 PM: Executing rootdev
12:55:17 PM: Executing mount
12:55:17 PM: Handling /tmp/sdb3/etc/init/fw_test.conf
12:55:17 PM: Executing rootdev
12:55:17 PM: Executing mount
12:55:17 PM: Executing mount /dev/sda5 /tmp/tmpgfrUqx
12:55:17 PM: Handling /tmp/tmpgfrUqx/etc/init/fw_test.conf
12:55:17 PM: Executing umount /tmp/tmpgfrUqx
12:55:18 PM: we are done!

Review URL: http://codereview.chromium.org/3061012

4 years agoUtility to support SAFT and a unit test for it.
vbendeb [Sat, 24 Jul 2010 00:33:13 +0000 (17:33 -0700)]
Utility to support SAFT and a unit test for it.

saft/flash_handler.py is a helper utility used by the SAFT\
(semi automated firmware test).

It provides the ability to load a firmware file (or read it
from the hardware when running on the target), verify the
file's integrity and modify certain section of the file to
introduce verification errors.

safe/test_flashrom_handler.py is a unit test for this
utility. It can run on host (in native and chroot
environments) and on the target.

x86-generic/flashrom_util.py is modified to suppress the
console output generated by the 'flashrom' utility when
operating on the target.

BUG=chromium-os:1994

TEST=See below

This is a sample unit test invocation case (with firmware
image placed in file zgax64.fd in the local directory):

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
(saft $) PATH=${PATH}:../../vboot_reference/build/utility \
 ./test_flashrom_handler.py \
 ../../vboot_reference/tests/devkeys/root_key.vbpubk \
 zgax64.fd
----------------------------------------------------------------------
Ran 2 tests in 0.643s

OK
(saft $)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The

Review URL: http://codereview.chromium.org/2834065