summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* 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>
* 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>
* Finally final results from l10n team.Bill Richardson2011-10-07423-756/+826
| | | | | | | | | | | | | | | | | | | | | | | | | | | | * Updated the text strings using the latest results from the localization experts. * Strip the leading byte-order-mark and trailing whitespace from the text files, since it's not used for anything and sometimes renders as a box. * Added options to the text_to_bmp script to handle right-to-left languages and to override the font. * Added scripts/newbitmaps/strings/localized_text/Makefile to regenerate all the bitmaps from the text strings. This handles right-to-left languages correctly. * Modified make_default_yaml so that the th/model.txt string is moved up a bit to align it properly with the HWID. * Regenerated DEFAULT.yaml using the new bitmaps. BUG=chromium-os:13037 TEST=none Change-Id: I095830a46ba831742d437867a9caac88c8e28de1 Reviewed-on: http://gerrit.chromium.org/gerrit/8834 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Hung-Te Lin <hungte@chromium.org>
* Enable (and test) custom dev-mode soundsBill Richardson2011-10-058-62/+461
| | | | | | | | | | | | | | BUG=none TEST=manual cd src/platform/vboot_reference make && make runtests Change-Id: I7f7d50d7c9c5541e0b99031245f882996a6b88ec Reviewed-on: http://gerrit.chromium.org/gerrit/8731 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Refactor dev-mode delay handling into a separate file.Bill Richardson2011-10-056-108/+189
| | | | | | | | | | | | | | BUG=none TEST=manual cd src/platform/vboot_reference make && make runtests Change-Id: I56feceb7d4fce80e4f50d5d7875eafef325363cc Reviewed-on: http://gerrit.chromium.org/gerrit/8659 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Added tests for VbBootDeveloper sound and delayBill Richardson2011-10-052-2/+343
| | | | | | | | | | | | | | BUG=none TEST=manual cd src/platform/vboot_reference make && make runtests Change-Id: I2c4084afa883f7e4cdc758ff1560eec900c75c17 Reviewed-on: http://gerrit.chromium.org/gerrit/8585 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* Add more debugging info to BIOS screens.Bill Richardson2011-09-281-1/+95
| | | | | | | | | | | | | | | | | | | | This displays the gbb.flags value when being warned about it being nonzero. It also decodes the recovery_reason value into English. BUG=chromium-os:20972 TEST=manual 1. Use gbb_utility to create a BIOS with valid bitmaps, but with gbb.flags set to a non-zero value. Boot into recovery mode. You should see the warning that gbb.flags is non-zero, and the value itself. 2. Press TAB. The recovery_reason field should display not only a value, but also an English string explaining the value. Change-Id: I99b7aa35bc67453bdf3385b9573491090c3dec1d Reviewed-on: http://gerrit.chromium.org/gerrit/8459 Reviewed-by: Bill Richardson <wfrichar@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* sign_official_build: allow repacking firmware when executed by sudoHung-Te Lin2011-09-261-0/+1
| | | | | | | | | | | | | | | To prevent execution permissions lost after being copied to /tmp, force adding a+rx to the staging file. BUG=chromium-os:20797 TEST=sudo sign_official_build.sh ssd \ x86-zgb-0.16.1089.0.bin ../../tests/devkeys ssd_image.bin Change-Id: Ibee12dbb3faea9f6b05600d1343620e0af8633fb Reviewed-on: http://gerrit.chromium.org/gerrit/8263 Tested-by: Hung-Te Lin <hungte@chromium.org> Reviewed-by: Gaurav Shah <gauravsh@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org>
* Make startup delay and noises simpler to change.Bill Richardson2011-09-262-26/+110
| | | | | | | | | | | | | BUG=none TEST=manual Booted in dev-mode. All noises and delays are unchanged (2 second delay when gbb.flags is 1, 30-second with beeps at 20 seconds when gbb.flags is 0). Change-Id: I816e57c4f8f6025299851b3d42b4a350f9925994 Reviewed-on: http://gerrit.chromium.org/gerrit/8240 Reviewed-by: Randall Spangler <rspangler@chromium.org> Tested-by: Bill Richardson <wfrichar@chromium.org>
* VbExBeep() now returns VbError_t instead of voidBill Richardson2011-09-233-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This enables us to support playing sounds in the background if the BIOS allows it, so we don't have to block while beeping is happening. The new declaration is: VbError_t VbExBeep(uint32_t msec, uint32_t frequency); If the audio codec can run in the background, then: zero frequency means OFF, non-zero frequency means ON zero msec means return immediately, non-zero msec means delay (and then OFF if needed) else: non-zero msec and non-zero frequency means ON, delay, OFF, return zero msec or zero frequency means do nothing and return immediately The return value is used by the caller to determine the capabilities. The implementation should always do the best it can if it cannot fully support all features - for example, beeping at a fixed frequency if frequency support is not available. At a minimum, it must delay for the specified non-zero duration. Currently, VbExBeep() is called only when displaying the dev-mode screen. BUG=none TEST=manual I've tested on x86 and ARM, all timeouts and noises work as before. Note that ARM and coreboot will require a corresponding change to their VbExBeep() implementations, which will have to be handled with separate, simultaneous CLs. Change-Id: I3417ae4b99d9d0aee63f2ccaeed39b61d4333e5d Reviewed-on: http://gerrit.chromium.org/gerrit/8234 Tested-by: Bill Richardson <wfrichar@chromium.org> Reviewed-by: Stefan Reinauer <reinauer@google.com>
* sign_official_build: Work around different verity arguments across imagesGaurav Shah2011-09-231-3/+14
| | | | | | | | | | | | | | | | | | | | | Work around the fact that we have 3 different verity kernel arguments depending on the image being signed (legacy parameters, new key=value parameters, new key= value parameters with salt). Since the signer is not branch conscious, expect and use the old verity binary to be present when legacy kernel arguments are specified. The last 2 types of verity arguments can be distinguished based on whether a salt is present. BUG=chromium-os:20640 TEST=manually tested by signing r14, r15 and r16 images and verifying that kernel parameters are set correctly. Change-Id: I96ecf6f506a94509a64ef12d7a108e977f94c23c Reviewed-on: http://gerrit.chromium.org/gerrit/8214 Commit-Ready: Gaurav Shah <gauravsh@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org> Reviewed-by: David McMahon <djmm@chromium.org> Tested-by: David McMahon <djmm@chromium.org>
* image security test: Allow alternatives for verity parametersGaurav Shah2011-09-212-15/+36
| | | | | | | | | | | | | | | | | | This is again working around the fact that the signer isn't branch conscious. Depending on which branch you look at, there are 3 possible verity parameter styles in use. This CL allows the kernel parameter test to allow multiple alternatives for verity dm= parameters. BUG=chromium-os:20640 TEST=manually tried with a R16, R15 and R14 image Change-Id: I07554594d6adbdfd1988395d3e91edfd603d8cd4 Reviewed-on: http://gerrit.chromium.org/gerrit/8067 Reviewed-by: Jim Hebert <jimhebert@chromium.org> Commit-Ready: Gaurav Shah <gauravsh@chromium.org> Tested-by: Gaurav Shah <gauravsh@chromium.org>
View Lorry Controller Status