| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
| |
* Just make new "bmp" files as necessary
BUG=chrome-os-partner:2558
TEST=runs as expected
Change-Id: I3046630ea3e3f0a40429bb63a986c6044b83c6a6
Review URL: http://codereview.chromium.org/6623008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I35158810184be03f18d98893e4dd640088384579
BUG=12904
TEST=manual
crossystem fwb_tries=1
crossystem fwb_tries?1 && echo YES || echo NO --> YES
crossystem fwb_tries?0x01 && echo YES || echo NO --> YES
crossystem fwb_tries?0 && echo YES || echo NO --> NO
crossystem fwb_tries=0
crossystem fwb_tries?0 && echo YES || echo NO --> YES
crossystem fwb_tries?1 && echo YES || echo NO --> NO
crossystem fwb_tries?0x01 && echo YES || echo NO --> NO
crossystem ecfw_act --> RW (if it's not, change RW to RO in the tests below)
crossystem ecfw_act?RW && echo YES || echo NO --> YES
crossystem ecfw_act?BOB && echo YES || echo NO --> NO
For the following tests, boot Alex with dev switch on and fwb_tries=1
Expected output of `crossystem mainfw_type mainfw_act cros_debug` under each of the following scenarios:
* Neither "cros_debug" nor" cros_nodebug" in kernel command line: normal B 1
* Kernel command line changed to include "cros_nodebug": normal B 0
* Kernel command line changed to include "cros_nodebugg": normal B 1
* Kernel command line changed to include "ccros_nodebug": normal B 1
Review URL: http://codereview.chromium.org/6665005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Kernel body load address was hard-coded to CROS_32BIT_ENTRY_ADDR, which
could be an invalid/unavailable memory location on other platforms.
This CL adds an option for setting the load address, and it is default to
CROS_32BIT_ENTRY_ADDR to maintain backward-compatibility.
BUG=chromium-os:1304
TEST=emerge vboot_reference successfully
Review URL: http://codereview.chromium.org/6651022
Change-Id: I158cfce10ac59bd019bca41cb061039d0085d5cc
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ie62364a87f7f144ee647054d2a9ef83522cdbe7d
BUG=12904
TEST=manual
Expected output of `crossystem mainfw_type cros_debug` under each of the following scenarios:
* Boot Alex with dev switch off: normal 0
* Boot Alex with dev switch on (and dev firmware): developer 1
* Boot Alex with dev switch on (and normal firmware): normal 1
* Boot Alex with recovery firmware: recovery 0
* Boot Alex with dev switch off, then turn the dev switch on after booting: normal 0
* Boot Cr-48 with dev switch off: normal 0
* Boot Cr-48 with dev switch on: developer 1
* Boot Cr-48 with recovery firmware: recovery 0
* Boot Alex with dev switch off and kernel command line changed to include "cros_debug": normal 1
* Boot Alex with dev switch off and kernel command line changed to include "cros_debugg": normal 0
* Boot Alex with dev switch off and kernel command line changed to include "ccros_debug": normal 0
* Boot H2O BIOS with kernel command line changed to include "cros_debug": nonchrome 1
* Boot H2O BIOS with kernel command line changed to include "cros_debugg": nonchrome 0
* Boot H2O BIOS with kernel command line changed to include "ccros_debug": nonchrome 0
Review URL: http://codereview.chromium.org/6659021
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
B is being run. This change also passes the GBB directly into LoadFirmware() and LoadKernel().
Change-Id: I976c11c82c3d665a4feb88226e919f16c2440f60
BUG=chrome-os-partner:1657
TEST=manual - see below
make && make runtests
Then test verifying a test image in both dev mode (-b1, no key specified) and recovery mode (key specified)
build/utility/load_kernel_test -b1 ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin
build/utility/load_kernel_test ~/b/USB_images/0.11.224.0-alex/chromiumos_test_image.bin tests/devkeys/recovery_key.vbpubk
And make sure the firmware with this change actually boots to USB and SSD.
NOTE: u-boot-next needs to change to work with this change. will attempt a follow-up CL with that change
Review URL: http://codereview.chromium.org/6626045
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I879c18cc139f8a02bcaa6eb80437eaf836a5e851
BUG=chrome-os-partner:2597
TEST=manual
install pvt-signed image
flip dev switch on and boot
install dev-signed firmware
reboot
reboot
sudo bash
stop tcsd
tpmc read 0x1008 0x0d
bytes 6-10 should be 1 0 1 0, not FF FF FF FF
Review URL: http://codereview.chromium.org/6626020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Make dev_debug_vboot look first for the new section names, then the old ones.
Change-Id: I723f022bbbb23257c7c57db9543d7c35f524f95d
BUG=chromium-os:12611
TEST=manual
Rerun the steps that reproduce the problem as reported in the initial bug
report. You should see much more information.
Review URL: http://codereview.chromium.org/6621003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
prebuilts.
make_dev_firmware should trust system firmware blobs instead of using its own
prebuilt binaries.
BUG=chromium-os:12400
TEST=1. make a build with .49+ BIOS, and create the firmware updater
2. install the new BIOS, turn on developer switch and reboot
3. an ugly "DEV" screen (in .49) is shown on screen
4. run the new make_dev_firmware.sh
5. reboot. seeing the ugly DEV instead of the prebuilt blue screen
(verified successfully)
Change-Id: If75d2821170649fa869db6a82d879b697f7588e6
Review URL: http://codereview.chromium.org/6614006
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:2558
TEST=some files are generated
Change-Id: I6a69bce20d626e9a273711db099d7ec5c3b08686
Review URL: http://codereview.chromium.org/6598091
|
|
|
|
|
|
|
|
|
| |
Change-Id: I9d4fefdd128c087f9495055dbf3b6aa63ac62fd2
BUG=none
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6610023
|
|
|
|
|
|
|
|
|
|
|
| |
(somehow that never got committed)
Change-Id: I304e594066c5dd72fc7cf37d31e27b1096ae1a38
BUG=12282
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6610019
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ia0e14a768d6ba6dadd520cd7c3961759771dab08
BUG=chromium-os:12643
TEST=none
Review URL: http://codereview.chromium.org/6588139
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I743060a27ab9d3caeeadde295883a18bdd864a1f
BUG=chrome-os-partner:2558
TEST=none
Documentation change only. No tests needed.
Review URL: http://codereview.chromium.org/6588127
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also re-factor the key generation script to its own directory, including wrappers for generating key pairs and keyblocks without needing to start keyset generation process from scratch. (Useful for generating new kernel keyblocks, and for retroactively adding new keys to an existing keyset - as in this case).
Finally, change hard coded algorithm ids and keyblock modes to bash variables, for each changes and telling keyset configuration from a glance.
BUG=chrome-os-partner:2218
TEST=manually tried the following:
1) Generating an entire new keyset.
2) Generating a new key pair and creating a keyblock from an existing key (for generating dev firmware keyblock for existing PVT keysets)
3) Firmware signing via sign_official_build.sh of an image with a firmware payload/
Change-Id: I4e9bb96ac7e5fe4cc0d95af6162ad6d37bbd4bda
Review URL: http://codereview.chromium.org/6594131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I0b364103e3b93d7fd3deebd72b4cb58239729aeb
BUG=chrome-os-partner:416
TEST=manual
Be sure you're running BIOS 49 or later, including the read-only portion.
Follow the instructions in
src/platform/vboot_reference/scripts/newbitmaps/{README,HWID.txt}
Review URL: http://codereview.chromium.org/6588093
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix try_b processing
And move key block flags check up in LoadFirmware(), which speeds up
boot when the dev switch is off because it doesn't do a signature
check and then throw it out.
BUG=12282
TEST=build firmware, try by hand
Review URL: http://codereview.chromium.org/6596081
Change-Id: I10474e9e0ae324906dfe02a351347d04ce847f67
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add bitmap_viewer program (to run OUTSIDE of chroot) and example bitmaps (to
be replaced by the REAL bitmaps for each platform).
BUG=chromium-os:10949
TEST=none
These are just nonessential tools and examples. No regression testing needed.
Change-Id: I7f9aab30809251e4c62d71bfa73293d0b4d97196
Review URL: http://codereview.chromium.org/6598046
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ifa5cc3bd8367a258fb720162572f450a1be99c03
BUG=none
TEST=manual
crossystem kern_nv=0x12345678
crossystem kern_nv
Review URL: http://codereview.chromium.org/6602040
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I19f402904978581eb5ca990ffbdf2f762b48c217
BUG=12282
TEST=make H2C firmware and verify using crossystem utility
(set fwb_tries, reboot, verify that mainfw_act is B)
Review URL: http://codereview.chromium.org/6597018
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ib8018bfe29eed50766c699d832efe4f1afcabb1a
BUG=none
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6597015
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) Did firmware attempt RW slot B before slot A?
2) Did firmware check the kernel keyblock signature, or just its hash?
Added crossystem support as well.
BUG=chrome-os-partner:1657
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6597011
Change-Id: I0d743ae87cedd938ba988170793717d3fdbd8ce9
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I3f158115c8514bda0b271674870d68717c4816e6
BUG=12282
TEST=manual
crossystem fwb_tries=0 && crossystem fwb_tries
This should print 0 on both BIOSes.
crossystem fwb_tries=6 && crossystem fwb_tries
This should print 1 on an older BIOS and 6 on a new BIOS (0050+)
Then reboot and run
crossystem mainfw_act
This should print 'B', since fwb_tries was non-zero.
Review URL: http://codereview.chromium.org/6576059
|
|
|
|
|
|
|
|
|
| |
Change-Id: I37b42088f94ee838e0d82f155ab0674323d859fc
BUG=none
TEST=manual (run crossystem and see that it prints hex values for savedmem_base and fmap_base)
Review URL: http://codereview.chromium.org/6582004
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: If2106cbde445edc0970862a06d3837d2e466d9ef
BUG=chrome-os-partner:2487
TEST=manual
From a root shell, type: crossystem fmap_base
Should match the contents of /sys/devices/platform/chromeos_acpi/FMAP
(note that you need a new BIOS >0049 to get one that supports FMAP)
Review URL: http://codereview.chromium.org/6580037
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The existing keys are kept the same, so that old dev kernels and
firmware remain compatible with new kernels and firmware.
Change-Id: I4177d1868904a477d79b9f2e6de88ed756ed57b4
BUG=chrome-os-partner:2218
TEST=manual:
Build firmware with new keys.
Boot with dev switch on.
Run 'crossystem mainfw_act mainfw_type'.
Should see "A developer"
Boot with dev switch off.
Run 'crossystem mainfw_act mainfw_type'.
Should see "B normal"
Review URL: http://codereview.chromium.org/6580035
|
|
|
|
|
|
|
|
|
| |
Change-Id: I6435a4b0f40a571f8e44830e6d32f42d2d3213ff
BUG=none
TEST=manually tested with a signed image and comparing the kernel, and rootfs partitions.
Review URL: http://codereview.chromium.org/6533015
|
|
|
|
|
|
|
|
|
|
|
| |
crossystem now covers all data currently provided by chromeos_acpi.
Change-Id: I3364c4d65ddf63fe788d3d9c1e9d05e64be22856
BUG=chromium-os:12282
TEST=manual - test on Cr-48 and compare with ACPI values
Review URL: http://codereview.chromium.org/6557001
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to run test cases in both Linux user mode and u-boot command
mode. The API header tlcl.h must be accessed by both ebuilds.
Change-Id: Ic027dc118f26666b88bf54c511e2455a55e4eb8f
BUG=chromium-os:10497
TEST=emerge vboot_reference-firmware successfully
Review URL: http://codereview.chromium.org/6469089
|
|
|
|
|
|
|
|
|
| |
BUG=12282
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6469059
Change-Id: I912b53ae33d65305353a747cc0bdd2b1ea62a04f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When --arch flag is not x86, x86-only operations in pack mode are
turned off so that we can reuse vbutil_kernel to generate kernel partition
images for other targets, such as arm.
See CL:6538014 for its application.
BUG=chromium-os:3790
TEST=Run "emerge vboot_reference" successfully
Review URL: http://codereview.chromium.org/6538015
Change-Id: If45cf092d1ecc762fad6fda1aa57d23e26a7e47a
|
|
|
|
|
|
|
|
|
| |
Change-Id: If51dd4f7d9e84f2f0f30506a3a9c354bc6a4b07b
BUG=chromium-os:7388
TEST=manually tested on an image, verified that the permissions on the copied key were correct.
Review URL: http://codereview.chromium.org/6543027
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crossystem can now be used in place of reboot_mode.
BUG=12327
TEST=manual by comparing with the old reboot_mode utility
crossystem recovery_request=1
reboot_mode
crossystem dbg_reset=1
reboot_mode
crossystem fwb_tries=1
reboot_mode
crossystem recovery_request=0
reboot_mode
crossystem dbg_reset=0
reboot_mode
crossystem fwb_tries=0
reboot_mode
Review URL: http://codereview.chromium.org/6538066
Change-Id: Ifde661d4621129d52e757654d85e386e65f90df5
|
|
|
|
|
|
|
|
|
|
|
| |
e.g. ro and cros_secure
Change-Id: Ic6dd5a883646103b32cfb58712df7d34725c5f62
BUG=chromium-os:12285
TEST=Ran ./ensure_secure_kernelparams.sh chromiumos_base_image.bin on today's mario build which had repro'd the bug
Review URL: http://codereview.chromium.org/6538034
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:12282
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6532040
Change-Id: I57099de54ed56aa722f1944568bbb58b71b14379
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:11490
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ia887fc1aa1de873c6da6c04995bc0a9ad6b364aa
Review URL: http://codereview.chromium.org/6541001
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:12161
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ic7708474ce7009744c9f12154d1967bdae8e55d2
Review URL: http://codereview.chromium.org/6534025
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that both the current and boot settings are incorrect as reported
by the BIOS. This fixes both.
Change-Id: Iebd2b4ac91232444e538f6e2763a22cb227f2e4f
BUG=chrome-os-partner:2078
TEST=manual
Run crossystem on Mario and Alex with WP enabled, disabled and check
Verify true hardware WP status by doing:
flashrom --wp-enable
flashrom --wp-status
flashrom --wp-disable
flashrom --wp-status
On a system with hardware WP enabled, the disable step should fail and write
protect will still report enabled.
Review URL: http://codereview.chromium.org/6531035
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures that equivalent yaml files produce identical bmpblock binaries.
BUG=chromium-os:12158
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Change-Id: Ic8103ff90e57034d72fb3920a6c198c77768f162
Review URL: http://codereview.chromium.org/6533012
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=emerge-${BOARD} vboot_reference
TBR=rspangler@chromium.org
Change-Id: I4cfec460fbc036d16f80b81cf8582209abb5945a
|
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:1302
TEST=emerge vboot_reference &&
(load_firmware_test firmware_image.bin | grep LOAD_FIRMWARE_SUCCESS)
Review URL: http://codereview.chromium.org/6465018
Change-Id: I85fce39aaf4abb50bd70d126ac8c7cb892a7857b
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
LZMA has better compression ratio and is also supported in u-boot already.
ARM BIOS will use LZMA to compress BMP files.
BUG=chromium-os:11017
TEST=manual
$ make
$ make runbmptests
Change-Id: I6b791e3284b65eb3085b0de548bd241eab2ee598
Review URL: http://codereview.chromium.org/6523019
|
|
|
|
|
|
|
|
|
| |
Change-Id: I1c82426854d48f23bdf7c08ae5e37cd965a08089
BUG=chrome-os-partner:1991
TEST=Run the corresponding test scripts with these config files. Works.
Review URL: http://codereview.chromium.org/6480121
|
|
|
|
|
|
|
|
|
| |
Change-Id: I4e185a5d08dee381d516683e4eda6f3404b6a060
BUG=chrome-os-partner:1991
TEST=none
Review URL: http://codereview.chromium.org/6526022
|
|
|
|
|
|
|
|
|
|
|
| |
New location is user-recovery-tools.git
BUG=none
TEST=none
TBR=scottz@chromium.org
Change-Id: I6a07307d7d03fc1111c0d378290ed72f32792982
|
|
|
|
|
|
|
|
|
| |
Change-Id: I5a42ba017974b3d591abc574ef7b9b7c9ac579e8
BUG=chrome-os-partner:1824
TEST=make && make runtests
Review URL: http://codereview.chromium.org/6462010
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This lets bmpbklk_utility generate BMPBLOCKs with EFIv1-compressed bitmaps.
It also adds the ability to display or unpack BMPBLOCK blobs.
The compression/decompression routines come from the tianocore EDK on
sourceforge and are written in C, so now there's a mix of C and C++, but it
works just fine.
BUG=chromium-os:11491
TEST=manual
cd src/platform/vboot_reference
make
make runbmptests
Review URL: http://codereview.chromium.org/6508006
Change-Id: Ie05e1a3fd42f4694447c8c440b2432af4ac0f601
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:11017
TEST=use RLE BMP files as input to run bmpblk_utility
Change-Id: I2398d1c6cb9d5f90a85d8bfcab0af6e41a52b022
Review URL: http://codereview.chromium.org/6489026
|
|
|
|
|
|
|
|
|
| |
BUG=chrome-os-partner:2316
TEST=tried signing firmware with old style and new style fmap and verified that it works.
Change-Id: I9076fe60308bdb787440486d592c9d5e72602199
Review URL: http://codereview.chromium.org/6516004
|
|
|
|
|
|
|
|
|
| |
BUG=chromium-os:11488
TEST=none
Change-Id: I6ee493037da5746d2db6e840ac6590dd12f37cfe
Review URL: http://codereview.chromium.org/6482001
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Old: Trim input file when it is larger than specified firmware section length
New: Raise exception when such thing happens
BUG=none
TEST=manual
$ cat > config <<EOF
OUTPUT='/dev/null'
SIZE=1024
ENTRIES = [
EntryBlob(offset=0, length=1, name='', flags=0, path='../LICENSE')
]
EOF
$ ./pack_firmware_image config
Traceback (most recent call last):
File "./pack_firmware_image", line 266, in <module>
main()
File "./pack_firmware_image", line 260, in main
pack_firmware_image(env['ENTRIES'], env['OUTPUT'], env['SIZE'])
File "./pack_firmware_image", line 227, in pack_firmware_image
entry.Pack(firmware_image, entries)
File "./pack_firmware_image", line 133, in Pack
raise PackError('blob too large: %d > %d' % (size, self.length))
__main__.PackError: blob too large: 1566 > 1
Review URL: http://codereview.chromium.org/6459017
Change-Id: I0b0fb8af37fc3ac055164c362278f32f93944ab4
|