summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Add new line after printing non-zero GBB flags.firmware-uboot_v2-1299.BStefan Reinauer2012-02-281-0/+1
| | | | | | | | | | | | | | | | | | | | | | Callers of vboot might print some additional information in VbExDisplayDebugInfo(). Add a new line to the end of the buffer so that output is aligned with the normal <tab> information. BUG=none TEST=set gbb flags to 1, see cursor go to next line at dev screen. Reviewed-on: https://gerrit.chromium.org/gerrit/17001 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 5ee257d94cb8aab2f3717c5cd4ceb37fbba3ec41) Change-Id: I49aa04900ac34d76213a49d00b97f13ad22f5d58 Reviewed-on: https://gerrit.chromium.org/gerrit/17008 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Revert "Add Ctrl-Enter as an additional key to trigger dev USB boot."Duncan Laurie2012-02-162-4/+1
| | | | | | | | | | | This reverts commit eda04e8c0df44ebb1ed84b1f767f518af97bcdf8. BUG=chrome-os-partner:8075 Change-Id: I8c6bb237cfa6d087ab4774b41873fd8c87ad0f61 Reviewed-on: https://gerrit.chromium.org/gerrit/16081 Tested-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Ronald G. Minnich <rminnich@chromium.org>
* Add Ctrl-Enter as an additional key to trigger dev USB boot.Tom Wai-Hong Tam2012-02-152-1/+4
| | | | | | | | | | | | | | | | | | | | | | | Due to the limitation of servo that is unable to send U keys, dev USB boot (triggered by Ctrl-U) is unable to be tested on FAFT. To solve it, firmware should add an addition key combination to workaround it. Ctrl-Enter is the one we picked. BUG=chrome-os-partner:6759 TEST=compile the firmware and update it to Lumpy; during the dev screen, press Ctrl-Enter to trigger USB boot. Reviewed-on: https://gerrit.chromium.org/gerrit/15749 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> (cherry picked from commit 2ddd5f64515b4be9847a16de793c59b161221e1b) Change-Id: Ib10e29864c95c8a6fb417d5530bcea599699357f Reviewed-on: https://gerrit.chromium.org/gerrit/15917 Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Bah. Fix the test, too.Bill Richardson2012-01-271-1/+1
| | | | | | | | | | | | | | | | BUG=chrome-os-partner:7775 TEST=none Reviewed-on: https://gerrit.chromium.org/gerrit/14968 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit ee2e590ff0db1f0a0c5f6a8122d7c090ea833924) Change-Id: Ic5eeac0f215cc6ec72f61dcf1802a068aea8ef82 Reviewed-on: https://gerrit.chromium.org/gerrit/14969 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@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. 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> (cherry picked from commit cbfc6dbd231828b0327583447f5192334ebd4101) Change-Id: I0432229673cd11a7eb247892c213c1acb0fe6e64 Reviewed-on: https://gerrit.chromium.org/gerrit/14965 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@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 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> (cherry picked from commit bf020a0d4db68897058503767067567565450dde) Change-Id: Ib61c7057bf31174cf3f54825bfcf324fb2ed0020 Reviewed-on: https://gerrit.chromium.org/gerrit/14826 Reviewed-by: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@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. 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> (cherry picked from commit 5fd35971de5e9fe2a7988519dc8d13ea3af0c0c5) Change-Id: I5d4ba8e8026479305706b4f41cb97458e66d58c0 Reviewed-on: https://gerrit.chromium.org/gerrit/14742 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@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> (cherry picked from commit 506649c5cd6f7943b2e0565325b2db8346b55f47) Reviewed-on: https://gerrit.chromium.org/gerrit/14607 Tested-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. 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> (cherry picked from commit 037dba21243559e93aa98c428c0655ceb418b23f) Change-Id: I6fb6adf4e9c8a037b8aac8eeeb9dbf1943fdc730 Reviewed-on: https://gerrit.chromium.org/gerrit/14537 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@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> Reviewed-on: https://gerrit.chromium.org/gerrit/14400
* Clean up return codes for better interaction with U-Boot.Stefan Reinauer2012-01-172-5/+7
| | | | | | | | | | | | | | | | | BUG=none TEST=none 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> (cherry picked from commit 82e69b9f7494c5f939e2b546c06eeb13d68bdd03) Change-Id: I1c9dc689a287b7df3118dd0ba930edb0f1744e7c Reviewed-on: https://gerrit.chromium.org/gerrit/14298 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* signing script: Check for errors on extracted dm params in kernel command line.Gaurav Shah2012-01-052-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. 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> (cherry picked from commit ce6649250583a8f3a7aeac78ee3a00679cf6223d) Change-Id: I7c689fb32c93ae0c9f2d38ab7afddb5d86767e15 Reviewed-on: https://gerrit.chromium.org/gerrit/13729 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* vboot_reference: sanity check firmware A/B content when resigningHung-Te Lin2012-01-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. 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> (cherry picked from commit 505a047c853b87caf808a180ec2eaf1381b68279) Change-Id: I86eff2e68f6f31b0928325ab7b03fb8f57f6882f Reviewed-on: https://gerrit.chromium.org/gerrit/13728 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Make dev firmware keyblock/data key generation and use optionalGaurav Shah2012-01-052-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 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> (cherry picked from commit a24e30cdc2f81e619f2441cdf372a7b6064e1844) Change-Id: I5cd2b150d8006523d56e0858c17b8001b22d8cb7 Reviewed-on: https://gerrit.chromium.org/gerrit/13727 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* signer: run kernel security test of kernel partition 4 instead of partition 2Gaurav Shah2012-01-051-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. Reviewed-on: https://gerrit.chromium.org/gerrit/12970 Reviewed-by: Jim Hebert <jimhebert@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> (cherry picked from commit e5d31dce377ad34e2a165e6e5d98f819b20c212d) Change-Id: I937dd3c38aef307ca1d80c9d85fb647fe40512ab Reviewed-on: https://gerrit.chromium.org/gerrit/13726 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "Revert "Add x86_64 architecture support""Simon Glass2012-01-052-0/+50
| | | | | | | | | | | | | | | | | This reverts commit 354630570900cd5c2180610acfa47422ff484fe6 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> (cherry picked from commit 8e85e987739281161ece1dbc9ff2b73f3e8e1e35) Change-Id: Ifcfa1774598ed545b4276a3ed8e24d378f95bbbd Reviewed-on: https://gerrit.chromium.org/gerrit/13725 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Allow caller to specify build output directorySimon Glass2012-01-051-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 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> (cherry picked from commit 6d696e532c6a0c93ad9b915c59dad4144e6f1b33) Change-Id: Id994d6d9f7d42ebbaa6ddd55ec0715b154f52fd5 Reviewed-on: https://gerrit.chromium.org/gerrit/13724 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "Revert "Revert "Revert "Break out common compile flags""""Simon Glass2012-01-051-22/+28
| | | | | | | | | | | | | | | | | This reverts commit 9d7d7c653bfac91180ec6e4a8047be8dc2e73448 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> (cherry picked from commit b265c34321c01bd279f3a1df0a2fea3601f732ee) Change-Id: I44a17a18c079ba4f358bb112d59297ac49c4578f Reviewed-on: https://gerrit.chromium.org/gerrit/13723 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Fix crossystem on amd64 boardsSonny Rao2012-01-051-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 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> (cherry picked from commit 5fffeee4124ec2a27baace5e5b8e473a18f32f16) Change-Id: I94091731f766a7ddbc25d4aa088b18ef54a932b7 Reviewed-on: https://gerrit.chromium.org/gerrit/13722 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Add a few comments and warnings when building incorrectlySimon Glass2012-01-052-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 Reviewed-on: https://gerrit.chromium.org/gerrit/11548 Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Simon Glass <sjg@chromium.org> (cherry picked from commit c25904536f2d8e3fe37860dff0ecc437323b760e) Change-Id: I887badec4fca9780a3eff8c2b46690f5f66251c5 Reviewed-on: https://gerrit.chromium.org/gerrit/13721 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Reviewed-by: Simon Glass <sjg@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Dev-mode allows booting self-signed kernels by default.Bill Richardson2012-01-059-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). 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> (cherry picked from commit 7272a6951107251a5c9b26330c506319a92a54b3) Change-Id: Iee619265dbe6ff012277b9f8107a406e50f883a5 Reviewed-on: https://gerrit.chromium.org/gerrit/13719 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "Display debug info on all screens for testing."Stefan Reinauer2012-01-031-10/+3
| | | | | | | | | | | | No longer needed because the required USB fixes went in. This reverts commit 01efb52cf1842849d51d6ff177698e75b56ba8f6 Change-Id: If5899dde975f6a6dbe08faac0af7bbbddaf17efc Reviewed-on: https://gerrit.chromium.org/gerrit/13587 Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Display debug info on all screens for testing.Stefan Reinauer2011-12-201-3/+10
| | | | | | | | | | | | | | | THIS IS A TEMPORARY WORKAROUND TO MAKE THE RECOVERY REASON AVAILABLE ON SYSTEMS WITH NON-WORKING USB KEYBOARDS. TO BE REMOVED AS SOON AS ALL USB FIXES WENT IN. BUG=none TEST=none Change-Id: I3d8611de5ba8e9ff5765303a02caed4fd2035ff3 Reviewed-on: https://gerrit.chromium.org/gerrit/13269 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add VB_INIT_OUT_ENABLE_ALTERNATE_OS flagStefan Reinauer2011-12-204-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. Reviewed-on: https://gerrit.chromium.org/gerrit/11714 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit 0d11efb0dc1d8d2b5eafdd5b65bce82e73fdeecc) Change-Id: I9507fad6486a3304a45067d8b51a99708e15bbff Reviewed-on: https://gerrit.chromium.org/gerrit/13258 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Dev-mode only boots official kernels by defaultStefan Reinauer2011-12-209-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. Reviewed-on: https://gerrit.chromium.org/gerrit/11442 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> (cherry picked from commit fa9d7782e837848a1aeb0e95295fa48ac23f7a26) Change-Id: Ief751c0181426bf304db883abc0b2aaf030f85ef Reviewed-on: https://gerrit.chromium.org/gerrit/13257 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Fix typo, add one VBDEBUG.Stefan Reinauer2011-12-192-1/+2
| | | | | | | | | | | | | | | | BUG=none TEST=none Reviewed-on: https://gerrit.chromium.org/gerrit/11670 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> (cherry picked from commit 791d6e6d75f1d1a0fb41c3a7be27dac7df78def3) Change-Id: Ie06db4fa0135a871fc1fd9db65aca9e303b03251 Reviewed-on: https://gerrit.chromium.org/gerrit/13188 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Address security concerns for vboot_audio.cStefan Reinauer2011-12-191-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 Reviewed-on: https://gerrit.chromium.org/gerrit/11516 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> (cherry picked from commit 931728a003a417bcb29cc1c203ce36d23feee9e8) Change-Id: I1b6f3bec9e7126d546d1a0102bacab2122a6d538 Reviewed-on: https://gerrit.chromium.org/gerrit/13187 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Sanity-check output of VbExDiskGetInfo()Stefan Reinauer2011-12-191-0/+9
| | | | | | | | | | | | | | | | | | BUG=chromium-os:22724 TEST=none Source change only, nothing for QA to test. Reviewed-on: https://gerrit.chromium.org/gerrit/11546 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> (cherry picked from commit 01bf572be8a04b2c4c32b9c6118a084061b42b48) Change-Id: Id384409160e95bcc5ba251b65369a466d4fb8db0 Reviewed-on: https://gerrit.chromium.org/gerrit/13186 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add flag to GBB to allow loading PCI Option ROMsStefan Reinauer2011-12-194-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 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> (cherry picked from commit c8e4ff7c15e6bf5992a578b66bec47d69cde3bea) Change-Id: Ib72d0644cb030844e4c88d2d2708ea24e547b431 Reviewed-on: https://gerrit.chromium.org/gerrit/13185 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* ONLY pressing the recovery button okays booting from USBStefan Reinauer2011-12-120-0/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. (cherry picked from commit 759d5c4ccda67308695d09f3448e3edb1910dd53) Change-Id: Ie05c3bee611310de68ff33c0d3909e00c4455135 Reviewed-on: https://gerrit.chromium.org/gerrit/12143 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/12445 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/12797 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* ONLY pressing the recovery button okays booting from USBBill Richardson2011-12-061-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=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: I9a670e4ddf2f9691373bc0919978164d6c0e624e Reviewed-on: https://gerrit.chromium.org/gerrit/12143 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://gerrit.chromium.org/gerrit/12445 Reviewed-by: Duncan Laurie <dlaurie@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* Revert "Dev-mode only boots official kernels by default"Stefan Reinauer2011-11-179-46/+8
| | | | | | | | | | | | | | | | | This reverts commit fa9d7782e837848a1aeb0e95295fa48ac23f7a26. reverting because it breaks factory on lumpy BUG=none TEST=boot factory image from SSD Change-Id: I595cb635d84cd9cb2730c3a2f89006e1eed06fcd Reviewed-on: https://gerrit.chromium.org/gerrit/11872 Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Rajesh Chenna <rchenna@chromium.org> Tested-by: Rajesh Chenna <rchenna@chromium.org> Reviewed-by: Jay Kim <yongjaek@chromium.org>
* Replace root and recovery keys in the GBB after firmware sections have been ↵Stefan Reinauer2011-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: I898a967253f8daa54ec2bef2990624b7928dc157 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> Reviewed-on: https://gerrit.chromium.org/gerrit/11829 Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org>
* vboot_reference: fix CMOS writing for x86 platformsStefan Reinauer2011-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: Ie5cdc21acf11962dac9debd1ef26108a05181326 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> Reviewed-on: https://gerrit.chromium.org/gerrit/11828 Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
* Wrap CMOS read/write functions so they automatically pacify the nvram driver.Stefan Reinauer2011-11-161-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: I218166732060f03923b20d5849b63f60bceaea94 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> Reviewed-on: https://gerrit.chromium.org/gerrit/11827 Commit-Ready: Stefan Reinauer <reinauer@chromium.org> Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Duncan Laurie <dlaurie@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>
* Move Memset from vboot_reference to vbexport/u-bootStefan Reinauer2011-11-023-28/+6
| | | | | | | | | | | | | | | | | | All memory operations (except the "safe ones") live in the firmware so the fast operations can be used. Except Memset. This CL changes that problem. This CL needs https://gerrit.chromium.org/gerrit/#change,10992 and a similar change in H2C. BUG=chrome-os-partner:6313 TEST=run coreboot/u-boot on Stumpy Change-Id: Ic961ebbb45470c8fc1316490b902759dcf221deb Reviewed-on: https://gerrit.chromium.org/gerrit/10993 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vboot_reference: Fix typo in firmware MakefileStefan Reinauer2011-11-021-1/+1
| | | | | | | | | | | BUG=none TEST=test booting on stumpy Change-Id: Ie89704d62714d1e78603d83ce86167ce9c682cb0 Reviewed-on: https://gerrit.chromium.org/gerrit/11055 Tested-by: Stefan Reinauer <reinauer@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Despeckle background images, improve x86 generation.Bill Richardson2011-11-025-12/+19
| | | | | | | | | | | | | | | | | | | | BUG=chrome-os-partner:6595 TEST=manual User our new officially finally final localizations for Stumpy. Start by removing some of the subtle speckles from the background images so they'll compress a little better, then modify the Makefile to autogenerate the bitmap blob (for x86, anyway). Note: the size improvment isn't much, but every little bit helps. With all 43 locales, bmpblock.bin was 659798 bytes. Now it's 665142 (5344 bytes saved). And, no, we can't fit all 43 locales in our current BIOS. Yet. Change-Id: I78cf8215f3da41a7ebc0e354cd1964c427a8c651 Reviewed-on: https://gerrit.chromium.org/gerrit/10879 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Change load_shflags to use the new location of shflags for clientsSonny Rao2011-10-271-6/+4
| | | | | | | | | | | | BUG=chromium-os:21742 TEST=manual, ensure vboot scripts continue to work like make_dev_ssd.sh on the client Change-Id: I405334bab734f35a1a81e4b9e90e93cb760cc3d2 Reviewed-on: https://gerrit.chromium.org/gerrit/10479 Reviewed-by: Hung-Te Lin <hungte@chromium.org> Tested-by: Sonny Rao <sonnyrao@chromium.org> Commit-Ready: Sonny Rao <sonnyrao@chromium.org>
* Add test script that can determine if a build contains ASAN-binaries.factory-1235.BJim Hebert2011-10-191-0/+35
| | | | | | | | | | BUG=chromium-os:21863 TEST=ensure_not_ASAN.sh image.bin Change-Id: I414f941a787e0023257401bb8ed7b4a5257f026a Reviewed-on: http://gerrit.chromium.org/gerrit/10352 Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Tested-by: Jim Hebert <jimhebert@chromium.org>
* Remove -isystem from CFLAGS for firmware buildrelease-R16-1193.BChe-Liang Chiou2011-10-171-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The -isystem and the rest of the CFLAGS for firmware builds is copied from U-Boot, where U-Boot generates it on the fly, as a temporary solution before we figure out how make the CFLAGS right. Given that, the hard-coded -isystem is both incorrect (since tool chain is upgraded to a new version) and unnecessary. It is unnecessary because firmware lib is carefully written that the lib does not (and probably should not) depend on any system header. Even if in the future a system header is added to the firmware lib, because firmware build sets -nostdinc to CFLAGS, the compiler will safely report missing header instead of silently using the standard system header. So this commit removes the -isystem. BUG=chromium-os:16808 TEST=Make sure non-firmware build still works by running `emerge-{tegra2_seaboard,x86-alex} vboot_reference` TEST=Run firmware build successfully `emerge-{tegra2_seaboard,x86-alex} vboot_reference-firmware` TEST=Add #include<stdarg.h> to any header in firmware/include/ and run firmware build again and observe build fail on missing stdarg.h Change-Id: I8291390f21a975446993640d7a92a3eed4750e32 Reviewed-on: http://gerrit.chromium.org/gerrit/10072 Tested-by: Che-Liang Chiou <clchiou@chromium.org> Reviewed-by: Mike Frysinger <vapier@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* vbutil: accept amd64 as a valid alias for x86Sonny Rao2011-10-121-1/+2
| | | | | | | | | | | | | | The rest of the chromiumos build system uses amd64 as the architecture name for 64bit x86. This adds support for this name to vbutil. BUG=chromium-os:21284 TEST=vbutil --arch amd64 should not return unknown architecture Change-Id: I37531591a7a31486f6447ae611d54569d1ea59d5 Reviewed-on: http://gerrit.chromium.org/gerrit/9959 Tested-by: Sonny Rao <sonnyrao@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* new signature for optional easter egg.Bill Richardson2011-10-113-6/+3
| | | | | | | | | | BUG=none TEST=none Change-Id: I86743dbba3210858d817c8e6982f17df96920420 Reviewed-on: http://gerrit.chromium.org/gerrit/9889 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Some easter eggs may need a refresh.Bill Richardson2011-10-113-3/+5
| | | | | | | | | | BUG=none TEST=none Change-Id: I4b8cffa63dd10261e45a5ca6233b4d5cd2471f62 Reviewed-on: http://gerrit.chromium.org/gerrit/9861 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* Fix potential NULL pointer dereference in vboot_kernel.cStefan Reinauer2011-10-101-1/+4
| | | | | | | | | | | | | | | | | | In the unlikely case that params is not set or the LoadKernelParams structure is not initialized correctly, LoadKernel will exit before initializing shcall. However, in LoadKernelExit it will be used to stire the function's return code, thus potentially dereferencing a NULL pointer. BUG=chrome-os-partner:6307 TEST=compile tested. Change-Id: I691c6b5054d8f77296de86834b3125de06e0e398 Reviewed-on: http://gerrit.chromium.org/gerrit/9791 Tested-by: Stefan Reinauer <reinauer@google.com> Reviewed-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org> Commit-Ready: Stefan Reinauer <reinauer@chromium.org>
View Lorry Controller Status