summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Refactor of cgpt tool for 32->64 autoupdate work.release-R18-1660.BJay Srinivasan2012-01-3016-1102/+1312
| | | | | | | | | | | | | | | | | | This check-in splits the cgpt into two layers. The top layer (cmd_* files) does the command-line parsing and the bottom layer (cgpt_* files) does the actual cgpt work. This is done so that the bottom layer can be reused for the monolithic C++ post-installer code that will be done in subsequent checkins. BUG=chromium-os:25374 TEST=Tested with existing cgpt unit tests as well as running the cgpt commands manually. Change-Id: I69a31eb3e867a1430cac9a694581331368aa7bb4 Reviewed-on: https://gerrit.chromium.org/gerrit/14940 Reviewed-by: Jay Srinivasan <jaysri@chromium.org> Tested-by: Jay Srinivasan <jaysri@chromium.org> Commit-Ready: Jay Srinivasan <jaysri@chromium.org>
* Bah. Fix the test, too.Bill Richardson2012-01-271-1/+1
| | | | | | | | | | BUG=chrome-os-partner:7775 TEST=none Change-Id: Id1409808b69f5c8f5b5e2244bb8bf6c7591cba0c Reviewed-on: https://gerrit.chromium.org/gerrit/14968 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Oops. Must still distinguish "no disks" from "no valid disks".Bill Richardson2012-01-271-1/+0
| | | | | | | | | | | | | | | | | | The fix for chrome-os-partner:7715 introduced a new bug. This fixes that. BUG=chrome-os-partner:7775 TEST=manual Boot into recovery mode. Insert invalid USB. You should see the YUCK screen. Change-Id: I868287eecd34bb0c48127bee04f573b418f5945c Reviewed-on: https://gerrit.chromium.org/gerrit/14963 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* remove.txt no longer mentions USB and SD cards explicitlyBill Richardson2012-01-2645-43/+43
| | | | | | | | | | | | | BUG=chrome-os-partner:6953 TEST=none Just changing the source, so nothing to test here. Change-Id: Ic09c45d49ea9e5acd4b57e281de73a4ca0a3af81 Reviewed-on: https://gerrit.chromium.org/gerrit/14915 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Bundle up the utilities methods used in dump_kernel_config andDon Garrett2012-01-265-102/+142
| | | | | | | | | | | | | | | export them as a library to be used by post installer programs. A matching change to vboot_reference-9999.ebuild is also required. TEST=Built, verified library symbols with nm on x86-mario, amd64-generic. BUG=chromium-os:25381 Change-Id: Icb23838a8cd804e0c66718c6d4d60f639ee6b72f Reviewed-on: https://gerrit.chromium.org/gerrit/14770 Commit-Ready: Don Garrett <dgarrett@chromium.org> Reviewed-by: Don Garrett <dgarrett@chromium.org> Tested-by: Don Garrett <dgarrett@chromium.org>
* Make VbTryLoadKernel() go to recovery when no valid disks are foundBill Richardson2012-01-253-3/+329
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, it was going to recovery only when no disks existed. That didn't catch the case where disks exist but none of them are usable. BUG=chrome-os-partner:7715 TEST=manual I've added a test specifically for this, so just make make runtests should verify it. To test on actual hardware, find a disk or USB drive that has something other than 512 bytes per LBA, and try it. It won't be bootable, but using it shouldn't hang the system or cause weird behavior. Once in recovery, press TAB, and you should see the reason code VBNV_RECOVERY_RW_NO_DISK Change-Id: I475ddd01e13fa806025a2107c260c030d098a17e Reviewed-on: https://gerrit.chromium.org/gerrit/14816 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Be aggressive in saving locale to nvram.Bill Richardson2012-01-242-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On x86 platforms, the power button and lid switch events have to be handled by coreboot SMM code, because it needs to interact with the southbridge and/or EC, and U-Boot doesn't have a way to do that. Once the kernel takes over, it sends an SMI to that code which tells it to start delivering ACPI events instead of whatever pre-ACPI handling it has been doing. U-Boot doesn't have any code to handle either case, and adding it would either be a major undertaking (adding ACPI support to U-Boot!), or would require creating yet another special-purpose interface just for our U-Boot (yuck). It's much simpler to just make vboot_reference be more aggressive about writing to the nvram for this one case where it matters. OTOH, ARM will need U-Boot to handle the lid switch and power button via GPIOs since it uses only U-Boot and has no SMI handler. This change isn't necessary for ARM, but shouldn't hurt either. BUG=chrome-os-partner:7689 TEST=manual 1. Boot to dev-mode screen or recovery screen. 2. Press arrow keys to change locale. 3. Power off (press power button or yank A/C & battery) 4. Power on again. The BIOS screen locale should still be set to your last choice before powering off. Change-Id: I9008811c3be71de47ff1c6899e81955cf0560a52 Reviewed-on: https://gerrit.chromium.org/gerrit/14721 Tested-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Remove debug messages from VbAudioLooping() - too noisy.Bill Richardson2012-01-221-9/+0
| | | | | | | | | | | | | | | | | The VBDEBUG() is logged even for production builds (visible as /sys/firmware/log once the system boots). Too many messages clutter it up. BUG=chrome-os-partner:7669 TEST=manual Boot in dev-mode, log in and look at /sys/firmware/log. You shouldn't see more than dozen lines or so of VbAudio debug messages. Change-Id: I00465c0092d49feaa8d94aa8a13acbfa1e07743d Reviewed-on: https://gerrit.chromium.org/gerrit/14603 Commit-Ready: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
* Fix audio loop for long-delay keyboard reads.Bill Richardson2012-01-194-85/+133
| | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:7428 TEST=manual Switch to dev-mode, turn it on, see how long it takes. With gbb.flags == 1 (factory mode), it should take 2 seconds. (You'll see a warning on the screen if gbb.flags is nonzero) With gbb.flags == 0 (after factory install), it should take 30 seconds. You should hear two beeps at 20 seconds. Change-Id: I4f14128b87d3482e291b1b40a11a6d27c72c1ad1 Reviewed-on: https://gerrit.chromium.org/gerrit/14534 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Add a failure check to ReadFdtBlock in ReadFdtPlatformFamilyBernie Thompson2012-01-191-1/+2
| | | | | | | | | | | | | | | | This adds in logic to check that ReadFdtBlock within ReadFdtPlatformFamily succeeded, returning NULL on failure. BUG=None TEST=Manual, run crossystem on an ARM system without a valid compatible FDT entry and ensure (error) is returned for platform_family. Change-Id: I6351292ff73e4bc08b028f85e72ccfe62159194a Reviewed-on: https://gerrit.chromium.org/gerrit/14321 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
* Acknowledge Ctrl+U fasterVincent Palatin2012-01-181-12/+18
| | | | | | | | | | | | | | | | | | When the user hits Ctrl+U on the dev screen, we used to change the screen only after we enumerate the USB devices, load the kernel from USB mass storage and boot it (about 4 seconds on the current firmware). Let's blank the screen earlier to show we got the key press. BUG=chrome-os-partner:7563 TEST=on a Stumpy in developer, hit Ctrl+U on the dev screen with an invalid key, then a valid key. Check which screen are displayed and how long it takes to get a new display after the key strokes. Change-Id: Ifc73b56055bcd50360d71c1cb6dee052d0fdf9aa Reviewed-on: https://gerrit.chromium.org/gerrit/14395 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Vincent Palatin <vpalatin@chromium.org> Tested-by: Vincent Palatin <vpalatin@chromium.org>
* Allow crossystem ReadFdtBlock() to use a direct path starting with '/'Bernie Thompson2012-01-181-4/+8
| | | | | | | | | | | | | | | | | This extends the ReadFdtBlock function for ARM to allow for a direct path to a FDT entry by starting the property with a '/'. This allows the ReadFdtPlatformFamily function to use a direct path instead of stepping back through folders, and will enable future crossystem entries to do the same. BUG=chromium-os:24669 TEST=Manual Change-Id: Ibddb881815947259c2532d7f5474eda5fdc9f803 Reviewed-on: https://gerrit.chromium.org/gerrit/14305 Reviewed-by: Olof Johansson <olofj@chromium.org> Reviewed-by: Bernie Thompson <bhthompson@chromium.org> Tested-by: Bernie Thompson <bhthompson@chromium.org> Commit-Ready: Bernie Thompson <bhthompson@chromium.org>
* Clean up return codes for better interaction with U-Boot.Bill Richardson2012-01-172-5/+7
| | | | | | | | | | | BUG=none TEST=none Change-Id: I432de92e00444b58c20faadf8671ccc1c0056e28 Reviewed-on: https://gerrit.chromium.org/gerrit/14181 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Bill Richardson <wfrichar@chromium.org>
* Fix compile by eliminating unused variableSonny Rao2012-01-091-1/+0
| | | | | | | | | | | | | | bug was introduced in https://gerrit.chromium.org/gerrit/#change,13891 946370d012a809bba833ff9d37fe0ce86af09860 BUG=none TEST=package compiles again Change-Id: Iaa1d4479b713b379955073eff02599c26b4b5bc4 Reviewed-on: https://gerrit.chromium.org/gerrit/13922 Tested-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Gabe Black (Do Not Use) <gabeblack@google.com>
* Add in a platform_family value to crossystemBernie Thompson2012-01-093-0/+107
| | | | | | | | | | | | | | | | | | | | | | This implements a platform_family value within the crossystem utility, as the platform (particularly for ARM) is not easily accessable elsewhere at runtime. For the ARM side this contains a table which is used to determine the platform family based on the /proc/device-tree/compatible entry. Similarly on x86 the table is used to check against PCI entries. Additional entries can be made as new platform families emerge. BUG=chromium-os:24669 TEST=Manual, verified that crossystem runs properly and returns a valid platform_family value on various platforms (mario, alex, z600, x220, etc). Change-Id: Id0e973902d27ead471c1243bcc6c3292acc8479d Reviewed-on: https://gerrit.chromium.org/gerrit/13520 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Olof Johansson <olofj@chromium.org> Reviewed-by: Olof Johansson <olofj@chromium.org> Tested-by: Olof Johansson <olofj@chromium.org>
* tpmc: add PCR reading functionKees Cook2012-01-096-0/+68
| | | | | | | | | | | | | | | Add ability to report a single PCR value via the tpmc utility. Using /sys/devices/platform/tpm_tis/pcrs is too slow, since it reads all PCRs before returning. Anything wanting to read PCR0 on a time-critical path needs maximum speed. BUG=chromium-os:22172 TEST=install and test x86-alex. Change-Id: I2d450961d33fa314d54b909135a74aa756279ec6 Signed-off-by: Kees Cook <keescook@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/13891 Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
* Enhance vbutil_what_keys to work on BIOS images too.Bill Richardson2011-12-161-26/+85
| | | | | | | | | | BUG=none TEST=none Change-Id: I3bc15e18dcb9f89346815615be48729b8966736c Reviewed-on: https://gerrit.chromium.org/gerrit/13014 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* signer: run kernel security test of kernel partition 4 instead of partition 2Gaurav Shah2011-12-151-1/+5
| | | | | | | | | | | | | | | | The test is run on a recovery image by the signer. We care more about the parameters on the kernel partition 4 (the SSD install kernel) than 2. It'd be nice to have security test on the recovery kernel too and I have marked that as a TODO for now. BUG=chromium-os:24077 TEST=tested on a R17 and R18 mario, alex and zgb image. Change-Id: Ia27ceaefb24dff64115f08b1cc6bbb75d1900071 Reviewed-on: https://gerrit.chromium.org/gerrit/12970 Reviewed-by: Jim Hebert <jimhebert@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org>
* signing script: Check for errors on extracted dm params in kernel command line.Gaurav Shah2011-12-132-34/+68
| | | | | | | | | | | | | | | | | | | | | | | | | Correctly handle the lack of valid dm config parameters in the kernel command line (dm="..."). In particular, skip trying to perform a rootfs hash update for that kernel partition. This change has the side effect of properly signing new recovery images with the in-flight changes recovery install changes being done as part of crosbug.com/22530. Also fix verification of recovery images to consider both kernel partitions for determing the hash to compare the calculated value against. Finally, remove dd's verbose output while signing the firmware. BUG=chromium-os:22530 TEST=manually re-signed new (Alex) and old (Lumpy) recovery image. Verified that recovery install works. Change-Id: Ied9f82f2e77ed581875cec0b43ce45fd98186db2 Reviewed-on: https://gerrit.chromium.org/gerrit/12588 Tested-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Will Drewry <wad@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
* sign_official_build: Do not ignore the firmware version while re-signing ↵Gaurav Shah2011-12-062-7/+7
| | | | | | | | | | | | | | | | | | | | firmware Change https://gerrit.chromium.org/gerrit/12471 introduced a regression where by we always sign a firmware with version 1. This change fixes that bug. BUG=chromium-os:23817 TEST=ran sign_official_build and made sure the firmware was signed with the right firmware version. Change-Id: I6c8d3e8b103f3f7329b7a4db5a78a8f1ce4415a2 Reviewed-on: https://gerrit.chromium.org/gerrit/12496 Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* sign_official_build: Use sign_firmware.sh for in-place firmware signing.release-R17-1412.BGaurav Shah2011-12-051-23/+9
| | | | | | | | | | | | | | | | | | | | | We recently fixed a bug in the sign_firmware.sh script to perform root key replacement after signing FWA and FWB to allow resign_firmwarefd.sh to correctly determine the preamble flag to use. As it turns out, the sign_official_build.sh script used by the signer for in-place firmware re-signing was using a different code path (by directly calling resign_firmwarefd.sh). This change makes sign_official_build script call sign_firmware.sh instead. BUG=chrome-os-partner:6874 TEST=tried signing a vanilla lumpy image with and without the fix, and observed the value of preamble flag used. Change-Id: Icffb1d86fbe44f69e444da51fe251ad3427635c6 Reviewed-on: https://gerrit.chromium.org/gerrit/12471 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org>
* vboot_reference: sanity check firmware A/B content when resigningHung-Te Lin2011-12-051-14/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | If the FW_A and FW_B contents are the same, we should not resign with DEV/NORM keyblocks. BUG=chrome-os-partner:6942 TEST=(to sign) ./resign_firmwarefd.sh bios.bin new.bin \ ../../tests/devkeys/firmware_data_key.vbprivk ../../tests/devkeys/firmware.keyblock \ ../../tests/devkeys/dev_firmware_data_key.vbprivk \ ../../tests/devkeys/dev_firmware.keyblock \ ../../tests/devkeys/kernel_subkey.vbpubk (to verify) dump_fmap -x new.bin vbutil_keyblock --unpack VBLOCK_A | grep Flags vbutil_keyblock --unpack VBLOCK_B | grep Flags When the input (bios.bin) have DEV FW (ex, zgb/alex), then output is A=6, B=7; when the input is old or new firmware without DEV (ex, mario/s*y/l*y), output is A=7, B=7, and you'lll see "Found firmware with same A/B content - ignore DEV keyblock." meessage during resign process. Change-Id: I10cbbf7370f35a40673b328b70c83e7d1213a45d Reviewed-on: https://gerrit.chromium.org/gerrit/12371 Commit-Ready: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org>
* ONLY pressing the recovery button okays booting from USBBill Richardson2011-11-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:1113 TEST=manual With the dev-switch OFF, insert a bootable USB drive, reboot while holding down recovery button. It should boot from the USB without prompting for removal. With the dev-switch OFF and the same bootable USB drive inserted, run crossystem recovery_request=2 reboot The BIOS screen should prompt you to remove the USB drive, then to insert it before it will boot from the USB. Prior to this fix, using recovery_request=2 would NOT require removal, while other non-zero values would. NO values of recovery_request should be able to override the removal request. Only physically pressing the button should allow booting immediately from recovery mode with the dev-switch OFF. Change-Id: I6d63ecb761c4b26820091cc7a97ca540b362c22e Reviewed-on: https://gerrit.chromium.org/gerrit/12143 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Allow caller to specify build output directorySimon Glass2011-11-231-2/+8
| | | | | | | | | | | | | | | | | This changes the Makefile to set the BUILD directory only if the caller does not specify it. This allows U-Boot to build vboot reference and put the resulting binaries into its own output directory. BUG=chromium-os:16808 TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario Change-Id: I6b0bba47e397f86a130e67c4e18fbcf5fffdfd68 Reviewed-on: https://gerrit.chromium.org/gerrit/11638 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Fix crossystem on amd64 boardsSonny Rao2011-11-231-57/+1
| | | | | | | | | | | | | | | | | Since x86 and amd64 boards use the same firmware and are otherwise identical use the same implementation for crossystem on both BUG=chromium-os:21386 TEST=emerge-x86-generic ; test crossystem works on Samsung Series 5 TEST=emerge-amd64-generic ; test crossystem works on Samsung Series 5 TEST=run unit tests on build machine with: RUNTESTS=1 make Change-Id: Ica516cca7ead6cb9cdfae0894bd532669ba3ba88 Reviewed-on: https://gerrit.chromium.org/gerrit/12059 Tested-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
* Make dev firmware keyblock/data key generation and use optionalGaurav Shah2011-11-222-3/+22
| | | | | | | | | | | | | | | | | | For key generation, only generate dev firmware keyblocks, if the --devkeyblock option is passed. For signing, re-use normal firmware keyblock and data key if no dev keyblocks or data key are found in the keyset directory. BUG=chrome-os-partner:6942 TEST=manual - tested key generation with/without the new flag - tested signing with or without the presence of dev keyblock Change-Id: Ic4bf72cb194461e07fcc0f6de39d4e16d1c979a6 Reviewed-on: https://gerrit.chromium.org/gerrit/12038 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
* Revert "Revert "Add x86_64 architecture support""Simon Glass2011-11-222-0/+50
| | | | | | | | | | This reverts commit 354630570900cd5c2180610acfa47422ff484fe6 Change-Id: I832a675911f66837f31ea47d19babf5c656bfaf9 Reviewed-on: https://gerrit.chromium.org/gerrit/12044 Commit-Ready: Simon Glass <sjg@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Dev-mode allows booting self-signed kernels by default.Bill Richardson2011-11-189-28/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | When you enter dev-mode, Pressing Ctrl-U to boot from USB is DISABLED. Booting any self-signed kernel from the SSD is ENABLED. This replaces the "crossystem dev_boot_custom" argument with "crossystem dev_boot_signed_only", which has the opposite polarity. So if you want to dev-mode to only boot official kernels, you have to explictly set it that way. If you leave dev-mode and then come back, it will go back to the conditions shown above. BUG=chrome-os-partner:5954 TEST=manual Just run the factory flow. It was broken; this should fix it (except for any workarounds that were added while it was broken; those may need to be reverted). Change-Id: I13e0edbc0e77c5d6ea609dabf771085006cd1805 Reviewed-on: https://gerrit.chromium.org/gerrit/11853 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "Revert "Revert "Revert "Break out common compile flags""""Simon Glass2011-11-171-22/+28
| | | | | | | | | | This reverts commit 9d7d7c653bfac91180ec6e4a8047be8dc2e73448 Change-Id: Id4357ee6f22666b47734a8f754da67317265d348 Reviewed-on: https://gerrit.chromium.org/gerrit/11809 Tested-by: Simon Glass <sjg@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org>
* Pressing the recovery button okays booting from USBBill Richardson2011-11-161-2/+4
| | | | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:1113 TEST=manual With the dev-switch OFF, insert a bootable USB drive, reboot while holding down recovery button. It should boot from the USB without prompting for removal. With the dev-switch OFF and the same bootable USB drive inserted, run crossystem recovery_request=1 reboot The BIOS screen should prompt you to remove the USB drive, then to insert it before it will boot from the USB. Change-Id: Ie2fe4302443e14b1f85f409b54aa43a94d6c5477 Reviewed-on: https://gerrit.chromium.org/gerrit/11788 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Revert "Revert "Revert "Break out common compile flags"""David Hendricks2011-11-161-28/+22
| | | | | | | | | | | reverted again (due to build breakage on ARM) This reverts commit 00e7bb9dd02287db868bc291e25d27066fc486da Change-Id: I9d7d7c653bfac91180ec6e4a8047be8dc2e73448 Reviewed-on: https://gerrit.chromium.org/gerrit/11789 Reviewed-by: David Hendricks <dhendrix@chromium.org> Tested-by: David Hendricks <dhendrix@chromium.org>
* Revert "Revert "Break out common compile flags""Simon Glass2011-11-161-22/+28
| | | | | | | | | | This reverts commit 45e1067502da0c3cbf77d8b6aafc9d17b461cea3 Change-Id: I00e7bb9dd02287db868bc291e25d27066fc486da Reviewed-on: https://gerrit.chromium.org/gerrit/11746 Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Replace root and recovery keys in the GBB after firmware sections have been ↵Gaurav Shah2011-11-161-7/+11
| | | | | | | | | | | | | | | | | re-signed resign_firmwarefd.sh needs a verifiable copy of the firmware (and associated root key) to determine the preamble flag value to use. BUG=chrome-os-partner:6874 TEST=manually tested resigning a firmware .bin using sign_firmware.sh. Verified correct preamble flag determination. Change-Id: Ifb132f54f4891dec4fa7250d3a00e7b4feda24c1 Reviewed-on: https://gerrit.chromium.org/gerrit/11776 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org>
* Add VB_INIT_OUT_ENABLE_ALTERNATE_OS flagBill Richardson2011-11-164-9/+22
| | | | | | | | | | | | | | | | | | | This adds a flag to the list of values returned by VbInit(). When this flag is set, the BIOS may be asked to boot something other than ChromeOS. If this requires some sort of special preparation, the BIOS should do it. BUG=chromium-os:22454 TEST=none There is no test for this. It requires a change to the BIOS in order to do anything differently, and we haven't yet decided whether the BIOS should pay attention to it. Change-Id: I5d89e7cd5b745ee74b8ace7fa613c0db03eebefd Reviewed-on: https://gerrit.chromium.org/gerrit/11714 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot_reference: fix CMOS writing for x86 platformsHung-Te Lin2011-11-161-10/+9
| | | | | | | | | | | | | | | | VbCmosWrite should seek to correct offset before starting to write; also fixed file handle leakage. BUG=chromium-os:23000 TEST=crossystem recovery_request=1; echo $? # show: 0 crossystem recovery_request # show: 1 reboot # see recovery screen Change-Id: I33bca8af2b351ba9b364309838df699a31bb543a Reviewed-on: https://gerrit.chromium.org/gerrit/11756 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Gabe Black <gabeblack@chromium.org> Commit-Ready: Hung-Te Lin <hungte@chromium.org>
* Fix typo, add one VBDEBUG.Bill Richardson2011-11-142-1/+2
| | | | | | | | | | BUG=none TEST=none Change-Id: Ie82c5eb3052c84272da4bf21d80cc2bf204fd08d Reviewed-on: https://gerrit.chromium.org/gerrit/11670 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Revert "Break out common compile flags"Nick Sanders2011-11-141-28/+22
| | | | | | | | | | | | | | This reverts commit 5ca219f8d6eb854d95c5d811a4cfdeff2d8405b4 Mysterious ARM PFQ breakage Change-Id: I45e1067502da0c3cbf77d8b6aafc9d17b461cea3 Reviewed-on: https://gerrit.chromium.org/gerrit/11663 Commit-Ready: Don Garrett <dgarrett@chromium.org> Reviewed-by: Don Garrett <dgarrett@chromium.org> Tested-by: Don Garrett <dgarrett@chromium.org> Reviewed-by: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org>
* Revert "Add x86_64 architecture support"Nick Sanders2011-11-142-50/+0
| | | | | | | | | | | This reverts commit fbf9de6b2ba3162a7183211872bd23ca52f58289 Mysterious ARM PFQ breakage Change-Id: I354630570900cd5c2180610acfa47422ff484fe6 Reviewed-on: https://gerrit.chromium.org/gerrit/11664 Reviewed-by: Nick Sanders <nsanders@chromium.org> Tested-by: Nick Sanders <nsanders@chromium.org>
* Add x86_64 architecture supportSimon Glass2011-11-142-0/+50
| | | | | | | | | | | | This is required for U-Boot's sandbox test system. BUG=chromium-os:16808 TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario Change-Id: I18b48b069dc56f9b2c826de99780dfff1e544ded Reviewed-on: https://gerrit.chromium.org/gerrit/5980 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Break out common compile flagsSimon Glass2011-11-141-22/+28
| | | | | | | | | | | | | Many of the compile flags are common between archs, so this makes that more obvious. BUG=chromium-os:16808 TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario Change-Id: I62bfbaadac392e3dd03d6997f24055fafac162af Reviewed-on: https://gerrit.chromium.org/gerrit/11549 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Add a few comments and warnings when building incorrectlySimon Glass2011-11-142-0/+7
| | | | | | | | | | | | | The Makefile requires a few defines and isn't very friendly if they are missing. This adds some warnings which should alert as to what is wrong. BUG=chromium-os:16808 TEST=emerge vboot_reference-firmware for tegra2-seaboard, x86-mario Change-Id: Id3b20365cfcc7f0aa7d984b33b6a0906ae0d44a5 Reviewed-on: https://gerrit.chromium.org/gerrit/11548 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org>
* Address security concerns for vboot_audio.cBill Richardson2011-11-141-2/+25
| | | | | | | | | | | | | Based on the compile-time constants, I don't think we were in any danger, but I've added the checks anyway. It never hurts to be certain! BUG=chromium-os:22786 TEST=none Change-Id: I469dda19b4589e484a41ca9bae1e107787f3cf4d Reviewed-on: https://gerrit.chromium.org/gerrit/11516 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
* Sanity-check output of VbExDiskGetInfo()Bill Richardson2011-11-141-0/+9
| | | | | | | | | | | | BUG=chromium-os:22724 TEST=none Source change only, nothing for QA to test. Change-Id: I058137c04622b5aedae4a94ce6e3887325c16974 Reviewed-on: https://gerrit.chromium.org/gerrit/11546 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org>
* Wrap CMOS read/write functions so they automatically pacify the nvram driver.Gabe Black2011-11-111-44/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A legacy checksum in CMOS is not maintained by coreboot and may be invalid. If the Linux kernel driver sees that the checksum is wrong, it will return EIO when read from or written to. That makes crossystem return an error since it can't read the CMOS, and it also prevents it from changing some settings. One way to fix the problem would be to remove the checksum check in the kernel driver. This would change the semantics of the driver so that either x86 was inconsistent with the other architectures, or change the semantics of those other architectures as well. Another option would be to fix the checksum during manufacturing since nothing should be changing those particular bytes of CMOS. The problem with this approach is that something might corrupt the CMOS after manufacturing, and we'd have the same problem again. Yet another solution would be to make the firmware, most likely coreboot, actually keep the checksum up to date. This seems like an awful waste of boot time, the bytes protected by the checksum aren't actually used by anything, and the bytes of the CMOS that are used are protected by vboot using its own checksum. The solution implemented here is to make crossystem recognize when the driver has determined that the checksum is invalid and make it call an ioctl that gets the driver to fix the checksum. Wrapper functions for fread, fwrite, fgetc, and fputc are implemented which first attempt to read or write, on failure check for the EIO error code, and if they find it to call the appropriate ioctl and attempt the access again. This way, we won't take any extra time to talk to the CMOS when everything is working properly, and when there's a problem it gets fixed up transparently. One problem with this approach is that using the /dev/nvram device file will still fail until crossystem is run at least once and given a chance to fix the checksum. BUG=chrome-os-partner:6718 TEST=For version 1, verified that crossystem reported an error on Sameer's Lumpy. Used strace to verify that crossystem received an EIO error when trying to read or write /dev/nvram. Built a new image with this change and booted it using a USB stick. Ran crossystem and verified that crossystem no longer reported an error. Rebooted into the original image and verified that crossystem worked there as well, indicating that the persistent problem in the CMOS had been corrected. For version 2, the same as version 1 except that I used a custom version of u-boot to purposefully corrupt the CMOS rather than using Sameer's Lumpy. Change-Id: I929535bd2a7d666e41a707b6b24c3f0b0df1147f Signed-off-by: Gabe Black <gabeblack@google.com> Reviewed-on: https://gerrit.chromium.org/gerrit/11373 Tested-by: Gabe Black <gabeblack@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add flag to GBB to allow loading PCI Option ROMsBill Richardson2011-11-114-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As shipped, H2C only loads the option ROM for the built-in video, and that only when it needs display the BIOS warning screens. By setting a flag in the GBB, you can allow all option ROMs to be loaded: Note that we'll never enable this ourselves (and there's a factory test to ensure that*) because it executes non-verified code. But if a customer wants to void their warranty and set this flag in the read-only flash so they can install and use other PCI devices, they should be able to do so. BUG=chrome-os-partner:6148 TEST=none The only way to test this is to use a BIOS that was compiled with serial debugging enabled, so there's nothing for QA to do. If you have such a BIOS, you can see the difference like so: flashrom -r oldbios.bin gbb_utility -s --flags=2 oldbios.bin newbios.bin flashrom -w newbios.bin <reboot> When bit 1 of the GBB flags is 0, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success When bit 1 of the GBB flags is 1, you'll see these lines in the serial output: LoadOpRomImage-->GetSystemConfigurationTable Status = Success LoadOpRomImage-->GetH2cBootMode Status = Success LoadOpRomImage-->PCI OpRom on 1.0.0 is allowed!!! This happens in any boot mode (normal, developer, recovery). -- *The factory test for GBB zero flags is gft_clear_gbb_flags.sh, in src/platform/factory_test_tools Change-Id: I31a10cc9d562b4b83669ca8a114b60e87ae28b0a Reviewed-on: https://gerrit.chromium.org/gerrit/11505 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Dev-mode only boots official kernels by defaultBill Richardson2011-11-109-8/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Although we're now using a single unified BIOS, it is pretty nice to be able to get a shell in developer mode while still using verified boot for the kernel and filesystem. Alex & ZGB implemented this by requiring the dev-mode user to install a special dev-mode BIOS. We don't do that, but we DO require setting a special flag with "crossystem" to accomplish the same thing. In order to allow booting a self-signed kernel, you must boot in developer mode, open a shell, and run this: crossystem dev_boot_custom=1 Special note to internal developers: If you're in the habit (as I am) of booting directly from a USB stick in dev-mode, you'll have to run this: crossystem dev_boot_custom=1 dev_boot_usb=1 Just using dev_boot_usb=1 is no longer enough, because the USB kernel is signed using the recovery key and by pressing Ctrl-U, we validate it with the kernel data key. That worked before this change because any self-signed kernel was fine, and that's how the USB key was treated. Now it actually requires a verified signature until you enable dev_boot_custom=1 also. BUG=chrome-os-partner:5954 TEST=manual Boot once in normal mode, which clears the special flags. Then switch to developer mode. You should be able to boot and get a root shell. Run crossystem dev_boot_usb=1 Obtain a USB recovery image that's keyed differently. For example, if you're testing with dev-keys, use a PVT-signed image or vice-versa. Reboot into dev-mode with the USB recovery stick inserted. At the dev-mode screen, press Ctrl-U. You should hear a single beep, but it should not boot. Press Ctrl-D to boot from the hard drive, log in to a shell and run crossystem dev_boot_custom=1 Repeat the previous test. This time when you press Ctrl-U, it should boot the recovery image. Turn the system off before it does anything. That's it. Change-Id: I1811ee9a188974b3f94c83c52b00b60028b86c69 Reviewed-on: https://gerrit.chromium.org/gerrit/11442 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* New and improved dev_debug_vbootBill Richardson2011-11-091-131/+270
| | | | | | | | | | | | | | | | | | | | | | | This new version adds a bunch more output, displays the TPM rollback version values (if it can; Cr-48 doesn't export this info through crossystem), looks for and validates all kernels on all devices, etc. It also add some command-line arguments to use to examine files containing BIOS, kernel, and disk images. BUG=chromium-os:6676 TEST=manual Boot, wait a minute or so, then log in and go to chrome://system Click the Expand button for "verified boot". You should see a bunch of useful text describing the firmware and kernel partitions. I tried this on Cr-48, Stumpy, and Kaen. Change-Id: I2d9aa0fcb0c12cf2b951ce9e2316b89532901125 Reviewed-on: https://gerrit.chromium.org/gerrit/11327 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Use the correct fonts for BIOS screens.Bill Richardson2011-11-02223-73/+115
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | We should have been using Droid Sans, not Helvetica, and some of the non-Roman locales need special handling to render clearly and correctly. We also get better results if we avoid scaling after rendering the text. Added scripts/newbitmaps/Makefile to regenerate it all, updated the READMEs. Since Hung-Te figured out how to use pango-view to render the UTF-8 reliably, we don't need to keep all the pre-rendered locale images anymore either. This provides the x86 bmpblock for Stumpy PVT. We may need some more tweaking for Lumpy and/or ARM. BUG=chrome-os-partner:6595 TEST=manual Put the new screens into the bios: gbb_utility -s --flags=0 -b bmpblock_x86.bin OLDBIOS NEWBIOS flashrom -w NEWBIOS Then reboot and look at the BIOS screens. The lettering is much clearer. Change-Id: Icb07bc6d131920730f41348c7de9151e42cc9518 Reviewed-on: https://gerrit.chromium.org/gerrit/11007 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Fix the tree for tangentStefan Reinauer2011-11-021-0/+2
| | | | | | | | | | | | | | u-boot got too big on ARM, so don't unroll the loops there. BUG=none TEST=none Change-Id: I426621e147bef7cff1285b0ce063123fbeea751b Reviewed-on: https://gerrit.chromium.org/gerrit/11078 Reviewed-by: Vince Laviano <vlaviano@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jon Kliegman <kliegs@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* vboot_reference: clean up CFLAGS and enable unrolled loopsStefan Reinauer2011-11-022-6/+10
| | | | | | | | | | | | | | | | | | - loop unrolling has a positive effect on execution speed. - This change also drops the -march=i386 and thus allows the compiler to use SSE instructions. - A few duplicate options are dropped from CFLAGS. - drop -fno-toplevel-reordering. This sneaked in from u-boot where it might be needed by some drivers. With this change I just successfully booted my Stumpy in 833ms BUG=chrome-os-partner:4675 TEST=boot tested on stumpy Change-Id: I805cbcaec48b4f8d1d8fa7d7bed9241178f59a8e Reviewed-on: https://gerrit.chromium.org/gerrit/11061 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
View Lorry Controller Status